From report at bugs.python.org Mon Jun 1 01:11:35 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 31 May 2015 23:11:35 +0000 Subject: [issue24323] Typo in Mutable Sequence Types documentation. In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za> Message-ID: <1433113895.64.0.419511584676.issue24323@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 01:28:11 2015 From: report at bugs.python.org (py.user) Date: Sun, 31 May 2015 23:28:11 +0000 Subject: [issue24338] In argparse adding wrong arguments makes malformed namespace In-Reply-To: <1433070096.48.0.744562806973.issue24338@psf.upfronthosting.co.za> Message-ID: <1433114891.85.0.124083182799.issue24338@psf.upfronthosting.co.za> py.user added the comment: Serhiy Storchaka wrote: > for example the use of such popular options as -0 or -@ Ok. What about inconsistent conversion dashes to underscores? >>> import argparse >>> >>> parser = argparse.ArgumentParser(prefix_chars='@') >>> _ = parser.add_argument('--x-one-two-three@') >>> _ = parser.add_argument('@@y-one-two-three@') >>> args = parser.parse_args(['abc']) >>> args Namespace(--x-one-two-three@='abc', y_one_two_three@=None) >>> We set dash as non-option char, but it continues to convert to underscore while another option char doesn't convert. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 01:30:38 2015 From: report at bugs.python.org (Matthias Bussonnier) Date: Sun, 31 May 2015 23:30:38 +0000 Subject: [issue24338] In argparse adding wrong arguments makes malformed namespace In-Reply-To: <1433070096.48.0.744562806973.issue24338@psf.upfronthosting.co.za> Message-ID: <1433115038.04.0.636099077475.issue24338@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: Maybe the __repr__ of _AttributeHolder should be changed so that invalid args are shown as unpacked dict in the signature ? Something that would : >>> argparse.Namespace(**{'foo bar':1}) argparse.Namespace(**{'foo bar':1}) ---------- nosy: +mbussonn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 01:40:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 23:40:45 +0000 Subject: [issue24317] Change installer Customize default to match quick settings In-Reply-To: <1432830796.7.0.202378193583.issue24317@psf.upfronthosting.co.za> Message-ID: <20150531234042.4348.71995@psf.io> Roundup Robot added the comment: New changeset 5bc396eb4e56 by Steve Dower in branch '3.5': Issue #24317: Makes Customize page default to installing per-user, and switching to All Users enable CompileAll. https://hg.python.org/cpython/rev/5bc396eb4e56 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 01:40:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 23:40:45 +0000 Subject: [issue24293] Windows installer unreadable with std/custom themes In-Reply-To: <1432684740.9.0.578796945246.issue24293@psf.upfronthosting.co.za> Message-ID: <20150531234042.4348.57980@psf.io> Roundup Robot added the comment: New changeset c7210097ac90 by Steve Dower in branch '3.5': Issue #24293: Adds mapping from explicit colours to system colours to correctly handle user themes. https://hg.python.org/cpython/rev/c7210097ac90 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 01:41:19 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 31 May 2015 23:41:19 +0000 Subject: [issue24293] Windows installer unreadable with std/custom themes In-Reply-To: <1432684740.9.0.578796945246.issue24293@psf.upfronthosting.co.za> Message-ID: <1433115679.66.0.932386048037.issue24293@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 01:41:39 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 31 May 2015 23:41:39 +0000 Subject: [issue24317] Change installer Customize default to match quick settings In-Reply-To: <1432830796.7.0.202378193583.issue24317@psf.upfronthosting.co.za> Message-ID: <1433115699.92.0.781956563291.issue24317@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 01:41:51 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 31 May 2015 23:41:51 +0000 Subject: [issue24317] Change installer Customize default to match quick settings In-Reply-To: <1432830796.7.0.202378193583.issue24317@psf.upfronthosting.co.za> Message-ID: <1433115711.34.0.610341085393.issue24317@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 01:43:43 2015 From: report at bugs.python.org (Matthias Bussonnier) Date: Sun, 31 May 2015 23:43:43 +0000 Subject: [issue24338] In argparse adding wrong arguments makes malformed namespace In-Reply-To: <1433070096.48.0.744562806973.issue24338@psf.upfronthosting.co.za> Message-ID: <1433115823.98.0.947813976529.issue24338@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: Minimal changes to the repr seem to work. I can submit a proper patch. class N2(Namespace): def __repr__(self): type_name = type(self).__name__ arg_strings = [] unarg={} for arg in self._get_args(): arg_strings.append(repr(arg)) for name, value in self._get_kwargs(): if name.isidentifier(): arg_strings.append('%s=%r' % (name, value)) else: unarg[name] = value if unarg: r_unarg = ', **%s' %(repr(unarg)) else: r_unarg = '' return '%s(%s%s)' % (type_name, ', '.join(arg_strings), r_unarg) >>> N2(a=1, b=2, **{"single ' quote ":"'", 'double " quote':'"'}) N = N2(a=1, b=2, **{"single ' quote ":"'", 'double " quote':'"'}) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 01:45:21 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 23:45:21 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <1433115921.09.0.460565714071.issue24336@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch with just the test case for 2.7, although I don?t have a strong opinion on whether it needs to be added or not. ---------- Added file: http://bugs.python.org/file39577/context-kw-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 03:37:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Jun 2015 01:37:45 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <20150601013741.18662.54655@psf.io> Roundup Robot added the comment: New changeset 0708aabefb55 by Yury Selivanov in branch '3.4': Issue 24017: Fix asyncio.CoroWrapper to support 'async def' coroutines https://hg.python.org/cpython/rev/0708aabefb55 New changeset 1dc232783012 by Yury Selivanov in branch '3.5': Issue 24017: Fix asyncio.CoroWrapper to support 'async def' coroutines https://hg.python.org/cpython/rev/1dc232783012 New changeset 2e7c45560c38 by Yury Selivanov in branch 'default': Issue 24017: Fix asyncio.CoroWrapper to support 'async def' coroutines https://hg.python.org/cpython/rev/2e7c45560c38 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 03:44:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Jun 2015 01:44:22 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <20150601014419.89799.79802@psf.io> Roundup Robot added the comment: New changeset a0a699b828e7 by Yury Selivanov in branch '3.5': Issue 24017: Add a test for CoroWrapper and 'async def' coroutines https://hg.python.org/cpython/rev/a0a699b828e7 New changeset 89521ac669f0 by Yury Selivanov in branch 'default': Issue 24017: Add a test for CoroWrapper and 'async def' coroutines https://hg.python.org/cpython/rev/89521ac669f0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 04:11:34 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 01 Jun 2015 02:11:34 +0000 Subject: [issue24342] coroutine wrapper recursion Message-ID: <1433124694.62.0.501554700121.issue24342@psf.upfronthosting.co.za> New submission from Yury Selivanov: Consider following piece of code: async def foo(): return 'spam' def wrapper(coro): async def wrap(coro): print('before') try: return await coro finally: print('after') return wrap(coro) import sys sys.set_coroutine_wrapper(wrapper) print(foo().send(None)) Current python will crash with a "RuntimeError: maximum recursion depth exceeded", because "wrap" is itself a coroutine, so ceval will call "wrapper" recursively. There are three options here: 1. Leave things as is; 2. Add a flag in tstate that coroutine_wrapper is executing, and raise a RuntimeError if it's reentering; 3. Add a flag in tstate (see 2) and skip wrapping when reentering (i.e. return what was passed to the wrapper). The attached patch implements (2). It also makes PyEval*CoroWrapper methods private. I, myself, vote for option 2. ---------- assignee: yselivanov components: Interpreter Core files: coro_wrapper.patch keywords: patch messages: 244569 nosy: gvanrossum, haypo, ncoghlan, yselivanov priority: normal severity: normal status: open title: coroutine wrapper recursion versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39578/coro_wrapper.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 04:12:29 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 01 Jun 2015 02:12:29 +0000 Subject: [issue24342] coroutine wrapper reentrancy In-Reply-To: <1433124694.62.0.501554700121.issue24342@psf.upfronthosting.co.za> Message-ID: <1433124749.24.0.189499292451.issue24342@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- stage: -> patch review title: coroutine wrapper recursion -> coroutine wrapper reentrancy type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 05:33:34 2015 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 01 Jun 2015 03:33:34 +0000 Subject: [issue19543] Add -3 warnings for codec convenience method changes In-Reply-To: <1384075247.27.0.0100141647279.issue19543@psf.upfronthosting.co.za> Message-ID: <1433129614.64.0.915381194595.issue19543@psf.upfronthosting.co.za> Nick Coghlan added the comment: The last two commit notifications were intended for issue #24270. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 06:30:27 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 01 Jun 2015 04:30:27 +0000 Subject: [issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping. In-Reply-To: <1432750979.18.0.523128349285.issue24303@psf.upfronthosting.co.za> Message-ID: <1433133027.08.0.370816195193.issue24303@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +jnoller _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 08:48:06 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Jun 2015 06:48:06 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <20150601064803.4334.47245@psf.io> Roundup Robot added the comment: New changeset bbb3a3129c12 by Serhiy Storchaka in branch '3.5': Moved Misc/NEWS entry (issue #24270) to correct section. https://hg.python.org/cpython/rev/bbb3a3129c12 New changeset ff1938d12240 by Serhiy Storchaka in branch 'default': Moved Misc/NEWS entry (issue #24270) to correct section. https://hg.python.org/cpython/rev/ff1938d12240 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 08:49:39 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Mon, 01 Jun 2015 06:49:39 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1433141379.05.0.547885412048.issue24259@psf.upfronthosting.co.za> Lars Gust?bel added the comment: @Martin: This is actually a nice idea that I hadn't thought of. I updated the Python 3 patch to use a seek() that moves to one byte before the next header block, reads the remaining byte and raises an error if it hits eof. The code looks rather clean compared to the previous patch, and it should perform like it always did. I am not quite sure about which exception type to use, ReadError is used in tarfile's header parsing code, but OSError is already used in tarfile.copyfileobj() and might be more like what the user expects. ---------- Added file: http://bugs.python.org/file39579/issue24259-3.x-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 08:53:26 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Mon, 01 Jun 2015 06:53:26 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1433141606.93.0.703383628157.issue24259@psf.upfronthosting.co.za> Changes by Lars Gust?bel : Added file: http://bugs.python.org/file39580/issue24259-2.x-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 09:23:47 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 01 Jun 2015 07:23:47 +0000 Subject: [issue24340] co_stacksize estimate can be highly off In-Reply-To: <1433096994.94.0.20833461119.issue24340@psf.upfronthosting.co.za> Message-ID: <1433143427.39.0.659171658093.issue24340@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> needs patch type: -> resource usage versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 10:28:41 2015 From: report at bugs.python.org (Laura Creighton) Date: Mon, 01 Jun 2015 08:28:41 +0000 Subject: [issue24343] Installing 3.4.3 gives error codes 2503 and 2502 on windows 8 Message-ID: <1433147321.07.0.242833893345.issue24343@psf.upfronthosting.co.za> New submission from Laura Creighton: This came in to webmaster, i.e. I don't have the machine with the problem and cannot test it. Two different people reported the same thing. One of them was able to get things working by running as Admin. The other was not. He was able to get things working by running in compatibility mode. When he reached that error, he got a popup, and the popup asked if he wanted to troubleshoot. He said yes. Then things silently ran, the installation suceeded and nothing was mentioned that needed troubleshooting. Thought you would like to know. ---------- components: Installation messages: 244573 nosy: lac priority: normal severity: normal status: open title: Installing 3.4.3 gives error codes 2503 and 2502 on windows 8 versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 11:36:52 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 01 Jun 2015 09:36:52 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433151412.01.0.941183505083.issue16991@psf.upfronthosting.co.za> Changes by Stefan Krah : Added file: http://bugs.python.org/file39581/crash-1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 11:37:20 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 01 Jun 2015 09:37:20 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433151440.13.0.111944209723.issue16991@psf.upfronthosting.co.za> Changes by Stefan Krah : Added file: http://bugs.python.org/file39582/crash-2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 12:11:33 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 01 Jun 2015 10:11:33 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433153493.27.0.82428649796.issue16991@psf.upfronthosting.co.za> Stefan Krah added the comment: crash-1.py is due to an unchecked return value from _odictnode_VALUE(). We should probably use PyDict_GetItemWithError(), also in other places. I normally try to steer clear of stylistic remarks, but the _odictnode* macros are hiding too many things. As of now, they were hiding that an assert() is always true and that a return value was unchecked. Also, they're very inconvenient in a debugger. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 12:19:03 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 01 Jun 2015 10:19:03 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433153943.19.0.14404174512.issue16991@psf.upfronthosting.co.za> Stefan Krah added the comment: crash-2.py is due to the fact that _PyDict_Pop() deletes a reference to 'key' in _odict_popkey(). The INCREF(key) in popitem should take place before calling _odict_popkey(). Again, I don't see the point of INCREF/DECREF *inside* of _odict_popkey(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 13:20:10 2015 From: report at bugs.python.org (John Helour) Date: Mon, 01 Jun 2015 11:20:10 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1433157610.56.0.935038620268.issue24339@psf.upfronthosting.co.za> John Helour added the comment: I've rewrote the iso6937 codec into Python 3. Could someone check it please? ---------- Added file: http://bugs.python.org/file39583/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 14:20:16 2015 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 01 Jun 2015 12:20:16 +0000 Subject: [issue24342] coroutine wrapper recursion In-Reply-To: <1433124694.62.0.501554700121.issue24342@psf.upfronthosting.co.za> Message-ID: Skip Montanaro added the comment: On Sun, May 31, 2015 at 9:11 PM, Yury Selivanov wrote: > Current python will crash with a "RuntimeError: maximum recursion depth exceeded" ... If it's good enough for other programmer-induced infinite recursion (and in my experience the cause is generally quite obvious from the traceback), why wouldn't it be good enough in this case? ---------- nosy: +skip.montanaro title: coroutine wrapper reentrancy -> coroutine wrapper recursion _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 14:27:19 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 01 Jun 2015 12:27:19 +0000 Subject: [issue24343] Installing 3.4.3 gives error codes 2503 and 2502 on windows 8 In-Reply-To: <1433147321.07.0.242833893345.issue24343@psf.upfronthosting.co.za> Message-ID: <1433161639.72.0.680216871421.issue24343@psf.upfronthosting.co.za> R. David Murray added the comment: I doubt there's much we can do without access to the OPs, but at least we can make sure the windows devs are aware and let them close it (I added the 'windows' component, which will auto-nosy them). ---------- components: +Windows nosy: +r.david.murray, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 14:42:01 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Mon, 01 Jun 2015 12:42:01 +0000 Subject: [issue24344] Overlap display issue in windows installer Message-ID: <1433162521.72.0.397093450999.issue24344@psf.upfronthosting.co.za> New submission from Ionel Cristian M?rie?: It appears that the new installer has some overlap issue when displaying progress info. Attached a screenshot. ---------- components: Installation files: installer-display-bug.png messages: 244579 nosy: ionelmc, steve.dower priority: normal severity: normal status: open title: Overlap display issue in windows installer versions: Python 3.5 Added file: http://bugs.python.org/file39584/installer-display-bug.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 15:21:56 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 01 Jun 2015 13:21:56 +0000 Subject: [issue24344] Overlap display issue in windows installer In-Reply-To: <1433162521.72.0.397093450999.issue24344@psf.upfronthosting.co.za> Message-ID: <1433164916.71.0.91275836626.issue24344@psf.upfronthosting.co.za> Steve Dower added the comment: Already fixed this in issue24293, which is what caused it. Unfortunately, I didn't get it done in time for beta 2. Thanks for the report though. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Windows installer unreadable with std/custom themes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 15:41:14 2015 From: report at bugs.python.org (Petr Viktorin) Date: Mon, 01 Jun 2015 13:41:14 +0000 Subject: [issue24345] Py_tp_finalize is missing Message-ID: <1433166074.58.0.387309124026.issue24345@psf.upfronthosting.co.za> New submission from Petr Viktorin: PEP 442 added the tp_finalize member for objects, but there's no corresponding Py_tp_finalize slot. This means that types defined using PyType_FromSpec (and in particular, extensions using the stable ABI) can't take advantage of the new GC finalization mechanism. ---------- components: Extension Modules, Interpreter Core files: add-py-tp-finalize.patch keywords: patch messages: 244581 nosy: encukou priority: normal severity: normal status: open title: Py_tp_finalize is missing versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39585/add-py-tp-finalize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 15:51:15 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 01 Jun 2015 13:51:15 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433166675.09.0.664536742806.issue18003@psf.upfronthosting.co.za> Martin Panter added the comment: This bug was originally raised against Python 3.3, and the speed has improved a lot since then. Perhaps this bug can be closed as it is, or maybe people would like to consider my decomp-optim.patch which squeezes a bit more speed out. I don?t actually have a strong opinion either way. Python 3.4 was apparently much faster than 3.3 courtesy of Issue 16034. In Python 3.5, all three decompression modules (LZMA, gzip and bzip) now use a BufferedReader internally, due to my work in Issue 23529. The modules delegate method calls to the internal BufferedReader, rather than returning an instance directly, for backwards compatibility. I found that bypassing the readline() delegation speeds things up significantly, and adding a custom ?closed? property on the underlying raw reader class also helps. However, I did not think it would be wise to bypass the locking in the ?bz2? module, I didn?t bypass BZ2File.readline() in the patch. Timing results and a test script I used to investigate different options below: lzma gzip bz2 ======= ======== ======== Unpatched 3.2 s 2.513 s 5.180 s Custom __iter__() 1.31 s 1.317 s 2.433 s __iter__() and closed 0.53 s* 0.543 s* 1.650 s closed change only 4.047 s* External BufferedReader 0.64 s 0.597 s 1.750 s Direct from BytesIO 0.33 s 0.370 s 1.280 s Command-line tool 0.063 s 0.053 s 0.993 s * Option implemented in decomp-optim.patch --- import lzma, io filename = "pacman.log.xz" # 256206 lines; 389 kB -> 13 MB # Basic case reader = lzma.LZMAFile(filename) # 3.2 s # Add __iter__() optimization def lzma_iter(self): self._check_can_read() return iter(self._buffer) lzma.LZMAFile.__iter__ = lzma_iter # 1.31 s # Add ?closed? optimization def decompressor_closed(self): return self._decompressor is None import _compression _compression.DecompressReader.closed = property(decompressor_closed) # 0.53 s #~ # External BufferedReader baseline #~ reader = io.BufferedReader(lzma.LZMAFile(filename)) # 0.64 s #~ # Direct from BytesIO baseline #~ with open(filename, "rb") as file: #~ data = file.read() #~ reader = io.BytesIO(lzma.decompress(data)) # 0.33 s for line in reader: pass ---------- keywords: +patch versions: +Python 3.5, Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file39586/decomp-optim.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 16:34:17 2015 From: report at bugs.python.org (Laura Creighton) Date: Mon, 01 Jun 2015 14:34:17 +0000 Subject: [issue24343] Installing 3.4.3 gives error codes 2503 and 2502 on windows 8 In-Reply-To: <1433147321.07.0.242833893345.issue24343@psf.upfronthosting.co.za> Message-ID: <1433169257.58.0.0980716022729.issue24343@psf.upfronthosting.co.za> Laura Creighton added the comment: Sorry that I forgot to add the 'windows'. It may be that there is nothing left to do but close this, however, one of the 2 that mailed webmaster looked at the bug tracker for a work-around for his problem -- at least if this happens again the next person will find something. ---------- components: -Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 16:48:00 2015 From: report at bugs.python.org (Laura Creighton) Date: Mon, 01 Jun 2015 14:48:00 +0000 Subject: [issue24343] Installing 3.4.3 gives error codes 2503 and 2502 on windows 8 In-Reply-To: <1433147321.07.0.242833893345.issue24343@psf.upfronthosting.co.za> Message-ID: <1433170080.75.0.397001621966.issue24343@psf.upfronthosting.co.za> Laura Creighton added the comment: Arggh! Components seems to be a radio box here? As in I can select Windows or Installation but not both? And by selecting installation again, I killed David's selection of Windows? Added this to put Windows back, but, well, if this is what we have it it time to make a small change to the bug tracker ... ---------- components: +Windows -Installation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 16:48:05 2015 From: report at bugs.python.org (stf) Date: Mon, 01 Jun 2015 14:48:05 +0000 Subject: [issue24346] Key Error at List in Tuple concatenation Message-ID: <1433170085.86.0.270970129026.issue24346@psf.upfronthosting.co.za> Changes by stf : ---------- components: Interpreter Core nosy: stf priority: normal severity: normal status: open title: Key Error at List in Tuple concatenation type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 16:48:55 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 01 Jun 2015 14:48:55 +0000 Subject: [issue24342] coroutine wrapper reentrancy In-Reply-To: <1433124694.62.0.501554700121.issue24342@psf.upfronthosting.co.za> Message-ID: <1433170135.37.0.720646269991.issue24342@psf.upfronthosting.co.za> Eric Snow added the comment: Changing the title back. :) ---------- nosy: +eric.snow title: coroutine wrapper recursion -> coroutine wrapper reentrancy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 16:54:19 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 01 Jun 2015 14:54:19 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433170459.07.0.448024360457.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: @Jim and Stefan, Thanks for thorough reviews! @Stefan, I'll take a look at those crashers and other suggestions ASAP. I really appreciate you taking the time. Now that the patch has been landed, would you mind opening new issues for each problem you find? That will help keep individual problems from getting lost. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 16:57:38 2015 From: report at bugs.python.org (stf) Date: Mon, 01 Jun 2015 14:57:38 +0000 Subject: [issue24346] Key Error at List in Tuple concatenation Message-ID: <1433170658.82.0.661588538732.issue24346@psf.upfronthosting.co.za> Changes by stf : Added file: http://bugs.python.org/file39587/bug.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 17:00:25 2015 From: report at bugs.python.org (Christian Heimes) Date: Mon, 01 Jun 2015 15:00:25 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433170825.38.0.639092078199.issue16991@psf.upfronthosting.co.za> Christian Heimes added the comment: Coverity has found an issue in odict, too: *** CID 1302699: Null pointer dereferences (NULL_RETURNS) /Objects/odictobject.c: 1316 in odict_copy() 1310 od_copy = PyObject_CallFunctionObjArgs((PyObject *)Py_TYPE(od), NULL); 1311 if (od_copy == NULL) 1312 return NULL; 1313 1314 if (PyODict_CheckExact(od)) { 1315 _odict_FOREACH(od, node) { >>> CID 1302699: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "PyDict_GetItem((PyObject *)(PyObject *)od, node->key)" when calling "PyODict_SetItem". 1316 int res = PyODict_SetItem((PyObject *)od_copy, 1317 _odictnode_KEY(node), 1318 _odictnode_VALUE(node, od)); 1319 if (res != 0) 1320 goto fail; 1321 } ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 17:01:48 2015 From: report at bugs.python.org (stf) Date: Mon, 01 Jun 2015 15:01:48 +0000 Subject: [issue24346] Key Error at List in Tuple concatenation Message-ID: <1433170908.12.0.936972780857.issue24346@psf.upfronthosting.co.za> New submission from stf: >>> a = ([1,2],) >>> a[0] += [3] this raises an Type Error but adds the Elements to a. So a is ([1, 2, 3],) afterwards. This Problem doesn't occur, when you use a[0].append(3) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 17:02:25 2015 From: report at bugs.python.org (stf) Date: Mon, 01 Jun 2015 15:02:25 +0000 Subject: [issue24346] Key Error at List in Tuple concatenation In-Reply-To: <1433170908.12.0.936972780857.issue24346@psf.upfronthosting.co.za> Message-ID: <1433170945.65.0.780374806212.issue24346@psf.upfronthosting.co.za> Changes by stf : Removed file: http://bugs.python.org/file39587/bug.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 17:05:55 2015 From: report at bugs.python.org (stf) Date: Mon, 01 Jun 2015 15:05:55 +0000 Subject: [issue24346] TypeError at List in Tuple concatenation In-Reply-To: <1433170908.12.0.936972780857.issue24346@psf.upfronthosting.co.za> Message-ID: <1433171155.67.0.826856561276.issue24346@psf.upfronthosting.co.za> Changes by stf : ---------- title: Key Error at List in Tuple concatenation -> TypeError at List in Tuple concatenation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 17:10:23 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 01 Jun 2015 15:10:23 +0000 Subject: [issue24343] Installing 3.4.3 gives error codes 2503 and 2502 on windows 8 In-Reply-To: <1433147321.07.0.242833893345.issue24343@psf.upfronthosting.co.za> Message-ID: <1433171423.95.0.918121142835.issue24343@psf.upfronthosting.co.za> R. David Murray added the comment: No, components is a multiselect. In my browser that means I hold ctl and click to add a second component, don't know what it looks like your browser. (I've added installation back.) ---------- components: +Installation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 17:12:39 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 01 Jun 2015 15:12:39 +0000 Subject: [issue24346] TypeError at List in Tuple concatenation In-Reply-To: <1433170908.12.0.936972780857.issue24346@psf.upfronthosting.co.za> Message-ID: <1433171559.23.0.524728438878.issue24346@psf.upfronthosting.co.za> R. David Murray added the comment: https://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 17:14:43 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Jun 2015 15:14:43 +0000 Subject: [issue24345] Py_tp_finalize is missing In-Reply-To: <1433166074.58.0.387309124026.issue24345@psf.upfronthosting.co.za> Message-ID: <20150601151440.18676.63441@psf.io> Roundup Robot added the comment: New changeset 5a354de919aa by Benjamin Peterson in branch '3.5': add Py_tp_finalize slot (closes #24345) https://hg.python.org/cpython/rev/5a354de919aa New changeset 959e998aa167 by Benjamin Peterson in branch 'default': merge 3.5 (#24345) https://hg.python.org/cpython/rev/959e998aa167 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 17:22:03 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 01 Jun 2015 15:22:03 +0000 Subject: [issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping. In-Reply-To: <1432750979.18.0.523128349285.issue24303@psf.upfronthosting.co.za> Message-ID: <1433172123.95.0.946976748807.issue24303@psf.upfronthosting.co.za> Davin Potts added the comment: Triggering it regularly in a build farm indeed sounds like genuine pain. @Paul or @vapier: In tracking down this issue, did you already create a convenient way to repro the misbehavior that could be used in testing? Any finalized patch that we make will need some form of test. ---------- assignee: -> davin components: +Library (Lib) type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 17:35:30 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 01 Jun 2015 15:35:30 +0000 Subject: [issue24342] coroutine wrapper reentrancy In-Reply-To: <1433124694.62.0.501554700121.issue24342@psf.upfronthosting.co.za> Message-ID: <1433172930.88.0.429120256203.issue24342@psf.upfronthosting.co.za> Yury Selivanov added the comment: > why wouldn't it be good enough in this case? Because it's highly non-obvious, it took me a while to understand what's *actually* going on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 17:47:49 2015 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 01 Jun 2015 15:47:49 +0000 Subject: [issue24342] coroutine wrapper reentrancy In-Reply-To: <1433124694.62.0.501554700121.issue24342@psf.upfronthosting.co.za> Message-ID: <1433173669.13.0.436688804911.issue24342@psf.upfronthosting.co.za> Skip Montanaro added the comment: This is a bit off topic, but why did my reply to Yuri's ticket by email change the title? I didn't mess with the subject in my mail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 17:54:10 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 01 Jun 2015 15:54:10 +0000 Subject: [issue24342] coroutine wrapper reentrancy In-Reply-To: <1433124694.62.0.501554700121.issue24342@psf.upfronthosting.co.za> Message-ID: <1433174050.78.0.652476232149.issue24342@psf.upfronthosting.co.za> Eric Snow added the comment: @Skip, because roundup will change the title to the subject of the email and the title had been changed after the message to which you replied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 18:16:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Jun 2015 16:16:03 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <20150601161600.25417.41934@psf.io> Roundup Robot added the comment: New changeset 1e9e0664ee9b by Yury Selivanov in branch '3.5': Issue 24017: Make PyEval_(Set|Get)CoroutineWrapper private https://hg.python.org/cpython/rev/1e9e0664ee9b New changeset 6fcb64097b1c by Yury Selivanov in branch 'default': Issue 24017: Make PyEval_(Set|Get)CoroutineWrapper private https://hg.python.org/cpython/rev/6fcb64097b1c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 18:19:10 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 01 Jun 2015 16:19:10 +0000 Subject: [issue24347] unchecked return value in C OrderedDict Message-ID: <1433175550.71.0.808685138133.issue24347@psf.upfronthosting.co.za> New submission from Eric Snow: (from msg244574 in issue16991) crash-1.py is due to an unchecked return value from _odictnode_VALUE(). We should probably use PyDict_GetItemWithError(), also in other places. I normally try to steer clear of stylistic remarks, but the _odictnode* macros are hiding too many things. As of now, they were hiding that an assert() is always true and that a return value was unchecked. Also, they're very inconvenient in a debugger. ---------- assignee: eric.snow components: Library (Lib) files: crash-1.py messages: 244597 nosy: eric.snow, skrah priority: release blocker severity: normal stage: test needed status: open title: unchecked return value in C OrderedDict type: crash versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39588/crash-1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 18:21:56 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 01 Jun 2015 16:21:56 +0000 Subject: [issue24348] incorrect decref in C OrderedDict Message-ID: <1433175716.41.0.847645147456.issue24348@psf.upfronthosting.co.za> New submission from Eric Snow: (from msg244575 in issue16991) crash-2.py is due to the fact that _PyDict_Pop() deletes a reference to 'key' in _odict_popkey(). The INCREF(key) in popitem should take place before calling _odict_popkey(). Again, I don't see the point of INCREF/DECREF *inside* of _odict_popkey(). ---------- assignee: eric.snow components: Library (Lib) files: crash-2.py messages: 244598 nosy: eric.snow, skrah priority: release blocker severity: normal stage: needs patch status: open title: incorrect decref in C OrderedDict type: crash versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39589/crash-2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 18:24:34 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 01 Jun 2015 16:24:34 +0000 Subject: [issue24349] Null pointer dereferences in C OrderedDict Message-ID: <1433175874.7.0.776296707125.issue24349@psf.upfronthosting.co.za> New submission from Eric Snow: (from msg244587 in issue16991) Coverity has found an issue in odict, too: *** CID 1302699: Null pointer dereferences (NULL_RETURNS) /Objects/odictobject.c: 1316 in odict_copy() 1310 od_copy = PyObject_CallFunctionObjArgs((PyObject *)Py_TYPE(od), NULL); 1311 if (od_copy == NULL) 1312 return NULL; 1313 1314 if (PyODict_CheckExact(od)) { 1315 _odict_FOREACH(od, node) { >>> CID 1302699: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "PyDict_GetItem((PyObject *)(PyObject *)od, node->key)" when calling "PyODict_SetItem". 1316 int res = PyODict_SetItem((PyObject *)od_copy, 1317 _odictnode_KEY(node), 1318 _odictnode_VALUE(node, od)); 1319 if (res != 0) 1320 goto fail; 1321 } ---------- assignee: eric.snow components: Library (Lib) messages: 244599 nosy: christian.heimes, eric.snow priority: release blocker severity: normal stage: needs patch status: open title: Null pointer dereferences in C OrderedDict type: crash versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 18:26:38 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 01 Jun 2015 16:26:38 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433175998.79.0.678033493895.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: I've opened the following issues to address the 3 last comments: issue24347 issue24348 issue24349 I'll be opening a separate issue for outstanding review comments. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 18:27:23 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 01 Jun 2015 16:27:23 +0000 Subject: [issue24347] unchecked return value in C OrderedDict In-Reply-To: <1433175550.71.0.808685138133.issue24347@psf.upfronthosting.co.za> Message-ID: <1433176043.04.0.189842283107.issue24347@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 18:27:27 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 01 Jun 2015 16:27:27 +0000 Subject: [issue24348] incorrect decref in C OrderedDict In-Reply-To: <1433175716.41.0.847645147456.issue24348@psf.upfronthosting.co.za> Message-ID: <1433176047.1.0.0138775992777.issue24348@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 18:27:30 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 01 Jun 2015 16:27:30 +0000 Subject: [issue24349] Null pointer dereferences in C OrderedDict In-Reply-To: <1433175874.7.0.776296707125.issue24349@psf.upfronthosting.co.za> Message-ID: <1433176050.91.0.555676615902.issue24349@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 18:33:08 2015 From: report at bugs.python.org (Graham Klyne) Date: Mon, 01 Jun 2015 16:33:08 +0000 Subject: [issue24350] dict({'a':'aa'}, a='bb') raises segmentation fault on Mac Message-ID: <1433176387.97.0.111097599452.issue24350@psf.upfronthosting.co.za> New submission from Graham Klyne: conina:~ graham$ python Python 2.7.3 (v2.7.3:70274d53c1dd, Apr 9 2012, 20:52:43) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> dict({'a':'aa'},b='bb') {'a': 'aa', 'b': 'bb'} >>> dict({'a':'aa'},a='bb') Segmentation fault: 11 conina:~ graham$ >From the docs: [[ If keyword arguments are given, the keyword arguments and their values are added to the dictionary created from the positional argument. If a key being added is already present, the value from the keyword argument replaces the value from the positional argument. ]] ---------- components: Macintosh messages: 244601 nosy: Graham Klyne, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: dict({'a':'aa'},a='bb') raises segmentation fault on Mac type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 18:36:48 2015 From: report at bugs.python.org (Graham Klyne) Date: Mon, 01 Jun 2015 16:36:48 +0000 Subject: [issue24350] dict({'a':'aa'}, a='bb') raises segmentation fault on Mac In-Reply-To: <1433176387.97.0.111097599452.issue24350@psf.upfronthosting.co.za> Message-ID: <1433176608.12.0.394434783664.issue24350@psf.upfronthosting.co.za> Graham Klyne added the comment: Oops, (RETURN) submitted before comments done... I think the example interactive python script is self-explanatory. I know my version of Python is a bit out of date, but I couldn't see anything in the issue list that indicated this problem had been seen and fixed. I had previously experienced some segment fault crashes while doing dictionary manipulation, but could not isolate the cause. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 18:39:57 2015 From: report at bugs.python.org (Graham Klyne) Date: Mon, 01 Jun 2015 16:39:57 +0000 Subject: [issue24350] dict({'a':'aa'}, a='bb') raises segmentation fault on Mac In-Reply-To: <1433176387.97.0.111097599452.issue24350@psf.upfronthosting.co.za> Message-ID: <1433176797.54.0.0306935679356.issue24350@psf.upfronthosting.co.za> Graham Klyne added the comment: I just tried the same on a Python 2.7.5 installation and it worked as expected (no crash). So I now assume this is fixed. Sorry for the noise. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 19:03:36 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 01 Jun 2015 17:03:36 +0000 Subject: [issue24350] dict({'a':'aa'}, a='bb') raises segmentation fault on Mac In-Reply-To: <1433176387.97.0.111097599452.issue24350@psf.upfronthosting.co.za> Message-ID: <1433178216.88.0.577501622276.issue24350@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: out of date -> duplicate stage: -> resolved superseder: -> python.org Interactive interpreter linked with libedit can segfault on future OS X _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 19:17:54 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 01 Jun 2015 17:17:54 +0000 Subject: [issue24347] unchecked return value in C OrderedDict In-Reply-To: <1433175550.71.0.808685138133.issue24347@psf.upfronthosting.co.za> Message-ID: <1433179074.28.0.30744356696.issue24347@psf.upfronthosting.co.za> Eric Snow added the comment: Regarding the macros, my intent was to limit leaking the details of the linked list implementation and make it easier to change the linked list implementation later. However, if that results in problems then I'm open to changing it. What would you recommend? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 19:21:00 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 01 Jun 2015 17:21:00 +0000 Subject: [issue24340] co_stacksize estimate can be highly off In-Reply-To: <1433096994.94.0.20833461119.issue24340@psf.upfronthosting.co.za> Message-ID: <1433179260.31.0.160060890412.issue24340@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 19:22:16 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 01 Jun 2015 17:22:16 +0000 Subject: [issue24342] coroutine wrapper reentrancy In-Reply-To: <1433124694.62.0.501554700121.issue24342@psf.upfronthosting.co.za> Message-ID: <1433179336.2.0.985036132745.issue24342@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 19:23:20 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 01 Jun 2015 17:23:20 +0000 Subject: [issue24347] unchecked return value in C OrderedDict In-Reply-To: <1433175550.71.0.808685138133.issue24347@psf.upfronthosting.co.za> Message-ID: <1433179400.73.0.955978183615.issue24347@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 19:23:50 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 01 Jun 2015 17:23:50 +0000 Subject: [issue24348] incorrect decref in C OrderedDict In-Reply-To: <1433175716.41.0.847645147456.issue24348@psf.upfronthosting.co.za> Message-ID: <1433179430.87.0.544334492719.issue24348@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 19:24:30 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 01 Jun 2015 17:24:30 +0000 Subject: [issue24349] Null pointer dereferences in C OrderedDict In-Reply-To: <1433175874.7.0.776296707125.issue24349@psf.upfronthosting.co.za> Message-ID: <1433179470.65.0.786457340616.issue24349@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 20:09:08 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 01 Jun 2015 18:09:08 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <1433182148.63.0.678490373538.issue24336@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 20:09:30 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 01 Jun 2015 18:09:30 +0000 Subject: [issue24341] Test suite emits many DeprecationWarnings about sys.exc_clear() when -3 is enabled In-Reply-To: <1433098290.5.0.721765999777.issue24341@psf.upfronthosting.co.za> Message-ID: <1433182170.77.0.710395362536.issue24341@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 20:20:11 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 01 Jun 2015 18:20:11 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433182811.5.0.740885792901.issue16991@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- nosy: -steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 20:24:20 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 01 Jun 2015 18:24:20 +0000 Subject: [issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET) In-Reply-To: <1429124647.47.0.946423694262.issue23968@psf.upfronthosting.co.za> Message-ID: <1433183060.85.0.511330141444.issue23968@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: What Lib/plat-$(PLATFORM_TRIPLET) directories will be introduced? This patch would make situation worse on rarely used architectures (these without Lib/plat-$(PLATFORM_TRIPLET) distributed in repository of CPython) if patch for bug #12619 is not applied. ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 20:27:49 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 01 Jun 2015 18:27:49 +0000 Subject: [issue23767] Library and include paths not added when cross-compiling on localized system In-Reply-To: <1427227440.25.0.884604694697.issue23767@psf.upfronthosting.co.za> Message-ID: <1433183269.81.0.747899507079.issue23767@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever title: Library and include paths not added when cross compiling on localized sytem -> Library and include paths not added when cross-compiling on localized system _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 20:28:51 2015 From: report at bugs.python.org (Armin Rigo) Date: Mon, 01 Jun 2015 18:28:51 +0000 Subject: [issue24340] co_stacksize estimate can be highly off In-Reply-To: <1433096994.94.0.20833461119.issue24340@psf.upfronthosting.co.za> Message-ID: <1433183331.19.0.843090023628.issue24340@psf.upfronthosting.co.za> Changes by Armin Rigo : ---------- nosy: -arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 20:41:32 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 01 Jun 2015 18:41:32 +0000 Subject: [issue24329] __qualname__ and __slots__ In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> Message-ID: <1433184092.91.0.869059065068.issue24329@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 20:45:28 2015 From: report at bugs.python.org (Brandon Milam) Date: Mon, 01 Jun 2015 18:45:28 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1433184328.28.0.369932031875.issue8232@psf.upfronthosting.co.za> Brandon Milam added the comment: Forgive me the excessive number of patch submissions as I am still getting my feet wet in contributing to Python. I'm posting another patch that is not functionally different from the last patch but should better adhere to the PEP8 style guide. Please let me know of any additional changes that need to be made or if a different functionality is preferred. ---------- Added file: http://bugs.python.org/file39590/webbrowserfix4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 21:05:08 2015 From: report at bugs.python.org (July Tikhonov) Date: Mon, 01 Jun 2015 19:05:08 +0000 Subject: [issue24351] string.Template documentation incorrectly references "identifiers" Message-ID: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za> New submission from July Tikhonov: Documentation of Template says: $identifier names a substitution placeholder matching a mapping key of "identifier". By default, "identifier" must spell a Python identifier. The first non-identifier character after the $ character terminates this placeholder specification. While it was true when these lines were written, Python 3 has greatly extended identifier character set, and it no longer matches the set of characters used by Template: >>> Template('$foo123??').substitute(foo=1, foo123=2, foo123??=3) '2??' I propose clarifying documentation. Actually extending character set is backward-incompatible, although it won't be if restricted to "${identifier}" syntax. ---------- assignee: docs at python components: Documentation messages: 244607 nosy: docs at python, july priority: normal severity: normal status: open title: string.Template documentation incorrectly references "identifiers" versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 21:15:30 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 01 Jun 2015 19:15:30 +0000 Subject: [issue24352] Provide a way for assertLogs to optionally not hide the logging output Message-ID: <1433186130.81.0.919581568401.issue24352@psf.upfronthosting.co.za> New submission from R. David Murray: In my test framework I have a 'verbose' flag that causes the logging output to be written to the console[*], which helps greatly during debugging. However, if assertLogs is used, the logging is suppressed, and when debugging logging failures it is really helpful to see the full logging output :). Ideally there would be a unittest-supported 'verbose' flag that assertLogs could look at and not suppress existing logging when it is at level 2 or greater. Or perhaps a flag specific to logging output would be better? I don't really care what the API is as long as I can arrange to set it from the CLI as part of running individual tests. ---------- components: Library (Lib) messages: 244608 nosy: r.david.murray priority: normal severity: normal status: open title: Provide a way for assertLogs to optionally not hide the logging output type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 21:51:56 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Mon, 01 Jun 2015 19:51:56 +0000 Subject: [issue24353] NameError: name 'path_separators' is not defined Message-ID: <1433188316.2.0.247864565419.issue24353@psf.upfronthosting.co.za> New submission from Ionel Cristian M?rie?: I get this: Traceback (most recent call last): File "c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\basecommand.py", line 223, in main status = self.run(options, args) File "c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\commands\install.py", line 297, in run root=options.root_path, File "c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\req\req_set.py", line 622, in install **kwargs File "c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\req\req_install.py", line 808, in install self.move_wheel_files(self.source_dir, root=root) File "c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\req\req_install.py", line 1003, in move_wheel_files isolated=self.isolated, File "c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\wheel.py", line 266, in move_wheel_files compileall.compile_dir(source, force=True, quiet=True) File "C:\Program Files\Python 3.5\lib\compileall.py", line 88, in compile_dir legacy, optimize): File "C:\Program Files\Python 3.5\lib\compileall.py", line 126, in compile_file cfile = importlib.util.cache_from_source(fullname) File "", line 267, in cache_from_source File "", line 58, in _path_split NameError: name 'path_separators' is not defined Any idea what's going on? Should I try to make a minimal reproducing example? ---------- components: Interpreter Core messages: 244609 nosy: ionelmc priority: normal severity: normal status: open title: NameError: name 'path_separators' is not defined versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 22:04:48 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 01 Jun 2015 20:04:48 +0000 Subject: [issue24353] NameError: name 'path_separators' is not defined In-Reply-To: <1433188316.2.0.247864565419.issue24353@psf.upfronthosting.co.za> Message-ID: <1433189088.3.0.66934962444.issue24353@psf.upfronthosting.co.za> R. David Murray added the comment: You have a mixture of python2 and python3 involved there, and unless I misunderstand something about pip, that's not going to work. I think this should be reported to the pip bug tracker, but it may be an error at the python installation level or virtual environment creation level. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 22:18:22 2015 From: report at bugs.python.org (loginname) Date: Mon, 01 Jun 2015 20:18:22 +0000 Subject: [issue24354] Requests Library get issue Message-ID: <1433189902.19.0.138832290406.issue24354@psf.upfronthosting.co.za> New submission from loginname: requests.get fails to get the website "http://www.merrickbank.com/" just doesn't get the website, and it freezes up quite a bit ---------- messages: 244611 nosy: loginname priority: normal severity: normal status: open title: Requests Library get issue type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 22:18:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Jun 2015 20:18:45 +0000 Subject: [issue24351] string.Template documentation incorrectly references "identifiers" In-Reply-To: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za> Message-ID: <1433189925.16.0.0150784384588.issue24351@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 22:22:05 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 01 Jun 2015 20:22:05 +0000 Subject: [issue24354] Requests Library get issue In-Reply-To: <1433189902.19.0.138832290406.issue24354@psf.upfronthosting.co.za> Message-ID: <1433190125.34.0.206650886613.issue24354@psf.upfronthosting.co.za> R. David Murray added the comment: Requests is not part of the python standard library. Please report the issue to the requests bug tracker. ---------- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 22:28:25 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 01 Jun 2015 20:28:25 +0000 Subject: [issue24355] Provide a unittest api for controlling verbosity in tests Message-ID: <1433190505.1.0.734052090716.issue24355@psf.upfronthosting.co.za> New submission from R. David Murray: The python regression test suite has a 'verbose' flag in its test.support that some tests and test fixtures (asserts, helper methods, etc) use to control how much additional information they output. unittest has a -v command line flag which controls the verbosity of the test runner (or whatever it is that prints out which tests have been run). It would be very helpful if the verbosity level specified on the unittest command line were accessible to test code so that the verbosity level of the test output can also be affected from the unittest command line (I, for example, would use this to control printing logging output to the console while using tests to do debugging). See also issue 24352. ---------- components: Library (Lib) messages: 244613 nosy: r.david.murray priority: normal severity: normal status: open title: Provide a unittest api for controlling verbosity in tests type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 22:34:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Jun 2015 20:34:18 +0000 Subject: [issue24355] Provide a unittest api for controlling verbosity in tests In-Reply-To: <1433190505.1.0.734052090716.issue24355@psf.upfronthosting.co.za> Message-ID: <1433190858.07.0.481852706865.issue24355@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue22197. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 22:38:22 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 01 Jun 2015 20:38:22 +0000 Subject: [issue24355] Provide a unittest api for controlling verbosity in tests In-Reply-To: <1433190505.1.0.734052090716.issue24355@psf.upfronthosting.co.za> Message-ID: <1433191102.23.0.71900258793.issue24355@psf.upfronthosting.co.za> R. David Murray added the comment: Ah! I *thought* an issue for this already existed, but I couldn't find it. That one has two enhancements in it, maybe we can use this one to diverge the two. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 1 23:25:14 2015 From: report at bugs.python.org (Brandon Milam) Date: Mon, 01 Jun 2015 21:25:14 +0000 Subject: [issue12020] Attribute error with flush on stdout,stderr In-Reply-To: <1304703877.7.0.898555574271.issue12020@psf.upfronthosting.co.za> Message-ID: <1433193914.07.0.672204317652.issue12020@psf.upfronthosting.co.za> Brandon Milam added the comment: I've been looking over the issue and the error is just raised by the stdout change not the stderr change (when the stdout line is commented out in the setAutoFlush function no error is raised). The flush method doesn't seem to be required as Serhiy pointed out since the script still is able to run. This is the cause for the error, however and I think that the required subset of methods for stdout objects to avoid errors could be clarified in the documentation. This documentation addition I think would be best under the sys.stdout info rather than under io.TextIOBase since the error can be raised without going through this class at all like in the original post. I would like to add this documentation under sys.stdout as required subset of methods that must be defined and was wondering if there were any other methods than flush() that would need to be defined. ---------- nosy: +jbmilam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 00:02:34 2015 From: report at bugs.python.org (David Bolen) Date: Mon, 01 Jun 2015 22:02:34 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1433196154.65.0.836276777262.issue4753@psf.upfronthosting.co.za> David Bolen added the comment: The 2.7 back-ported version of this patch appears to have broken compilation on the Windows XP buildbot, during the OpenSSL build process, when the newly built Python is used to execute the build_ssl.py script. After this patch, when that stage executes, and prior to any output from the build script, the python_d process goes to 100% CPU and sticks there until the build process times out 1200s later and kills it. I don't think it's really ssl related though, as after doing some debugging the exact same thing happens if I simply run python_d (I never see a prompt - it just sits there burning CPU). So I think build_ssl.py is just the first use of the generated python_d during the build process. I did try attaching to the CPU-stuck version of python_d from VS, and so far from what I can see, the process never gets past the Py_Initialize() call in Py_Main(). It's all over the place in terms of locations if I try interrupting it, but it's always stuck inside that first Py_Initialize call. I'm not sure if it's something environmental on my slave, or a difference with a debug vs. production build (I haven't had a chance to try building a release version yet). -- David ---------- nosy: +db3l _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 00:21:33 2015 From: report at bugs.python.org (Graham Oliver) Date: Mon, 01 Jun 2015 22:21:33 +0000 Subject: [issue24356] venv documentation incorrect / misleading Message-ID: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za> New submission from Graham Oliver: See my question here https://groups.google.com/forum/#!topic/comp.lang.python/BUmyc_hzAsA In particular Carl Meyer's response https://groups.google.com/d/msg/comp.lang.python/BUmyc_hzAsA/-cT-N-g_LL4J I am not sure what is possible with venv but I would suggest that the statement 'allowing creation of environments with various Python versions' needs to be clarified and / or altered. Thanks Graham ---------- assignee: docs at python components: Documentation messages: 244618 nosy: Graham.Oliver, docs at python priority: normal severity: normal status: open title: venv documentation incorrect / misleading versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 00:25:07 2015 From: report at bugs.python.org (Graham Oliver) Date: Mon, 01 Jun 2015 22:25:07 +0000 Subject: [issue24356] venv documentation incorrect / misleading In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za> Message-ID: <1433197507.58.0.57645517095.issue24356@psf.upfronthosting.co.za> Graham Oliver added the comment: See also https://groups.google.com/d/msg/comp.lang.python/BUmyc_hzAsA/Nx5QgT1gzYEJ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 00:26:56 2015 From: report at bugs.python.org (David Bolen) Date: Mon, 01 Jun 2015 22:26:56 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1433197616.6.0.596561530079.issue4753@psf.upfronthosting.co.za> David Bolen added the comment: I ran a few more tests, and the generated executable hangs in both release and debug builds. The closest I can get at the moment is that it's stuck importing errno from the "import sys, errno" line in os.py - at least no matter how long I wait after starting a process before breaking out, output with -v looks like: > python_d -v # installing zipimport hook import zipimport # builtin # installed zipimport hook # D:\cygwin\home\db3l\test\python2.7\lib\site.pyc matches D:\cygwin\home\db3l\test\python2.7\lib\site.py import site # precompiled from D:\cygwin\home\db3l\test\python2.7\lib\site.pyc # D:\cygwin\home\db3l\test\python2.7\lib\os.pyc matches D:\cygwin\home\db3l\test\python2.7\lib\os.py import os # precompiled from D:\cygwin\home\db3l\test\python2.7\lib\os.pyc import errno # builtin Traceback (most recent call last): File "D:\cygwin\home\db3l\test\python2.7\lib\site.py", line 62, in import os File "D:\cygwin\home\db3l\test\python2.7\lib\os.py", line 26, in import sys, errno KeyboardInterrupt # clear __builtin__._ # clear sys.path # clear sys.argv # clear sys.ps1 # clear sys.ps2 # clear sys.exitfunc # clear sys.exc_type # clear sys.exc_value # clear sys.exc_traceback # clear sys.last_type # clear sys.last_value # clear sys.last_traceback # clear sys.path_hooks # clear sys.path_importer_cache # clear sys.meta_path # clear sys.flags # clear sys.float_info # restore sys.stdin # restore sys.stdout # restore sys.stderr # cleanup __main__ # cleanup[1] zipimport # cleanup[1] errno # cleanup[1] signal # cleanup[1] exceptions # cleanup[1] _warnings # cleanup sys # cleanup __builtin__ [8991 refs] # cleanup ints: 6 unfreed ints # cleanup floats I never have a problem interrupting the process, so KeyboardInterrupt is processed normally - it just looks like it gets stuck in an infinite loop during startup. -- David ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 02:04:11 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 02 Jun 2015 00:04:11 +0000 Subject: [issue24342] coroutine wrapper reentrancy In-Reply-To: <1433124694.62.0.501554700121.issue24342@psf.upfronthosting.co.za> Message-ID: <1433203451.92.0.490258777482.issue24342@psf.upfronthosting.co.za> Nick Coghlan added the comment: Making sure I'm following the issue correctly here: 1. wrapper is a normal function, so there's no change for set_couroutine_wrapper() to detect anything might be amiss 2. any "async def" statement will call the registered coroutine wrapper to wrap the created function and turn it into a coroutine 3. this means any coroutine wrapper that directly or indirectly includes an "async def" statement will fail with RecursionError, without the problem being at all obvious 4. Yury's proposed patch effectively detects the use of "async def" inside a coroutine wrapper definition I like the idea in principle, I don't like the error message in the current patch (since it only makes sense if you already understand the chain of reasoning above). While it's a little verbose, I suggest an error like: "Coroutine wrapper %r attempted to recursively wrap %r", passing in the currently registered coroutine wrapper, and the code object we're attempting to wrap, respectively. The latter repr gives the name, filename and line number of the offending code object, while the former should give the qualname of the registered wrapper. The docs for set_coroutine_wrapper() should also be tweaked to note the constraint that the wrapper function cannot itself define new asynchronous functions (neither directly nor indirectly). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 02:08:23 2015 From: report at bugs.python.org (Cliff Dyer) Date: Tue, 02 Jun 2015 00:08:23 +0000 Subject: [issue24258] BZ2File objects do not have name attribute In-Reply-To: <1432199816.0.0.178283144298.issue24258@psf.upfronthosting.co.za> Message-ID: <1433203703.71.0.0485905244039.issue24258@psf.upfronthosting.co.za> Cliff Dyer added the comment: I've got a fix for this now. In working on it, I've discovered that not all file-like objects have a .name attribute. io.BytesIO (which is used all over the test suite) does not. I've written a patch that always creates a .name attribute on BZ2File, but sets it to None if the associated file-like object has no .name. See the linked branch ---------- hgrepos: +311 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 02:11:35 2015 From: report at bugs.python.org (Cliff Dyer) Date: Tue, 02 Jun 2015 00:11:35 +0000 Subject: [issue24258] BZ2File objects do not have name attribute In-Reply-To: <1432199816.0.0.178283144298.issue24258@psf.upfronthosting.co.za> Message-ID: <1433203895.72.0.808884281848.issue24258@psf.upfronthosting.co.za> Cliff Dyer added the comment: It's probably too late for this to get into 3.5, since we're already in betas. Pushing back to 3.6. ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 02:32:15 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Tue, 02 Jun 2015 00:32:15 +0000 Subject: [issue24353] NameError: name 'path_separators' is not defined In-Reply-To: <1433188316.2.0.247864565419.issue24353@psf.upfronthosting.co.za> Message-ID: <1433205135.08.0.908491422456.issue24353@psf.upfronthosting.co.za> Ionel Cristian M?rie? added the comment: Ooops, sorry for the noise, I had some weird breakage in my virtualenv. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 02:44:25 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 02 Jun 2015 00:44:25 +0000 Subject: [issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za> Message-ID: <1433205865.24.0.952254526541.issue11549@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 02:55:59 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 02 Jun 2015 00:55:59 +0000 Subject: [issue24355] Provide a unittest api for controlling verbosity in tests In-Reply-To: <1433190505.1.0.734052090716.issue24355@psf.upfronthosting.co.za> Message-ID: <1433206559.23.0.716739202148.issue24355@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 02:59:40 2015 From: report at bugs.python.org (Paul Marks) Date: Tue, 02 Jun 2015 00:59:40 +0000 Subject: [issue24357] www.python.org lost IPv6 connectivity Message-ID: <1433206780.04.0.828660872449.issue24357@psf.upfronthosting.co.za> New submission from Paul Marks: Python's web servers were formerly reachable from IPv6 clients, as evidenced by this example code for socket.getaddrinfo(): https://docs.python.org/3/library/socket.html#socket.getaddrinfo But today, www.python.org is IPv4-only: >>> import socket >>> socket.getaddrinfo("www.python.org", 80, proto=socket.IPPROTO_TCP) [(, , 6, '', ('23.235.40.223', 80))] Please either restore IPv6 connectivity to www.python.org, or accept the shame and defeat of pointing the documentation to someone else's domain. ---------- assignee: docs at python components: Documentation messages: 244625 nosy: Paul Marks, docs at python priority: normal severity: normal status: open title: www.python.org lost IPv6 connectivity _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 03:03:01 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 02 Jun 2015 01:03:01 +0000 Subject: [issue24358] Should compression file-like objects provide .fileno(), misleading subprocess? Message-ID: <1433206981.32.0.719516838977.issue24358@psf.upfronthosting.co.za> New submission from Josh Rosenberg: subprocess, when accepting objects for stdin, stdout, and stderr, assumes that possessing a .fileno() means it's a legitimate object for use with the forked process; that the file descriptor is interchangeable with the object itself. But gzip, bz2 and lzma file-like objects all violate this rule; they provide .fileno(), but it's unadorned. Providing .fileno() on these objects is misleading, since they produce the uncompressed data (likely useless) which causes subprocess to pass the "wrong" data to the subprocess, or write uncompressed data from the process (the exception being processes that expect compressed data from stdin or write compressed data to stdout, but that usually just means the compressor utilities themselves). Is subprocess's assumption about fileno() (that you can read equivalent data from it, modulo issues with flushing/seeking) intended? If so, should .fileno() be removed from the compressed file interfaces? If not, should subprocess attempt to perform further checking, document this wart, or something else? ---------- components: IO messages: 244626 nosy: josh.r priority: normal severity: normal status: open title: Should compression file-like objects provide .fileno(), misleading subprocess? versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 03:08:20 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 02 Jun 2015 01:08:20 +0000 Subject: [issue24347] unchecked return value in C OrderedDict In-Reply-To: <1433175550.71.0.808685138133.issue24347@psf.upfronthosting.co.za> Message-ID: <1433207300.9.0.343771493526.issue24347@psf.upfronthosting.co.za> Eric Snow added the comment: Using PyDict_GetItemWithError() is a good idea. Also, raising KeyError when the value is NULL (and no errors set) eliminates the crash. Here's a patch that fixes the problem. Unless there are any objections, I'll commit it in a couple hours. ---------- stage: test needed -> patch review Added file: http://bugs.python.org/file39591/issue24347.dif _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 03:11:15 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 01:11:15 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1433207475.23.0.574717624004.issue4753@psf.upfronthosting.co.za> R. David Murray added the comment: Please open a new issue with the details about your problem. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 03:12:07 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 02 Jun 2015 01:12:07 +0000 Subject: [issue24349] Null pointer dereferences in C OrderedDict In-Reply-To: <1433175874.7.0.776296707125.issue24349@psf.upfronthosting.co.za> Message-ID: <1433207527.2.0.360553966323.issue24349@psf.upfronthosting.co.za> Eric Snow added the comment: Correct me if I'm wrong, but this is a duplicate of the bug Stefan reported in issue24347. ---------- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> unchecked return value in C OrderedDict _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 03:16:45 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 02 Jun 2015 01:16:45 +0000 Subject: [issue24357] Change socket.getaddrinfo example to show IPv6 connectivity In-Reply-To: <1433206780.04.0.828660872449.issue24357@psf.upfronthosting.co.za> Message-ID: <1433207805.83.0.728763385933.issue24357@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report. According to the PSF Infrastructure Team, www.python.org currently does not support IPv6 because the Content Delivery Network that we now use does not support it yet. One Python URL that does support IPv6: >>> socket.getaddrinfo("hg.python.org", 80, proto=socket.IPPROTO_TCP) [(, , 6, '', ('2001:4802:7901:0:e60a:1375:0:4', 80, 0, 0)), (, , 6, '', ('104.130.43.97', 80))] ---------- keywords: +easy nosy: +ned.deily stage: -> needs patch title: www.python.org lost IPv6 connectivity -> Change socket.getaddrinfo example to show IPv6 connectivity versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 03:18:15 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 01:18:15 +0000 Subject: [issue24356] venv documentation incorrect / misleading In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za> Message-ID: <1433207895.56.0.15691890375.issue24356@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. We don't in general mention 2.7 in the python3 docs (in fact I found only one mention of it, in the logging package docs). I suppose this might be confusing enough to warrant it. But it might be better to rewrite that sentence to make it clear that the python binary you get in your virtual environment is the one that the venv command comes from. That should make it pretty clear you can't use it with 2.7, since 2.7 doesn't include venv. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 03:19:28 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 01:19:28 +0000 Subject: [issue24353] NameError: name 'path_separators' is not defined In-Reply-To: <1433188316.2.0.247864565419.issue24353@psf.upfronthosting.co.za> Message-ID: <1433207968.91.0.91857709161.issue24353@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 03:39:33 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 02 Jun 2015 01:39:33 +0000 Subject: [issue24358] Should compression file-like objects provide .fileno(), misleading subprocess? In-Reply-To: <1433206981.32.0.719516838977.issue24358@psf.upfronthosting.co.za> Message-ID: <1433209173.95.0.908562867035.issue24358@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Apparently similar issue occurs when tarfile assumes a GzipFile can have its fileno() fstat-ed (see #22468). An awful lot of libraries seem to assume that fileno() will provide useful information about the data you'd read from the file-like object itself, but all the compressed file-like objects violate that expectation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 03:58:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Jun 2015 01:58:02 +0000 Subject: [issue24357] Change socket.getaddrinfo example to show IPv6 connectivity In-Reply-To: <1433206780.04.0.828660872449.issue24357@psf.upfronthosting.co.za> Message-ID: <20150602015759.4340.72639@psf.io> Roundup Robot added the comment: New changeset b461d900fdb5 by Ned Deily in branch '3.4': Issue #24357: Change host in socket.getaddrinfo example to one that https://hg.python.org/cpython/rev/b461d900fdb5 New changeset 22b77f859521 by Ned Deily in branch '3.5': Issue #24357: merge from 3.4 https://hg.python.org/cpython/rev/22b77f859521 New changeset 7c7b1fffafdf by Ned Deily in branch 'default': Issue #24357: merge from 3.5 https://hg.python.org/cpython/rev/7c7b1fffafdf New changeset 30da21d2fa4f by Ned Deily in branch '2.7': Issue #24357: Change host in socket.getaddrinfo example to one that https://hg.python.org/cpython/rev/30da21d2fa4f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 04:06:51 2015 From: report at bugs.python.org (Graham Oliver) Date: Tue, 02 Jun 2015 02:06:51 +0000 Subject: [issue24356] venv documentation incorrect / misleading In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za> Message-ID: <1433210811.41.0.644784154893.issue24356@psf.upfronthosting.co.za> Graham Oliver added the comment: ok current version Each virtual environment has its own Python binary (allowing creation of environments with various Python versions) and can have its own independent set of installed Python packages in its site directories. Suggested Alternative Each virtual environment has its own isolated Python binary (which matches the version used to create it) and can have its own independent set of installed Python packages in its site directories. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 04:07:53 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 02 Jun 2015 02:07:53 +0000 Subject: [issue24342] coroutine wrapper reentrancy In-Reply-To: <1433124694.62.0.501554700121.issue24342@psf.upfronthosting.co.za> Message-ID: <1433210873.83.0.843889954588.issue24342@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks, Nick! I'll commit the patch with your error message (it's much better!) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 04:11:56 2015 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 02 Jun 2015 02:11:56 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1433211116.68.0.931751928969.issue2771@psf.upfronthosting.co.za> Ezio Melotti added the comment: test after roundup upgrade ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 04:13:02 2015 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 02 Jun 2015 02:13:02 +0000 Subject: [issue2771] Test issue In-Reply-To: <1433211116.68.0.931751928969.issue2771@psf.upfronthosting.co.za> Message-ID: Ezio Melotti added the comment: test message via email ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 04:24:55 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Jun 2015 02:24:55 +0000 Subject: [issue24357] Change socket.getaddrinfo example to show IPv6 connectivity In-Reply-To: <1433206780.04.0.828660872449.issue24357@psf.upfronthosting.co.za> Message-ID: <20150602022451.91795.3440@psf.io> Roundup Robot added the comment: New changeset acf4dbd99d11 by Ned Deily in branch '3.4': Issue #24357: fix typo https://hg.python.org/cpython/rev/acf4dbd99d11 New changeset fcb415e5b40b by Ned Deily in branch '3.5': Issue #24357: merge from 3.4 https://hg.python.org/cpython/rev/fcb415e5b40b New changeset 74ff057c2c83 by Ned Deily in branch 'default': Issue #24357: merge from 3.5 https://hg.python.org/cpython/rev/74ff057c2c83 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 04:30:31 2015 From: report at bugs.python.org (Carol Willing) Date: Tue, 02 Jun 2015 02:30:31 +0000 Subject: [issue24356] venv documentation incorrect / misleading In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za> Message-ID: <1433212231.71.0.77577503315.issue24356@psf.upfronthosting.co.za> Carol Willing added the comment: Current version Each virtual environment has its own Python binary (allowing creation of environments with various Python versions) and can have its own independent set of installed Python packages in its site directories. Another suggested revision Since its introduction in Python 3.3, venv may be used to create a virtual environment with its own Python binary and optionally its own independent set of installed Python packages in its site directories. Multiple virtual environments permit various Python versions to exist on a system. David and Graham, Perhaps moving the "see also" box (see also Python Packaging User Guide: Creating and using virtual environments) closer to the top, perhaps under the pep reference, would be helpful for the user. Virtual environments are confusing for those new to Python since there are many "env"s such as venv, pyvenv, virtualenv, virtualenvwrapper, pyenv tool, and myenv used in many examples. Carol ---------- nosy: +willingc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 04:37:47 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 02:37:47 +0000 Subject: [issue24356] venv documentation incorrect / misleading In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za> Message-ID: <1433212667.71.0.646167931469.issue24356@psf.upfronthosting.co.za> R. David Murray added the comment: I think Graham's formulation provides more information. venv already has a "new in python 3.3" at the top (just before that sentence), so putting that in the text feels redundant. On the other hand, the current placement of the 'see also' box looks odd, unless the packaging authority doesn't mention virtual environments on Windows (and if it doesn't, it should!). I agree that moving that up to just after the PEP reference is probably a good idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 04:39:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Jun 2015 02:39:15 +0000 Subject: [issue24357] Change socket.getaddrinfo example to show IPv6 connectivity In-Reply-To: <1433206780.04.0.828660872449.issue24357@psf.upfronthosting.co.za> Message-ID: <20150602023912.83489.98264@psf.io> Roundup Robot added the comment: New changeset fb12d742b70c by Ned Deily in branch '3.4': Issue #24357: fix real typo https://hg.python.org/cpython/rev/fb12d742b70c New changeset 5bfa78bf0607 by Ned Deily in branch '3.5': Issue #24357: merge from 3.4 https://hg.python.org/cpython/rev/5bfa78bf0607 New changeset 421847aa0b22 by Ned Deily in branch 'default': Issue #24357: merge from 3.5 https://hg.python.org/cpython/rev/421847aa0b22 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 04:41:15 2015 From: report at bugs.python.org (Carol Willing) Date: Tue, 02 Jun 2015 02:41:15 +0000 Subject: [issue24356] venv documentation incorrect / misleading In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za> Message-ID: <1433212875.82.0.321356770013.issue24356@psf.upfronthosting.co.za> Carol Willing added the comment: David, Sounds good to me. I'll submit a patch with Graham's suggested text and move the See also box up right after the PEP reference. Thanks, Carol ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 04:45:04 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 02 Jun 2015 02:45:04 +0000 Subject: [issue24357] Change socket.getaddrinfo example to show IPv6 connectivity In-Reply-To: <1433206780.04.0.828660872449.issue24357@psf.upfronthosting.co.za> Message-ID: <1433213104.19.0.915096913929.issue24357@psf.upfronthosting.co.za> Ned Deily added the comment: We decided to use google.com as an example instead. (And I tested the tracker upgrade by fixing the wrong initial typo that I had made.) ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 04:48:42 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 02 Jun 2015 02:48:42 +0000 Subject: [issue22442] Deprecate PIPE with subprocess.check_call() and call() In-Reply-To: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za> Message-ID: <1433213322.06.0.553810191241.issue22442@psf.upfronthosting.co.za> Martin Panter added the comment: I agree with the deprecation idea. The parameter checking logic doesn?t seem right though; see Reitveld. Also, I would have made the warning specify exactly what is deprecated, in case the stack trace doesn?t identify the function, which I think would always happen with check_call(). Also be less specific about future changes, unless there is clear consensus to make this change in 3.6. Maybe something like: "Passing PIPE to call() and check_call() is deprecated; use DEVNULL instead to discard output or provide empty input" Since 3.5 is now in the beta phase, would adding this deprecation be allowed, or should it be deferred to the 3.6 branch? Also, I?m not sure what the policy is for Python 2. Maybe it would be acceptable as a Python 3 compatibility warning, triggered by the ?python2 -3? option; I dunno. ---------- components: -Windows nosy: +vadmium stage: -> needs patch title: subprocess.check_call hangs on large PIPEd data. -> Deprecate PIPE with subprocess.check_call() and call() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 06:16:30 2015 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 02 Jun 2015 04:16:30 +0000 Subject: [issue22442] Deprecate PIPE with subprocess.check_call() and call() In-Reply-To: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za> Message-ID: <1433218590.21.0.00485141197883.issue22442@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: 3.5 have `subprocess.run`[1] that is much saner to use, and what you want to use in most cases. `call` and `check_call` docs even mention run. [1]: https://docs.python.org/3.5/library/subprocess.html#subprocess.run ---------- nosy: +mbussonn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 06:22:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Jun 2015 04:22:16 +0000 Subject: [issue24357] Change socket.getaddrinfo example to show IPv6 connectivity In-Reply-To: <1433206780.04.0.828660872449.issue24357@psf.upfronthosting.co.za> Message-ID: <20150602042213.91787.33670@psf.io> Roundup Robot added the comment: New changeset 5ae3418fe63e by Ned Deily in branch '2.7': Issue #24357: use example.org instead https://hg.python.org/cpython/rev/5ae3418fe63e New changeset dbf3aa36bea7 by Ned Deily in branch '3.4': Issue #24357: use example.org instead https://hg.python.org/cpython/rev/dbf3aa36bea7 New changeset d751900d0406 by Ned Deily in branch '3.5': Issue #24357: merge from 3.4 https://hg.python.org/cpython/rev/d751900d0406 New changeset e09cefe1e5b8 by Ned Deily in branch 'default': Issue #24357: merge from 3.5 https://hg.python.org/cpython/rev/e09cefe1e5b8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 06:36:56 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 02 Jun 2015 04:36:56 +0000 Subject: [issue5319] stdout error at interpreter shutdown fails to return OS error status In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za> Message-ID: <1433219816.16.0.861507084886.issue5319@psf.upfronthosting.co.za> Martin Panter added the comment: Updated patch resolving minor merge conflicts with current code, a coding style fix, and some tweaks and syntax fixes to the documentation. ---------- stage: -> patch review versions: +Python 3.5, Python 3.6 -Python 3.1, Python 3.2 Added file: http://bugs.python.org/file39592/finalize-error.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 06:59:51 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 02 Jun 2015 04:59:51 +0000 Subject: [issue12020] Attribute error with flush on stdout,stderr In-Reply-To: <1304703877.7.0.898555574271.issue12020@psf.upfronthosting.co.za> Message-ID: <1433221191.4.0.187395834887.issue12020@psf.upfronthosting.co.za> Martin Panter added the comment: I wouldn?t expect to see a message for stderr because there is nowhere else to send the message. However with my patch for Issue 5319, at least we get a non-zero exit status. Brandon: I agree this should be under sys.stdin/out/err; I wasn?t saying to put it under the io.TextIOBase documentation. What I meant was one option would be to refer to that class as a duck-typing API. Say something like: ?sys.stdout [etc] may be replaced with other objects, as long as they implement [the write-only parts, etc of] the TextIOBase API [optionally ?buffer? etc]?. Exact details to be determined. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 07:06:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Jun 2015 05:06:37 +0000 Subject: [issue24347] unchecked return value in C OrderedDict In-Reply-To: <1433175550.71.0.808685138133.issue24347@psf.upfronthosting.co.za> Message-ID: <20150602050634.4326.12695@psf.io> Roundup Robot added the comment: New changeset 1a7c34e23ec9 by Eric Snow in branch '3.5': Issue #24347: Set KeyError if PyDict_GetItemWithError returns NULL. https://hg.python.org/cpython/rev/1a7c34e23ec9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 07:07:09 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 02 Jun 2015 05:07:09 +0000 Subject: [issue24347] unchecked return value in C OrderedDict In-Reply-To: <1433175550.71.0.808685138133.issue24347@psf.upfronthosting.co.za> Message-ID: <1433221629.18.0.216396773186.issue24347@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 07:14:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Jun 2015 05:14:48 +0000 Subject: [issue24348] incorrect decref in C OrderedDict In-Reply-To: <1433175716.41.0.847645147456.issue24348@psf.upfronthosting.co.za> Message-ID: <20150602051445.111604.44168@psf.io> Roundup Robot added the comment: New changeset 8631b88c23f6 by Eric Snow in branch '3.5': Issue #24348: Drop superfluous increfs/decrefs. https://hg.python.org/cpython/rev/8631b88c23f6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 07:15:22 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 02 Jun 2015 05:15:22 +0000 Subject: [issue24348] incorrect decref in C OrderedDict In-Reply-To: <1433175716.41.0.847645147456.issue24348@psf.upfronthosting.co.za> Message-ID: <1433222122.29.0.864358402848.issue24348@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 07:21:56 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 02 Jun 2015 05:21:56 +0000 Subject: [issue24359] C OrderedDict needs to check for changes during iteration Message-ID: <1433222516.05.0.83881283764.issue24359@psf.upfronthosting.co.za> New submission from Eric Snow: Currently test_detect_deletion_during_iteration is disabled for the C implementation of OrderedDict. The test needs to pass after being enabled. ---------- assignee: eric.snow components: Library (Lib) messages: 244651 nosy: eric.snow priority: release blocker severity: normal stage: needs patch status: open title: C OrderedDict needs to check for changes during iteration type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 07:34:16 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 02 Jun 2015 05:34:16 +0000 Subject: [issue24358] Should compression file-like objects provide .fileno(), misleading subprocess? In-Reply-To: <1433206981.32.0.719516838977.issue24358@psf.upfronthosting.co.za> Message-ID: <1433223256.26.0.243057295509.issue24358@psf.upfronthosting.co.za> Martin Panter added the comment: Also related: Issue 23740, where the HTTP client assumes it can use stat() on the fileno() to determine the Content-Length. Providing fileno() on file wrapper objects like GzipFile is certainly not necessary, but it could be useful. For instance in the tarfile case, the modification time, file mode, owner user, etc may still be useful even if the file size isn?t. On the other hand, fileno() is a low level operation, so maybe it should only have been made available on light-weight RawIOBase objects or something. Even for a BufferedReader/Writer or TextIOWrapper, the data read from or written to the Python-level file object does not match the corresponding file descriptor operations. You could get deadlocks, data loss, etc, due to buffering. For example the commented-out-code near the bottom of . The subprocess module documentation only says that the streams can be ?existing file objects?. I think it should at least be clarified to say the file objects are taken to represent OS-level file descriptors. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 07:40:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Jun 2015 05:40:11 +0000 Subject: [issue24359] C OrderedDict needs to check for changes during iteration In-Reply-To: <1433222516.05.0.83881283764.issue24359@psf.upfronthosting.co.za> Message-ID: <20150602054008.89791.26799@psf.io> Roundup Robot added the comment: New changeset 141eb4d1b766 by Eric Snow in branch '3.5': Issue #24359: Check for changed OrderedDict size during iteration. https://hg.python.org/cpython/rev/141eb4d1b766 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 07:40:57 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 02 Jun 2015 05:40:57 +0000 Subject: [issue24359] C OrderedDict needs to check for changes during iteration In-Reply-To: <1433222516.05.0.83881283764.issue24359@psf.upfronthosting.co.za> Message-ID: <1433223657.8.0.00454159715744.issue24359@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 08:00:19 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 02 Jun 2015 06:00:19 +0000 Subject: [issue24267] test_venv.EnsurePipTest.test_with_pip triggers version check over network In-Reply-To: <1432363202.9.0.592751761498.issue24267@psf.upfronthosting.co.za> Message-ID: <1433224819.34.0.856732906459.issue24267@psf.upfronthosting.co.za> Ned Deily added the comment: All of the 3.x buildbots are broken again due to the pip 7.0.3 update. ====================================================================== FAIL: test_with_pip (test.test_venv.EnsurePipTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildbot/slaves/profile-opt-bot/3.5.gps-debian-profile-opt/build/Lib/test/test_venv.py", line 390, in test_with_pip self.assertEqual(err, "") AssertionError: "You are using pip version 7.0.1, however[102 chars]d.\n" != '' - You are using pip version 7.0.1, however version 7.0.3 is available. - You should consider upgrading via the 'pip install --upgrade pip' command. ---------- nosy: +ned.deily priority: normal -> critical versions: +Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 08:00:51 2015 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 02 Jun 2015 06:00:51 +0000 Subject: [issue24360] improve argparse.Namespace __repr__ for invalid identifiers. Message-ID: <1433224851.97.0.184092285023.issue24360@psf.upfronthosting.co.za> New submission from Matthias Bussonnier: The argparse Namespace can be missleading in case where the args names are not valid identifiers, eg thinks like a closing bracket: In [5]: Namespace(a=1, **{')':3}) Out[5]: Namespace()=3, a=1) more funny: In [3]: Namespace(a=1, **{s:3}) Out[3]: Namespace(a=1, b=2), Namespace(c=3) for `s = 'b=2), Namespace(c'` With this patch the args that are not valid identifiers are shown in ** unpacked-dict, which has the side effect of almost always having repr(eval(repr(obj)))== repr(obj). I'm sure we can find counter example with quotes and triple-quoted string... but anyway. with this patch (indentation mine for easy comparison): >>> from argparse import Namespace >>> Namespace(a=1, **{')': 3}) Namespace(a=1, **{')': 3}) Which is I think what most user would expect. Test passes locally (except SSL cert, network thingies, curses and threaded_lru_cache) which look unrelated and is most likely due to my machine. ---------- components: Library (Lib) files: improve-namespace-repr.patch keywords: patch messages: 244655 nosy: mbussonn priority: normal severity: normal status: open title: improve argparse.Namespace __repr__ for invalid identifiers. type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file39593/improve-namespace-repr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 08:04:09 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 02 Jun 2015 06:04:09 +0000 Subject: [issue24308] Test failure: test_with_pip (test.test_venv.EnsurePipTest in 3.x In-Reply-To: <1432782572.48.0.713630416896.issue24308@psf.upfronthosting.co.za> Message-ID: <1433225049.33.0.547432085015.issue24308@psf.upfronthosting.co.za> Ned Deily added the comment: This is covered by Issue24267; let's track it there. ---------- nosy: +ned.deily resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> test_venv.EnsurePipTest.test_with_pip triggers version check over network _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 09:23:25 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 02 Jun 2015 07:23:25 +0000 Subject: [issue24360] improve argparse.Namespace __repr__ for invalid identifiers. In-Reply-To: <1433224851.97.0.184092285023.issue24360@psf.upfronthosting.co.za> Message-ID: <1433229805.6.0.762376920295.issue24360@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 09:38:11 2015 From: report at bugs.python.org (Mike Frysinger) Date: Tue, 02 Jun 2015 07:38:11 +0000 Subject: [issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping. In-Reply-To: <1432750979.18.0.523128349285.issue24303@psf.upfronthosting.co.za> Message-ID: <1433230691.43.0.648222354877.issue24303@psf.upfronthosting.co.za> Mike Frysinger added the comment: the original report on our side w/bunches of tracebacks: http://crbug.com/481223 with that traceback in hand, it's pretty trivial to write a reproduction :). attached! i couldn't figure out how to make it work w/out completely execing a new python instance. i suspect the internals were communicating and thus defeating the race. the unshare() might need some checks so that it skips on older kernels or ones with pidns support disabled. but i don't have any such system anymore ;). if all goes well, it should fail fairly quickly: $ python3.3 ./test.py Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.3/multiprocessing/__init__.py", line 187, in Event return Event() File "/usr/lib64/python3.3/multiprocessing/synchronize.py", line 293, in __init__ self._cond = Condition(Lock()) File "/usr/lib64/python3.3/multiprocessing/synchronize.py", line 174, in __init__ self._wait_semaphore = Semaphore(0) File "/usr/lib64/python3.3/multiprocessing/synchronize.py", line 84, in __init__ SemLock.__init__(self, SEMAPHORE, value, SEM_VALUE_MAX) File "/usr/lib64/python3.3/multiprocessing/synchronize.py", line 48, in __init__ sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) FileExistsError: [Errno 17] File exists failed and doesn't take that long to pass: $ time python3.4 ./test-issue24303.py passed! real 0m1.715s ---------- Added file: http://bugs.python.org/file39594/test-issue24303.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 09:45:32 2015 From: report at bugs.python.org (Mike Frysinger) Date: Tue, 02 Jun 2015 07:45:32 +0000 Subject: [issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping. In-Reply-To: <1432750979.18.0.523128349285.issue24303@psf.upfronthosting.co.za> Message-ID: <1433231132.36.0.730828295551.issue24303@psf.upfronthosting.co.za> Mike Frysinger added the comment: also, it looks like this bug is in python-3.3. not sure what the status of that branch is, but maybe the backport from 3.4 would be easy ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 10:36:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Jun 2015 08:36:58 +0000 Subject: [issue24360] improve argparse.Namespace __repr__ for invalid identifiers. In-Reply-To: <1433224851.97.0.184092285023.issue24360@psf.upfronthosting.co.za> Message-ID: <1433234218.04.0.459967464189.issue24360@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- nosy: +bethard, serhiy.storchaka stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 10:39:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Jun 2015 08:39:10 +0000 Subject: [issue24358] Should compression file-like objects provide .fileno(), misleading subprocess? In-Reply-To: <1433206981.32.0.719516838977.issue24358@psf.upfronthosting.co.za> Message-ID: <1433234350.77.0.891712570522.issue24358@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +benjamin.peterson, pitrou, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 10:41:32 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 02 Jun 2015 08:41:32 +0000 Subject: [issue24267] test_venv.EnsurePipTest.test_with_pip triggers version check over network In-Reply-To: <1432363202.9.0.592751761498.issue24267@psf.upfronthosting.co.za> Message-ID: <1433234492.3.0.536077113573.issue24267@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 11:49:59 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 02 Jun 2015 09:49:59 +0000 Subject: [issue24267] test_venv.EnsurePipTest.test_with_pip triggers version check over network In-Reply-To: <1432363202.9.0.592751761498.issue24267@psf.upfronthosting.co.za> Message-ID: <1433238599.19.0.581402774179.issue24267@psf.upfronthosting.co.za> Nick Coghlan added the comment: Adding the "--disable-pip-version-check" option doesn't make the warning go away, and apparently the already passed "--no-index" flag is supposed to imply that one anyway: ================== --disable-pip-version-check Don't periodically check PyPI to determine whether a new version of pip is available for download. Implied with --no-index. ================== Filed https://github.com/pypa/pip/issues/2860, reassigning to Donald and adding Paul to the nosy list. ---------- assignee: ncoghlan -> dstufft nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 12:02:57 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 02 Jun 2015 10:02:57 +0000 Subject: [issue24361] OrderedDict: crash with threads Message-ID: <1433239377.83.0.708657008711.issue24361@psf.upfronthosting.co.za> New submission from Stefan Krah: I tried to disprove my own claim of unreachable code in resize()/get_index() using a convoluted threaded test case. The code still fails to be reached, but another segfault turned up. ---------- components: Extension Modules files: crash-th.py messages: 244661 nosy: Arfrever, BreamoreBoy, Jim.Jewett, Mark.Shannon, Ryan.Gonzalez, alex, asvetlov, benjamin.peterson, christian.heimes, eric.araujo, eric.smith, eric.snow, ezio.melotti, flox, gregory.p.smith, introom, josh.r, mrabarnett, ncoghlan, ned.deily, pitrou, python-dev, rhettinger, scoder, serhiy.storchaka, skrah, tonn81, westurner, yselivanov priority: normal severity: normal stage: needs patch status: open title: OrderedDict: crash with threads type: crash versions: Python 3.6 Added file: http://bugs.python.org/file39595/crash-th.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 12:08:55 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Jun 2015 10:08:55 +0000 Subject: [issue5319] stdout error at interpreter shutdown fails to return OS error status In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za> Message-ID: <1433239735.87.0.891076987529.issue5319@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't know how acceptable it is to add a return value to Py_Finalize(). Can it break the stable ABI? ---------- nosy: +loewis, steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 12:32:32 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 02 Jun 2015 10:32:32 +0000 Subject: [issue24358] Should compression file-like objects provide .fileno(), misleading subprocess? In-Reply-To: <1433206981.32.0.719516838977.issue24358@psf.upfronthosting.co.za> Message-ID: <1433241152.62.0.241306087578.issue24358@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Blech, typo earlier "since they produce the *compressed* data (likely useless) when read as subprocess stdin". Context should make it obvious, but trying to be clear. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 12:43:10 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 02 Jun 2015 10:43:10 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433241790.02.0.499203221193.issue16991@psf.upfronthosting.co.za> Stefan Krah added the comment: It's fine to open other issues, but I'm not happy with the resize()/get_index() situation. Currently I can't come up even with an informal "proof" that it'll always work (and see #24361). I think these functions really *need* 100% code coverage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 13:49:20 2015 From: report at bugs.python.org (Christian Heimes) Date: Tue, 02 Jun 2015 11:49:20 +0000 Subject: [issue23239] SSL match_hostname does not accept IP Address In-Reply-To: <1421226292.77.0.451398063166.issue23239@psf.upfronthosting.co.za> Message-ID: <1433245760.57.0.670143196706.issue23239@psf.upfronthosting.co.za> Christian Heimes added the comment: The patch has a couple of issues 1) match_hostname()'s doc string needs to be updated. It still contains "but IP addresses are not accepted for *hostname*" 2) The stdlib uses server_hostname for SNI and matching. An IP address in the SNI TLS extension violates RF 3546 https://tools.ietf.org/html/rfc3546#page-9 Literal IPv4 and IPv6 addresses are not permitted in "HostName". 3) The code doesn't match IP addresses in dNSName and DNS names in IP Address fields. Hynek's service identity module and Mozilla's NSS [1] agree with you. As far as I have studied OpenSSL 1.0.2, it has a different opinion. I'm in favor for the current check. I suggest to document the decision in the code and raise a more explicit exception. The current message is a bit confusing: ssl.CertificateError: hostname '127.0.0.1' doesn't match '127.0.0.1' 4) The code doesn't check the CN field for IP address as NSS does. [2] In order to fix 2) and make the check more explicit I like to suggest an API change. Don't convert the host name to an IP address implicitly. If the user wants to validate an IP address, then she must pass in an ipaddress object as server_hostname. In that case SSLSocket.server_hostname is set to the ipaddress object. socket._wrap_socket() is called with server_hostname=None for ipaddress. That fixes the RFC violation. [1] cert_VerifySubjectAltName() https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/certdb/certdb.c#1427 [2] CERT_VerifyCertName https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/certdb/certdb.c#1769 ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 15:11:19 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 02 Jun 2015 13:11:19 +0000 Subject: [issue5319] stdout error at interpreter shutdown fails to return OS error status In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za> Message-ID: <1433250679.1.0.979562966545.issue5319@psf.upfronthosting.co.za> Steve Dower added the comment: Going from void to int is fine for when the return value is ignored. However, those who check the return value will see garbage on earlier versions. As always, safest to add a new function here. Or make the stable version continue to be void - it won't affect the exports. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 16:00:31 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 02 Jun 2015 14:00:31 +0000 Subject: [issue24362] Simplify the fast nodes resize logic in C OrderedDict. Message-ID: <1433253631.63.0.422253960427.issue24362@psf.upfronthosting.co.za> New submission from Eric Snow: Between comments on issue16991 and review comments there, it's clear that the implementation of _odict_resize and _odict_get_index in Objects/odictobject.c are too complicated to be a long-term solution. simplifying the approach to avoid recursion should help substantially. ---------- assignee: eric.snow components: Library (Lib) messages: 244667 nosy: eric.snow, skrah priority: release blocker severity: normal stage: needs patch status: open title: Simplify the fast nodes resize logic in C OrderedDict. versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 16:01:03 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 02 Jun 2015 14:01:03 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433253663.25.0.942304442615.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Addressing the concerns with resize()/get_index() is next on my list. I had meant to open up an issue on it last night but it was getting pretty late for me and it slipped my mind. I've opened issue24362 to track that work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 16:37:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Jun 2015 14:37:19 +0000 Subject: [issue24267] test_venv.EnsurePipTest.test_with_pip triggers version check over network In-Reply-To: <1432363202.9.0.592751761498.issue24267@psf.upfronthosting.co.za> Message-ID: <20150602143712.18161.21600@psf.io> Roundup Robot added the comment: New changeset aaa015dde686 by Donald Stufft in branch '3.4': Closes #24267 - Does not check version on ensurepip uninstall https://hg.python.org/cpython/rev/aaa015dde686 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 16:38:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Jun 2015 14:38:33 +0000 Subject: [issue24267] test_venv.EnsurePipTest.test_with_pip triggers version check over network In-Reply-To: <1432363202.9.0.592751761498.issue24267@psf.upfronthosting.co.za> Message-ID: <20150602143832.18662.48949@psf.io> Roundup Robot added the comment: New changeset f39e9bcd789b by Donald Stufft in branch '3.5': Merge the fix for #24267 https://hg.python.org/cpython/rev/f39e9bcd789b New changeset 6dffea6134ad by Donald Stufft in branch 'default': Merge the fix for #24267 https://hg.python.org/cpython/rev/6dffea6134ad ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 16:54:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Jun 2015 14:54:44 +0000 Subject: [issue24267] test_venv.EnsurePipTest.test_with_pip triggers version check over network In-Reply-To: <1432363202.9.0.592751761498.issue24267@psf.upfronthosting.co.za> Message-ID: <20150602145441.4346.5197@psf.io> Roundup Robot added the comment: New changeset 02d214716367 by Donald Stufft in branch '2.7': Issue #24267 - Ensure that pip version check is disabled on uninstall https://hg.python.org/cpython/rev/02d214716367 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 17:06:03 2015 From: report at bugs.python.org (Michael Del Monte) Date: Tue, 02 Jun 2015 15:06:03 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers Message-ID: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> New submission from Michael Del Monte: Initially reported at https://github.com/kennethreitz/requests/issues/2622 Closely related to http://bugs.python.org/issue19996 An HTTP response with an invalid header line that contains non-blank characters but *no* colon (contrast http://bugs.python.org/issue19996 in which it contained a colon as the first character) causes the same behavior. httplib.HTTPMessage.readheaders() oddly does not appear even to attempt to follow RFC 2616, which requires the header to terminate with a blank line. The invalid header line, which admittedly also breaks RFC 2616, is at least non-blank and should not terminate the header. Yet readheaders() takes it as an indicator that the header is over and then fails properly to process the rest of the response. The problem is exacerbated by a chunked encoding, which will not be properly received if the encoding header is not seen because readheaders() terminates early. An example (why are banks always the miscreants here?) is: p = response.get("http://www.merrickbank.com/") My recommended fix would be to insert these lines at httplib:327 # continue reading headers on non-blank lines elif not len(line.strip()): continue # break only on blank lines This would cause readheaders() to terminate only on a non-blank non-header non-comment line, in accordance with RFC 2616. ---------- components: Library (Lib) messages: 244672 nosy: mgdelmonte priority: normal severity: normal status: open title: httplib fails to handle semivalid HTTP headers type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 17:22:40 2015 From: report at bugs.python.org (Ian Cordasco) Date: Tue, 02 Jun 2015 15:22:40 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433258560.37.0.0132815584046.issue24363@psf.upfronthosting.co.za> Ian Cordasco added the comment: FWIW, the proper section to reference now is 3.2 in RFC 7230 (https://tools.ietf.org/html/rfc7230#section-3.2) ---------- nosy: +icordasc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 17:24:44 2015 From: report at bugs.python.org (Ian Cordasco) Date: Tue, 02 Jun 2015 15:24:44 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433258684.53.0.435677735178.issue24363@psf.upfronthosting.co.za> Ian Cordasco added the comment: Also I'm marking this as affecting 3.3, 3.4, and 3.5. I haven't tested against 3.5, but it definitely fails on 3.4. I hope to be able to test against 3.5.0b2 tonight ---------- versions: +Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 17:47:17 2015 From: report at bugs.python.org (Michael Del Monte) Date: Tue, 02 Jun 2015 15:47:17 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433260037.81.0.616133132394.issue24363@psf.upfronthosting.co.za> Michael Del Monte added the comment: Thanks. Also I meant to have said, "...to terminate only on a *blank* non-header non-comment line, in accordance with RFC 2616 (and 7230)." I note that the RFCs require CRLF to terminate but in my experience you can get all manner of "blank" lines, so accepting len(line.strip())==0 is going to accommodate servers that give CRCR or LFLF or (and I have seen this) LFCRLF. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 18:08:58 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 16:08:58 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433261338.34.0.794386874417.issue24363@psf.upfronthosting.co.za> R. David Murray added the comment: The current behavior probably comes out of the RFC822 world, where when seeing a line that doesn't look like a header the error recovery is to treat that line as the beginning of the body (ie: assume the blank line is missing). Is there in fact any guidance on what the optimal error recovery strategy is for http? I've actually considered trying to make the error recovery in email smarter, by seeing if the *next* line looks like a header before making the decision. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 18:27:05 2015 From: report at bugs.python.org (Felipe) Date: Tue, 02 Jun 2015 16:27:05 +0000 Subject: [issue23078] unittest.mock patch autospec doesn't work on staticmethods In-Reply-To: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za> Message-ID: <1433262425.31.0.525646895913.issue23078@psf.upfronthosting.co.za> Felipe added the comment: Regarding Claudiu's comment about `staticmethod(x)` or `classmethod(x)` not being callable, would it suffice to add a specific check of the form `(isinstance(x, (classmethod, staticmethod)) and _callable(x.__func__))`? Separately, would it be better to include the check for `staticmethod` and `classmethod` objects (with an underlying callable) inside the `_callable` function? Not sure if this would break anything, but it seems like conceptually the issue is with the definition of a callable object, not the selection of mock type to use. ---------- nosy: +fov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 18:28:01 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 16:28:01 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433262481.26.0.956385695526.issue24363@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, in fact that's exactly where it comes from, since httplib uses the email header parsing code. In python3 we are actually using the email package to parse the headers (which is sensible) (in 2.7 it is a copy of code from the old mimelib with some tweaks). Fixing this in python3 is best done by making the error recovery enhancement(s) I mentioned in the email package. Please note that changing this behavior has the potential to break working code. That is, just as we have here a server that is out of spec and sending invalid links in the middle of headers, we may have a server that is out of spec by not sending the blank delimiter, which is currently being handled "correctly". Thus I don't think your simple fix is advisable, instead I think we should pursue the more complicated "look ahead" fix. ---------- versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 18:28:55 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 16:28:55 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433262535.78.0.972610071125.issue24363@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +email keywords: +easy nosy: +barry stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 18:39:13 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 16:39:13 +0000 Subject: [issue24364] Not all defects pass through email policy Message-ID: <1433263153.11.0.33312264244.issue24364@psf.upfronthosting.co.za> New submission from R. David Murray: This is a note to myself. While looking at another issue I noticed that I never completed the work to make sure that all message defects discovered by feedparser are passed through the policy defect handler. The fix is simple, the time consuming part is writing the tests. ---------- components: email keywords: easy messages: 244679 nosy: barry, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Not all defects pass through email policy type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 19:37:51 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 02 Jun 2015 17:37:51 +0000 Subject: [issue24266] raw_input + readline: Ctrl+C during search breaks readline In-Reply-To: <1432306683.9.0.470835567306.issue24266@psf.upfronthosting.co.za> Message-ID: <1433266671.49.0.675553287374.issue24266@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The patch is two lines, but I do not know our general policy for working around bugs in external modules. I do know that Idle has workarounds for tk bugs (or 'os-dependencies'). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 19:39:58 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 02 Jun 2015 17:39:58 +0000 Subject: [issue24320] Remove a now-unnecessary workaround from importlib._bootstrap. In-Reply-To: <1432852496.91.0.597570741784.issue24320@psf.upfronthosting.co.za> Message-ID: <1433266798.7.0.358344660079.issue24320@psf.upfronthosting.co.za> Eric Snow added the comment: https://hg.python.org/cpython/rev/5c4ba50f6a57 I'll see if that does it. @Larry, would you be opposed to dropping the hack for beta 3? That would mean just deleting the last 2 lines in Lib/importlib/_bootstrap_external.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 19:47:07 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 17:47:07 +0000 Subject: [issue24266] raw_input + readline: Ctrl+C during search breaks readline In-Reply-To: <1432306683.9.0.470835567306.issue24266@psf.upfronthosting.co.za> Message-ID: <1433267227.02.0.769560736844.issue24266@psf.upfronthosting.co.za> R. David Murray added the comment: I believe that in general we do do workarounds if they don't make the code too complicated and upstream hasn't solved the problem (or we need to support older upstream versions). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 20:17:25 2015 From: report at bugs.python.org (sping) Date: Tue, 02 Jun 2015 18:17:25 +0000 Subject: [issue24266] raw_input + readline: Ctrl+C during search breaks readline In-Reply-To: <1432306683.9.0.470835567306.issue24266@psf.upfronthosting.co.za> Message-ID: <1433269045.35.0.360420381699.issue24266@psf.upfronthosting.co.za> sping added the comment: I guess supporting older upstream versions would be nice in this case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 20:54:59 2015 From: report at bugs.python.org (Petr Viktorin) Date: Tue, 02 Jun 2015 18:54:59 +0000 Subject: [issue24365] Conditionalize 3.5 additions to the stable API Message-ID: <1433271299.64.0.126998075643.issue24365@psf.upfronthosting.co.za> New submission from Petr Viktorin: I have sent patches to 3.5 that add new stable API, and later I learned [0] that additions should be conditional on the value of Py_LIMITED_API. This patch adds #ifdef blocks for what was added in issues #24268 and #24345. [0] https://mail.python.org/pipermail/python-dev/2015-June/140425.html ---------- components: Extension Modules, Interpreter Core files: guard-stable-api.patch keywords: patch messages: 244684 nosy: encukou priority: normal severity: normal status: open title: Conditionalize 3.5 additions to the stable API versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39596/guard-stable-api.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 20:56:02 2015 From: report at bugs.python.org (Petr Viktorin) Date: Tue, 02 Jun 2015 18:56:02 +0000 Subject: [issue24365] Conditionalize 3.5 additions to the stable ABI In-Reply-To: <1433271299.64.0.126998075643.issue24365@psf.upfronthosting.co.za> Message-ID: <1433271362.13.0.561143239801.issue24365@psf.upfronthosting.co.za> Petr Viktorin added the comment: I meant "stable ABI", of course ---------- title: Conditionalize 3.5 additions to the stable API -> Conditionalize 3.5 additions to the stable ABI _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 21:14:36 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 02 Jun 2015 19:14:36 +0000 Subject: [issue24266] raw_input + readline: Ctrl+C during search breaks readline In-Reply-To: <1432306683.9.0.470835567306.issue24266@psf.upfronthosting.co.za> Message-ID: <1433272476.0.0.822990278941.issue24266@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 21:23:55 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 02 Jun 2015 19:23:55 +0000 Subject: [issue24352] Provide a way for assertLogs to optionally not hide the logging output In-Reply-To: <1433186130.81.0.919581568401.issue24352@psf.upfronthosting.co.za> Message-ID: <1433273035.65.0.698346964284.issue24352@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ezio.melotti, michael.foord, rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 21:24:17 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 02 Jun 2015 19:24:17 +0000 Subject: [issue24362] Simplify the fast nodes resize logic in C OrderedDict. In-Reply-To: <1433253631.63.0.422253960427.issue24362@psf.upfronthosting.co.za> Message-ID: <1433273057.72.0.60669986187.issue24362@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 21:25:39 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 02 Jun 2015 19:25:39 +0000 Subject: [issue24365] Conditionalize 3.5 additions to the stable ABI In-Reply-To: <1433271299.64.0.126998075643.issue24365@psf.upfronthosting.co.za> Message-ID: <1433273139.66.0.900777050484.issue24365@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +ncoghlan stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 21:26:21 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 02 Jun 2015 19:26:21 +0000 Subject: [issue24355] Provide a unittest api for controlling verbosity in tests In-Reply-To: <1433190505.1.0.734052090716.issue24355@psf.upfronthosting.co.za> Message-ID: <1433273181.34.0.372971226997.issue24355@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ezio.melotti, michael.foord, rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 21:28:49 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 19:28:49 +0000 Subject: [issue20155] Regression test test_httpservers fails, hangs on Windows In-Reply-To: <1389053951.39.0.997653737297.issue20155@psf.upfronthosting.co.za> Message-ID: <1433273329.21.0.0185495778075.issue20155@psf.upfronthosting.co.za> R. David Murray added the comment: Terry: the slowdown might be IPV6 handling, which was a bit broken on windows. In any case, I think the slowdown should be treated as a separate issue if you care about it, so I'm going to close this. (I think it would be great if someone would do a review of the test suite looking for things to speed up...maybe we could add that to the devguide as a what-can-I-work-on project...) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 21:30:43 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 19:30:43 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1433273443.71.0.0838178628666.issue7559@psf.upfronthosting.co.za> R. David Murray added the comment: It looks to me like this is complete, so closing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 21:33:54 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 19:33:54 +0000 Subject: [issue22725] improve documentation for enumerate() (built-in function) In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za> Message-ID: <1433273634.64.0.618633661969.issue22725@psf.upfronthosting.co.za> R. David Murray added the comment: Per Raymond's last message, closing this as rejected. ---------- assignee: rhettinger -> docs at python stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 21:41:10 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 19:41:10 +0000 Subject: [issue23171] csv.writer.writerow() does not accept generator (must be coerced to list) In-Reply-To: <1420479102.66.0.846752030326.issue23171@psf.upfronthosting.co.za> Message-ID: <1433274070.02.0.393276953222.issue23171@psf.upfronthosting.co.za> R. David Murray added the comment: Looks like Serhiy forgot to close this, so closing it. ---------- assignee: serhiy.storchaka -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 21:45:10 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 19:45:10 +0000 Subject: [issue23171] csv.writer.writerow() does not accept generator (must be coerced to list) In-Reply-To: <1420479102.66.0.846752030326.issue23171@psf.upfronthosting.co.za> Message-ID: <1433274310.1.0.298388663234.issue23171@psf.upfronthosting.co.za> R. David Murray added the comment: No, I just had a stale tab :( :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 21:50:35 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 19:50:35 +0000 Subject: [issue23440] Extend http.server.SimpleHTTPRequestHandler testing In-Reply-To: <1423640571.78.0.653754704207.issue23440@psf.upfronthosting.co.za> Message-ID: <1433274635.0.0.762020268059.issue23440@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 23:09:51 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 02 Jun 2015 21:09:51 +0000 Subject: [issue19699] Update zipimport for PEP 451 In-Reply-To: <1385137762.02.0.629134883022.issue19699@psf.upfronthosting.co.za> Message-ID: <1433279391.99.0.168989016628.issue19699@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 23:22:40 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Jun 2015 21:22:40 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433280160.74.0.24205415435.issue18003@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This looks good to me. Larry would probably have to validate it for 3.5, although we may try to sneak it in (he isn't reading :-D). ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 23:32:49 2015 From: report at bugs.python.org (Etienne Le Sueur) Date: Tue, 02 Jun 2015 21:32:49 +0000 Subject: [issue18458] interactive interpreter crashes and test_readline fails on OS X 10.9 Mavericks due to libedit update In-Reply-To: <1373891060.78.0.881069869114.issue18458@psf.upfronthosting.co.za> Message-ID: <1433280769.93.0.183195582325.issue18458@psf.upfronthosting.co.za> Etienne Le Sueur added the comment: So what's the resolution here? All I see is a script that disables the readline module depending on whether the interactive session crashes... Has a fix been pushed into the 3.4 release such that linking the readline module against editline results in a working interactive interpreter? ---------- nosy: +Etienne Le Sueur _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 23:38:03 2015 From: report at bugs.python.org (David Bolen) Date: Tue, 02 Jun 2015 21:38:03 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1433281083.37.0.210512013797.issue4753@psf.upfronthosting.co.za> David Bolen added the comment: Oops, sorry, I had just followed the commit comment to this issue. For the record here, it looks like Benjamin has committed an update (5e8fa1b13516) that resolves the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 23:39:24 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 21:39:24 +0000 Subject: [issue18458] interactive interpreter crashes and test_readline fails on OS X 10.9 Mavericks due to libedit update In-Reply-To: <1373891060.78.0.881069869114.issue18458@psf.upfronthosting.co.za> Message-ID: <1433281164.0.0.721202844841.issue18458@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, this is fixed, as the issue resolution says. If you are curious about the fix, follow the links to the commits starting in msg197116. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 23:50:00 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 02 Jun 2015 21:50:00 +0000 Subject: [issue24320] Remove a now-unnecessary workaround from importlib._bootstrap. In-Reply-To: <1432852496.91.0.597570741784.issue24320@psf.upfronthosting.co.za> Message-ID: <1433281800.06.0.95935870854.issue24320@psf.upfronthosting.co.za> Larry Hastings added the comment: Sounds okay in theory. Is the bug in question now tested in our regression suite? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 23:51:00 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 02 Jun 2015 21:51:00 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433281860.91.0.665363337772.issue18003@psf.upfronthosting.co.za> Larry Hastings added the comment: Quoi? Je comprends que le fran?ais. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 23:51:25 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 02 Jun 2015 21:51:25 +0000 Subject: [issue24320] Remove a now-unnecessary workaround from importlib._bootstrap. In-Reply-To: <1432852496.91.0.597570741784.issue24320@psf.upfronthosting.co.za> Message-ID: <1433281885.19.0.686642441132.issue24320@psf.upfronthosting.co.za> Eric Snow added the comment: Yep. test_venv failures is how I found the problem in the first place. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 23:51:50 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Jun 2015 21:51:50 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433281910.62.0.0824997043432.issue18003@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Nous disions que tu aurais probablement ? valider ce changement, mais que nous pourrions peut-?tre aussi le faufiler discr?tement dans la base de code, vu que tu ne lis pas ces message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 2 23:51:54 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 02 Jun 2015 21:51:54 +0000 Subject: [issue24320] Remove a now-unnecessary workaround from importlib._bootstrap. In-Reply-To: <1432852496.91.0.597570741784.issue24320@psf.upfronthosting.co.za> Message-ID: <1433281914.82.0.933217617121.issue24320@psf.upfronthosting.co.za> Larry Hastings added the comment: Then you may fire when ready. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 00:01:56 2015 From: report at bugs.python.org (ppperry) Date: Tue, 02 Jun 2015 22:01:56 +0000 Subject: [issue24252] IDLE removes elements from tracebacks. In-Reply-To: <1432169048.6.0.710293421877.issue24252@psf.upfronthosting.co.za> Message-ID: <1433282516.0.0.734944540805.issue24252@psf.upfronthosting.co.za> ppperry added the comment: This problem also occurs in other situati, such as when trying to get items from an empty queue >>> import Queue >>> Q = Queue.Queue() >>> q.get_nowait() Traceback (most recent call last): File "", line 1, in q.get_nowait() Empty In that case, it doesn't really matter, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 00:04:04 2015 From: report at bugs.python.org (Etienne Le Sueur) Date: Tue, 02 Jun 2015 22:04:04 +0000 Subject: [issue18458] interactive interpreter crashes and test_readline fails on OS X 10.9 Mavericks due to libedit update In-Reply-To: <1433281164.0.0.721202844841.issue18458@psf.upfronthosting.co.za> Message-ID: <556E2851.1010908@lesueur.net.nz> Etienne Le Sueur added the comment: Thanks, I had missed that message. On 6/2/15 4:39 PM, R. David Murray wrote: > R. David Murray added the comment: > > Yes, this is fixed, as the issue resolution says. If you are curious about the fix, follow the links to the commits starting in msg197116. > > ---------- > nosy: +r.david.murray > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 00:09:35 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 02 Jun 2015 22:09:35 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433282975.71.0.758718267328.issue18003@psf.upfronthosting.co.za> Larry Hastings added the comment: If I understand this correctly, I can ignore everything up to May 2015, as it has to do with line-reading a compressed binary file (!) being slow. Then, Martin Panter proposes a new optimization in May 2015, which is to simply add __iter__ methods to gzip.GzipFile and lzma.LZMAFile. Is this right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 00:11:54 2015 From: report at bugs.python.org (Cory Benfield) Date: Tue, 02 Jun 2015 22:11:54 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433283113.99.0.0650830202907.issue24363@psf.upfronthosting.co.za> Cory Benfield added the comment: This is one of those bugs that's actually super tricky to correctly fix. The correct path is to have the goal of conservatively accepting as many headers as possible. Probably this means looking ahead to the next few lines and seeing if they appear to roughly keep a header structure (\r\n line breaks and colon separated values). However, I'm not entirely sure how to structure that sentiment in code at this time. ---------- nosy: +Lukasa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 00:22:15 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Jun 2015 22:22:15 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433283735.49.0.0485802611895.issue24363@psf.upfronthosting.co.za> R. David Murray added the comment: I think there may be a way to accomplish this in a reasonably straightforward fashion in python3 given that feedparser has an 'unreadline' function. The python2 case is probably going to be a more complicated change. And I agree that multiple lines should be examined. There is also the question of what to do with the extra data. I think the correct approach is to treat a line that does not conform as a line that is missing the leading whitespace that would make it a continuation line. It looks like that would certainly be correct for the case in hand. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 00:26:10 2015 From: report at bugs.python.org (Daniel) Date: Tue, 02 Jun 2015 22:26:10 +0000 Subject: [issue24366] Simple indentation Message-ID: <1433283970.95.0.861661990338.issue24366@psf.upfronthosting.co.za> Changes by Daniel : ---------- files: indent.patch keywords: patch nosy: li4ick priority: normal severity: normal status: open title: Simple indentation versions: Python 3.6 Added file: http://bugs.python.org/file39597/indent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 00:29:03 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 02 Jun 2015 22:29:03 +0000 Subject: [issue24365] Conditionalize 3.5 additions to the stable ABI In-Reply-To: <1433271299.64.0.126998075643.issue24365@psf.upfronthosting.co.za> Message-ID: <1433284143.45.0.713569868049.issue24365@psf.upfronthosting.co.za> Nick Coghlan added the comment: Looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 00:29:40 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 02 Jun 2015 22:29:40 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433284180.48.0.0919536202126.issue24363@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 00:45:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Jun 2015 22:45:25 +0000 Subject: [issue24342] coroutine wrapper reentrancy In-Reply-To: <1433124694.62.0.501554700121.issue24342@psf.upfronthosting.co.za> Message-ID: <20150602224522.22624.18344@psf.io> Roundup Robot added the comment: New changeset 19d613c2cd5f by Yury Selivanov in branch '3.5': Issue 24342: Let wrapper set by sys.set_coroutine_wrapper fail gracefully https://hg.python.org/cpython/rev/19d613c2cd5f New changeset 8a6db1679a23 by Yury Selivanov in branch 'default': Issue 24342: Let wrapper set by sys.set_coroutine_wrapper fail gracefully https://hg.python.org/cpython/rev/8a6db1679a23 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 00:47:06 2015 From: report at bugs.python.org (ppperry) Date: Tue, 02 Jun 2015 22:47:06 +0000 Subject: [issue24367] Idle hangs when you close the debugger while debugging Message-ID: <1433285226.41.0.804518988574.issue24367@psf.upfronthosting.co.za> New submission from ppperry: [DEBUG ON] >>> some_code (debugger closed before pressing any buttons) [DEBUG OFF] >>> more_code (no response) ---------- components: IDLE messages: 244707 nosy: kbk, ppperry, roger.serwy, terry.reedy priority: normal severity: normal status: open title: Idle hangs when you close the debugger while debugging type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 00:47:26 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 02 Jun 2015 22:47:26 +0000 Subject: [issue24342] coroutine wrapper reentrancy In-Reply-To: <1433124694.62.0.501554700121.issue24342@psf.upfronthosting.co.za> Message-ID: <1433285246.23.0.5259056676.issue24342@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 00:47:45 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 02 Jun 2015 22:47:45 +0000 Subject: [issue24362] Simplify the fast nodes resize logic in C OrderedDict. In-Reply-To: <1433253631.63.0.422253960427.issue24362@psf.upfronthosting.co.za> Message-ID: <1433285265.0.0.645565628182.issue24362@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a patch that adds stores the hash on each node. This eliminates the need to call PyObject_Hash when rebuilding the fast nodes table during a resize. The patch also drops a superfluous while loop. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file39598/issue24362-odict-resize.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 00:55:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Jun 2015 22:55:45 +0000 Subject: [issue24366] Simple indentation Message-ID: <20150602225541.22892.85980@psf.io> New submission from Roundup Robot: New changeset 035aa81c2ba8 by Yury Selivanov in branch '3.3': Issue 24366: Indent code (thanks to li4ick for reporting). https://hg.python.org/cpython/rev/035aa81c2ba8 New changeset 95d1f38e540e by Yury Selivanov in branch '3.4': Issue 24366: Merge 3.3 https://hg.python.org/cpython/rev/95d1f38e540e New changeset 67f0843a2ecf by Yury Selivanov in branch '3.5': Issue 24366: Merge 3.4 https://hg.python.org/cpython/rev/67f0843a2ecf New changeset 54459fdf2bca by Yury Selivanov in branch 'default': Issue 24366: Merge 3.5 https://hg.python.org/cpython/rev/54459fdf2bca ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 00:56:07 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 02 Jun 2015 22:56:07 +0000 Subject: [issue24366] Simple indentation In-Reply-To: <20150602225541.22892.85980@psf.io> Message-ID: <1433285767.7.0.342569861896.issue24366@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 01:07:50 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 02 Jun 2015 23:07:50 +0000 Subject: [issue24320] Remove a now-unnecessary workaround from importlib._bootstrap. In-Reply-To: <1432852496.91.0.597570741784.issue24320@psf.upfronthosting.co.za> Message-ID: <1433286470.89.0.185382358119.issue24320@psf.upfronthosting.co.za> Eric Snow added the comment: Hmm. Looks like the fix in setuptools/pkg_resources is 17.0. [1] The bundled pip to which we just updated is 7.0.3, which appears to bundle pkg_resources 15.0. [2] So unless I've misunderstood, the hack will have to linger for a bit longer. Here's a patch for when we get there. [1] https://bitbucket.org/pypa/setuptools/commits/tag/17.0 [2] https://github.com/pypa/pip/blob/7.0.3/pip/_vendor/README.rst ---------- keywords: +patch nosy: +dstufft stage: needs patch -> patch review Added file: http://bugs.python.org/file39599/issue24320-remove-hack.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 01:14:43 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Jun 2015 23:14:43 +0000 Subject: [issue24365] Conditionalize 3.5 additions to the stable ABI In-Reply-To: <1433271299.64.0.126998075643.issue24365@psf.upfronthosting.co.za> Message-ID: <20150602231439.94510.7691@psf.io> Roundup Robot added the comment: New changeset c835dd16539a by Yury Selivanov in branch '3.5': Issue 24365: Conditionalize PEP 489 additions to the stable ABI https://hg.python.org/cpython/rev/c835dd16539a New changeset fd265fa89c36 by Yury Selivanov in branch 'default': Issue 24365: Merge 3.5 https://hg.python.org/cpython/rev/fd265fa89c36 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 01:14:57 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 02 Jun 2015 23:14:57 +0000 Subject: [issue24365] Conditionalize 3.5 additions to the stable ABI In-Reply-To: <1433271299.64.0.126998075643.issue24365@psf.upfronthosting.co.za> Message-ID: <1433286897.19.0.702398755911.issue24365@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 01:17:51 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 02 Jun 2015 23:17:51 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1433287071.02.0.586969261731.issue24270@psf.upfronthosting.co.za> Yury Selivanov added the comment: Can this issue be closed now? ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 01:18:47 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 02 Jun 2015 23:18:47 +0000 Subject: [issue24361] OrderedDict: crash with threads In-Reply-To: <1433239377.83.0.708657008711.issue24361@psf.upfronthosting.co.za> Message-ID: <1433287127.92.0.659669494987.issue24361@psf.upfronthosting.co.za> Eric Snow added the comment: FYI, this doesn't crash when I have the patch from issue24362 applied. ---------- assignee: -> eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 01:32:07 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 02 Jun 2015 23:32:07 +0000 Subject: [issue24252] IDLE removes elements from tracebacks. In-Reply-To: <1432169048.6.0.710293421877.issue24252@psf.upfronthosting.co.za> Message-ID: <1433287927.27.0.854011162598.issue24252@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Your message arrived as I was just starting on this issue, wondering whether the exclusion of threading and queue blocks is proper and wishing for an easy test example, such as you provided. It verifies the issue in 3.x. It also answers the question: trimming queue blocks is not acceptible. (Many threading functions also raise various exceptions.) Informative tracebacks are a major python feature. So Idle should be conservative about trimming tracebacks. The attached 3.4 patch solves queue and threading problems by deleting them from the exclude list. It attempts to solve your pdb problem by conditionally removing bdb.py also. Could you patch your Idle, by hand if necessary, and test? ---------- keywords: +patch stage: needs patch -> patch review versions: +Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39600/tb-trim.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 01:37:52 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 02 Jun 2015 23:37:52 +0000 Subject: [issue24367] Idle hangs when you close the debugger while debugging In-Reply-To: <1433285226.41.0.804518988574.issue24367@psf.upfronthosting.co.za> Message-ID: <1433288272.84.0.945405232534.issue24367@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Previous issue has a patch that needs independent review. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> IDLE - shell becomes unresponsive if debugger windows is closed while active. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 02:02:42 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 03 Jun 2015 00:02:42 +0000 Subject: [issue24368] Some C OrderedDict methods need to support keyword arguments. Message-ID: <1433289762.01.0.562215924476.issue24368@psf.upfronthosting.co.za> New submission from Eric Snow: Several methods were implemented using PyArg_UnpackTuple and need to use PyArg_ParseTupleAndKeywords instead. ---------- assignee: eric.snow components: Library (Lib) messages: 244716 nosy: eric.snow priority: release blocker severity: normal stage: needs patch status: open title: Some C OrderedDict methods need to support keyword arguments. type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 02:08:59 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 03 Jun 2015 00:08:59 +0000 Subject: [issue24368] Some C OrderedDict methods need to support keyword arguments. In-Reply-To: <1433289762.01.0.562215924476.issue24368@psf.upfronthosting.co.za> Message-ID: <1433290139.37.0.194937435774.issue24368@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a patch with tests. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file39601/issue24368-kwargs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 02:12:18 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 03 Jun 2015 00:12:18 +0000 Subject: [issue24369] Using OrderedDict.move_to_end during iteration is problematic. Message-ID: <1433290338.7.0.000891245826788.issue24369@psf.upfronthosting.co.za> New submission from Eric Snow: While the dict/OrderedDict iterators already check for additions and deletions, using the OrderedDict.move_to_end during iteration can lead to surprising results. The following results in an infinite loop: od = OrderedDict.fromkeys('abc') last = None for k in od: if last is not None: od.move_to_end(last) last = k Ideally we could disallow changing order during iteration, just like we disallow deletion. Since we've gone 3 minor versions already, would it be too late to break backward compatibility on this point? ---------- components: Library (Lib) messages: 244718 nosy: eric.snow, rhettinger priority: high severity: normal stage: test needed status: open title: Using OrderedDict.move_to_end during iteration is problematic. type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 02:16:28 2015 From: report at bugs.python.org (Michael Del Monte) Date: Wed, 03 Jun 2015 00:16:28 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433290588.08.0.191996139711.issue24363@psf.upfronthosting.co.za> Michael Del Monte added the comment: I don't want to speak out of school and you guys certainly know what you're doing, but it seems a shame to go through these gyrations -- lookahead plus "unreading" lines -- only to preserve the ability to parse email headers, when HTTP really does follow a different spec. My suggestion would be to examine the header and decide, if it's HTTP, to just ignore nonconforming lines; and if it's email, then the problem is already solved (as email doesn't have encoding rules that would cause problems later). My fear would be that you'll eventually get that nonconforming line with leading whitespace, which will lead right back to the same error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 02:48:35 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 03 Jun 2015 00:48:35 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433292515.77.0.740739380851.issue24363@psf.upfronthosting.co.za> R. David Murray added the comment: No, the point is to do "best practical" error recovery when faced with dirty data that may be dirty in various ways, and it doesn't really matter whether it is http headers or email headers. A line with leading whitespace is treated as part of the preceding header line now, and this is the way it should behave, since the older http standards adopted that behavior from rfc822. You will note that the standard referenced by Ian is explicit about that, in the obs-fold clause. That is, we are required by the standard to support that behavior, which is why I posit that the best recovery is to assume an invalid line followed by what look like headers is in fact an incorrectly folded obs-fold continuation line. That this will also conform to the email standard is a not-accidental consequence of how these standards evolved. (That is, email and http header handling are *not* "different" specs in the sense of being disjoint, they are derivatives of a common ancestor spec and some effort is spent keeping them interoperable, to my understanding.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 02:52:31 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 03 Jun 2015 00:52:31 +0000 Subject: [issue24320] Remove a now-unnecessary workaround from importlib._bootstrap. In-Reply-To: <1432852496.91.0.597570741784.issue24320@psf.upfronthosting.co.za> Message-ID: <1433292751.7.0.0491894208273.issue24320@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 02:58:05 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 03 Jun 2015 00:58:05 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433293085.36.0.1992152346.issue24363@psf.upfronthosting.co.za> Martin Panter added the comment: Regarding the suggested fix for Python 2, make sure it does not prematurely end the parsing on empty folded lines (having only tabs and spaces in them). E.g. according to RFC 7230 this should be a single header field: b"Header: obsolete but\r\n" b" \r\n" b" still valid\r\n" I suspect the RFC doesn?t say anything specifically about this case. In general the guidance seems to be things like: * User agents should be tolerant of errors received in the protocol * Proxies should fix up errors when forwarding messages upstream * Servers should often reject errors in requests with 400 Bad Request (presumably to avoid the possibility of a downstream proxy being tricked by the protocol error and not triggering some security filter) In the case of the bank web site, the last lines of the header are: X-Frame-Options: SAMEORIGIN\r\n Set-Cookie: mb-CookieP=; HttpOnly; \r\n Secure\r\n Set-Cookie: mb-CookieP=; HttpOnly; Secure\r\n \r\n It is obvious that this case could be treated as a folded (continuation) line. But in general I think it would be better to ignore the erroneous line, or to record it as a defect so that the server module or other user can check it. Looking at the Python 3 code, both the client and server call http.client._parse_headers(), which sensibly reads each line until it sees a blank line (Lib/http/client.py:197). But then after jumping through some more hoops we parse it again until we find a line that fails the regular expression at Lib/email/feedparser.py:37. The remaining lines become the ?payload? of the HTTP header: >>> with urlopen("http://www.merrickbank.com/") as response: ... response.info().get_payload() ... 'Secure\r\nSet-Cookie: mb-CookieP=; HttpOnly; Secure\r\n\r\n' What might be nice is a way to reuse the email header field parsing code, without worrying about the ?From? line stuff, or the payload stuff. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 03:25:09 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 03 Jun 2015 01:25:09 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433294709.29.0.524192632917.issue24363@psf.upfronthosting.co.za> R. David Murray added the comment: Since the email package has the correct logic for handling the blank continuation line case (even in Python2) (because, again, that derives from the original email standard), it might be reasonable to use feedparser's headersonly mode. If necessary we can introduce a (private) variation that actually stops parsing the stream at the end of the headers. (This would be a non-public API on feedparser for 2.7 and 3.4/5, and a public one in 3.6.) Since feedparser was itself a rewrite of the mimetools code httplib is using and theoretically backward compatible with it in behavior, this should not in theory introduce any behavior changes (famous last words?). The problem here is the good chance that someone is depending on the internal implementation of HTTPMessage. So, I'm not at all sure about this suggestion. And yes, the email package in python3 records header defects. However, I think it is better to treat the no-leading-blank non-header as an incorrectly folded continuation line rather than discarding the data. The data is in the headers section for *some* reason, and IMO that is the only reasonable guess as to why. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 03:58:20 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 03 Jun 2015 01:58:20 +0000 Subject: [issue24369] Using OrderedDict.move_to_end during iteration is problematic. In-Reply-To: <1433290338.7.0.000891245826788.issue24369@psf.upfronthosting.co.za> Message-ID: <1433296700.37.0.687069583429.issue24369@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The C version should defend itself against any key-changes during iteration (see the state counter used in deque objects for an example of how to do this). The pure python version of OrderedDict has only minimal defenses against mutating during iteration, and it should be left as-is. FWIW, "surprising" is in the eye of the beholder. When it comes to mutating containers during iteration, all kinds of things can happen (that is why databases implement reader and writer locks). The following results in an infinite loop: s = list('abc') for k in s: s.append(k) ---------- assignee: -> rhettinger priority: high -> normal versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 04:31:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 03 Jun 2015 02:31:01 +0000 Subject: [issue24342] coroutine wrapper reentrancy In-Reply-To: <1433124694.62.0.501554700121.issue24342@psf.upfronthosting.co.za> Message-ID: <20150603023057.129618.64392@psf.io> Roundup Robot added the comment: New changeset d11cb1218489 by Yury Selivanov in branch '3.5': Issue 24342: No need to use PyAPI_FUNC for _PyEval_ApplyCoroutineWrapper https://hg.python.org/cpython/rev/d11cb1218489 New changeset b83fbc13ae1e by Yury Selivanov in branch 'default': Issue 24342: No need to use PyAPI_FUNC for _PyEval_ApplyCoroutineWrapper https://hg.python.org/cpython/rev/b83fbc13ae1e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 04:31:19 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 03 Jun 2015 02:31:19 +0000 Subject: [issue24369] Using OrderedDict.move_to_end during iteration is problematic. In-Reply-To: <1433290338.7.0.000891245826788.issue24369@psf.upfronthosting.co.za> Message-ID: <1433298679.6.0.576412704755.issue24369@psf.upfronthosting.co.za> Eric Snow added the comment: Sounds good. Thanks, Raymond. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 04:44:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 03 Jun 2015 02:44:04 +0000 Subject: [issue24368] Some C OrderedDict methods need to support keyword arguments. In-Reply-To: <1433289762.01.0.562215924476.issue24368@psf.upfronthosting.co.za> Message-ID: <20150603024400.79372.64004@psf.io> Roundup Robot added the comment: New changeset 38ffea158630 by Eric Snow in branch '3.5': Issue #24368: Support keyword arguments in OrderedDict methods. https://hg.python.org/cpython/rev/38ffea158630 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 04:44:24 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 03 Jun 2015 02:44:24 +0000 Subject: [issue24368] Some C OrderedDict methods need to support keyword arguments. In-Reply-To: <1433289762.01.0.562215924476.issue24368@psf.upfronthosting.co.za> Message-ID: <1433299464.07.0.126445276894.issue24368@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 05:01:20 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 03 Jun 2015 03:01:20 +0000 Subject: [issue24370] OrderedDict behavior is unclear with misbehaving keys. Message-ID: <1433300480.06.0.538096094872.issue24370@psf.upfronthosting.co.za> New submission from Eric Snow: How well does OrderedDict need to behave in the face of keys with unstable hashes (e.g. define __hash__ with varying results across calls)? I would expect the behavior to be undefined (though non-crashing). Here's an example of a misbehaving key: class Key: def __hash__(self): return randrange(10000) FWIW, dict does pretty well even with bad keys. The pure Python OrderedDict does okay. ---------- assignee: eric.snow components: Library (Lib) messages: 244727 nosy: eric.snow, rhettinger priority: normal severity: normal stage: needs patch status: open title: OrderedDict behavior is unclear with misbehaving keys. type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 08:08:07 2015 From: report at bugs.python.org (Tal Einat) Date: Wed, 03 Jun 2015 06:08:07 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1433311687.19.0.562599704369.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: Indeed, it should be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 09:19:57 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 03 Jun 2015 07:19:57 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433315997.41.0.110309757458.issue18003@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, this is right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 09:34:28 2015 From: report at bugs.python.org (Yavuz Selim Komur) Date: Wed, 03 Jun 2015 07:34:28 +0000 Subject: [issue24371] configparser hate dot in option like eth2.6 Message-ID: <1433316868.88.0.0222677980936.issue24371@psf.upfronthosting.co.za> New submission from Yavuz Selim Komur: [remember] eth2.6 = True eth5 = True eth5 correct but eth2.6 return exception ---------- components: Extension Modules, Library (Lib) messages: 244730 nosy: Yavuz Selim Komur priority: normal severity: normal status: open title: configparser hate dot in option like eth2.6 versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 10:11:30 2015 From: report at bugs.python.org (Tal Einat) Date: Wed, 03 Jun 2015 08:11:30 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1433319090.66.0.854333591397.issue20186@psf.upfronthosting.co.za> Tal Einat added the comment: Attached is an updated patch for Modules/mathmodule.c. This is based on Georg's patch, updated to apply to current 3.5, with several improvements: * replaced legacy converters * converted math.ceil() and math.floor() functions * converted the new math.gcd() and math.isclose() functions * AC generated code in separate file: Modules/clinic/mathmodule.c.h * this patch doesn't change any internal variable names in the C code ---------- nosy: +taleinat Added file: http://bugs.python.org/file39602/issue20186.mathmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 10:21:34 2015 From: report at bugs.python.org (Cory Benfield) Date: Wed, 03 Jun 2015 08:21:34 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433319694.45.0.14236085819.issue24363@psf.upfronthosting.co.za> Cory Benfield added the comment: > It is obvious that this case could be treated as a folded (continuation) line. But in general I think it would be better to ignore the erroneous line, or to record it as a defect so that the server module or other user can check it. Just to clarify, in an instance very similar to this one this would be *terrible* advice. The token that would be lost here is the 'Secure' field on the cookie, which is an extremely important token to have: if we don't correctly parse it, we run the risk of sending the cookie on plaintext connections. Discarding data is the problem, and while discarding *less* data is an improvement, it would be good if we could resolve this problem in such a way that we'd have correctly parsed this header. Generally speaking, if we treat these as continuation lines I think we have the best change of making a useful header out of this mess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 10:39:22 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 03 Jun 2015 08:39:22 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1433320762.43.0.304270255004.issue24270@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 11:01:42 2015 From: report at bugs.python.org (Cory Benfield) Date: Wed, 03 Jun 2015 09:01:42 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433322102.69.0.0648590979661.issue24363@psf.upfronthosting.co.za> Cory Benfield added the comment: While we're here and I'm recommending to drop as little data as possible: we need to be really careful about not exposing ourselves to any kind of data smuggling attack here. It's really important that we don't let attackers construct bodies of requests or responses that will cause us to misinterpret header blocks. It's therefore going to be really tricky to balance those concerns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 11:54:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 03 Jun 2015 09:54:09 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1433325249.52.0.473814128846.issue20186@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: needs patch -> patch review versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 12:04:32 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 03 Jun 2015 10:04:32 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433325872.87.0.495642277696.issue18003@psf.upfronthosting.co.za> Martin Panter added the comment: Yes that?s basically right Larry. The __iter__() was previously inherited; now I am overriding it with a custom version. Similarly for the ?closed? property, but that one is only a member of objects internal to the gzip, lzma and bz2 modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 12:20:08 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 03 Jun 2015 10:20:08 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433326808.86.0.572576305052.issue18003@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't see anything about "closed" in the patch you posted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 12:20:51 2015 From: report at bugs.python.org (Tal Einat) Date: Wed, 03 Jun 2015 10:20:51 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1433326851.48.0.501040833746.issue20186@psf.upfronthosting.co.za> Tal Einat added the comment: Should Argument Clinic conversion patches still be against the 'default' branch, and not 3.5, even though they don't include any functionality changes? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 12:52:38 2015 From: report at bugs.python.org (Tal Einat) Date: Wed, 03 Jun 2015 10:52:38 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1433328758.4.0.957538078566.issue20186@psf.upfronthosting.co.za> Tal Einat added the comment: Attached is an AC conversion patch for Objects/enumobject.c. Note that this file contains the implementations of the 'enumerate' and 'reversed' classes, but *not* the 'Enum' class. This is based on the 3.5 branch. ---------- Added file: http://bugs.python.org/file39603/issue20186.enumobject.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 13:07:23 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 03 Jun 2015 11:07:23 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433329643.78.0.440847383776.issue18003@psf.upfronthosting.co.za> Martin Panter added the comment: Looking at , the ?closed? property is the first of the three hunks: 1. Adds @property / def closed(self) to Lib/_compression.py 2. Adds def __iter__(self) to Lib/gzip.py 3. Adds def __iter__(self) to Lib/lzma.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 13:12:53 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 03 Jun 2015 11:12:53 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433329973.0.0.194988608294.issue18003@psf.upfronthosting.co.za> Martin Panter added the comment: New patch just fixes the spelling error in the comment. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file39604/decomp-optim.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 14:51:52 2015 From: report at bugs.python.org (Tim Graham) Date: Wed, 03 Jun 2015 12:51:52 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1433335912.44.0.206648275497.issue24134@psf.upfronthosting.co.za> Tim Graham added the comment: Unfortunately, the revert wasn't merged to the 2.7 branch until after the release of 2.7.10. I guess this regression wouldn't be considered serious enough to warrant a 2.7.11 soon, correct? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 14:54:18 2015 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 03 Jun 2015 12:54:18 +0000 Subject: [issue24371] configparser hate dot in option like eth2.6 In-Reply-To: <1433316868.88.0.0222677980936.issue24371@psf.upfronthosting.co.za> Message-ID: <1433336058.33.0.431987956465.issue24371@psf.upfronthosting.co.za> Skip Montanaro added the comment: What little I could find about Windows INI file syntax didn't identify the valid character set of the keys. Like other Windows-based file formats, INI seems to only be operationally defined. It wouldn't surprise me if you needed to restrict yourself to the usual identifier syntax. In regular expression terms: [_A-Za-z][a-zA-Z_0-9]* ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 15:10:46 2015 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 03 Jun 2015 13:10:46 +0000 Subject: [issue24372] Documentation for ssl.wrap_socket's ssl_version parameter is odd Message-ID: <1433337046.56.0.760667574061.issue24372@psf.upfronthosting.co.za> New submission from Eric V. Smith: The documentation for ssl.wrap_socket()'s ssl_version parameter says "ssl_version={see docs}". But as far as I can tell, there's no reason not to document it as PROTOCOL_SSLv23, since that's what it actually is in the code. My use case is that I'm producing a utility function for an RFC-5804 Manage Sieve client, which implements starttls(). I want to expose most of wrap_sockets()'s parameters, and pass them in to ssl.wrap_socket() itself. In order to do so, I need to specify the default values to match wrap_socket(). But ssl_version's default isn't documented. Is the reason to allow us to change the default in a bug fix release? If that's the case, I suggest creating a sentinel value, like ssl.DEFAULT_PROTOCOL, and have that be the documented default. Then I could declare my parameter as defaulting to ssl.DEFAULT_PROTOCOL, pass it in to ssl.wrap_socket(), and have it use the "current" default. If that's a desirable solution, I'll happily write a patch. If so, it would just apply to 3.6, but if we just want to document the actual value of ssl_version, then it would apply to the versions I've selected. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 244742 nosy: docs at python, eric.smith priority: low severity: normal status: open title: Documentation for ssl.wrap_socket's ssl_version parameter is odd type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 15:21:01 2015 From: report at bugs.python.org (Petr Viktorin) Date: Wed, 03 Jun 2015 13:21:01 +0000 Subject: [issue24373] Use traverse & finalize in xxlimited and in PEP 489 tests Message-ID: <1433337661.83.0.639894570386.issue24373@psf.upfronthosting.co.za> New submission from Petr Viktorin: The example object in the xxlimited module can be part of a reference loop (it can contain itself), so it needs GC and tp_traverse. The tp_dealloc hook was incorrect, and a correct version would be difficult to generalize for something more complicated than a example class (#16690; [0]). It's better to avoid dealloc and show off tp_finalize. Same for the class in _testmultiphase (PEP 489 tests), which is based on xxlimited. The incorrect dealloc is causing the reference leak mentioned in #24268. The Xxo object also wasn't actually added to the module. Here is a patch to fix these. [0] https://mail.python.org/pipermail/python-dev/2015-June/140422.html ---------- components: Extension Modules files: xxlimited-finalize.patch keywords: patch messages: 244743 nosy: encukou, ncoghlan priority: normal severity: normal status: open title: Use traverse & finalize in xxlimited and in PEP 489 tests versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39605/xxlimited-finalize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 15:37:14 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 03 Jun 2015 13:37:14 +0000 Subject: [issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za> Message-ID: <1433338634.12.0.850483287873.issue24079@psf.upfronthosting.co.za> Martin Panter added the comment: Okay, here is a version with most of the wording reverted to J?r?me?s suggestion. I only left my itertext() example, and the grouping of text and tail together. If there are any more bits that are incorrect or unclear please identify them. ---------- Added file: http://bugs.python.org/file39606/etree-text.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 15:48:18 2015 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 03 Jun 2015 13:48:18 +0000 Subject: [issue24372] Documentation for ssl.wrap_socket's ssl_version parameter is odd In-Reply-To: <1433337046.56.0.760667574061.issue24372@psf.upfronthosting.co.za> Message-ID: <1433339298.69.0.231472669954.issue24372@psf.upfronthosting.co.za> Eric V. Smith added the comment: It occurs to me that None would also be a fine default, and probably the smarter choice. Then wrap_socket could say: if ssl_version is None: ssl_version = PROTOCOL_SSLv23 And we could change the default as needed, without being held to the actual value. And wrapper code, like mine, would declare a default of None and things would continue to work across versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 15:52:04 2015 From: report at bugs.python.org (Christian Heimes) Date: Wed, 03 Jun 2015 13:52:04 +0000 Subject: [issue24372] Documentation for ssl.wrap_socket's ssl_version parameter is odd In-Reply-To: <1433337046.56.0.760667574061.issue24372@psf.upfronthosting.co.za> Message-ID: <1433339524.76.0.685098831392.issue24372@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 15:52:51 2015 From: report at bugs.python.org (Stefan Krah) Date: Wed, 03 Jun 2015 13:52:51 +0000 Subject: [issue24362] Simplify the fast nodes resize logic in C OrderedDict. In-Reply-To: <1433253631.63.0.422253960427.issue24362@psf.upfronthosting.co.za> Message-ID: <1433339571.91.0.779111697557.issue24362@psf.upfronthosting.co.za> Stefan Krah added the comment: I think this is much nicer, thank you! And the XXX comment looks right, updating od_size could be moved down. I suspect that updating it too early was the cause for #24361, which is also solved by this patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 15:54:25 2015 From: report at bugs.python.org (Christian Heimes) Date: Wed, 03 Jun 2015 13:54:25 +0000 Subject: [issue24372] Documentation for ssl.wrap_socket's ssl_version parameter is odd In-Reply-To: <1433337046.56.0.760667574061.issue24372@psf.upfronthosting.co.za> Message-ID: <1433339665.91.0.120750041861.issue24372@psf.upfronthosting.co.za> Christian Heimes added the comment: I'd like to deprecate ssl.wrap_socket() in favor of SSLContext.wrap_socket(). Libraries should rather accept a context than expose the awkward interface of ssl.wrap_socket(). A context object is far more powerful and easier to use. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 16:04:49 2015 From: report at bugs.python.org (Piotr Dobrogost) Date: Wed, 03 Jun 2015 14:04:49 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433340289.8.0.836945439278.issue24363@psf.upfronthosting.co.za> Changes by Piotr Dobrogost : ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 16:09:54 2015 From: report at bugs.python.org (Christian Heimes) Date: Wed, 03 Jun 2015 14:09:54 +0000 Subject: [issue24372] Documentation for ssl.wrap_socket's ssl_version parameter is odd In-Reply-To: <1433337046.56.0.760667574061.issue24372@psf.upfronthosting.co.za> Message-ID: <1433340594.69.0.984249982862.issue24372@psf.upfronthosting.co.za> Christian Heimes added the comment: DISCLAIMER: I'm currently planning and researching two SSL related PEPs. One PEP is about SSLContext. I like to standardize a minimal interface for SSL context object, so libraries can deal with any abitrary SSL implementation. With just one small addition and an SSLContext ABC, every library could then support stdlib ssl, PyOpenSSL, GnuTLS, NSS, PyQT/PySide QSslSocket and even non-standard sockets like NSPR PRFileDesc and QTcpSocket. My idea only works with a SSL context object. So I'm interested that people use the new feature rather then the old ssl.wrap_socket() function. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 16:12:00 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 03 Jun 2015 14:12:00 +0000 Subject: [issue24374] Plug refleak in set_coroutine_wrapper Message-ID: <1433340719.96.0.108674882489.issue24374@psf.upfronthosting.co.za> New submission from Yury Selivanov: Code to raise RuntimeError introduced in issue24342 has some refleaks. Please review the attached patch. ---------- assignee: yselivanov components: Interpreter Core files: set_coro.patch keywords: patch messages: 244749 nosy: ncoghlan, yselivanov priority: normal severity: normal stage: patch review status: open title: Plug refleak in set_coroutine_wrapper versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39607/set_coro.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 16:14:05 2015 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 03 Jun 2015 14:14:05 +0000 Subject: [issue24372] Documentation for ssl.wrap_socket's ssl_version parameter is odd In-Reply-To: <1433337046.56.0.760667574061.issue24372@psf.upfronthosting.co.za> Message-ID: <1433340845.98.0.115328342967.issue24372@psf.upfronthosting.co.za> Eric V. Smith added the comment: I have a requirement to support 2.7.5, so SSLContext is currently a problem for me. I realize that 2.7 could at best get a documentation change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 16:17:17 2015 From: report at bugs.python.org (Michiel de Hoon) Date: Wed, 03 Jun 2015 14:17:17 +0000 Subject: [issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening) In-Reply-To: <1421201583.23.0.507661432161.issue23237@psf.upfronthosting.co.za> Message-ID: <1433341037.19.0.135285330804.issue23237@psf.upfronthosting.co.za> Michiel de Hoon added the comment: I am uploading an updated version of the patch. I'd be happy to submit a patch to the documentation also, but wasn't able to find it on Mercurial. Can somebody please point me to the right repository for the documentation? ---------- Added file: http://bugs.python.org/file39608/issue23237.version2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 16:19:09 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 03 Jun 2015 14:19:09 +0000 Subject: [issue24374] Plug refleak in set_coroutine_wrapper In-Reply-To: <1433340719.96.0.108674882489.issue24374@psf.upfronthosting.co.za> Message-ID: <1433341149.89.0.564488126609.issue24374@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +gvanrossum, haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 16:36:26 2015 From: report at bugs.python.org (Michael Del Monte) Date: Wed, 03 Jun 2015 14:36:26 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433342186.84.0.340444077082.issue24363@psf.upfronthosting.co.za> Michael Del Monte added the comment: Given that obs-fold is technically valid, then can I recommend reading the entire header first (reading to the first blank line) and then tokenizing the individual headers using a regular expression rather than line by line? That would solve the problem more elegantly and easily than attempting to read lines on the fly and then "unreading" the nonconforming lines. Here's my recommendation: def readheaders(self): self.dict = {} self.unixfrom = '' self.headers = hlist = [] self.status = '' # read entire header (read until first blank line) while True: line = self.fp.readline(_MAXLINE+1) if not line: self.status = 'EOF in headers' break if len(line) > _MAXLINE: raise LineTooLong("header line") hlist.append(line) if line in ('\n', '\r\n'): break if len(hlist) > _MAXHEADERS: raise HTTPException("got more than %d headers" % _MAXHEADERS) # reproduce and parse as string header = "\n".join(hlist) self.headers = re.findall(r"[^ \n][^\n]+\n(?: +[^\n]+\n)*", header) firstline = True for line in self.headers: if firstline and line.startswith('From '): self.unixfrom = self.unixfrom + line continue firstline = False if ':' in line: k,v = line.split(':',1) self.addheader(k, re.sub("\n +", " ", v.strip())) else: self.status = 'Non-header line where header expected' if self.dict else 'No headers' I think this handles everything you're trying to do. I don't understand the unixfrom bit, but I think I have it right. As for Cory's concern re: smuggling, _MAXLINE and _MAXHEADERS should help with that. The regexp guarantees that every line plus continuation appears as a single header. I use re.sub("\n +", " ", v.strip()) to clean the value and remove the continuation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 16:41:46 2015 From: report at bugs.python.org (Michael Del Monte) Date: Wed, 03 Jun 2015 14:41:46 +0000 Subject: [issue24363] httplib fails to handle semivalid HTTP headers In-Reply-To: <1433257563.79.0.772954216205.issue24363@psf.upfronthosting.co.za> Message-ID: <1433342506.12.0.170499889384.issue24363@psf.upfronthosting.co.za> Michael Del Monte added the comment: ... or perhaps if ':' in line and line[0] != ':': to avoid the colon-as-first-char bug that plagued this library earlier, though the only ill-effect of leaving it alone would be a header with a blank key; not the end of the world. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 16:49:27 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 03 Jun 2015 14:49:27 +0000 Subject: [issue24375] Performance regression relative to 2.7 Message-ID: <1433342967.51.0.80560077079.issue24375@psf.upfronthosting.co.za> New submission from Yury Selivanov: Attached (t.py) is a random script that I stumbled upon pretty randomly on the internet -- someone used it to test different languages VMs performance. The interesting thing is that 2.7 runs it 20-30% faster than 3.4 & 3.5 consistently. The script does not involve any unicode data manipulation, it's mostly abount float arithmetic and function calls. ---------- components: Interpreter Core files: t.py messages: 244754 nosy: benjamin.peterson, haypo, ncoghlan, pitrou, yselivanov priority: normal severity: normal status: open title: Performance regression relative to 2.7 versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39609/t.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 17:01:46 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 03 Jun 2015 15:01:46 +0000 Subject: [issue24375] Performance regression relative to 2.7 In-Reply-To: <1433342967.51.0.80560077079.issue24375@psf.upfronthosting.co.za> Message-ID: <1433343706.74.0.575178636022.issue24375@psf.upfronthosting.co.za> Antoine Pitrou added the comment: FTR, Python 2.7 was slower until the computed gotos patch was backported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 17:03:02 2015 From: report at bugs.python.org (Stefan Krah) Date: Wed, 03 Jun 2015 15:03:02 +0000 Subject: [issue24375] Performance regression relative to 2.7 In-Reply-To: <1433342967.51.0.80560077079.issue24375@psf.upfronthosting.co.za> Message-ID: <1433343782.74.0.345646086199.issue24375@psf.upfronthosting.co.za> Stefan Krah added the comment: This is my experience, too: Floating-point calculations are often 20-30% faster on 2.7. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 17:05:06 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 03 Jun 2015 15:05:06 +0000 Subject: [issue24375] Performance regression relative to 2.7 In-Reply-To: <1433342967.51.0.80560077079.issue24375@psf.upfronthosting.co.za> Message-ID: <1433343906.6.0.758741910913.issue24375@psf.upfronthosting.co.za> Yury Selivanov added the comment: This is strange. On one of my gentoo boxes I'm having about the same performance of 2.7.9 and 3.4.3. On macos x, 2.7.10 is faster than 3.5.x (make distclean & ./configure & make). I don't know if I should close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 17:09:53 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 03 Jun 2015 15:09:53 +0000 Subject: [issue24375] Performance regression relative to 2.7 In-Reply-To: <1433342967.51.0.80560077079.issue24375@psf.upfronthosting.co.za> Message-ID: <1433344193.85.0.448464241989.issue24375@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > This is strange. On one of my gentoo boxes I'm having about the same performance of 2.7.9 and 3.4.3. As I said: the computed gotos patch improved performance between 2.7.9 and 2.7.10. In any case, if there's no obvious course of action you can suggest, I think it's better to close this issue. We don't want to keep an issue open for each performance regression in the wild. (also, computing the Mandelbrot set using the CPython interpreter isn't a very good use case) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 17:16:08 2015 From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=) Date: Wed, 03 Jun 2015 15:16:08 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1433344568.19.0.0273116948677.issue24017@psf.upfronthosting.co.za> Alex Gr?nholm added the comment: Was __await__() deliberately left out of concurrent.futures.Future or was that an oversight? Or am I misunderstanding something? ---------- nosy: +alex.gronholm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 17:16:16 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 03 Jun 2015 15:16:16 +0000 Subject: [issue24375] Performance regression relative to 2.7 In-Reply-To: <1433342967.51.0.80560077079.issue24375@psf.upfronthosting.co.za> Message-ID: <1433344576.74.0.420868091298.issue24375@psf.upfronthosting.co.za> Yury Selivanov added the comment: Alright. I'm closing it, as it seems it's not obvious what's really going on here. I'll try to profile it on my own later. > (also, computing the Mandelbrot set using the CPython interpreter isn't a very good use case) Antoine, well, regardless of the actual task, we shouldn't have such cases (ideally). FWIW, using numba.jit gives a ~50x boost ;) ---------- resolution: -> postponed status: open -> closed type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 17:18:53 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 03 Jun 2015 15:18:53 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1433344733.37.0.617991180931.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Was __await__() deliberately left out of concurrent.futures.Future or was that an oversight? Or am I misunderstanding something? I don't think concurrent.Future is supposed to be used with asyncio (in 'yield from' or 'await' expressions). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 17:29:03 2015 From: report at bugs.python.org (Carl Osterwisch) Date: Wed, 03 Jun 2015 15:29:03 +0000 Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za> Message-ID: <1433345343.09.0.581677257901.issue14243@psf.upfronthosting.co.za> Carl Osterwisch added the comment: I need to have an external DLL open and read the named file but this current NamedTemporaryFile implementation prevents that from working on Windows. ---------- nosy: +Carl Osterwisch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 17:31:11 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 03 Jun 2015 15:31:11 +0000 Subject: [issue24371] configparser hate dot in option like eth2.6 In-Reply-To: <1433316868.88.0.0222677980936.issue24371@psf.upfronthosting.co.za> Message-ID: <1433345471.78.0.339145680887.issue24371@psf.upfronthosting.co.za> R. David Murray added the comment: I'm guessing python3 would also handle unicode identifiers, but I haven't checked. That said, there's no reason configparser couldn't handle any key that doesn't have a '#', ';', ':' or '=' in it, in theory. Whether we *want* to do that or not is a different question, and would lead to the question of what the correct normalization would be for keys. ---------- nosy: +lukasz.langa, r.david.murray type: -> enhancement versions: +Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 17:53:47 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 03 Jun 2015 15:53:47 +0000 Subject: [issue24376] xxlimited.c errors when building 32 and 64 bit on Windows Message-ID: <1433346827.17.0.151975233058.issue24376@psf.upfronthosting.co.za> New submission from Mark Lawrence: 5>..\Modules\xxlimited.c(268): error C2061: syntax error : identifier 'xx_slots' 5>..\Modules\xxlimited.c(268): error C2059: syntax error : ';' 5>..\Modules\xxlimited.c(268): error C3409: empty attribute block is not allowed 5>..\Modules\xxlimited.c(268): error C2513: '/*global*/ ' : no variable declared before '=' 5>..\Modules\xxlimited.c(269): error C2065: 'Py_mod_exec' : undeclared identifier 5>..\Modules\xxlimited.c(279): error C2065: 'xx_slots' : undeclared identifier 5>..\Modules\xxlimited.c(283): error C2099: initializer is not a constant 5>..\Modules\xxlimited.c(290): warning C4013: 'PyModuleDef_Init' undefined; assuming extern returning int 5>..\Modules\xxlimited.c(290): warning C4047: 'return' : 'PyObject *' differs in levels of indirection from 'int' I believe it's down to r46496. ---------- components: Windows messages: 244764 nosy: BreamoreBoy, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: xxlimited.c errors when building 32 and 64 bit on Windows type: compile error versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 18:16:41 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 03 Jun 2015 16:16:41 +0000 Subject: [issue24376] xxlimited.c errors when building 32 and 64 bit on Windows In-Reply-To: <1433346827.17.0.151975233058.issue24376@psf.upfronthosting.co.za> Message-ID: <1433348200.99.0.165009734035.issue24376@psf.upfronthosting.co.za> Steve Dower added the comment: Which revision? Can you post a hash or issue number instead - in my repo r46496 is from a couple of years ago... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 18:21:17 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 03 Jun 2015 16:21:17 +0000 Subject: [issue24376] xxlimited.c errors when building 32 and 64 bit on Windows In-Reply-To: <1433346827.17.0.151975233058.issue24376@psf.upfronthosting.co.za> Message-ID: <1433348477.61.0.564705130461.issue24376@psf.upfronthosting.co.za> Mark Lawrence added the comment: Try r96496 :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 18:27:47 2015 From: report at bugs.python.org (paul j3) Date: Wed, 03 Jun 2015 16:27:47 +0000 Subject: [issue24251] Different behavior for argparse between 2.7.8 and 2.7.9 when adding the same arguments to the root and the sub commands In-Reply-To: <1432161314.48.0.939908418066.issue24251@psf.upfronthosting.co.za> Message-ID: <1433348867.76.0.274906491942.issue24251@psf.upfronthosting.co.za> paul j3 added the comment: And the corresponding bug issue http://bugs.python.org/issue9351 ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 18:29:09 2015 From: report at bugs.python.org (paul j3) Date: Wed, 03 Jun 2015 16:29:09 +0000 Subject: [issue9351] argparse set_defaults on subcommands should override top level set_defaults In-Reply-To: <1279894012.43.0.0678646409.issue9351@psf.upfronthosting.co.za> Message-ID: <1433348949.58.0.483564571784.issue9351@psf.upfronthosting.co.za> paul j3 added the comment: Another example of this patch causing backward compatibility problems http://bugs.python.org/issue24251 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 18:34:06 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 03 Jun 2015 16:34:06 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1433349246.48.0.56444487439.issue8232@psf.upfronthosting.co.za> Steve Dower added the comment: I do like this fix, and I'm sorry I didn't get to reviewing it before beta 1 was released - can we consider this something to fix for 3.5 or do we need to slip it until 3.6? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 18:34:54 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 03 Jun 2015 16:34:54 +0000 Subject: [issue24376] xxlimited.c errors when building 32 and 64 bit on Windows In-Reply-To: <1433346827.17.0.151975233058.issue24376@psf.upfronthosting.co.za> Message-ID: <1433349294.19.0.553850569437.issue24376@psf.upfronthosting.co.za> Steve Dower added the comment: It's more recent, but still only a doc change. What's the description of the change you're referring to? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 18:35:31 2015 From: report at bugs.python.org (smparkes) Date: Wed, 03 Jun 2015 16:35:31 +0000 Subject: [issue9351] argparse set_defaults on subcommands should override top level set_defaults In-Reply-To: <1279894012.43.0.0678646409.issue9351@psf.upfronthosting.co.za> Message-ID: <1433349331.33.0.921710530878.issue9351@psf.upfronthosting.co.za> Changes by smparkes : ---------- nosy: +smparkes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 18:45:01 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 03 Jun 2015 16:45:01 +0000 Subject: [issue24376] xxlimited.c errors when building 32 and 64 bit on Windows In-Reply-To: <1433346827.17.0.151975233058.issue24376@psf.upfronthosting.co.za> Message-ID: <1433349901.71.0.268565156713.issue24376@psf.upfronthosting.co.za> Mark Lawrence added the comment: Following taken from tortoisehg workbench, the only file changed is setup.py so please don't ask. Changeset: 96496 (6278f932fb29) upgrade xxlimited abi to 3.5 Branch: 3.5 User: Benjamin Peterson Date: 2015-06-03 00:04:46 -0500 (11 hours) Parent: 96494 (38ffea158630) Issue #24368: Support keyword arguments in OrderedDict methods. Child: 96497 (6278231825a1) default merge 3.5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 18:54:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 03 Jun 2015 16:54:49 +0000 Subject: [issue24362] Simplify the fast nodes resize logic in C OrderedDict. In-Reply-To: <1433253631.63.0.422253960427.issue24362@psf.upfronthosting.co.za> Message-ID: <20150603165445.79362.81667@psf.io> Roundup Robot added the comment: New changeset c78c5832ccc0 by Eric Snow in branch '3.5': Issue #24362: Simplify the C OrderedDict fast nodes resize logic. https://hg.python.org/cpython/rev/c78c5832ccc0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 18:55:46 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 03 Jun 2015 16:55:46 +0000 Subject: [issue24362] Simplify the fast nodes resize logic in C OrderedDict. In-Reply-To: <1433253631.63.0.422253960427.issue24362@psf.upfronthosting.co.za> Message-ID: <1433350546.62.0.256020720704.issue24362@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks for pushing this, Stefan (and Jim). :) ---------- resolution: -> fixed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 18:56:46 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 03 Jun 2015 16:56:46 +0000 Subject: [issue24361] OrderedDict: crash with threads In-Reply-To: <1433239377.83.0.708657008711.issue24361@psf.upfronthosting.co.za> Message-ID: <1433350606.21.0.888251136926.issue24361@psf.upfronthosting.co.za> Eric Snow added the comment: This has been fixed via issue24362. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 19:08:50 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 03 Jun 2015 17:08:50 +0000 Subject: [issue24377] Refleak in OrderedDict.__repr__ when an item is not found. Message-ID: <1433351330.67.0.565425708761.issue24377@psf.upfronthosting.co.za> New submission from Eric Snow: It should be a one-line fix. ---------- assignee: eric.snow messages: 244775 nosy: eric.snow priority: high severity: normal stage: needs patch status: open title: Refleak in OrderedDict.__repr__ when an item is not found. type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 19:11:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 03 Jun 2015 17:11:38 +0000 Subject: [issue24377] Refleak in OrderedDict.__repr__ when an item is not found. In-Reply-To: <1433351330.67.0.565425708761.issue24377@psf.upfronthosting.co.za> Message-ID: <20150603171134.94496.37494@psf.io> Roundup Robot added the comment: New changeset 6df1b3c6c8e8 by Eric Snow in branch '3.5': Issue #24377: Fix a ref leak in OrderedDict.__repr__. https://hg.python.org/cpython/rev/6df1b3c6c8e8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 19:12:05 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 03 Jun 2015 17:12:05 +0000 Subject: [issue24377] Refleak in OrderedDict.__repr__ when an item is not found. In-Reply-To: <1433351330.67.0.565425708761.issue24377@psf.upfronthosting.co.za> Message-ID: <1433351525.92.0.625819611911.issue24377@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 19:13:47 2015 From: report at bugs.python.org (paul j3) Date: Wed, 03 Jun 2015 17:13:47 +0000 Subject: [issue24338] In argparse adding wrong arguments makes malformed namespace In-Reply-To: <1433070096.48.0.744562806973.issue24338@psf.upfronthosting.co.za> Message-ID: <1433351627.73.0.0304628682619.issue24338@psf.upfronthosting.co.za> paul j3 added the comment: The code that converts '-' to '_' is independent of the code that uses 'prefix_chars'. The '-' conversion handles a long standing UNIX practice of allowing that character in the middle of option flags. It's an attempt to turn such flags into valid variable names. There is a bug/issue about whether the conversion should be applied to positional argument 'dest' parameters. Is the use of other funny characters in optional flags common enough to warrant a patch? It probably wouldn't be hard to convert all 'prefix_chars' to '_'. But should it still convert '-', even if it isn't in that list? What about users who are content with using 'getattr', and don't want the conversion? Note also that you can invoke `parse_args` with your own custom Namespace object. https://docs.python.org/3.4/library/argparse.html#the-namespace-object This means you can write a Namespace class alternative that can handle funny characters in any way you want. I discuss the use of custom Namespace classes in http://bugs.python.org/issue9351. Between the availability of 'getattr' and namespace customization, I don't think there's anything here that requires a patch. But I'm in favor of keeping the issue open for discussion. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 19:30:31 2015 From: report at bugs.python.org (paul j3) Date: Wed, 03 Jun 2015 17:30:31 +0000 Subject: [issue24360] improve argparse.Namespace __repr__ for invalid identifiers. In-Reply-To: <1433224851.97.0.184092285023.issue24360@psf.upfronthosting.co.za> Message-ID: <1433352631.65.0.810884538111.issue24360@psf.upfronthosting.co.za> paul j3 added the comment: Off hand I don't see a problem with this patch (but I haven't tested it yet). But I have a couple of cautions: The docs say, regarding the Namespace class: > This class is deliberately simple, just an object subclass with a readable string representation. This patch improves the 'readable' part, but adds some complexity. The docs also note that the user can provide their own namespace object, and by implication, a custom Namespace class with this improved '__repr__'. The Namespace '__repr__' is mainly of value during code development, especially when trying ideas in an interactive shell. It's unlikely that you would want to show the whole namespace to your end user. So even if your final API requires funny characters, you don't need to use them during development. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 19:42:57 2015 From: report at bugs.python.org (Matthias Bussonnier) Date: Wed, 03 Jun 2015 17:42:57 +0000 Subject: [issue24360] improve argparse.Namespace __repr__ for invalid identifiers. In-Reply-To: <1433224851.97.0.184092285023.issue24360@psf.upfronthosting.co.za> Message-ID: <1433353377.25.0.474308222423.issue24360@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: Sure and anyway if you have a huge namespace, things will become unreadable. But during development/teaching, having object that have a "sane" representation is useful, otherwise your brain (well at least mine), choke on the output and break the flow of my thoughts. One could also just use __repr(self)__ = repr(self.__dict__), that woudl be even simpler and readable :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 19:55:26 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 03 Jun 2015 17:55:26 +0000 Subject: [issue24376] xxlimited.c errors when building 32 and 64 bit on Windows In-Reply-To: <1433349901.71.0.268565156713.issue24376@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: We need to bump the Py_LIMITED_API definition in PCbuild/xxlimited.vcxproj as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 20:05:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 03 Jun 2015 18:05:07 +0000 Subject: [issue24376] xxlimited.c errors when building 32 and 64 bit on Windows In-Reply-To: <1433346827.17.0.151975233058.issue24376@psf.upfronthosting.co.za> Message-ID: <20150603180504.837.87065@psf.io> Roundup Robot added the comment: New changeset b8bcc5507541 by Steve Dower in branch '3.5': Issue #24376: xxlimited.c errors when building 32 and 64 bit on Windows https://hg.python.org/cpython/rev/b8bcc5507541 New changeset c802fba79554 by Steve Dower in branch 'default': Issue #24376: xxlimited.c errors when building 32 and 64 bit on Windows https://hg.python.org/cpython/rev/c802fba79554 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 20:06:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 03 Jun 2015 18:06:13 +0000 Subject: [issue24376] xxlimited.c errors when building 32 and 64 bit on Windows In-Reply-To: <1433346827.17.0.151975233058.issue24376@psf.upfronthosting.co.za> Message-ID: <20150603180611.129630.89418@psf.io> Roundup Robot added the comment: New changeset 31301b84ac8d by Steve Dower in branch 'default': Issue #24376: Bumps xxlimited.vcxproj to use 3.6 limited ABI. https://hg.python.org/cpython/rev/31301b84ac8d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 20:25:09 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 03 Jun 2015 18:25:09 +0000 Subject: [issue24376] xxlimited.c errors when building 32 and 64 bit on Windows In-Reply-To: <1433346827.17.0.151975233058.issue24376@psf.upfronthosting.co.za> Message-ID: <1433355909.26.0.40127951452.issue24376@psf.upfronthosting.co.za> R. David Murray added the comment: Mark, FYI the 'r' numbers are unique to each mercurial checkout and meaningless to anyone else. Only the hash numbers can be used to compare revisions between different repositories. (You *could* refer to the r number from the cpython repository as seen in the mercurial web interface to it, because other people could look that one up via the web interface, but it is best to get in the habit of always using the hash.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 20:25:35 2015 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Wed, 03 Jun 2015 18:25:35 +0000 Subject: [issue24251] Different behavior for argparse between 2.7.8 and 2.7.9 when adding the same arguments to the root and the sub commands In-Reply-To: <1432161314.48.0.939908418066.issue24251@psf.upfronthosting.co.za> Message-ID: <1433355935.53.0.176808696705.issue24251@psf.upfronthosting.co.za> Changes by R?mi Rampin : ---------- nosy: +remram _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 20:28:29 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 03 Jun 2015 18:28:29 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1433356109.7.0.353125767774.issue8232@psf.upfronthosting.co.za> R. David Murray added the comment: I haven't reviewed the patch, but if it only makes the existing API actually work for Windows, I think it would be fair game for 3.5. Larry would need to make the call, though. ---------- nosy: +larry, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 20:35:40 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 03 Jun 2015 18:35:40 +0000 Subject: [issue24369] Using OrderedDict.move_to_end during iteration is problematic. In-Reply-To: <1433290338.7.0.000891245826788.issue24369@psf.upfronthosting.co.za> Message-ID: <1433356540.45.0.600210205928.issue24369@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a patch that tracks changes to the C OrderedDict linked list, similar to how it's done in deque. I've left the pure Python OrderedDict alone. @Raymond, that state counter works great. :) ---------- keywords: +patch stage: test needed -> patch review Added file: http://bugs.python.org/file39610/issue24369-iteration-mutation.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 20:35:56 2015 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Wed, 03 Jun 2015 18:35:56 +0000 Subject: [issue9351] argparse set_defaults on subcommands should override top level set_defaults In-Reply-To: <1279894012.43.0.0678646409.issue9351@psf.upfronthosting.co.za> Message-ID: <1433356556.96.0.609820978518.issue9351@psf.upfronthosting.co.za> R?mi Rampin added the comment: To me this is much more than a compatibility problem. The way it worked before made a lot of sense, and just felt like the "correct" solution to accept a flag in multiple places. Having a --verbose flag is something everybody should consider (Python has a decent builtin logging module), and anybody providing it would definitely want to accept it before and after subcommands (or at least, for every subcommand). The only way right now is to not only create different arguments with add_argument(), for each parser, but you also need to provide different destination names (and then do something shitty like verbosity = args.verb_main+args.verb_subcommand). This bug makes argparse completely unusable for any real-life application that uses subparsers (in addition to breaking existing programs). And it breaks silently too, simply amazing! Of course there is very little point in fixing this now. Since this affects multiple released versions of Python, I have to use a work-around anyway (until I can move from argparse to something that won't decide to break someday for the hell of it). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 22:00:13 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 03 Jun 2015 20:00:13 +0000 Subject: [issue24376] xxlimited.c errors when building 32 and 64 bit on Windows In-Reply-To: <1433346827.17.0.151975233058.issue24376@psf.upfronthosting.co.za> Message-ID: <1433361613.83.0.485452206703.issue24376@psf.upfronthosting.co.za> Mark Lawrence added the comment: Thanks for the comment David. Last time I used any kind of change system in anger was Visual Source Safe 15 years ago, and VAX/VMS CMS/MMF(?) before that. Where do I start with Mercurial? I don't even know what the difference is between setting up the now default 3.6 and 3.5? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 22:33:06 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 03 Jun 2015 20:33:06 +0000 Subject: [issue24374] Plug refleak in set_coroutine_wrapper In-Reply-To: <1433340719.96.0.108674882489.issue24374@psf.upfronthosting.co.za> Message-ID: <1433363586.2.0.929838309584.issue24374@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file39611/set_coro.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 22:48:40 2015 From: report at bugs.python.org (Tim Pierce) Date: Wed, 03 Jun 2015 20:48:40 +0000 Subject: [issue22931] cookies with square brackets in value In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za> Message-ID: <1433364520.37.0.332108463889.issue22931@psf.upfronthosting.co.za> Changes by Tim Pierce : ---------- nosy: +Tim Pierce _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 22:52:07 2015 From: report at bugs.python.org (paul j3) Date: Wed, 03 Jun 2015 20:52:07 +0000 Subject: [issue24360] improve argparse.Namespace __repr__ for invalid identifiers. In-Reply-To: <1433224851.97.0.184092285023.issue24360@psf.upfronthosting.co.za> Message-ID: <1433364727.43.0.393436218755.issue24360@psf.upfronthosting.co.za> paul j3 added the comment: An alternative would be to wrap a non-identifier name in 'repr()': def repr1(self): def fmt_name(name): if name.isidentifier(): return name else: return repr(name) type_name = type(self).__name__ arg_strings = [] for arg in self._get_args(): arg_strings.append(repr(arg)) for name, value in self._get_kwargs(): arg_strings.append('%s=%r' % (fmt_name(name), value)) return '%s(%s)' % (type_name, ', '.join(arg_strings)) This would produce lines like: Namespace(baz='one', 'foo bar'='test', 'x __y'='other') Namespace(a=1, b=2, 'double " quote'='"', "single ' quote "="'") Namespace(')'=3, a=1) Namespace(a=1, 'b=2), Namespace(c'=3) With names that are deliberately messy, it is hard to say which is clearer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 3 23:15:00 2015 From: report at bugs.python.org (paul j3) Date: Wed, 03 Jun 2015 21:15:00 +0000 Subject: [issue24338] In argparse adding wrong arguments makes malformed namespace In-Reply-To: <1433070096.48.0.744562806973.issue24338@psf.upfronthosting.co.za> Message-ID: <1433366100.39.0.38356679438.issue24338@psf.upfronthosting.co.za> paul j3 added the comment: http://bugs.python.org/issue15125 argparse: positional arguments containing - in name not handled well Discussion on whether positionals 'dest' should translate '-' to '_'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 00:31:45 2015 From: report at bugs.python.org (Petr Viktorin) Date: Wed, 03 Jun 2015 22:31:45 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1433370705.13.0.125144720772.issue24268@psf.upfronthosting.co.za> Petr Viktorin added the comment: I've posted a patch that fixes the remaining refleak in issue24373. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 00:42:13 2015 From: report at bugs.python.org (py.user) Date: Wed, 03 Jun 2015 22:42:13 +0000 Subject: [issue24338] In argparse adding wrong arguments makes malformed namespace In-Reply-To: <1433070096.48.0.744562806973.issue24338@psf.upfronthosting.co.za> Message-ID: <1433371333.66.0.596629910083.issue24338@psf.upfronthosting.co.za> py.user added the comment: paul j3 wrote: > It's an attempt to turn such flags into valid variable names. I'm looking at code and see that he wanted to make it handy for use in a resulting Namespace. args = argparse.parse_args(['--a-b-c']) abc = args.a_b_c If he doesn't convert, he cannot get attribute without getattr(). It's not a UNIX reason. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 01:12:47 2015 From: report at bugs.python.org (Matthias Bussonnier) Date: Wed, 03 Jun 2015 23:12:47 +0000 Subject: [issue24360] improve argparse.Namespace __repr__ for invalid identifiers. In-Reply-To: <1433224851.97.0.184092285023.issue24360@psf.upfronthosting.co.za> Message-ID: <1433373167.78.0.0503369102164.issue24360@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: > Namespace(a=1, 'b=2), Namespace(c'=3) :-) I read that a `prime-b`=2 and `c-prime`=3. I just feel like having a repr which is closer to the constructor signature is better, but I guess it's a question of taste. Anyway, both would be fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 01:52:22 2015 From: report at bugs.python.org (paul j3) Date: Wed, 03 Jun 2015 23:52:22 +0000 Subject: [issue24338] In argparse adding wrong arguments makes malformed namespace In-Reply-To: <1433070096.48.0.744562806973.issue24338@psf.upfronthosting.co.za> Message-ID: <1433375542.28.0.346561007388.issue24338@psf.upfronthosting.co.za> paul j3 added the comment: Yes, the '_' makes it accessible as an attribute name. But the presence of '-' in the option name has a UNIX history. That is a flag like '--a-b-c' is typical, '--a_b_c' is not. There is less of precedent for a flag like '@@a at b' or '--a at b'. Here's the relevant code from '_ActionContainer' class. def _get_optional_kwargs(self, *args, **kwargs): # determine short and long option strings ... for option_string in args: # error on strings that don't start with an appropriate prefix if not option_string[0] in self.prefix_chars: ... raise ValueError(msg % args) # strings starting with two prefix characters are long options option_strings.append(option_string) if option_string[0] in self.prefix_chars: if len(option_string) > 1: if option_string[1] in self.prefix_chars: long_option_strings.append(option_string) # infer destination, '--foo-bar' -> 'foo_bar' and '-x' -> 'x' dest = kwargs.pop('dest', None) if dest is None: if long_option_strings: dest_option_string = long_option_strings[0] else: dest_option_string = option_strings[0] dest = dest_option_string.lstrip(self.prefix_chars) if not dest: msg = _('dest= is required for options like %r') raise ValueError(msg % option_string) dest = dest.replace('-', '_') Even if you need to have odd ball characters in the option flag, you don't have to settle for them in the 'dest'. You can always give the argument a nice looking 'dest'. That's a rather common pattern in 'argparse'. Provide a default handling for common cases, and provide parameters that let the user override those defaults. The net effect is to limit the complexity of the code, while increasing the complexity of the documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 01:57:49 2015 From: report at bugs.python.org (Matthias Bussonnier) Date: Wed, 03 Jun 2015 23:57:49 +0000 Subject: [issue24294] DeprecationWarnings should be visible by default in the interactive REPL In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za> Message-ID: <1433375869.46.0.0630842133485.issue24294@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: I gave that a shot. Doing it "cleanly" in C as the warning module is initialized much earlier. Though I'm not super used to CPython internals. Doing just before the repl by using `PyRun_SimpleString` make the patch relatively small. ---------- keywords: +patch nosy: +mbussonn Added file: http://bugs.python.org/file39612/enable_deprecation_warnings_in_repl.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 05:21:32 2015 From: report at bugs.python.org (paul j3) Date: Thu, 04 Jun 2015 03:21:32 +0000 Subject: [issue24360] improve argparse.Namespace __repr__ for invalid identifiers. In-Reply-To: <1433224851.97.0.184092285023.issue24360@psf.upfronthosting.co.za> Message-ID: <1433388092.8.0.58947335075.issue24360@psf.upfronthosting.co.za> paul j3 added the comment: I mentioned in the related bug/issue that no one has to use odd characters and spaces in the Namespace. While they are allowed by 'getattr' etc, the programmer has the option of supplying rational names in the 'dest' parameter. There's also the question of what kinds of strings can you supply via 'sys.argv'. For example, I have to use quotes to enter $ python echoargv.py '--b=2), Namespace(c' test Without them 'bash' gives me an error. Strings like this may be nice for exercising a patch, they may not be realistic in full argparse context. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 05:57:37 2015 From: report at bugs.python.org (Matthias Bussonnier) Date: Thu, 04 Jun 2015 03:57:37 +0000 Subject: [issue24360] improve argparse.Namespace __repr__ for invalid identifiers. In-Reply-To: <1433224851.97.0.184092285023.issue24360@psf.upfronthosting.co.za> Message-ID: <1433390257.7.0.628050389157.issue24360@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: As far as I remember, argparse is not only use to parse things from sys.argv where the quoting is not necessary. And Namespace is not only use in argparse. But if you don't want improvement, feel free to close. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 06:22:32 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 04 Jun 2015 04:22:32 +0000 Subject: [issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping. In-Reply-To: <1432750979.18.0.523128349285.issue24303@psf.upfronthosting.co.za> Message-ID: <1433391752.49.0.0271183731765.issue24303@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think it would be a better idea to partially backport the 2.7 logic that uses the random module. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 07:06:05 2015 From: report at bugs.python.org (koobs) Date: Thu, 04 Jun 2015 05:06:05 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <1433394365.46.0.0590306336384.issue22359@psf.upfronthosting.co.za> Changes by koobs : ---------- stage: resolved -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 07:06:26 2015 From: report at bugs.python.org (koobs) Date: Thu, 04 Jun 2015 05:06:26 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <1433394386.97.0.246380601305.issue22359@psf.upfronthosting.co.za> Changes by koobs : ---------- components: +Cross-Build _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 07:06:36 2015 From: report at bugs.python.org (Alka Yadav) Date: Thu, 04 Jun 2015 05:06:36 +0000 Subject: [issue24378] dir(dictobject) returns empty list when __getattribute__ is overriden in the class Message-ID: <1433394396.84.0.259561149442.issue24378@psf.upfronthosting.co.za> New submission from Alka Yadav: When __getattribute__ method is overrriden in a class,then in case of calling an attribute not in class object should throw KeyError. But when calling dir on classs object gives an empty list as dir(dictobject) calls dictobject.__getattribute__(dir) and it throws KeyError instead of AttributeError in dir annd it returns NULL upstream So dir source code need to be fixed to catch KeyError appropriately. ---------- components: Library (Lib) files: direrror.py messages: 244798 nosy: alkayadavit07 at gmail.com priority: normal severity: normal status: open title: dir(dictobject) returns empty list when __getattribute__ is overriden in the class type: crash versions: Python 2.7 Added file: http://bugs.python.org/file39613/direrror.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 07:30:28 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 04 Jun 2015 05:30:28 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1433395828.17.0.0668480935611.issue24017@psf.upfronthosting.co.za> Stefan Behnel added the comment: Hmm, but IMHO a) the new syntax isn't just for asyncio and b) awaiting a Future seems like a *very* reasonable thing to do. I think opening a new ticket for this is a good idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 07:41:01 2015 From: report at bugs.python.org (Chris Lasher) Date: Thu, 04 Jun 2015 05:41:01 +0000 Subject: [issue22385] Define a binary output formatting mini-language for *.hex() In-Reply-To: <1410393301.25.0.193851592698.issue22385@psf.upfronthosting.co.za> Message-ID: <1433396461.45.0.692032179233.issue22385@psf.upfronthosting.co.za> Changes by Chris Lasher : ---------- nosy: +gotgenes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 07:43:03 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 04 Jun 2015 05:43:03 +0000 Subject: [issue24369] Using OrderedDict.move_to_end during iteration is problematic. In-Reply-To: <1433290338.7.0.000891245826788.issue24369@psf.upfronthosting.co.za> Message-ID: <1433396583.0.0.773590679776.issue24369@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This patch looks correct. Go ahead and apply. ---------- assignee: rhettinger -> eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 07:44:01 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 04 Jun 2015 05:44:01 +0000 Subject: [issue24378] dir(dictobject) returns empty list when __getattribute__ is overriden in the class In-Reply-To: <1433394396.84.0.259561149442.issue24378@psf.upfronthosting.co.za> Message-ID: <1433396641.28.0.0409634315593.issue24378@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 08:07:04 2015 From: report at bugs.python.org (Joe Jevnik) Date: Thu, 04 Jun 2015 06:07:04 +0000 Subject: [issue24379] slice.literal notation Message-ID: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> New submission from Joe Jevnik: I often find that when working with pandas and numpy I want to store slice objects in variables to pass around and re-use; however, the syntax for constructing a slice literal outside of an indexer is very different from the syntax used inside of a subscript. This patch proposes the following change: slice.literal This would be a singleton instance of a class that looks like: class sliceliteral(object): def __getitem__(self, key): return key The basic idea is to provide an alternative constructor to 'slice' that uses the subscript syntax. This allows people to write more understandable code. Consider the following examples: reverse = slice(None, None, -1) reverse = slice.literal[::-1] all_rows_first_col = slice(None), slice(0) all_rows_first_col = slice.literal[:, 0] first_row_all_cols_but_last = slice(0), slice(None, -1) first_row_all_cols_but_last = slice.literal[0, :-1] Again, this is not intended to make the code shorter, instead, it is designed to make it more clear what the slice object your are constructing looks like. Another feature of the new `literal` object is that it is not limited to just the creation of `slice` instances; instead, it is designed to mix slices and other types together. For example: >>> slice.literal[0] 0 >>> slice.literal[0, 1] (0, 1) >>> slice.literal[0, 1:] (0, slice(1, None, None) >>> slice.literal[:, ..., ::-1] (slice(None, None, None), Ellipsis, slice(None, None, -1) These examples show that sometimes the subscript notation is much more clear that the non-subscript notation. I believe that while this is trivial, it is very convinient to have on the slice type itself so that it is quickly available. This also prevents everyone from rolling their own version that is accesible in different ways (think Py_RETURN_NONE). Another reason that chose this aproach is that it requires no change to the syntax to support. There is a second change proposed here and that is to 'slice.__repr__'. This change makes the repr of a slice object match the new literal syntax to make it easier to read. >>> slice.literal[:] slice.literal[:] >>> slice.literal[1:] slice.literal[1:] >>> slice.literal[1:-1] slice.literal[1:-1] >>> slice.literal[:-1] slice.literal[:-1] >>> slice.literal[::-1] slice.literal[::-1] This change actually affects old behaviour so I am going to upload it as a seperate patch. I understand that the change to repr much be less desirable than the addition of 'slice.literal' ---------- components: Interpreter Core files: slice.patch keywords: patch messages: 244801 nosy: llllllllll priority: normal severity: normal status: open title: slice.literal notation type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file39614/slice.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 08:07:35 2015 From: report at bugs.python.org (Joe Jevnik) Date: Thu, 04 Jun 2015 06:07:35 +0000 Subject: [issue24379] slice.literal notation In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1433398055.28.0.0206015415796.issue24379@psf.upfronthosting.co.za> Joe Jevnik added the comment: Here is the patch that includes the updates to 'slice.__repr__' ---------- Added file: http://bugs.python.org/file39615/slicerepr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 08:12:36 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Jun 2015 06:12:36 +0000 Subject: [issue24369] Using OrderedDict.move_to_end during iteration is problematic. In-Reply-To: <1433290338.7.0.000891245826788.issue24369@psf.upfronthosting.co.za> Message-ID: <20150604061233.16265.99580@psf.io> Roundup Robot added the comment: New changeset 0d8679858272 by Eric Snow in branch '3.5': Issue #24369: Defend against key-changes during iteration. https://hg.python.org/cpython/rev/0d8679858272 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 08:13:02 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 04 Jun 2015 06:13:02 +0000 Subject: [issue24369] Using OrderedDict.move_to_end during iteration is problematic. In-Reply-To: <1433290338.7.0.000891245826788.issue24369@psf.upfronthosting.co.za> Message-ID: <1433398382.86.0.375371635159.issue24369@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 08:21:00 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 04 Jun 2015 06:21:00 +0000 Subject: [issue24379] slice.literal notation In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1433398860.97.0.848177747415.issue24379@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I like this idea. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 08:36:18 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 04 Jun 2015 06:36:18 +0000 Subject: [issue24379] slice.literal notation In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1433399778.77.0.755096048459.issue24379@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 08:39:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Jun 2015 06:39:07 +0000 Subject: [issue24379] slice.literal notation In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1433399947.06.0.833694940763.issue24379@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why not index the slice type itself? slice[1:2] > Another feature of the new `literal` object is that it is not limited to just the creation of `slice` instances; instead, it is designed to mix slices and other types together. This looks as disadvantage. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 09:17:28 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 04 Jun 2015 07:17:28 +0000 Subject: [issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening) In-Reply-To: <1421201583.23.0.507661432161.issue23237@psf.upfronthosting.co.za> Message-ID: <1433402248.65.0.341232341532.issue23237@psf.upfronthosting.co.za> Martin Panter added the comment: Hi Michiel, if you are looking for the source of , that corresponds to Doc/c-api/veryhigh.rst in the repository. This bug would be fairly easy to solve for ?tkinter? if we could drop the Tcl_DoOneEvent(0) half of the code, and always use the TCL_DONT_WAIT polling instead. Then the event hook could return if there were no immediate events, and it would be up to readline() or whatever to check for interrupts or input, or loop back to PyOS_InputHook() after a small delay. Otherwise, I think we need to come up with a way to inject an event into a TCL event queue when there is a signal that needs handling. If this were possible, it would also fix the SIGINT responsiveness from Tk.mainloop() etc. Or it would be nice if there was a Tcl_DoOneEvent(WAIT_UNTIL_INTERRUPTED_BY_A_SIGNAL) option. A possible test case for this bug would reopen stdin to something harmless, set a SIGALRM handler, and call input(). The signal should eventually cause input() to raise an exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 10:00:38 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 04 Jun 2015 08:00:38 +0000 Subject: [issue24373] Use traverse & finalize in xxlimited and in PEP 489 tests In-Reply-To: <1433337661.83.0.639894570386.issue24373@psf.upfronthosting.co.za> Message-ID: <1433404838.26.0.121739595039.issue24373@psf.upfronthosting.co.za> Nick Coghlan added the comment: Would it also be worth making at docs update to tp_dealloc, suggesting the use of tp_traverse/finalize?: https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_dealloc And perhaps from PyType_FromSpec? https://docs.python.org/3/c-api/type.html?highlight=pytype_fromspec#c.PyType_FromSpec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 10:07:31 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 04 Jun 2015 08:07:31 +0000 Subject: [issue24374] Plug refleak in set_coroutine_wrapper In-Reply-To: <1433340719.96.0.108674882489.issue24374@psf.upfronthosting.co.za> Message-ID: <1433405251.08.0.212025130457.issue24374@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, I'd missed that the previous code wouldn't clean up properly in the failure case. +1 for inlining the check and using the existing error label. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 10:53:10 2015 From: report at bugs.python.org (Petr Viktorin) Date: Thu, 04 Jun 2015 08:53:10 +0000 Subject: [issue24373] Use traverse & finalize in xxlimited and in PEP 489 tests In-Reply-To: <1433337661.83.0.639894570386.issue24373@psf.upfronthosting.co.za> Message-ID: <1433407990.81.0.118639626217.issue24373@psf.upfronthosting.co.za> Petr Viktorin added the comment: tp_traverse is completely orthogonal to tp_dealloc, it's needed to detect (and then break) reference cycles like: obj = xxlimited.Xxo() obj.foo = obj As for tp_finalize: yes, mentioning it in tp_dealloc docs would be good, but I'll need a bit more studying to understand the problem correctly. The cases fixed here are relatively simple; Antoine gives more complex ones in [0]. When I feel qualified to give advice, I'll change the docs. (And most likely, write a PEP to make things easier; some changes to classes will be needed anyway to make PEP 489 multi-phase init work nicely in all cases). But, I plan to focus my CPython time on documenting PEP 489 before diving in here. I think issue 16690 is a good place to track tp_dealloc docs changes. [0] https://mail.python.org/pipermail/python-dev/2015-June/140423.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 13:01:54 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 04 Jun 2015 11:01:54 +0000 Subject: [issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening) In-Reply-To: <1421201583.23.0.507661432161.issue23237@psf.upfronthosting.co.za> Message-ID: <1433415714.82.0.762062219256.issue23237@psf.upfronthosting.co.za> Martin Panter added the comment: I take back my claim about it being easy to fix tkinter with the existing API. My ideas break down because PyOS_InputHook() is used differently in Parser/myreadline.c to Modules/readline.c. So think if we want proper compatibility, a separate hook API might be needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 13:14:19 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 04 Jun 2015 11:14:19 +0000 Subject: [issue24379] slice.literal notation In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1433416459.36.0.0896500063192.issue24379@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I'm with Serhiy, I don't think we need a "literal", just make slice itself indexable: reverse = slice(None, None, -1) reverse = slice[::-1] The only question in my mind is what slice should do when given just a single index: slice[0] I suppose that should be a ValueError? ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 13:36:08 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 04 Jun 2015 11:36:08 +0000 Subject: [issue5319] stdout error at interpreter shutdown fails to return OS error status In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za> Message-ID: <1433417768.46.0.468973489222.issue5319@psf.upfronthosting.co.za> Martin Panter added the comment: I guess this would involve: * Making a new API called Py_Finalize2() or something that returns the status * Redefine the existing Py_Finalize() to call Py_Finalize2() and ignore the return value ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 13:58:34 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Jun 2015 11:58:34 +0000 Subject: [issue24373] Use traverse & finalize in xxlimited and in PEP 489 tests In-Reply-To: <1433337661.83.0.639894570386.issue24373@psf.upfronthosting.co.za> Message-ID: <20150604115827.44977.60800@psf.io> Roundup Robot added the comment: New changeset 265eeb60443a by Nick Coghlan in branch '3.5': Issue #24373: Eliminate PEP 489 test refleaks https://hg.python.org/cpython/rev/265eeb60443a New changeset f24cd8bc5250 by Nick Coghlan in branch 'default': Merge fix for issue #24373 from 3.5 https://hg.python.org/cpython/rev/f24cd8bc5250 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 13:58:34 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Jun 2015 11:58:34 +0000 Subject: [issue16690] Reference leak with custom tp_dealloc in PyType_FromSpec In-Reply-To: <1355535565.73.0.312355807055.issue16690@psf.upfronthosting.co.za> Message-ID: <20150604115826.44977.71474@psf.io> Roundup Robot added the comment: New changeset 265eeb60443a by Nick Coghlan in branch '3.5': Issue #24373: Eliminate PEP 489 test refleaks https://hg.python.org/cpython/rev/265eeb60443a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 14:32:26 2015 From: report at bugs.python.org (Michiel de Hoon) Date: Thu, 04 Jun 2015 12:32:26 +0000 Subject: [issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening) In-Reply-To: <1421201583.23.0.507661432161.issue23237@psf.upfronthosting.co.za> Message-ID: <1433421146.97.0.999700275314.issue23237@psf.upfronthosting.co.za> Michiel de Hoon added the comment: Patch for Modules/_tkinter.c. To be used together with issue23237.version2.patch. ---------- Added file: http://bugs.python.org/file39616/_tkinter.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 14:33:14 2015 From: report at bugs.python.org (Michiel de Hoon) Date: Thu, 04 Jun 2015 12:33:14 +0000 Subject: [issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening) In-Reply-To: <1421201583.23.0.507661432161.issue23237@psf.upfronthosting.co.za> Message-ID: <1433421194.61.0.50980767901.issue23237@psf.upfronthosting.co.za> Michiel de Hoon added the comment: I am not sure if I follow. With the patch to _tkinter.c, interrupts seem to work correctly with all three variations of PyOS_InputHook. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 14:41:44 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Jun 2015 12:41:44 +0000 Subject: [issue5319] stdout error at interpreter shutdown fails to return OS error status In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za> Message-ID: <1433421704.81.0.120994623809.issue5319@psf.upfronthosting.co.za> Antoine Pitrou added the comment: We would probably call it Py_FinalizeEx(), but yes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 14:58:45 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 04 Jun 2015 12:58:45 +0000 Subject: [issue24373] Use traverse & finalize in xxlimited and in PEP 489 tests In-Reply-To: <1433337661.83.0.639894570386.issue24373@psf.upfronthosting.co.za> Message-ID: <1433422725.56.0.940862515365.issue24373@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 15:06:12 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 04 Jun 2015 13:06:12 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1433423172.24.0.124792942599.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Hmm, but IMHO a) the new syntax isn't just for asyncio and b) awaiting a Future seems like a *very* reasonable thing to do. I think opening a new ticket for this is a good idea. Stefan, I honestly have bo idea what concurrent.Future.__await__ would do. There is no loop for concurrent module. If you have a patch with tests in mind, please open a separate issue (targeting 3.6). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 15:23:04 2015 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 04 Jun 2015 13:23:04 +0000 Subject: [issue24379] slice.literal notation In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1433424184.35.0.616751767776.issue24379@psf.upfronthosting.co.za> Mark Dickinson added the comment: For prior art, it's worth taking a look at NumPy, and in particular its `s_` and `index_exp` functions: >>> import numpy as np >>> np.s_[1:2] slice(1, 2, None) >>> np.s_[0] 0 >>> np.s_[1:2, 3] (slice(1, 2, None), 3) ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 15:23:56 2015 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 04 Jun 2015 13:23:56 +0000 Subject: [issue24379] slice.literal notation In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1433424236.1.0.647364605007.issue24379@psf.upfronthosting.co.za> Mark Dickinson added the comment: (Correction: they're not functions, or even callables.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 15:32:33 2015 From: report at bugs.python.org (Joe Jevnik) Date: Thu, 04 Jun 2015 13:32:33 +0000 Subject: [issue24379] slice.literal notation In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1433424753.73.0.300647009519.issue24379@psf.upfronthosting.co.za> Joe Jevnik added the comment: > Why not index the slice type itself? slice[1:2] I originally considered this and I personally really like this syntax, but I was concerned with ambiguity with the typing module > The only question in my mind is what slice should do when given just a single index I think some of the power of this concept comes from the fact that I can express a complicated indexer without worrying about how it desugars. I would personally prefer being able to have this return tuples and scalars so that the syntax is easier to explain. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 16:10:25 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 04 Jun 2015 14:10:25 +0000 Subject: [issue24378] dir(dictobject) returns empty list when __getattribute__ is overriden in the class In-Reply-To: <1433394396.84.0.259561149442.issue24378@psf.upfronthosting.co.za> Message-ID: <1433427025.84.0.663617100371.issue24378@psf.upfronthosting.co.za> R. David Murray added the comment: If you override __getattribute__ it is your responsibility to fulfill its contract, so your method is the one that needs to catch the KeyError and return the expected AttributeError. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 16:20:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Jun 2015 14:20:04 +0000 Subject: [issue24374] Plug refleak in set_coroutine_wrapper In-Reply-To: <1433340719.96.0.108674882489.issue24374@psf.upfronthosting.co.za> Message-ID: <20150604142000.22040.97342@psf.io> Roundup Robot added the comment: New changeset 3f2bf0ff262c by Yury Selivanov in branch '3.5': Issue 24374: Plug refleak in set_coroutine_wrapper https://hg.python.org/cpython/rev/3f2bf0ff262c New changeset 68f40b6448b9 by Yury Selivanov in branch 'default': Issue 24374: Plug refleak in set_coroutine_wrapper https://hg.python.org/cpython/rev/68f40b6448b9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 16:20:49 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 04 Jun 2015 14:20:49 +0000 Subject: [issue24374] Plug refleak in set_coroutine_wrapper In-Reply-To: <1433340719.96.0.108674882489.issue24374@psf.upfronthosting.co.za> Message-ID: <1433427649.79.0.699887632203.issue24374@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 16:20:59 2015 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 04 Jun 2015 14:20:59 +0000 Subject: [issue24380] Got warning when compiling _scproxy.c on Mac Message-ID: <1433427659.62.0.118183885403.issue24380@psf.upfronthosting.co.za> New submission from Vajrasky Kok: Got this warning when compiling Python on Mac: building '_scproxy' extension gcc -Wno-unused-result -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. -IInclude -I/usr/local/include -I/Users/sky/Code/python/cpython/Include -I/Users/sky/Code/python/cpython -c /Users/sky/Code/python/cpython/Modules/_scproxy.c -o build/temp.macosx-10.9-x86_64-3.6-pydebug/Users/sky/Code/python/cpython/Modules/_scproxy.o /Users/sky/Code/python/cpython/Modules/_scproxy.c:74:10: warning: comparison of address of 'kSCPropNetProxiesExcludeSimpleHostnames' not equal to a null pointer is always true [-Wtautological-pointer-compare] if (&kSCPropNetProxiesExcludeSimpleHostnames != NULL) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~ /System/Library/Frameworks/SystemConfiguration.framework/Headers/SCSchemaDefinitions.h:3812:17: note: expanded from macro 'kSCPropNetProxiesExcludeSimpleHostnames' SC_SCHEMA_KV(kSCPropNetProxiesExcludeSimpleHostnames \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /System/Library/Frameworks/SystemConfiguration.framework/Headers/SCSchemaDefinitions.h:469:31: note: expanded from macro 'SC_SCHEMA_KV' #define SC_SCHEMA_KV(k,v,t) k ^ 1 warning generated. gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.9-x86_64-3.6-pydebug/Users/sky/Code/python/cpython/Modules/_scproxy.o -L/usr/local/lib -o build/lib.macosx-10.9-x86_64-3.6-pydebug/_scproxy.cpython-36dm-darwin.so -framework SystemConfiguration -framework CoreFoundation I am not sure though whether the patch is correct solution. But anyway.... ---------- components: Macintosh files: fix_scproxy_compile_warning.patch keywords: patch messages: 244824 nosy: ned.deily, ronaldoussoren, vajrasky priority: normal severity: normal status: open title: Got warning when compiling _scproxy.c on Mac versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39617/fix_scproxy_compile_warning.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 16:44:05 2015 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 04 Jun 2015 14:44:05 +0000 Subject: [issue24381] Got warning when compiling ffi.c on Mac Message-ID: <1433429045.53.0.896226238413.issue24381@psf.upfronthosting.co.za> New submission from Vajrasky Kok: On my OS X Yosemite 10.10.3, I got this warning when compiling Modules/_ctypes/libffi_osx/ffi.c. gcc -Wno-unused-result -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I_ctypes/darwin -I/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/include -I/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/powerpc -I./Include -I. -IInclude -I/usr/local/include -I/Users/sky/Code/python/cpython/Include -I/Users/sky/Code/python/cpython -c /Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/ffi.c -o build/temp.macosx-10.9-x86_64-3.6-pydebug/Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/ffi.o -DMACOSX /Users/sky/Code/python/cpython/Modules/_ctypes/libffi_osx/ffi.c:108:1: warning: unused function 'struct_on_stack' [-Wunused-function] struct_on_stack( ^ 1 warning generated. Here is the patch that I think can fix the warning. ---------- components: Macintosh files: fix_ffi_compile_warning.patch keywords: patch messages: 244825 nosy: ned.deily, ronaldoussoren, vajrasky priority: normal severity: normal status: open title: Got warning when compiling ffi.c on Mac versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39618/fix_ffi_compile_warning.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 17:05:57 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 04 Jun 2015 15:05:57 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1433423172.24.0.124792942599.issue24017@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Maybe it's possible to give an interpretation to awaiting on a threaded Future? __await__ could return a new asyncio Future, and add a completion callback to the original Future that makes the asyncio Future ready and transfers the result/exception. This would have to use loop.call_soon_threadsafe() to transfer control from the exector thread to the thread where the loop is running. The only thing I don't know is whether it's possible for __await__ to return a Future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 17:17:50 2015 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 04 Jun 2015 15:17:50 +0000 Subject: [issue24382] Fail to build time module on Mac Message-ID: <1433431070.5.0.947300140334.issue24382@psf.upfronthosting.co.za> New submission from Vajrasky Kok: On my OSX Yosemite 10 with GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53), I fail to build time module. Failed to build these modules: time Here is the patch to fix the compile error. ---------- components: Macintosh files: fix_fail_build_time_module.patch keywords: patch messages: 244827 nosy: ned.deily, ronaldoussoren, vajrasky priority: normal severity: normal status: open title: Fail to build time module on Mac type: compile error versions: Python 3.6 Added file: http://bugs.python.org/file39619/fix_fail_build_time_module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 17:21:29 2015 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 04 Jun 2015 15:21:29 +0000 Subject: [issue24382] Fail to build time module on Mac In-Reply-To: <1433431070.5.0.947300140334.issue24382@psf.upfronthosting.co.za> Message-ID: <1433431289.49.0.607816850533.issue24382@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the error message: building 'time' extension gcc -Wno-unused-result -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. -IInclude -I/usr/local/include -I/Users/sky/Code/python/cpython/Include -I/Users/sky/Code/python/cpython -c /Users/sky/Code/python/cpython/Modules/timemodule.c -o build/temp.macosx-10.9-x86_64-3.6-pydebug/Users/sky/Code/python/cpython/Modules/timemodule.o /Users/sky/Code/python/cpython/Modules/timemodule.c:656:9: error: use of undeclared identifier '_Py_BEGIN_SUPPRESS_IPH' _Py_BEGIN_SUPPRESS_IPH ^ /Users/sky/Code/python/cpython/Modules/timemodule.c:659:9: error: use of undeclared identifier '_Py_END_SUPPRESS_IPH' _Py_END_SUPPRESS_IPH ^ 2 errors generated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 17:31:49 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 04 Jun 2015 15:31:49 +0000 Subject: [issue24382] Fail to build time module on Mac In-Reply-To: <1433431070.5.0.947300140334.issue24382@psf.upfronthosting.co.za> Message-ID: <1433431909.32.0.382238892197.issue24382@psf.upfronthosting.co.za> Zachary Ware added the comment: See discussion on #24244, I think this is an issue with your checkout rather than the code. ---------- nosy: +zach.ware status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 17:36:07 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 04 Jun 2015 15:36:07 +0000 Subject: [issue24382] Fail to build time module on Mac In-Reply-To: <1433431070.5.0.947300140334.issue24382@psf.upfronthosting.co.za> Message-ID: <1433432167.35.0.551911817734.issue24382@psf.upfronthosting.co.za> Ned Deily added the comment: Yes, try "make distclean". I am unable to reproduce the problem and don't see why your proposed patch would make a difference. ---------- resolution: -> works for me stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 17:38:14 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 04 Jun 2015 15:38:14 +0000 Subject: [issue24383] consider implementing __await__ on concurrent.futures.Future Message-ID: <1433432294.12.0.421609125243.issue24383@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- assignee: yselivanov components: Library (Lib), asyncio nosy: gvanrossum, haypo, scoder, yselivanov priority: normal severity: normal status: open title: consider implementing __await__ on concurrent.futures.Future type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 17:38:35 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 04 Jun 2015 15:38:35 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1433432315.86.0.0295987791946.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: Guido, Stefen, please see issue24383. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 17:42:58 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 04 Jun 2015 15:42:58 +0000 Subject: [issue24383] consider implementing __await__ on concurrent.futures.Future Message-ID: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za> New submission from Yury Selivanov: > Maybe it's possible to give an interpretation to awaiting on a threaded > Future? __await__ could return a new asyncio Future, and add a completion > callback to the original Future that makes the asyncio Future ready and > transfers the result/exception. This would have to use > loop.call_soon_threadsafe() to transfer control from the exector thread to > the thread where the loop is running. It didn't occur to me that we can implement __await__ on concurrent.Future to integrate it *with* asyncio. I guess it makes sense (although we don't have this kind of integration in 3.4 with 'yield from') > The only thing I don't know is whether it's possible for __await__ to > return a Future. It is -- we just have to return "iter(asyncio.Future())" Please see the attached patch -- it needs some more tuning, but it demonstrates that the integration is possible. ---------- keywords: +patch Added file: http://bugs.python.org/file39620/concurrent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 17:43:48 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 04 Jun 2015 15:43:48 +0000 Subject: [issue24383] consider implementing __await__ on concurrent.futures.Future In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za> Message-ID: <1433432628.43.0.83418030209.issue24383@psf.upfronthosting.co.za> Guido van Rossum added the comment: So in issue24017 I wrote: """ Maybe it's possible to give an interpretation to awaiting on a threaded Future? __await__ could return a new asyncio Future, and add a completion callback to the original Future that makes the asyncio Future ready and transfers the result/exception. This would have to use loop.call_soon_threadsafe() to transfer control from the exector thread to the thread where the loop is running. The only thing I don't know is whether it's possible for __await__ to return a Future. """ Yuri, is that possible? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 17:44:18 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 04 Jun 2015 15:44:18 +0000 Subject: [issue24383] consider implementing __await__ on concurrent.futures.Future In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za> Message-ID: <1433432658.32.0.384287343577.issue24383@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- Removed message: http://bugs.python.org/msg244833 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 17:44:49 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 04 Jun 2015 15:44:49 +0000 Subject: [issue24383] consider implementing __await__ on concurrent.futures.Future In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za> Message-ID: <1433432689.51.0.089816203013.issue24383@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Yuri, is that possible? Please see my previous comment and the attached patch :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 17:45:06 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 04 Jun 2015 15:45:06 +0000 Subject: [issue24383] consider implementing __await__ on concurrent.futures.Future In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za> Message-ID: <1433432706.01.0.998400786939.issue24383@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- Removed message: http://bugs.python.org/msg244834 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 18:30:21 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 04 Jun 2015 16:30:21 +0000 Subject: [issue24383] consider implementing __await__ on concurrent.futures.Future In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za> Message-ID: <1433435421.89.0.373658149967.issue24383@psf.upfronthosting.co.za> Yury Selivanov added the comment: Added a unittest for cancellation ---------- Added file: http://bugs.python.org/file39621/concurrent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 19:09:58 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 04 Jun 2015 17:09:58 +0000 Subject: [issue24383] consider implementing __await__ on concurrent.futures.Future In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za> Message-ID: <1433437798.0.0.742778335297.issue24383@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file39622/concurrent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 19:22:55 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 04 Jun 2015 17:22:55 +0000 Subject: [issue24376] xxlimited.c errors when building 32 and 64 bit on Windows In-Reply-To: <1433346827.17.0.151975233058.issue24376@psf.upfronthosting.co.za> Message-ID: <1433438575.52.0.16206188889.issue24376@psf.upfronthosting.co.za> Mark Lawrence added the comment: Now compiles, thanks guys :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 21:00:14 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 04 Jun 2015 19:00:14 +0000 Subject: [issue24383] consider implementing __await__ on concurrent.futures.Future In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za> Message-ID: <1433444414.07.0.322203034792.issue24383@psf.upfronthosting.co.za> Yury Selivanov added the comment: Alternative patch with monkeypatching instead of Future subclassing. ---------- Added file: http://bugs.python.org/file39623/concurrent_alt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 21:04:18 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 04 Jun 2015 19:04:18 +0000 Subject: [issue24383] consider implementing __await__ on concurrent.futures.Future In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za> Message-ID: <1433444658.0.0.42521060113.issue24383@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sorry, I don't like that either. See my review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 21:16:12 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 04 Jun 2015 19:16:12 +0000 Subject: [issue24383] consider implementing __await__ on concurrent.futures.Future In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za> Message-ID: <1433445372.02.0.184657441139.issue24383@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file39624/concurrent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 21:47:32 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 04 Jun 2015 19:47:32 +0000 Subject: [issue24383] consider implementing __await__ on concurrent.futures.Future In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za> Message-ID: <1433447252.18.0.0662920114612.issue24383@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thinking about this more I think we should pass on this for now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 22:12:55 2015 From: report at bugs.python.org (floyd) Date: Thu, 04 Jun 2015 20:12:55 +0000 Subject: [issue24384] difflib.SequenceMatcher faster quick_ratio with lower bound specification Message-ID: <1433448775.15.0.914528193485.issue24384@psf.upfronthosting.co.za> New submission from floyd: I guess a lot of users of difflib call the SequenceMatcher in the following way (where a and b often have different lengths): if difflib.SequenceMatcher.quick_ratio(None, a, b) >= threshold: However, for this use case the current quick_ratio is quite a performance loss. Therefore I propose to add an additional, optimized version quick_ratio_ge which would be called like this: if difflib.SequenceMatcher.quick_ratio_ge(None, a, b, threshold): As we are able to calculate upper bounds for threshold depending on the lengths of a and b this function would return much faster in a lot of cases. An example of how quick_ratio_ge could be implemented is attached. ---------- components: Library (Lib) files: difflib_SequenceMatcher_quick_ratio_ge.py messages: 244840 nosy: floyd priority: normal severity: normal status: open title: difflib.SequenceMatcher faster quick_ratio with lower bound specification type: enhancement Added file: http://bugs.python.org/file39625/difflib_SequenceMatcher_quick_ratio_ge.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 22:22:45 2015 From: report at bugs.python.org (floyd) Date: Thu, 04 Jun 2015 20:22:45 +0000 Subject: [issue24384] difflib.SequenceMatcher faster quick_ratio with lower bound specification In-Reply-To: <1433448775.15.0.914528193485.issue24384@psf.upfronthosting.co.za> Message-ID: <1433449365.96.0.723569128654.issue24384@psf.upfronthosting.co.za> floyd added the comment: Now that I gave it another thought, I think it would be better if we simply add threshold as a named parameter of quick_ratio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 22:52:13 2015 From: report at bugs.python.org (Jan Harkes) Date: Thu, 04 Jun 2015 20:52:13 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects Message-ID: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> New submission from Jan Harkes: mingw32 fails to link with libpython27.a fails with the following error /cygdrive/C/Python27/libs/libpython27.a: error adding symbols: File format not recognized extracting all the objects from libpython27.a and checking them with objdump shows that two objects (dmmet.o and dmmeh.o) are not recognized, file returns 'data' for their file types. objdump from a 64-bit version of mingw recognizes these as pe-x86-64. ---------- components: Library (Lib) messages: 244842 nosy: Jan Harkes priority: normal severity: normal status: open title: libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 23:02:51 2015 From: report at bugs.python.org (Brandon Milam) Date: Thu, 04 Jun 2015 21:02:51 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1433451771.69.0.997262705229.issue8232@psf.upfronthosting.co.za> Brandon Milam added the comment: Here's a patch addressing all of the comments in the review. Changing the browsers from a set to a list though resulted in duplicates in the _tryorder list that were not present before because the set had filtered the duplicates before the partial string comparisons. The _browsers dictionary did not contain the duplicates so I don't think this will have any functional changes. ---------- Added file: http://bugs.python.org/file39626/webbrowserfix5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 23:42:05 2015 From: report at bugs.python.org (Brandon Milam) Date: Thu, 04 Jun 2015 21:42:05 +0000 Subject: [issue24148] 'cum' not a valid sort key for pstats.Stats.sort_stats In-Reply-To: <1431184757.15.0.93515789631.issue24148@psf.upfronthosting.co.za> Message-ID: <1433454125.85.0.111669615955.issue24148@psf.upfronthosting.co.za> Brandon Milam added the comment: They are correct. 'cum' is not one of the available keywords and so here is the fix changing it to say 'cumulative' for consistency as ramiro suggested. ---------- keywords: +patch nosy: +jbmilam Added file: http://bugs.python.org/file39627/profile_example_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 23:52:58 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Thu, 04 Jun 2015 21:52:58 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1433454778.17.0.211108403494.issue23496@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: #1 and #2 are fixed. I hand-edited the patch file (!!), so here's to hoping it'll work... Working on #3. You probably should try the tests now (which is obviously the scary part ;). ---------- Added file: http://bugs.python.org/file39628/kbox_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 4 23:56:18 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Thu, 04 Jun 2015 21:56:18 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1433454978.57.0.87793671066.issue23496@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: Fixes for readline and _crypt done. ---------- Added file: http://bugs.python.org/file39629/lib_fixes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 00:22:06 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 04 Jun 2015 22:22:06 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433456526.04.0.590089282921.issue24385@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- assignee: -> steve.dower components: +Build, Installation, Windows -Library (Lib) nosy: +steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 00:30:48 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 04 Jun 2015 22:30:48 +0000 Subject: [issue24383] consider implementing __await__ on concurrent.futures.Future In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za> Message-ID: <1433457048.46.0.139565185985.issue24383@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 00:34:30 2015 From: report at bugs.python.org (Benjamin Gilbert) Date: Thu, 04 Jun 2015 22:34:30 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433457270.89.0.830434136295.issue24385@psf.upfronthosting.co.za> Changes by Benjamin Gilbert : ---------- nosy: +bgilbert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 00:48:41 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 04 Jun 2015 22:48:41 +0000 Subject: [issue24168] Unittest discover fails with namespace package if the path contains the string same as the module name In-Reply-To: <1431393278.14.0.705809016524.issue24168@psf.upfronthosting.co.za> Message-ID: <1433458121.76.0.465585514761.issue24168@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 01:00:26 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 04 Jun 2015 23:00:26 +0000 Subject: [issue24168] Unittest discover fails with namespace package if the path contains the string same as the module name In-Reply-To: <1431393278.14.0.705809016524.issue24168@psf.upfronthosting.co.za> Message-ID: <1433458826.18.0.0682086125648.issue24168@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: If you need a test case, try https://gitlab.com/warsaw/flufl.lock ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 01:21:33 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 04 Jun 2015 23:21:33 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433460093.69.0.862788084513.issue24385@psf.upfronthosting.co.za> Steve Dower added the comment: Given I can't generate the file any other way that will be compatible for everyone, unless someone contributes a fix I'm going to stop shipping these files and let people generate them using whatever tools they have. If anyone wants to suggest instructions then I'll make a readme file that has some suggestions on how to generate them. Please include information about what build/fork/version of mingw your instructions are for. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 01:41:44 2015 From: report at bugs.python.org (Graham Oliver) Date: Thu, 04 Jun 2015 23:41:44 +0000 Subject: [issue24386] Bug Tracker emails going to gmail spam Message-ID: <1433461304.02.0.848740275785.issue24386@psf.upfronthosting.co.za> New submission from Graham Oliver: I noticed that when I created an issue in this Bug Tracjer all of the associated emails were ending up in my gmail spam. '...in violation of Google's recommended email sender guidelines.' An explanatory link sends me to https://support.google.com/mail/answer/81126?hl=en-GB#authentication Cheers g ---------- components: email messages: 244849 nosy: Graham.Oliver, barry, r.david.murray priority: normal severity: normal status: open title: Bug Tracker emails going to gmail spam type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 02:01:58 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 05 Jun 2015 00:01:58 +0000 Subject: [issue24386] Bug Tracker emails going to gmail spam In-Reply-To: <1433461304.02.0.848740275785.issue24386@psf.upfronthosting.co.za> Message-ID: <1433462518.6.0.33947075044.issue24386@psf.upfronthosting.co.za> R. David Murray added the comment: There are already open issues about this in the meta tracker. (See the 'report tracker problem' link at the bottom of the left column.) ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 02:04:00 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 05 Jun 2015 00:04:00 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433462640.24.0.373583056844.issue24385@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 02:53:00 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 05 Jun 2015 00:53:00 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1433465580.81.0.858935611023.issue8232@psf.upfronthosting.co.za> Larry Hastings added the comment: Go ahead for beta 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 02:59:04 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Fri, 05 Jun 2015 00:59:04 +0000 Subject: [issue24294] DeprecationWarnings should be visible by default in the interactive REPL In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za> Message-ID: <1433465944.51.0.422023576747.issue24294@psf.upfronthosting.co.za> Nathaniel Smith added the comment: For whatever it's worth as a non-core-developer, the patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 04:27:15 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 05 Jun 2015 02:27:15 +0000 Subject: [issue24384] difflib.SequenceMatcher faster quick_ratio with lower bound specification In-Reply-To: <1433448775.15.0.914528193485.issue24384@psf.upfronthosting.co.za> Message-ID: <1433471235.15.0.606408387907.issue24384@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 04:28:45 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 05 Jun 2015 02:28:45 +0000 Subject: [issue24351] string.Template documentation incorrectly references "identifiers" In-Reply-To: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za> Message-ID: <1433471325.18.0.985780931116.issue24351@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> barry nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 04:46:06 2015 From: report at bugs.python.org (Matthew Barnett) Date: Fri, 05 Jun 2015 02:46:06 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433472366.22.0.0203450466556.issue24385@psf.upfronthosting.co.za> Matthew Barnett added the comment: Here's how I can build the regex module on Windows 8.1, 64-bit, using only MinGW64. For Python 3.5, I can link against "python35.dll", but for earlier versions, including Python 2.7, I need "libpython??.a". I have built regex module for all of the 16 supported versions of Python (2.5-2.7, 3.1-3.5, 64-bit and 32-bit) and they have all passed the tests. rem For Python 3.5, 64-bit. rem Can link against the Python DLL. rem Compile "C:\MinGW64\bin\gcc.exe" -mdll -m64 -DMS_WIN64 -O2 -Wall -Wsign-compare -Wconversion -I"C:\Python35-64\include" -c "D:\mrab-regex\source\_regex_unicode.c" -o "D:\mrab-regex\release\3.5-64\_regex_unicode.o" "C:\MinGW64\bin\gcc.exe" -mdll -m64 -DMS_WIN64 -O2 -Wall -Wsign-compare -Wconversion -I"C:\Python35-64\include" -c "D:\mrab-regex\source\_regex.c" -o "D:\mrab-regex\release\3.5-64\_regex.o" rem Link "C:\MinGW64\bin\gcc.exe" -m64 -shared -s "D:\mrab-regex\release\3.5-64\_regex_unicode.o" "D:\mrab-regex\release\3.5-64\_regex.o" -L"C:\Python35" -lpython35 -o "D:\mrab-regex\release\3.5-64\_regex.pyd" rem For Python 3.5, 32-bit. rem Can link against the Python DLL. rem Compile "C:\MinGW64\bin\gcc.exe" -mdll -m32 -O2 -Wall -Wsign-compare -Wconversion -I"C:\Python35-32\include" -c "D:\mrab-regex\source\_regex_unicode.c" -o "D:\mrab-regex\release\3.5-32\_regex_unicode.o" "C:\MinGW64\bin\gcc.exe" -mdll -m32 -O2 -Wall -Wsign-compare -Wconversion -I"C:\Python35-32\include" -c "D:\mrab-regex\source\_regex.c" -o "D:\mrab-regex\release\3.5-32\_regex.o" rem Link "C:\MinGW64\bin\gcc.exe" -m32 -shared -s "D:\mrab-regex\release\3.5-32\_regex_unicode.o" "D:\mrab-regex\release\3.5-32\_regex.o" -L"C:\Python35-32" -lpython35 -o "D:\mrab-regex\release\3.5-32\_regex.pyd" rem For Python 3.4, 64-bit. rem Need to link against the Python .a file. rem Make libpython34.a "C:\MinGW64\x86_64-w64-mingw32\bin\gendef.exe" - "C:\Windows\System32\python34.dll" >"C:\Python34-64\libs\libpython34.def" "C:\MinGW64\bin\dlltool.exe" --dllname python34.dll --def "C:\Python34-64\libs\libpython34.def" --output-lib "C:\Python34-64\libs\libpython34.a" rem Compile "C:\MinGW64\bin\gcc.exe" -mdll -m64 -DMS_WIN64 -O2 -Wall -Wsign-compare -Wconversion -I"C:\Python34-64\include" -c "D:\mrab-regex\source\_regex_unicode.c" -o "D:\mrab-regex\release\3.4-64\_regex_unicode.o" rem Link "C:\MinGW64\bin\gcc.exe" -mdll -m64 -DMS_WIN64 -O2 -Wall -Wsign-compare -Wconversion -I"C:\Python34-64\include" -c "D:\mrab-regex\source\_regex.c" -o "D:\mrab-regex\release\3.4-64\_regex.o" "C:\MinGW64\bin\gcc.exe" -m64 -shared -s "D:\mrab-regex\release\3.4-64\_regex_unicode.o" "D:\mrab-regex\release\3.4-64\_regex.o" -L"C:\Python34-64\libs" -lpython34 -o "D:\mrab-regex\release\3.4-64\_regex.pyd" rem For Python 3.4, 32-bit. rem Need to link against the Python .a file. rem Make libpython34.a "C:\MinGW64\x86_64-w64-mingw32\bin\gendef.exe" - "C:\Windows\SysWOW64\python34.dll" >"C:\Python34-32\libs\libpython34.def" "C:\MinGW64\x86_64-w64-mingw32\bin\dlltool.exe" --as-flags=--32 -m i386 --dllname python34.dll --def "C:\Python34-32\libs\libpython34.def" --output-lib "C:\Python34-32\libs\libpython34.a" rem Compile "C:\MinGW64\bin\gcc.exe" -mdll -m32 -O2 -Wall -Wsign-compare -Wconversion -I"C:\Python34-32\include" -c "D:\mrab-regex\source\_regex_unicode.c" -o "D:\mrab-regex\release\3.4-32\_regex_unicode.o" "C:\MinGW64\bin\gcc.exe" -mdll -m32 -O2 -Wall -Wsign-compare -Wconversion -I"C:\Python34-32\include" -c "D:\mrab-regex\source\_regex.c" -o "D:\mrab-regex\release\3.4-32\_regex.o" rem Link "C:\MinGW64\bin\gcc.exe" -m32 -shared -s "D:\mrab-regex\release\3.4-32\_regex_unicode.o" "D:\mrab-regex\release\3.4-32\_regex.o" -L"C:\Python34-32\libs" -lpython34 -o "D:\mrab-regex\release\3.4-32\_regex.pyd" rem For earlier versions of Python, follow the pattern of Python 3.4. ---------- nosy: +mrabarnett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 05:47:21 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 05 Jun 2015 03:47:21 +0000 Subject: [issue24376] xxlimited.c errors when building 32 and 64 bit on Windows In-Reply-To: <1433346827.17.0.151975233058.issue24376@psf.upfronthosting.co.za> Message-ID: <1433476041.44.0.162221045941.issue24376@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- assignee: -> steve.dower resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 05:57:58 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 05 Jun 2015 03:57:58 +0000 Subject: [issue24371] configparser hate dot in option like eth2.6 In-Reply-To: <1433316868.88.0.0222677980936.issue24371@psf.upfronthosting.co.za> Message-ID: <1433476678.14.0.783327664452.issue24371@psf.upfronthosting.co.za> Zachary Ware added the comment: Am I missing something here? Python 3.6.0a0 (default:c2c3b79ba992, Jun 4 2015, 10:24:23) >>> from configparser import ConfigParser >>> cp = ConfigParser() >>> cp.read_string("""\ ... [remember] ... eth2.6 = True ... eth5 = True ... """) >>> cp['remember']['eth2.6'] 'True' ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 05:58:56 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 05 Jun 2015 03:58:56 +0000 Subject: [issue24352] Provide a way for assertLogs to optionally not hide the logging output In-Reply-To: <1433186130.81.0.919581568401.issue24352@psf.upfronthosting.co.za> Message-ID: <1433476736.26.0.640252755208.issue24352@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 08:52:20 2015 From: report at bugs.python.org (Yavuz Selim Komur) Date: Fri, 05 Jun 2015 06:52:20 +0000 Subject: [issue24371] configparser hate dot in option like eth2.6 In-Reply-To: <1433316868.88.0.0222677980936.issue24371@psf.upfronthosting.co.za> Message-ID: <1433487140.61.0.895318225062.issue24371@psf.upfronthosting.co.za> Yavuz Selim Komur added the comment: I'm sorry, my fault. bond1.999 vs bond1.199 my mistake.. I'm in a big shame :( [remember] # Her bir interface icin Beni hatirla uygulamasi etkinlestirme # default: False bond1.999 = True bond1.778 = False [timeout] # Saniye cinsinden inactive session bulma suresi # her bir interface icin ayri ayri yazilacak. # default: -1 bond1.199 = 120 bond1.778 = -1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 09:00:27 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 05 Jun 2015 07:00:27 +0000 Subject: [issue24371] configparser hate dot in option like eth2.6 In-Reply-To: <1433316868.88.0.0222677980936.issue24371@psf.upfronthosting.co.za> Message-ID: <1433487627.6.0.445442269361.issue24371@psf.upfronthosting.co.za> Zachary Ware added the comment: Ahhh, bitten by a typo? :) ---------- components: -Extension Modules resolution: -> not a bug stage: -> resolved status: open -> closed type: enhancement -> behavior versions: +Python 3.3, Python 3.4 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 09:28:50 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 05 Jun 2015 07:28:50 +0000 Subject: [issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening) In-Reply-To: <1421201583.23.0.507661432161.issue23237@psf.upfronthosting.co.za> Message-ID: <1433489330.03.0.684084520293.issue23237@psf.upfronthosting.co.za> Martin Panter added the comment: My previous comments were about trying to maintain backwards compatibility. E.g. with the current patches, an old PyOS_InputHook() that happened to always return a negative value would mean the input never gets checked by the new Python code. I dunno what the policy on changing the C API though. Perhaps people are happy changing this in 3.6. Also, the signal handling isn?t perfect in tkinter (e.g. it doesn?t account for non-SIGINT handlers), but perhaps practicality and simplicity beat purity here and we can say it is good enough :) I am posting hook-interrupt.3.6.patch, which combines the readline and tkinter patches and fixes them up for Python 3. Also added some notes to the PyOS_InputHook documentation. ---------- versions: +Python 3.6 -Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39630/hook-interrupt.3.6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 10:22:03 2015 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 05 Jun 2015 08:22:03 +0000 Subject: [issue23642] Interaction of ModuleSpec and C Extension Modules In-Reply-To: <1426086531.98.0.531682777516.issue23642@psf.upfronthosting.co.za> Message-ID: <1433492523.43.0.0691372210728.issue23642@psf.upfronthosting.co.za> Petr Viktorin added the comment: Since PEP 489 (Python 3.5.0b1), loaders now support create_module/exec_module. For modules which don't use the PEP's new multi-phase init mechanism (which is most of them, currently), load_module() does all the work and exec_module is a no-op. So, this issue can be closed. Python 3.5.0b2+ (default, Jun 2 2015, 20:48:59) [GCC 4.9.2 20150212 (Red Hat 4.9.2-6)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from importlib.util import find_spec, module_from_spec >>> spec = find_spec('math') >>> spec ModuleSpec(name='math', loader=<_frozen_importlib_external.ExtensionFileLoader object at 0x7f7d67b51588>, origin='/home/petr/dev/cpython/__installed__/lib/python3.5/lib-dynload/math.cpython-35m-x86_64-linux-gnu.so') >>> math = module_from_spec(spec) >>> math >>> dir(math) ['__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', 'acos', 'acosh', 'asin', 'asinh', 'atan', 'atan2', 'atanh', 'ceil', 'copysign', 'cos', 'cosh', 'degrees', 'e', 'erf', 'erfc', 'exp', 'expm1', 'fabs', 'factorial', 'floor', 'fmod', 'frexp', 'fsum', 'gamma', 'gcd', 'hypot', 'inf', 'isclose', 'isfinite', 'isinf', 'isnan', 'ldexp', 'lgamma', 'log', 'log10', 'log1p', 'log2', 'modf', 'nan', 'pi', 'pow', 'radians', 'sin', 'sinh', 'sqrt', 'tan', 'tanh', 'trunc'] >>> spec.loader.exec_module(math) >>> spec.loader.load_module(spec.name) >>> dir(math) ['__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', 'acos', 'acosh', 'asin', 'asinh', 'atan', 'atan2', 'atanh', 'ceil', 'copysign', 'cos', 'cosh', 'degrees', 'e', 'erf', 'erfc', 'exp', 'expm1', 'fabs', 'factorial', 'floor', 'fmod', 'frexp', 'fsum', 'gamma', 'gcd', 'hypot', 'inf', 'isclose', 'isfinite', 'isinf', 'isnan', 'ldexp', 'lgamma', 'log', 'log10', 'log1p', 'log2', 'modf', 'nan', 'pi', 'pow', 'radians', 'sin', 'sinh', 'sqrt', 'tan', 'tanh', 'trunc'] The "array" module implements multi-phase init, so create_module/exec_module work more like with Python modules: >>> spec = find_spec('array') >>> spec ModuleSpec(name='array', loader=<_frozen_importlib_external.ExtensionFileLoader object at 0x7f7d67b51f60>, origin='/home/petr/dev/cpython/__installed__/lib/python3.5/lib-dynload/array.cpython-35m-x86_64-linux-gnu.so') >>> array = module_from_spec(spec) >>> array >>> dir(array) ['__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', '_array_reconstructor'] >>> spec.loader.exec_module(array) >>> dir(array) ['ArrayType', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', '_array_reconstructor', 'array', 'typecodes'] (Module methods [like _array_reconstructor here] and __doc__ are initialized in load_module -- an implementation detail related to reusing the existing C structure for defining extension modules.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 10:36:28 2015 From: report at bugs.python.org (John Helour) Date: Fri, 05 Jun 2015 08:36:28 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1433493388.87.0.636186521482.issue24339@psf.upfronthosting.co.za> Changes by John Helour : Added file: http://bugs.python.org/file39631/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 10:44:16 2015 From: report at bugs.python.org (John Helour) Date: Fri, 05 Jun 2015 08:44:16 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1433493856.11.0.802157972606.issue24339@psf.upfronthosting.co.za> Changes by John Helour : Added file: http://bugs.python.org/file39632/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 10:44:33 2015 From: report at bugs.python.org (John Helour) Date: Fri, 05 Jun 2015 08:44:33 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1433493873.57.0.00240620617866.issue24339@psf.upfronthosting.co.za> Changes by John Helour : Removed file: http://bugs.python.org/file39631/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 10:45:49 2015 From: report at bugs.python.org (John Helour) Date: Fri, 05 Jun 2015 08:45:49 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1433493949.19.0.944161159134.issue24339@psf.upfronthosting.co.za> Changes by John Helour : Removed file: http://bugs.python.org/file39583/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 13:22:07 2015 From: report at bugs.python.org (Cyd Haselton) Date: Fri, 05 Jun 2015 11:22:07 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1433454778.17.0.211108403494.issue23496@psf.upfronthosting.co.za> Message-ID: Cyd Haselton added the comment: Will do...if by "try the tests now" you mean "run 'make tests'"...but it may be about a week or two as a) I'm currently in the last stages of a mono port and b) will be working on a PIE gcc for android 5.0 after, so that I have a KBOX environment to work with after verizon updates my tablet. If I can keep putting off the verizon 5.0 update On June 4, 2015 4:52:59 PM CDT, Ryan Gonzalez wrote: > >Ryan Gonzalez added the comment: > >#1 and #2 are fixed. I hand-edited the patch file (!!), so here's to >hoping it'll work... > >Working on #3. You probably should try the tests now (which is >obviously the scary part ;). > >---------- >Added file: http://bugs.python.org/file39628/kbox_fix.patch > >_______________________________________ >Python tracker > >_______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 13:48:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Jun 2015 11:48:59 +0000 Subject: [issue24148] 'cum' not a valid sort key for pstats.Stats.sort_stats In-Reply-To: <1431184757.15.0.93515789631.issue24148@psf.upfronthosting.co.za> Message-ID: <20150605114855.25588.81255@psf.io> Roundup Robot added the comment: New changeset bfc043eab54e by Berker Peksag in branch '3.4': Issue #24148: Fix incorrect Stats.sort_stats() example. https://hg.python.org/cpython/rev/bfc043eab54e New changeset ffb7019d70cf by Berker Peksag in branch '3.5': Issue #24148: Fix incorrect Stats.sort_stats() example. https://hg.python.org/cpython/rev/ffb7019d70cf New changeset 123419b216e0 by Berker Peksag in branch 'default': Issue #24148: Fix incorrect Stats.sort_stats() example. https://hg.python.org/cpython/rev/123419b216e0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 13:50:49 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 05 Jun 2015 11:50:49 +0000 Subject: [issue24148] 'cum' not a valid sort key for pstats.Stats.sort_stats In-Reply-To: <1431184757.15.0.93515789631.issue24148@psf.upfronthosting.co.za> Message-ID: <1433505049.26.0.0140648831078.issue24148@psf.upfronthosting.co.za> Berker Peksag added the comment: Fixed! Thanks for the report, ramiro and thanks for the patch, Brandon. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 14:18:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Jun 2015 12:18:14 +0000 Subject: [issue23659] csv.register_dialect doc string In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za> Message-ID: <20150605121811.11547.15627@psf.io> Roundup Robot added the comment: New changeset 9377ffb9eaf2 by Berker Peksag in branch '3.4': Issue #23659: Document **fmtparams in csv.register_dialect docstring. https://hg.python.org/cpython/rev/9377ffb9eaf2 New changeset eee64e72d294 by Berker Peksag in branch '3.5': Issue #23659: Document **fmtparams in csv.register_dialect docstring. https://hg.python.org/cpython/rev/eee64e72d294 New changeset a3fbf1fe8fa6 by Berker Peksag in branch 'default': Issue #23659: Document **fmtparams in csv.register_dialect docstring. https://hg.python.org/cpython/rev/a3fbf1fe8fa6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 14:19:52 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 05 Jun 2015 12:19:52 +0000 Subject: [issue23659] csv.register_dialect doc string In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za> Message-ID: <1433506792.09.0.409245487743.issue23659@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 14:21:48 2015 From: report at bugs.python.org (CT Radu) Date: Fri, 05 Jun 2015 12:21:48 +0000 Subject: [issue24387] json.loads should be idempotent when the argument is a dictionary Message-ID: <1433506908.4.0.832946693119.issue24387@psf.upfronthosting.co.za> New submission from CT Radu: Currently, json.loads expects a string as input and is expected to return a dictionary or raise an exception. Proposal: If the first argument of json.loads is a dictionary return that dictionary, instead of raising a TypeError as it happens now. There are some use cases where json.loads would be applied multiple times to the same object. Once the string has been parsed once, it shouldn't be reloaded. ---------- components: Library (Lib) messages: 244864 nosy: CT Radu priority: normal severity: normal status: open title: json.loads should be idempotent when the argument is a dictionary type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 14:28:35 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 05 Jun 2015 12:28:35 +0000 Subject: [issue24387] json.loads should be idempotent when the argument is a dictionary In-Reply-To: <1433506908.4.0.832946693119.issue24387@psf.upfronthosting.co.za> Message-ID: <1433507315.52.0.312499669982.issue24387@psf.upfronthosting.co.za> Eric V. Smith added the comment: What are the use cases where json.loads would be called on the return from json.loads? It seems to me a better design would be to wrap such calls with a test, instead of having json.loads do this test. Hiding it in json.loads would mask other programming errors, for instance if you pass an unrelated dict to json.loads. ---------- nosy: +eric.smith versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 14:33:54 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 05 Jun 2015 12:33:54 +0000 Subject: [issue21297] csv.skipinitialspace only skips spaces, not "whitespace" in general In-Reply-To: <1397821941.61.0.706896478348.issue21297@psf.upfronthosting.co.za> Message-ID: <1433507634.38.0.469940809132.issue21297@psf.upfronthosting.co.za> Berker Peksag added the comment: The patch looks good to me, thanks! Could you also convert your test script to a test case and add it in Lib/test/test_csv.py? ---------- nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 15:23:30 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 05 Jun 2015 13:23:30 +0000 Subject: [issue24387] json.loads should be idempotent when the argument is a dictionary In-Reply-To: <1433506908.4.0.832946693119.issue24387@psf.upfronthosting.co.za> Message-ID: <1433510610.71.0.631858249752.issue24387@psf.upfronthosting.co.za> R. David Murray added the comment: Agreed that this is not a good API change. If this makes sense for a particular program it is easy to write a wrapper, while the current behavior is much more useful for typical programs. loads is not a "coercion" style call, it is specifically parsing a string, and should fail if passed something it can't parse as a string. Another argument along these lines is that if you call int() on something, you know you get back an int. If you call json.loads and it returns a dictionary unmodified, you do *not* know if you have something that is valid json data or not (that is, it might contain un-jsonifiable objects). ---------- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 16:57:38 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Fri, 05 Jun 2015 14:57:38 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: Message-ID: <27817CCE-1C64-4703-B61F-F47C4C78CA8A@gmail.com> Ryan Gonzalez added the comment: On June 5, 2015 6:22:07 AM CDT, Cyd Haselton wrote: > >Cyd Haselton added the comment: > >Will do...if by "try the tests now" you mean "run 'make tests'" Pretty much. >...but it may be about a week or two as a) I'm currently in the last stages of >a mono port and b) will be working on a PIE gcc for android 5.0 after, >so that I have a KBOX environment to work with after verizon updates my >tablet. Try CCTools. Works on Android 5.0. Clang can be a little broken, but with a bit of flag twiddling it works. > >If I can keep putting off the verizon 5.0 update > >On June 4, 2015 4:52:59 PM CDT, Ryan Gonzalez >wrote: >> >>Ryan Gonzalez added the comment: >> >>#1 and #2 are fixed. I hand-edited the patch file (!!), so here's to >>hoping it'll work... >> >>Working on #3. You probably should try the tests now (which is >>obviously the scary part ;). >> >>---------- >>Added file: http://bugs.python.org/file39628/kbox_fix.patch >> >>_______________________________________ >>Python tracker >> >>_______________________________________ > >---------- > >_______________________________________ >Python tracker > >_______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 17:08:48 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 05 Jun 2015 15:08:48 +0000 Subject: [issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za> Message-ID: <1433516928.58.0.889120708273.issue24079@psf.upfronthosting.co.za> Stefan Behnel added the comment: Looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 17:30:57 2015 From: report at bugs.python.org (Michiel de Hoon) Date: Fri, 05 Jun 2015 15:30:57 +0000 Subject: [issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening) In-Reply-To: <1421201583.23.0.507661432161.issue23237@psf.upfronthosting.co.za> Message-ID: <1433518257.09.0.0600475511916.issue23237@psf.upfronthosting.co.za> Michiel de Hoon added the comment: I tried the patch hook-interrupt.3.6.patch ; as far as I can tell it is working fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 18:46:00 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 05 Jun 2015 16:46:00 +0000 Subject: [issue24351] string.Template documentation incorrectly references "identifiers" In-Reply-To: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za> Message-ID: <1433522760.43.0.299431720786.issue24351@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Rather than change the code, which strives to keep the "Simple" in PEP 292's title, I'd rather just update the documentation to define what "identifier" means here. E.g. " * ``$identifier`` names a substitution placeholder matching a mapping key of ``"identifier"``. By default, ``"identifier"`` is restricted to any case-insensitive ASCII alphanumeric string (including underscores) that starts with an underscore or ASCII letter. The first non-identifier character after the ``$`` character terminates this placeholder specification. " ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 19:37:29 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 05 Jun 2015 17:37:29 +0000 Subject: [issue24330] Idle doc: explain "Configure Idle" not in "Options" on OSX, etc. In-Reply-To: <1432962360.31.0.591497904103.issue24330@psf.upfronthosting.co.za> Message-ID: <1433525849.17.0.986045296134.issue24330@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python title: "Configure Idle" not in "Options" -> Idle doc: explain "Configure Idle" not in "Options" on OSX, etc. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 19:39:09 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 05 Jun 2015 17:39:09 +0000 Subject: [issue24330] Idle doc: explain "Configure Idle" not in "Options" on OSX, etc. In-Reply-To: <1432962360.31.0.591497904103.issue24330@psf.upfronthosting.co.za> Message-ID: <1433525949.56.0.790137849027.issue24330@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: docs at python -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 20:09:23 2015 From: report at bugs.python.org (John Helour) Date: Fri, 05 Jun 2015 18:09:23 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1433527763.31.0.711639222397.issue24339@psf.upfronthosting.co.za> Changes by John Helour : Removed file: http://bugs.python.org/file39632/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 20:10:54 2015 From: report at bugs.python.org (John Helour) Date: Fri, 05 Jun 2015 18:10:54 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1433527854.61.0.816887427113.issue24339@psf.upfronthosting.co.za> Changes by John Helour : Added file: http://bugs.python.org/file39633/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 21:20:56 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 05 Jun 2015 19:20:56 +0000 Subject: [issue23653] Make inspect._empty test to False In-Reply-To: <1426195909.5.0.733462239813.issue23653@psf.upfronthosting.co.za> Message-ID: <1433532056.19.0.589560956529.issue23653@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nathan, consider the following signature: def foo(a=0:''): pass now, sig.parameters['a'].annotation will be '' and .default will be 0, and they will fail 'if param.annotation or param.default' check. That's why we encourage checks like 'if param.annotation is not param.empty'. Closing this issue. ---------- assignee: -> yselivanov nosy: +yselivanov resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 21:26:47 2015 From: report at bugs.python.org (Nathan West) Date: Fri, 05 Jun 2015 19:26:47 +0000 Subject: [issue23653] Make inspect._empty test to False In-Reply-To: <1433532056.19.0.589560956529.issue23653@psf.upfronthosting.co.za> Message-ID: Nathan West added the comment: Doesn't the same issue exist for all other uses of the idiom, though? Python provides container "truthiness" even though `len(x) == 0` is more "correct." On Fri, Jun 5, 2015, 3:20 PM Yury Selivanov wrote: > > Yury Selivanov added the comment: > > Nathan, consider the following signature: > > def foo(a=0:''): pass > > now, sig.parameters['a'].annotation will be '' and .default will be 0, and > they will fail 'if param.annotation or param.default' check. That's why we > encourage checks like 'if param.annotation is not param.empty'. > > Closing this issue. > > ---------- > assignee: -> yselivanov > nosy: +yselivanov > resolution: -> rejected > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 21:30:17 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 05 Jun 2015 19:30:17 +0000 Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.5 or ??? In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za> Message-ID: <1433532617.5.0.351159625639.issue13248@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 21:35:05 2015 From: report at bugs.python.org (Jan Harkes) Date: Fri, 05 Jun 2015 19:35:05 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433532905.12.0.617971511554.issue24385@psf.upfronthosting.co.za> Jan Harkes added the comment: The Python-2.7.9 version of the Windows-x86 MSI installed version works fine with the 32-bit mingw. In fact I rolled back to that release and built my code successfully. Somehow the fix for https://bugs.python.org/issue23199 must have broken the 32-bit libpython27.a. In fact, just tried running the commands in the comments to that previous bug report by hand which produces a similarly broken 32-bit libpython27.a. x86_64-w64-mingw32-dlltool --dllname python27.dll --def mingwlib.def --output-lib win32\libpython27.a -m i386 This creates an archive with two 64-bit object files. However the following builds a correct import library with all 32-bit objects. i686-w64-mingw32-dlltool --dllname python27.dll --def mingwlib.def --output-lib win32\libpython27.a -m i386 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 21:40:35 2015 From: report at bugs.python.org (Jan Harkes) Date: Fri, 05 Jun 2015 19:40:35 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433533235.72.0.758355392315.issue24385@psf.upfronthosting.co.za> Jan Harkes added the comment: Just noticed in Matthew Barnett's comment that he has an additional "--as-flags=--32" argument. x86_64-w64-mingw32-dlltool --as-flags=--32 --dllname python27.dll --def mingwlib.def --output-lib win32\libpython27.a -m i386 Creates a correct libpython27.a where every object is 32-bit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 5 22:19:39 2015 From: report at bugs.python.org (Ulrich Petri) Date: Fri, 05 Jun 2015 20:19:39 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1433535579.36.0.292259188754.issue24120@psf.upfronthosting.co.za> Ulrich Petri added the comment: The attached patch adds an unaccessible directory to the pathlib tests to provoke the problem and also fixes the cause in pathlib. It applies to at least 3.4 - 3.6 ---------- keywords: +patch nosy: +ulope Added file: http://bugs.python.org/file39634/issue24120.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 01:10:29 2015 From: report at bugs.python.org (Ed Maste) Date: Fri, 05 Jun 2015 23:10:29 +0000 Subject: [issue24388] Python readline module crashes in history_get on FreeBSD with libedit Message-ID: <1433545828.57.0.0902862993292.issue24388@psf.upfronthosting.co.za> New submission from Ed Maste: I encountered a segfault in Python's call_readline from LLDB on FreeBSD, with libedit. There is a fix for this issue already in readline.c, but under #ifdef __APPLE__ Backtrace: (lldb) target create "/data/emaste/src/llvm/build/bin/lldb" --core "lldb-3.7.0.core" Core file '/tank/emaste/projects/lldb-talk/demo/lldb-3.7.0.core' (x86_64) was loaded. (lldb) bt * thread #1: tid = 0, 0x0000000809706dcd readline.so`call_readline(sys_stdin=0x00000008055d9d10, sys_stdout=0x00000008055d9e40, prompt=0x0000000806eb7854) + 397 at readline.c:1132, name = 'lldb-3.7.0', stop reason = signal SIGSEGV * frame #0: 0x0000000809706dcd readline.so`call_readline(sys_stdin=0x00000008055d9d10, sys_stdout=0x00000008055d9e40, prompt=0x0000000806eb7854) + 397 at readline.c:1132 frame #1: 0x0000000805c48f1f libpython2.7.so.1`PyOS_Readline(sys_stdin=0x00000008055d9d10, sys_stdout=0x00000008055d9e40, prompt=0x0000000806eb7854) + 383 at myreadline.c:207 frame #2: 0x0000000805d7f94f libpython2.7.so.1`builtin_raw_input(self=0x0000000000000000, args=0x000000080bec1df0) + 639 at bltinmodule.c:2060 frame #3: 0x0000000805cce5c6 libpython2.7.so.1`PyCFunction_Call(func=0x00000008007b78d0, arg=0x000000080bec1df0, kw=0x0000000000000000) + 166 at methodobject.c:81 frame #4: 0x0000000805d992aa libpython2.7.so.1`call_function(pp_stack=0x00007fffffffbcd0, oparg=1) + 1754 at ceval.c:4033 frame #5: 0x0000000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x0000000806ecfdf0, throwflag=0) + 51160 at ceval.c:2679 frame #6: 0x0000000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x0000000805a6af60, globals=0x0000000806f9a580, locals=0x0000000000000000, args=0x000000080a06c670, argcount=2, kws=0x000000080a06c680, kwcount=0, defs=0x0000000805aaeda8, defcount=1, closure=0x0000000000000000) + 5284 at ceval.c:3265 frame #7: 0x0000000805d9c2b6 libpython2.7.so.1`fast_function(func=0x0000000806f7da38, pp_stack=0x00007fffffffc520, n=2, na=2, nk=0) + 822 at ceval.c:4129 frame #8: 0x0000000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x00007fffffffc520, oparg=1) + 2296 at ceval.c:4054 frame #9: 0x0000000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x000000080a06c4b0, throwflag=0) + 51160 at ceval.c:2679 frame #10: 0x0000000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x0000000805a5ebf0, globals=0x0000000806f9a580, locals=0x0000000000000000, args=0x000000080a06c3e0, argcount=2, kws=0x000000080a06c3f0, kwcount=0, defs=0x0000000805aaecc8, defcount=1, closure=0x0000000000000000) + 5284 at ceval.c:3265 frame #11: 0x0000000805d9c2b6 libpython2.7.so.1`fast_function(func=0x0000000806f7d8e8, pp_stack=0x00007fffffffcd70, n=2, na=2, nk=0) + 822 at ceval.c:4129 frame #12: 0x0000000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x00007fffffffcd70, oparg=1) + 2296 at ceval.c:4054 frame #13: 0x0000000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x000000080a06c230, throwflag=0) + 51160 at ceval.c:2679 frame #14: 0x0000000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x0000000805a869e0, globals=0x0000000806f9a580, locals=0x0000000000000000, args=0x000000080a06b9f8, argcount=0, kws=0x000000080a06b9f8, kwcount=2, defs=0x00000008009af688, defcount=3, closure=0x0000000000000000) + 5284 at ceval.c:3265 frame #15: 0x0000000805d9c2b6 libpython2.7.so.1`fast_function(func=0x0000000806f7d300, pp_stack=0x00007fffffffd5c0, n=4, na=0, nk=2) + 822 at ceval.c:4129 frame #16: 0x0000000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x00007fffffffd5c0, oparg=512) + 2296 at ceval.c:4054 frame #17: 0x0000000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x000000080a06b830, throwflag=0) + 51160 at ceval.c:2679 frame #18: 0x0000000805d9c16a libpython2.7.so.1`fast_function(func=0x0000000806f9d300, pp_stack=0x00007fffffffdbd0, n=1, na=1, nk=0) + 490 at ceval.c:4119 frame #19: 0x0000000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x00007fffffffdbd0, oparg=1) + 2296 at ceval.c:4054 frame #20: 0x0000000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x000000080098c9c0, throwflag=0) + 51160 at ceval.c:2679 frame #21: 0x0000000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x00000008008ffa90, globals=0x00000008007d8580, locals=0x00000008007d8580, args=0x0000000000000000, argcount=0, kws=0x0000000000000000, kwcount=0, defs=0x0000000000000000, defcount=0, closure=0x0000000000000000) + 5284 at ceval.c:3265 frame #22: 0x0000000805d857a5 libpython2.7.so.1`PyEval_EvalCode(co=0x00000008008ffa90, globals=0x00000008007d8580, locals=0x00000008007d8580) + 85 at ceval.c:667 frame #23: 0x0000000805dd4a15 libpython2.7.so.1`run_mod(mod=0x000000080a14f128, filename=0x0000000805e22022, globals=0x00000008007d8580, locals=0x00000008007d8580, flags=0x0000000000000000, arena=0x000000080a027800) + 101 at pythonrun.c:1371 frame #24: 0x0000000805dd50a4 libpython2.7.so.1`PyRun_StringFlags(str=0x000000080a0ff820, start=257, globals=0x00000008007d8580, locals=0x00000008007d8580, flags=0x0000000000000000) + 148 at pythonrun.c:1334 frame #25: 0x0000000805dd4f54 libpython2.7.so.1`PyRun_SimpleStringFlags(command=0x000000080a0ff820, flags=0x0000000000000000) + 100 at pythonrun.c:975 frame #26: 0x0000000802085fa4 liblldb.so.3.7`IOHandlerPythonInterpreter::Run() + 324 frame #27: 0x0000000801f78c12 liblldb.so.3.7`lldb_private::Debugger::ExecuteIOHandlers() + 162 frame #28: 0x000000080206635e liblldb.so.3.7`lldb_private::CommandInterpreter::RunCommandInterpreter(bool, bool, lldb_private::CommandInterpreterRunOptions&) + 126 frame #29: 0x00000008012bc79f liblldb.so.3.7`lldb::SBDebugger::RunCommandInterpreter(bool, bool) + 63 frame #30: 0x0000000000406546 lldb`Driver::MainLoop() + 2454 frame #31: 0x0000000000406a17 lldb`main + 439 frame #32: 0x000000000040362f lldb`_start + 367 frame #0: 0x0000000809706dcd readline.so`call_readline(sys_stdin=0x00000008055d9d10, sys_stdout=0x00000008055d9e40, prompt=0x0000000806eb7854) + 397 at readline.c:1132 1129 line = history_get(length + libedit_history_start - 1)->line; 1130 } else 1131 #endif /* __APPLE__ */ -> 1132 line = history_get(length)->line; 1133 else 1134 line = ""; 1135 if (strcmp(p, line)) It looks like a straightforward s/#ifdef __APPLE__/#if defined(__APPLE__) || defined(__FreeBSD__)/ fixes the issue (as in the attached proof of concept patch). ---------- components: Extension Modules files: readline.diff keywords: patch messages: 244877 nosy: emaste priority: normal severity: normal status: open title: Python readline module crashes in history_get on FreeBSD with libedit versions: Python 2.7 Added file: http://bugs.python.org/file39635/readline.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 01:22:10 2015 From: report at bugs.python.org (Ed Maste) Date: Fri, 05 Jun 2015 23:22:10 +0000 Subject: [issue24388] Python readline module crashes in history_get on FreeBSD with libedit In-Reply-To: <1433545828.57.0.0902862993292.issue24388@psf.upfronthosting.co.za> Message-ID: <1433546530.1.0.444974772985.issue24388@psf.upfronthosting.co.za> Ed Maste added the comment: Presumably the #ifdefs ought to just be deleted though, relying on the runtime detection of libedit compatibility issues on any platform. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 03:38:07 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 06 Jun 2015 01:38:07 +0000 Subject: [issue24388] Python readline module crashes in history_get on FreeBSD with libedit In-Reply-To: <1433545828.57.0.0902862993292.issue24388@psf.upfronthosting.co.za> Message-ID: <1433554687.58.0.999977124032.issue24388@psf.upfronthosting.co.za> Martin Panter added the comment: See also Issue 13501 for a more platform-independent approach. I think this crash is actually due to a bug in Editline (later fixed; see Issue 18458), but since Python already has the workaround, it makes sense to use the workaround if necessary for Free BSD, or maybe even in general. ---------- nosy: +vadmium type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 03:46:49 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 06 Jun 2015 01:46:49 +0000 Subject: [issue10666] OS X installer variants have confusing readline differences In-Reply-To: <1291931066.91.0.86480513545.issue10666@psf.upfronthosting.co.za> Message-ID: <1433555209.59.0.359359083036.issue10666@psf.upfronthosting.co.za> Ned Deily added the comment: As of Python 3.3.0 and 2.7.9, the 32-bit-only OS X installers on python.org now have a minimum deployment target of 10.5, rather than 10.3. This means that all current OS X installers on python.org are now dynamically linked with the Apple-provided system editline (libedit) libraries. Users who prefer or need to use the GPL-licensed GNU readline libraries can pip install the third-party gnureadline from PyPI (https://pypi.python.org/pypi/gnureadline). ---------- resolution: -> out of date stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 03:57:22 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 06 Jun 2015 01:57:22 +0000 Subject: [issue24388] Python readline module crashes in history_get on FreeBSD with libedit In-Reply-To: <1433545828.57.0.0902862993292.issue24388@psf.upfronthosting.co.za> Message-ID: <1433555842.85.0.44357508401.issue24388@psf.upfronthosting.co.za> Ned Deily added the comment: The change in spec in editline was to better match GNU readline behavior. Unfortunately, we depended on the old behavior. Technically, we don't support editline out-of-the-box other than on OS X; as Martin notes, generalizing that support is what Issue13501 is about. I'm going to close this as a duplicate of it. ---------- nosy: +ned.deily resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Make libedit support more generic; port readline / libedit to FreeBSD _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 03:58:45 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 06 Jun 2015 01:58:45 +0000 Subject: [issue13501] Make libedit support more generic; port readline / libedit to FreeBSD In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za> Message-ID: <1433555925.93.0.779838389432.issue13501@psf.upfronthosting.co.za> Ned Deily added the comment: See also suggested patch in Issue24388. ---------- nosy: +emaste stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 04:02:12 2015 From: report at bugs.python.org (Ed Maste) Date: Sat, 06 Jun 2015 02:02:12 +0000 Subject: [issue13501] Make libedit support more generic; port readline / libedit to FreeBSD In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za> Message-ID: <1433556132.12.0.929348059385.issue13501@psf.upfronthosting.co.za> Ed Maste added the comment: This issue causes the LLDB debugger to crash on FreeBSD (it uses Python as its embedded script interpreter). What needs to be done to make some progress on this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 04:07:48 2015 From: report at bugs.python.org (Harvesting Ore) Date: Sat, 06 Jun 2015 02:07:48 +0000 Subject: [issue24389] idle launches in cmd but not from any other method. Message-ID: <1433556468.4.0.207321673571.issue24389@psf.upfronthosting.co.za> New submission from Harvesting Ore: so i've seen dozens of fixes for this, but none of them worked for me. i went to cmd prompt put in the directory c:python31\lib\idlelib\idle.py which launched the program but gave me the following errors... Warning: os.path.expanduser("~") points to %USERPROFILE%, but the path does not exist. Warning: os.path.expanduser("~") points to %USERPROFILE%, but the path does not exist. Warning: os.path.expanduser("~") points to %USERPROFILE%, but the path does not exist. please note that idle for 3.1.1 works when launched from cmd prompt but not via the shortcuts or from the menu. i've made double sure that 'run as administrator' is checked in properties and compatability is set for xp sp 1. i have made absolutely no changes to my system aside from the typical windows updates rubbish. ---------- components: IDLE messages: 244884 nosy: Harvesting Ore priority: normal severity: normal status: open title: idle launches in cmd but not from any other method. type: crash versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 04:07:53 2015 From: report at bugs.python.org (Ed Maste) Date: Sat, 06 Jun 2015 02:07:53 +0000 Subject: [issue13501] Make libedit support more generic; port readline / libedit to FreeBSD In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za> Message-ID: <1433556473.48.0.093130879716.issue13501@psf.upfronthosting.co.za> Ed Maste added the comment: Note that the patch in Issue24388 is more a proof of concept. I'm not sure it's the "right" fix. LLDB is a bit of a special case: LLDB links against libedit, but the Python libedit module is built as if readline is in use. It turns out this "magically" works out, presumably due to the runtime workaround detection. As far as I know this issue would affect Linux as well, but perhaps the version of libedit on common Linux distributions is one with the 0-based vs 1-based history fix? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 04:18:04 2015 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 06 Jun 2015 02:18:04 +0000 Subject: [issue24389] idle launches in cmd but not from any other method. In-Reply-To: <1433556468.4.0.207321673571.issue24389@psf.upfronthosting.co.za> Message-ID: <1433557084.73.0.890537090522.issue24389@psf.upfronthosting.co.za> Ezio Melotti added the comment: Could you try with the latest version of Python (Python 3.4)? ---------- components: +Windows nosy: +ezio.melotti, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 04:24:45 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 06 Jun 2015 02:24:45 +0000 Subject: [issue13501] Make libedit support more generic; port readline / libedit to FreeBSD In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za> Message-ID: <1433557485.07.0.601073330551.issue13501@psf.upfronthosting.co.za> Ned Deily added the comment: The suggested change to generalize support for libedit to other platforms is a new feature so, by default, it would first appear in a new feature release, e.g. 3.6. There would probably have to be an exception granted to add it to 2.7.x or other 3.x releases, which are in maintenance mode. I think the quickest workarounds are to either link Python with GNU readline or, if that is not acceptable, persuade FreeBSD to carry a patch similar to the one you suggested for their current versions of Python. WRT Linux, it looks like Debian has both a libeditline0 package (presumably the old ABI) and a libedit2 package and their lldb package is linked with the latter. (The Debian Pythons are always linked with GNU readline.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 04:29:35 2015 From: report at bugs.python.org (Harvesting Ore) Date: Sat, 06 Jun 2015 02:29:35 +0000 Subject: [issue24389] idle launches in cmd but not from any other method. In-Reply-To: <1433556468.4.0.207321673571.issue24389@psf.upfronthosting.co.za> Message-ID: <1433557775.73.0.352068544313.issue24389@psf.upfronthosting.co.za> Harvesting Ore added the comment: sure, i'll give it a shot.. but while i'm doing that i managed to get further errors when trying to launch the shell and editor Warning: os.path.expanduser("~") points to %USERPROFILE%, but the path does not exist. Warning: os.path.expanduser("~") points to %USERPROFILE%, but the path does not exist. Failed to import extension: AutoComplete Failed to load extension 'AutoComplete' Traceback (most recent call last): File "C:\Python31\lib\idlelib\EditorWindow.py", line 922, in load_standard_ext ensions self.load_extension(name) File "C:\Python31\lib\idlelib\EditorWindow.py", line 932, in load_extension mod = __import__(name, globals(), locals(), []) File "C:\Python31\Lib\idlelib\AutoComplete.py", line 21, in from idlelib import AutoCompleteWindow File "C:\Python31\lib\idlelib\AutoCompleteWindow.py", line 6, in from idlelib.AutoComplete import COMPLETE_FILES, COMPLETE_ATTRIBUTES File "C:\Python31\lib\idlelib\AutoComplete.py", line 21, in from idlelib import AutoCompleteWindow ImportError: cannot import name AutoCompleteWindow Exception in Tkinter callback Traceback (most recent call last): File "C:\Python31\lib\tkinter\__init__.py", line 1399, in __call__ return self.func(*args) File "C:\Python31\Lib\idlelib\ScriptBinding.py", line 130, in run_module_event code = self.checksyntax(filename) File "C:\Python31\Lib\idlelib\ScriptBinding.py", line 88, in checksyntax self.shell = shell = self.flist.open_shell() AttributeError: 'NoneType' object has no attribute 'open_shell' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 04:33:26 2015 From: report at bugs.python.org (Harvesting Ore) Date: Sat, 06 Jun 2015 02:33:26 +0000 Subject: [issue24389] idle launches in cmd but not from any other method. In-Reply-To: <1433556468.4.0.207321673571.issue24389@psf.upfronthosting.co.za> Message-ID: <1433558006.95.0.343533059347.issue24389@psf.upfronthosting.co.za> Harvesting Ore added the comment: 2.5.4 works normally as does 3.4.3 as well. problem still exists with 3.1.1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 04:48:16 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 06 Jun 2015 02:48:16 +0000 Subject: [issue24389] idle launches in cmd but not from any other method. In-Reply-To: <1433556468.4.0.207321673571.issue24389@psf.upfronthosting.co.za> Message-ID: <1433558896.25.0.0675203444414.issue24389@psf.upfronthosting.co.za> Zachary Ware added the comment: Python 3.1 is so old at this point that you're pretty much on your own.? If you for some reason have to use 3.1, you can go fishing on python-list for assistance in getting it working. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 05:27:23 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 06 Jun 2015 03:27:23 +0000 Subject: [issue5319] stdout error at interpreter shutdown fails to return OS error status In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za> Message-ID: <1433561243.41.0.832625167532.issue5319@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch adding a new Py_FinalizeEx() API. Please let me know if anything else needs to be added. Perhaps some sort of Py_LIMITED_API condition, adding to PC/python3.def, etc. I am not really familiar with these things. I also changed the version notices to 3.6, assuming it is too late for 3.5. ---------- versions: -Python 3.5 Added file: http://bugs.python.org/file39636/Py_FinalizeEx.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 07:05:08 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 06 Jun 2015 05:05:08 +0000 Subject: [issue18885] handle EINTR in the stdlib In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za> Message-ID: <1433567108.84.0.27049562079.issue18885@psf.upfronthosting.co.za> Martin Panter added the comment: With PEP 475 now implemented (see Issue 23648), perhaps this could be closed? Or is there something else to be done? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 07:21:35 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 06 Jun 2015 05:21:35 +0000 Subject: [issue14287] sys.stdin.readline and KeyboardInterrupt on windows In-Reply-To: <1331647625.41.0.2361094593.issue14287@psf.upfronthosting.co.za> Message-ID: <1433568095.67.0.875198514561.issue14287@psf.upfronthosting.co.za> Martin Panter added the comment: If the interrupt truly occurred after readline() succeeded, then x should contain actual input from the user, not the empty string. So I think this is a valid bug. However it looks like this is the same as Issue 18597, which has more discussion. ---------- nosy: +vadmium resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> On Windows sys.stdin.readline() doesn't handle Ctrl-C properly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 11:20:26 2015 From: report at bugs.python.org (Ivan Bykov) Date: Sat, 06 Jun 2015 09:20:26 +0000 Subject: [issue24390] Python 3.4.3 64 bits is not "high dpi aware" Message-ID: <1433582426.79.0.462452103713.issue24390@psf.upfronthosting.co.za> New submission from Ivan Bykov: Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32 Type "copyright", "credits" or "license()" for more information. >>> SM_CYSCREEN = 1 >>> from ctypes import windll >>> GetSystemMetrics = windll.user32.GetSystemMetrics >>> GetSystemMetrics(SM_CYSCREEN) 1067 >>> 'really this value is 1600' >>> 'executable must be labeled as "high dpi aware"' ---------- components: Windows messages: 244894 nosy: ivb, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python 3.4.3 64 bits is not "high dpi aware" type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 11:33:34 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 06 Jun 2015 09:33:34 +0000 Subject: [issue24383] consider implementing __await__ on concurrent.futures.Future In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za> Message-ID: <1433583214.86.0.0598301442581.issue24383@psf.upfronthosting.co.za> Stefan Behnel added the comment: (Copying my review comment here so that it doesn't get lost as it's more of a general design thing than a specific review comment.) Having Future know and deal with asyncio seems wrong to me. asyncio should be able to deal *somehow* with a Future that is being awaited, but a Future shouldn't require asyncio in order to be awaited. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 12:21:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Jun 2015 10:21:42 +0000 Subject: [issue24391] Better repr for threading objects Message-ID: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch adds makes reprs of threading objects Semaphore, BoundedSemaphore, Event, and Barrier expose their public states. This will help for debugging. Examples: ---------- components: Library (Lib) messages: 244896 nosy: berker.peksag, brett.cannon, pitrou, rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Better repr for threading objects type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 12:23:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Jun 2015 10:23:38 +0000 Subject: [issue24391] Better repr for threading objects In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> Message-ID: <1433586218.08.0.66616920293.issue24391@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file39637/threading_objects_reprs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 13:04:05 2015 From: report at bugs.python.org (Padmanabhan Tr) Date: Sat, 06 Jun 2015 11:04:05 +0000 Subject: [issue24392] pop functioning Message-ID: <1433588645.87.0.239082859229.issue24392@psf.upfronthosting.co.za> New submission from Padmanabhan Tr: I have attached the python sequence & my comments. I use Python version 3.4.2 I guess a bug need be corrected ---------- components: Regular Expressions files: bug_a messages: 244897 nosy: Padmanabhan.Tr, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: pop functioning type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file39638/bug_a _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 13:42:13 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 06 Jun 2015 11:42:13 +0000 Subject: [issue24392] pop functioning In-Reply-To: <1433588645.87.0.239082859229.issue24392@psf.upfronthosting.co.za> Message-ID: <1433590933.84.0.798857554924.issue24392@psf.upfronthosting.co.za> Steven D'Aprano added the comment: The behaviour is correct, this is not a bug. Each time you pop from aa, the following items move down one space. Then, the next time you pop, the items have moved: ['a0', 'b1', 'c2', 'd3', 'e4', 'f5', 'g6', 'h7', 'i8', 'j9', 'k10', 'l11'] d3 is the third item and gets popped; ['a0', 'b1', 'c2', 'e4', 'f5', 'g6', 'h7', 'i8', 'j9', 'k10', 'l11'] g6 is the fifth item and gets popped; ['a0', 'b1', 'c2', 'e4', 'f5', 'h7', 'i8', 'j9', 'k10', 'l11'] j9 is the seventh item and gets popped. To get the result you want, you can use slicing: aa[3:9:2] => returns ['d3', 'f5', 'h7'] then del aa[3:9:2] => leaves ['a0', 'b1', 'c2', 'e4', 'g6', 'i8', 'j9', 'k10', 'l11'] ---------- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 14:01:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Jun 2015 12:01:58 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1433592118.22.0.00506327637307.issue24120@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The glob module is not affected because it ignores all OSErrors (including "Permission denied" and "Too many levels of symbolic links"). >>> import glob >>> glob.glob('**/*', recursive=True) ['dir2/file1', 'dir2/file2', 'dir2/dir3', 'dir1/file1', 'dir1/file2'] There is no special test for PermissionError. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 14:06:55 2015 From: report at bugs.python.org (Brett Cannon) Date: Sat, 06 Jun 2015 12:06:55 +0000 Subject: [issue24391] Better repr for threading objects In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> Message-ID: <1433592415.49.0.746351133065.issue24391@psf.upfronthosting.co.za> Brett Cannon added the comment: While I like the concept, I don't like the reprs where the type is not the first thing listed, e.g., "set Event" not having "Event" first. The default repr and typical practice of having the type come first makes my brain initially read that repr as a "set of Events" instead of "an Event that is set". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 14:48:56 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_Buira?=) Date: Sat, 06 Jun 2015 12:48:56 +0000 Subject: [issue24393] Test urllib2_localnet fails depending on host proxy configuration Message-ID: <1433594936.74.0.27552580361.issue24393@psf.upfronthosting.co.za> New submission from ?tienne Buira: test_urllib2_localnet make non-explicit use of host configured http_proxy and no_proxy, that will fail the test depending on their contents. ---------- components: Tests files: test_urllib2_localnet_proxy_conf.diff keywords: patch messages: 244901 nosy: eacb priority: normal severity: normal status: open title: Test urllib2_localnet fails depending on host proxy configuration type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file39639/test_urllib2_localnet_proxy_conf.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 15:01:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Jun 2015 13:01:42 +0000 Subject: [issue24391] Better repr for threading objects In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> Message-ID: <1433595702.43.0.931945911042.issue24391@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is for consistency with reprs of lock objects (issue21137): ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 15:05:19 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Jun 2015 13:05:19 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433595919.72.0.413636796911.issue18003@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 15:06:02 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Jun 2015 13:06:02 +0000 Subject: [issue24391] Better repr for threading objects In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> Message-ID: <1433595962.74.0.479959750571.issue24391@psf.upfronthosting.co.za> Antoine Pitrou added the comment: +1. The patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 15:08:49 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 06 Jun 2015 13:08:49 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433596129.33.0.0743419118407.issue18003@psf.upfronthosting.co.za> Larry Hastings added the comment: A small last-minute optimization is not a release-blocker. ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 15:47:13 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 06 Jun 2015 13:47:13 +0000 Subject: [issue24391] Better repr for threading objects In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> Message-ID: <1433598433.19.0.959049716433.issue24391@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 15:49:30 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Jun 2015 13:49:30 +0000 Subject: [issue24391] Better repr for threading objects In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> Message-ID: <1433598570.48.0.642909254037.issue24391@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'd like to see this in 3.5. This is a no-brainer improvement and has very little chance of breaking anything compared to a new OrderedDict implementation. ---------- nosy: +larry versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 16:00:50 2015 From: report at bugs.python.org (Ram Rachum) Date: Sat, 06 Jun 2015 14:00:50 +0000 Subject: [issue24394] TypeError: popitem() takes no keyword arguments Message-ID: <1433599250.82.0.983830780418.issue24394@psf.upfronthosting.co.za> New submission from Ram Rachum: Python 3.5.0b2 (v3.5.0b2:7a088af5615b, May 31 2015, 06:22:19) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import collections >>> o=collections.OrderedDict() >>> o.popitem(last=True) Traceback (most recent call last): File "", line 1, in TypeError: popitem() takes no keyword arguments ---------- messages: 244906 nosy: cool-RR priority: normal severity: normal status: open title: TypeError: popitem() takes no keyword arguments _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 16:01:03 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 06 Jun 2015 14:01:03 +0000 Subject: [issue24391] Better repr for threading objects In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> Message-ID: <1433599263.85.0.0196594418113.issue24391@psf.upfronthosting.co.za> Larry Hastings added the comment: I'll allow it. But I agree with Brett, I really would prefer that the type be the first thing in the repr. I'd rather fix the lock objects than compound our error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 16:06:12 2015 From: report at bugs.python.org (Ram Rachum) Date: Sat, 06 Jun 2015 14:06:12 +0000 Subject: [issue24394] TypeError: popitem() takes no keyword arguments In-Reply-To: <1433599250.82.0.983830780418.issue24394@psf.upfronthosting.co.za> Message-ID: <1433599572.78.0.446685644728.issue24394@psf.upfronthosting.co.za> Ram Rachum added the comment: I'm seeing a similar problem with `move_to_end` and its `last` keyword argument. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 16:19:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Jun 2015 14:19:58 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433600398.21.0.414004804841.issue18003@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: bz2 will gain great benefit from such optimization too. Microbenchmark results: $ ./python -m timeit -s "import gzip" -- "f=gzip.GzipFile('words.gz', 'r')" "for line in f: pass" 2.7: 10 loops, best of 3: 374 msec per loop 3.2: 10 loops, best of 3: 325 msec per loop 3.3: 10 loops, best of 3: 311 msec per loop 3.4: 10 loops, best of 3: 328 msec per loop 3.5: 10 loops, best of 3: 325 msec per loop 3.5+decomp-optim.v3: 10 loops, best of 3: 61.2 msec per loop $ ./python -m timeit -s "import bz2" -- "f=bz2.BZ2File('words.bz2', 'r')" "for line in f: pass" 2.7: 10 loops, best of 3: 92.1 msec per loop 3.2: 10 loops, best of 3: 92.4 msec per loop 3.3: 10 loops, best of 3: 567 msec per loop 3.4: 10 loops, best of 3: 535 msec per loop 3.5: 10 loops, best of 3: 603 msec per loop 3.5+decomp-optim.v2: 10 loops, best of 3: 525 msec per loop 3.5+decomp-optim.v3: 10 loops, best of 3: 131 msec per loop $ python -m timeit -s "import lzma" -- "f=lzma.LZMAFile('words.xz', 'r')" "for line in f: pass" 2.7: 10 loops, best of 3: 49.4 msec per loop 3.3: 10 loops, best of 3: 1.67 sec per loop 3.4: 10 loops, best of 3: 400 msec per loop 3.5: 10 loops, best of 3: 423 msec per loop 3.5+decomp-optim.v3: 10 loops, best of 3: 89.6 msec per loop The fact that bz2 and lzma have 5-15% regression in 3.5 (comparing to 3.4) makes applying this patch to 3.5 more desirable. ---------- Added file: http://bugs.python.org/file39640/decomp-optim.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 16:23:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Jun 2015 14:23:01 +0000 Subject: [issue24394] TypeError: popitem() takes no keyword arguments In-Reply-To: <1433599250.82.0.983830780418.issue24394@psf.upfronthosting.co.za> Message-ID: <1433600581.19.0.349594347166.issue24394@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Library (Lib) nosy: +eric.snow, rhettinger type: -> behavior versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 16:28:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Jun 2015 14:28:10 +0000 Subject: [issue24391] Better repr for threading objects In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> Message-ID: <1433600890.43.0.862876507654.issue24391@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Would following reprs good? (what is better: "unset" or "clear"?) Should the repr contain the module name ()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 16:28:50 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 06 Jun 2015 14:28:50 +0000 Subject: [issue24391] Better repr for threading objects In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> Message-ID: <1433600930.19.0.791987866258.issue24391@psf.upfronthosting.co.za> Larry Hastings added the comment: FWIW I find "unset" more obvious. I don't think it needs the module name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 16:30:08 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 06 Jun 2015 14:30:08 +0000 Subject: [issue14586] TypeError: truncate() takes no keyword arguments In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za> Message-ID: <1433601008.86.0.262347218755.issue14586@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 16:59:29 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Jun 2015 14:59:29 +0000 Subject: [issue24391] Better repr for threading objects In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> Message-ID: <1433602769.98.0.629806828425.issue24391@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think the module name is useful, since there are also multiprocessing events and semaphores. Also, Event is a fairly generic name which may be used in other contexts (e.g. GUI libraries). "set" and "unset" sound good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 17:23:00 2015 From: report at bugs.python.org (Hasan Diwan) Date: Sat, 06 Jun 2015 15:23:00 +0000 Subject: [issue24395] webbrowser.py update to use argparse.py Message-ID: <1433604179.81.0.192966490206.issue24395@psf.upfronthosting.co.za> New submission from Hasan Diwan: The webbrowser module uses getopt, which needs to be ripped out and replaced with argparse. The attached file does just this. ---------- components: Library (Lib) files: webbrowser.py messages: 244913 nosy: Hasan Diwan, georg.brandl priority: normal severity: normal status: open title: webbrowser.py update to use argparse.py type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file39641/webbrowser.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 17:30:54 2015 From: report at bugs.python.org (Ram Rachum) Date: Sat, 06 Jun 2015 15:30:54 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1433604654.09.0.439327042236.issue24195@psf.upfronthosting.co.za> Ram Rachum added the comment: A problem I just realized with Brian's 2-line implementation of `filter`: It doesn't work for iterables which aren't sequences, since it attempts to exhaust the iterable twice. So if you have a non-sequence you'll have to make it into a sequence first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 17:37:58 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 06 Jun 2015 15:37:58 +0000 Subject: [issue24395] webbrowser.py update to use argparse.py In-Reply-To: <1433604179.81.0.192966490206.issue24395@psf.upfronthosting.co.za> Message-ID: <1433605078.69.0.170757739115.issue24395@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! A few comments: * New features like this can only go into Python 3.6 (the "default" branch) * The CLI is partially tested (see Lib/test/test_webbrowser.py). You'll need to add additional tests (e.g. add tests for the -t and -h options) * It would be nice if you could send your changes in a patch format. Please see https://docs.python.org/devguide/patch.html for more information ---------- nosy: +berker.peksag stage: -> needs patch versions: +Python 3.6 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 17:38:26 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 06 Jun 2015 15:38:26 +0000 Subject: [issue24394] TypeError: popitem() takes no keyword arguments In-Reply-To: <1433599250.82.0.983830780418.issue24394@psf.upfronthosting.co.za> Message-ID: <1433605106.22.0.615470939664.issue24394@psf.upfronthosting.co.za> Eric Snow added the comment: This has been fixed in issue24368. The fix came just after the beta 2 release. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Some C OrderedDict methods need to support keyword arguments. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 17:42:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Jun 2015 15:42:02 +0000 Subject: [issue24391] Better repr for threading objects In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> Message-ID: <1433605322.28.0.588436344697.issue24391@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is updated patch. Now the repr always starts with the qualified class name. But there is other question. Should reprs be consistent with reprs of corresponding classes in multiprocessing and asyncio modules? In multiprocessing: In asyncio: ---------- Added file: http://bugs.python.org/file39642/threading_objects_reprs_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 18:08:08 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 06 Jun 2015 16:08:08 +0000 Subject: [issue24395] webbrowser.py update to use argparse.py In-Reply-To: <1433604179.81.0.192966490206.issue24395@psf.upfronthosting.co.za> Message-ID: <1433606888.39.0.412754258294.issue24395@psf.upfronthosting.co.za> Mark Lawrence added the comment: This strikes me as pointless code churn. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 18:28:11 2015 From: report at bugs.python.org (Eryn Wells) Date: Sat, 06 Jun 2015 16:28:11 +0000 Subject: [issue24255] Replace debuglevel-related logic with logging In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za> Message-ID: <1433608091.82.0.508775815905.issue24255@psf.upfronthosting.co.za> Eryn Wells added the comment: Hi. This is my first issue, but I'd be willing to have a go at updating this module. Do either of you have specific ideas about what changes you want here? My thought was to import logging, create a logger object, and start by replacing all the self.debuglevel stuff with appropriate log statements. Does that make sense? Do each of the classes need separate loggers, or is just one module-level logger enough? ---------- nosy: +erynofwales _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 18:47:47 2015 From: report at bugs.python.org (Madison May) Date: Sat, 06 Jun 2015 16:47:47 +0000 Subject: [issue24396] Provide convenience function for paths relative to the current module Message-ID: <1433609267.34.0.395735074965.issue24396@psf.upfronthosting.co.za> New submission from Madison May: I often find myself trying to access a file relative to the module I'm working on. When this occurs, I'll often use something like the following: ``` os.path.abspath(os.path.join(os.path.dirname(__file__), "data/resource.pkl")) ``` I have good reason to believe that I'm not the only one, as searching for other examples of this code on github returns ~20k exact matches: https://github.com/search?utf8=%E2%9C%93&q=%22os.path.abspath%28os.path.join%28os.path.dirname%28__file__%29%22+&type=Code&ref=searchresults Low priority, but a more concise way of achieving the same result would be much appreciated. ---------- components: Library (Lib) messages: 244920 nosy: madison.may priority: normal severity: normal status: open title: Provide convenience function for paths relative to the current module type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 18:54:36 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 06 Jun 2015 16:54:36 +0000 Subject: [issue24255] Replace debuglevel-related logic with logging In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za> Message-ID: <1433609676.22.0.692112395427.issue24255@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 19:32:20 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_Buira?=) Date: Sat, 06 Jun 2015 17:32:20 +0000 Subject: [issue24393] Test urllib2_localnet fails depending on host proxy configuration In-Reply-To: <1433594936.74.0.27552580361.issue24393@psf.upfronthosting.co.za> Message-ID: <1433611940.23.0.709709142464.issue24393@psf.upfronthosting.co.za> ?tienne Buira added the comment: Patch was for 2.7 Hunks about no_proxy are also relevant for other branches. ---------- versions: +Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 19:32:23 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_Buira?=) Date: Sat, 06 Jun 2015 17:32:23 +0000 Subject: [issue24397] Test asynchat makes wrong assumptions Message-ID: <1433611943.2.0.834798500483.issue24397@psf.upfronthosting.co.za> New submission from ?tienne Buira: Amount of data the server could not send back is not a reliable indication on how much data it received. ---------- components: Tests files: test_asynchat_check_received_len_if_received_len_matters.diff keywords: patch messages: 244922 nosy: eacb priority: normal severity: normal status: open title: Test asynchat makes wrong assumptions type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39643/test_asynchat_check_received_len_if_received_len_matters.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 20:13:52 2015 From: report at bugs.python.org (Christie) Date: Sat, 06 Jun 2015 18:13:52 +0000 Subject: [issue24398] Update test_capi to use test.support.script_helper Message-ID: <1433614432.33.0.0607159967244.issue24398@psf.upfronthosting.co.za> New submission from Christie: As described in Issue9517, many test modules do not make use of the helpers in script_helpers.py to invoke the python interpreter in a subprocess. Issue9517 will be broken down into several smaller issues so we can address smaller change sets. This issue is to update test_capi.py to use script_helpers.py. ---------- messages: 244923 nosy: bobcatfish priority: normal severity: normal status: open title: Update test_capi to use test.support.script_helper versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 20:14:29 2015 From: report at bugs.python.org (Christie) Date: Sat, 06 Jun 2015 18:14:29 +0000 Subject: [issue9517] Make test.script_helper more comprehensive, and use it in the test suite In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za> Message-ID: <1433614469.52.0.368458207066.issue9517@psf.upfronthosting.co.za> Christie added the comment: Created issue24398 for updating test_capi. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 22:04:55 2015 From: report at bugs.python.org (Nathan Ringo) Date: Sat, 06 Jun 2015 20:04:55 +0000 Subject: [issue24399] Backports Arch Linux support for platform.linux_distribution() Message-ID: <1433621095.46.0.0189003442326.issue24399@psf.upfronthosting.co.za> New submission from Nathan Ringo: On Arch Linux, running `python2 -c "import platform; print platform.linux_distribution()"' Before patch: ('', '', '') After patch: ('arch', 'Arch', 'Linux') This matches the Python 3 behavior: `python3 -c "import platform; print(platform.linux_distribution())"' ('arch', 'Arch', 'Linux') ---------- files: support_dist_arch.patch keywords: patch messages: 244925 nosy: Nathan Ringo priority: normal severity: normal status: open title: Backports Arch Linux support for platform.linux_distribution() versions: Python 2.7 Added file: http://bugs.python.org/file39644/support_dist_arch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 22:14:47 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 06 Jun 2015 20:14:47 +0000 Subject: [issue24399] Backports Arch Linux support for platform.linux_distribution() In-Reply-To: <1433621095.46.0.0189003442326.issue24399@psf.upfronthosting.co.za> Message-ID: <1433621687.68.0.509585458668.issue24399@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report. This is a duplicate of issue 20454. ---------- nosy: +berker.peksag resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> platform.linux_distribution() returns empty value on Archlinux and python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 22:15:16 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 06 Jun 2015 20:15:16 +0000 Subject: [issue20454] platform.linux_distribution() returns empty value on Archlinux and python 2.7 In-Reply-To: <1391166165.52.0.4413803514.issue20454@psf.upfronthosting.co.za> Message-ID: <1433621716.19.0.215840454888.issue20454@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +Nathan Ringo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 22:24:17 2015 From: report at bugs.python.org (Nathan Ringo) Date: Sat, 06 Jun 2015 20:24:17 +0000 Subject: [issue20454] platform.linux_distribution() returns empty value on Archlinux and python 2.7 In-Reply-To: <1391166165.52.0.4413803514.issue20454@psf.upfronthosting.co.za> Message-ID: <1433622257.07.0.00660151360243.issue20454@psf.upfronthosting.co.za> Nathan Ringo added the comment: The problem is, existing software (Ansible) relies on linux_distribution() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 6 22:30:52 2015 From: report at bugs.python.org (Tim Graham) Date: Sat, 06 Jun 2015 20:30:52 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1433622652.04.0.374484147221.issue14373@psf.upfronthosting.co.za> Tim Graham added the comment: This changed caused a problem in Django's test suite (bisected to 0d0989359bbb0). File "/home/tim/code/django/django/db/models/options.py", line 709, in _populate_directed_relation_graph all_models = self.apps.get_models(include_auto_created=True) TypeError: get_models() missing 1 required positional argument: 'self' The get_models() method is decorated with @lru_cache.lru_cache(maxsize=None) https://github.com/django/django/blob/c2b4967e76fd671e6199e4dd54d2a2c1f096b8eb/django/apps/registry.py#L157-L179 ---------- nosy: +Tim.Graham _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 00:01:33 2015 From: report at bugs.python.org (Christie) Date: Sat, 06 Jun 2015 22:01:33 +0000 Subject: [issue18576] Document test.support.script_helper In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za> Message-ID: <1433628093.42.0.907860004998.issue18576@psf.upfronthosting.co.za> Christie added the comment: @ncoghlan I've taken the test.rst changes from the previous diff and reviewed them against the latest script_helper (including updates from issue24033). Nothing had fallen behind, but I've added what was missing. * I've realized that spawn_python and the helper run_python I added in issue24033 are basically the same so I will reconcile those * Is there some way to load the docstrings from script_helper.py in test.rst instead of writing explanations for each method twice? ---------- Added file: http://bugs.python.org/file39645/issue18576.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 00:02:01 2015 From: report at bugs.python.org (Christie) Date: Sat, 06 Jun 2015 22:02:01 +0000 Subject: [issue24033] Update _test_multiprocessing.py to use script helpers In-Reply-To: <1429748807.96.0.769250379827.issue24033@psf.upfronthosting.co.za> Message-ID: <1433628121.76.0.655246936125.issue24033@psf.upfronthosting.co.za> Christie added the comment: run_python and spawn_python are basically the same, I need to reconcile those. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 00:04:24 2015 From: report at bugs.python.org (Christie) Date: Sat, 06 Jun 2015 22:04:24 +0000 Subject: [issue24398] Update test_capi to use test.support.script_helper In-Reply-To: <1433614432.33.0.0607159967244.issue24398@psf.upfronthosting.co.za> Message-ID: <1433628264.1.0.764064524085.issue24398@psf.upfronthosting.co.za> Christie added the comment: I can't seem to get test_no_FatalError_infinite_loop to fail - I tried reverting the fix that this was verifying, but the test still passed and no infinite loop to be seen. I'm wondering if this is because I can't reproduce it on a mac. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 00:05:13 2015 From: report at bugs.python.org (Christie) Date: Sat, 06 Jun 2015 22:05:13 +0000 Subject: [issue23981] Update test_unicodedata.py to use script_helpers In-Reply-To: <1429228835.0.0.167852596687.issue23981@psf.upfronthosting.co.za> Message-ID: <1433628313.2.0.30924606207.issue23981@psf.upfronthosting.co.za> Changes by Christie : ---------- nosy: +berker.peksag, ezio.melotti, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 00:05:38 2015 From: report at bugs.python.org (Christie) Date: Sat, 06 Jun 2015 22:05:38 +0000 Subject: [issue24279] Update test_base64 to use test.support.script_helper In-Reply-To: <1432498391.21.0.154907178378.issue24279@psf.upfronthosting.co.za> Message-ID: <1433628338.58.0.494175190325.issue24279@psf.upfronthosting.co.za> Changes by Christie : ---------- nosy: +berker.peksag, ezio.melotti, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 00:20:14 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 06 Jun 2015 22:20:14 +0000 Subject: [issue23981] Update test_unicodedata.py to use script_helpers In-Reply-To: <1429228835.0.0.167852596687.issue23981@psf.upfronthosting.co.za> Message-ID: <1433629214.81.0.475422039703.issue23981@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 01:29:21 2015 From: report at bugs.python.org (ppperry) Date: Sat, 06 Jun 2015 23:29:21 +0000 Subject: [issue24252] IDLE removes elements from tracebacks. In-Reply-To: <1432169048.6.0.710293421877.issue24252@psf.upfronthosting.co.za> Message-ID: <1433633361.17.0.276021786241.issue24252@psf.upfronthosting.co.za> ppperry added the comment: Is there any reason why the end of the traceback, rather then just the beginning, needs to be pruned in the first place? Additionally, the "search for pdb in the tb" method will still undesirably prune the traceback if someone invents there own buggy debugger that subclasses from bdb.Bdb. Would this cleanup function work? def cleanup_traceback(tb): idle_directory = os.path.dirname(__file__) while os.path.dirname(tb[0][0]) == idle_directory: del tb[0] [rest of code not having to do with pruning tracebacks] The only situation that this function would behave wrongly is when someone launches IDLE from the shell (Why would they do that?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 01:49:34 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 06 Jun 2015 23:49:34 +0000 Subject: [issue24396] Provide convenience function for paths relative to the current module In-Reply-To: <1433609267.34.0.395735074965.issue24396@psf.upfronthosting.co.za> Message-ID: <1433634574.27.0.981233152416.issue24396@psf.upfronthosting.co.za> Martin Panter added the comment: This feature could be handy for finding test files in test suites. However I don?t think the abspath() step is necessary. We kind of want a urljoin() for OS paths, that automatically removes the current file name. As a new feature I think it would be too late for 3.5. There is the recently added ?pathlib? module. I haven?t used it much, and it doesn?t have the perfect API for the job, but maybe this is good enough: vadmium at localhost:~/proj/python/lib$ cat demo_package/__init__.py from pathlib import PurePath print(PurePath(__file__).with_name("sibling.pkl")) print(PurePath(__file__).parent.joinpath("data/resource.pkl")) vadmium at localhost:~/proj/python/lib$ python3 -bWall -c 'import demo_package' /home/proj/python/lib/demo_package/sibling.pkl /home/proj/python/lib/demo_package/data/resource.pkl ---------- nosy: +vadmium versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 01:56:58 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 06 Jun 2015 23:56:58 +0000 Subject: [issue24396] Provide convenience function for paths relative to the current module In-Reply-To: <1433609267.34.0.395735074965.issue24396@psf.upfronthosting.co.za> Message-ID: <1433635018.53.0.851095178351.issue24396@psf.upfronthosting.co.za> Martin Panter added the comment: There is also pkgutil.get_data(), but that returns the file contents rather than file path, which has rarely been useful to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 02:09:09 2015 From: report at bugs.python.org (ppperry) Date: Sun, 07 Jun 2015 00:09:09 +0000 Subject: [issue24252] IDLE removes elements from tracebacks. In-Reply-To: <1432169048.6.0.710293421877.issue24252@psf.upfronthosting.co.za> Message-ID: <1433635749.16.0.07660129353.issue24252@psf.upfronthosting.co.za> ppperry added the comment: Another example of this overzealous removing is when you create a module named rpc, run, RemoteDebugger, or bdb. For example (in this environment, a file in the current directory named rpc.py exists and refers to the undefined name "bar"): >>>import rpc Traceback (most recent call last): File "", line 1, in import rpc NameError: name 'bar' is not defined The correct traceback is: Traceback (most recent call last): File "", line 1, in File "rpc.py", line 2, in bar NameError: name 'bar' is not defined The IDLE debugger also refuses to debug code in the above file (only if it is named "rpc" not any of the other names). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 02:44:53 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 07 Jun 2015 00:44:53 +0000 Subject: [issue18576] Document test.support.script_helper In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za> Message-ID: <1433637893.34.0.398784452306.issue18576@psf.upfronthosting.co.za> Martin Panter added the comment: If you diffed your patch from a public revision in the main repository, there should be a nice ?Review? link. Anyway, here are some comments on issue18576.patch: +.. function:: assert_python_ok(*args, **env_vars) + + Runs the interpreter with *args* and optional environment + variables, asserting that *env_vars* succeeds (``rc == 0``). Perhaps you mean *env_vars* are the optional environment variables, and that the interpreter is asserted to have succeeded. Also maybe clarify where the *__cleanenv* and *__isolated* keywords come from? Function signatures? Also applies to assert_python_failure(), run_python/_until_end(). Maybe it is worth mentioning that assert_python_ok/failure() strip whitespace from the stderr stream. I seem to remember being tricked by this (writing a test to ensure stderr ended in a newline or something). + ``stdout`` are configured as binary pipes and ``stderr`` is merged with + ``stdout``.. There are two full stops above here.. I encourage you to start sentences with capital letters (although I admit sometimes other people do not agree with this). Suggestions: + *kw* is passed through to subprocess.Popen as additional keyword + arguments. => The *kw* arguments are passed through to subprocess.Popen. + *source* is a Unicode string which will be written to the file as UTF-8. => The *source* argument is a Unicode string which will be written to the file as UTF-8. + *depth* controls how many deeply nested the package is. => The *depth* argument controls how deeply nested the package is. + Creates a new zip archive in the given directory, containing the specified + Python script/module Needs one of those full stops I mentioned earlier :) ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 03:04:49 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 07 Jun 2015 01:04:49 +0000 Subject: [issue14586] TypeError: truncate() takes no keyword arguments In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za> Message-ID: <1433639089.64.0.861298462756.issue14586@psf.upfronthosting.co.za> Martin Panter added the comment: See also Issue 23738 and PEP 457 for fixing the documentation instead, possibly something like truncate(size=None, /). Also, Issue 17003 has changed some of the keywords to be more consistent, making parts of this patch incorrect. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 03:49:24 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 07 Jun 2015 01:49:24 +0000 Subject: [issue24396] Provide convenience function for paths relative to the current module In-Reply-To: <1433609267.34.0.395735074965.issue24396@psf.upfronthosting.co.za> Message-ID: <1433641764.15.0.442982190614.issue24396@psf.upfronthosting.co.za> R. David Murray added the comment: The pkguitil.get_data function is the *right* way to access package-relative data (because in the general case the data may not be on the file system), and IMO it would not be a good idea to make it easier to do things the "wrong" way. Any deficiencies with get_data (and its visibility) will, I think, be addressed as part of the ongoing effort to make using zipped applications more convenient. So I'm -1 on adding a convenience function for this. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 03:55:24 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 07 Jun 2015 01:55:24 +0000 Subject: [issue24397] Test asynchat makes wrong assumptions In-Reply-To: <1433611943.2.0.834798500483.issue24397@psf.upfronthosting.co.za> Message-ID: <1433642124.45.0.453654828171.issue24397@psf.upfronthosting.co.za> R. David Murray added the comment: Your emendation doesn't seem to do anything differently (logic wise) than the original code. Unless I am missing something, it is pointless to track the length of the buffer separately from the contents of the buffer. The buffer knows its length. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 03:57:44 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 07 Jun 2015 01:57:44 +0000 Subject: [issue24397] Test asynchat makes wrong assumptions In-Reply-To: <1433611943.2.0.834798500483.issue24397@psf.upfronthosting.co.za> Message-ID: <1433642264.63.0.864155888673.issue24397@psf.upfronthosting.co.za> R. David Murray added the comment: (Calling that variable 'buffer' is a bit misleading...it isn't really a buffer that gets filled, it is an immutable bytes object that gets replaced by a new one with the additional received data appended.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 06:16:11 2015 From: report at bugs.python.org (Padmanabhan Tr) Date: Sun, 07 Jun 2015 04:16:11 +0000 Subject: [issue24392] pop functioning In-Reply-To: <1433590933.84.0.798857554924.issue24392@psf.upfronthosting.co.za> Message-ID: <1810131658.3274082.1433650396543.JavaMail.yahoo@mail.yahoo.com> Padmanabhan Tr added the comment: Dear StevenThank you.? I am clear now.Padmanabhan On Saturday, June 6, 2015 5:12 PM, Steven D'Aprano wrote: Steven D'Aprano added the comment: The behaviour is correct, this is not a bug. Each time you pop from aa, the following items move down one space. Then, the next time you pop, the items have moved: ['a0', 'b1', 'c2', 'd3', 'e4', 'f5', 'g6', 'h7', 'i8', 'j9', 'k10', 'l11'] d3 is the third item and gets popped; ['a0', 'b1', 'c2', 'e4', 'f5', 'g6', 'h7', 'i8', 'j9', 'k10', 'l11'] g6 is the fifth item and gets popped; ['a0', 'b1', 'c2', 'e4', 'f5', 'h7', 'i8', 'j9', 'k10', 'l11'] j9 is the seventh item and gets popped. To get the result you want, you can use slicing: aa[3:9:2] => returns ['d3', 'f5', 'h7'] then del aa[3:9:2] => leaves ['a0', 'b1', 'c2', 'e4', 'g6', 'i8', 'j9', 'k10', 'l11'] ---------- nosy: +steven.daprano resolution:? -> not a bug stage:? -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 07:06:53 2015 From: report at bugs.python.org (Ben Darnell) Date: Sun, 07 Jun 2015 05:06:53 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch Message-ID: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> New submission from Ben Darnell: The new collections.abc.Awaitable ABC relies on __instancecheck__, which makes it incompatible with functools.singledispatch (singledispatch works based on args[0].__class__; any instance-level information is discarded). This surprised me because the first thing I tried to do with Awaitable was add it to my singledispatch-based coroutine compatibility layer. Ideally coroutine would be an actual subclass of generator, instead of a generator with an extra bit set on the instance that changes how it answers isinstance() checks. That would be a big change, though, so it might be better to just document that Awaitable is kind of unusual (if we weren't already in the beta period I might argue that the ABCs should be removed and we should just use the functions in the inspect module instead). ---------- components: asyncio messages: 244942 nosy: Ben.Darnell, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: Awaitable ABC incompatible with functools.singledispatch versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 07:45:02 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 07 Jun 2015 05:45:02 +0000 Subject: [issue18576] Document test.support.script_helper In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za> Message-ID: <1433655902.86.0.349167589574.issue18576@psf.upfronthosting.co.za> Nick Coghlan added the comment: As far as using docstrings for the online docs goes, there are some useful Sphinx add-ons that we've never enabled for the main Python docs (like autodoc, blockdiag, seqdiag) that could be good options to have available. For autodoc in particular, we prefer to avoid it for the main docs because "good docstring" and "good prose documentation" don't necessarily look alike. For ease of maintenance of test.support though, I think the "write a good docstring, get the online docs for free" rationale is a compelling one (since these docs are core contributor facing, rather than being aimed at Python users in general) docs at python.org would be the place to ask about the appropriateness of enabling some Sphinx add-ons. While enabling them seems like a reasonable idea to me, I don't personally know if there are actually technical issues with the idea, or if there just hasn't been a volunteer to add/enable them and update https://docs.python.org/devguide/documenting.html accordingly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 07:55:54 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 07 Jun 2015 05:55:54 +0000 Subject: [issue24393] Test urllib2_localnet fails depending on host proxy configuration In-Reply-To: <1433594936.74.0.27552580361.issue24393@psf.upfronthosting.co.za> Message-ID: <1433656554.15.0.134553583851.issue24393@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +orsenthil stage: -> patch review versions: +Python 3.6 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 08:44:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 07 Jun 2015 06:44:39 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1433659479.92.0.543084048985.issue14373@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that adds __get__ for lru_cache object. ---------- Added file: http://bugs.python.org/file39646/clru_cache_descr_get.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 09:32:09 2015 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 07 Jun 2015 07:32:09 +0000 Subject: [issue23891] Tutorial doesn't mention either pip or virtualenv In-Reply-To: <1428521410.44.0.984619918633.issue23891@psf.upfronthosting.co.za> Message-ID: <1433662329.91.0.74293850102.issue23891@psf.upfronthosting.co.za> A.M. Kuchling added the comment: One unrelated improvement: describe some of the recently-added modules, and mention the json module. ---------- keywords: +patch Added file: http://bugs.python.org/file39647/modules.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 09:33:56 2015 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 07 Jun 2015 07:33:56 +0000 Subject: [issue23891] Tutorial doesn't mention either pip or virtualenv In-Reply-To: <1428521410.44.0.984619918633.issue23891@psf.upfronthosting.co.za> Message-ID: <1433662436.9.0.278428539403.issue23891@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Rewrite discussion of python-list a bit, and add pyvideo.org to the list of links. ---------- Added file: http://bugs.python.org/file39648/tutorial.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 09:35:02 2015 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 07 Jun 2015 07:35:02 +0000 Subject: [issue23891] Tutorial doesn't mention either pip or virtualenv In-Reply-To: <1428521410.44.0.984619918633.issue23891@psf.upfronthosting.co.za> Message-ID: <1433662502.4.0.263261113388.issue23891@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Finally, the major stuff: add a section on pyvenv and pip to the tutorial. ---------- Added file: http://bugs.python.org/file39649/venv.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 09:37:27 2015 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 07 Jun 2015 07:37:27 +0000 Subject: [issue23891] Tutorial doesn't mention either pip or virtualenv In-Reply-To: <1428521410.44.0.984619918633.issue23891@psf.upfronthosting.co.za> Message-ID: <1433662647.59.0.629940343599.issue23891@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 11:10:28 2015 From: report at bugs.python.org (Laura Creighton) Date: Sun, 07 Jun 2015 09:10:28 +0000 Subject: [issue24401] Windows 8.1 install gives DLL required to complete could not run Message-ID: <1433668228.61.0.22658051744.issue24401@psf.upfronthosting.co.za> New submission from Laura Creighton: Another report from webmaster. (I still don't have a windows machine). Somebody tried to install 3.3, 3.4 or 3.5 and got this error. I asked them to try the Activestate installer. That worked. Thus Activestate knows to include something that users sometimes don't have, which we do not. We probably should analyse this and include what we are missing. ---------- components: Installation, Windows messages: 244948 nosy: lac, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows 8.1 install gives DLL required to complete could not run versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 11:30:52 2015 From: report at bugs.python.org (Keita Kita) Date: Sun, 07 Jun 2015 09:30:52 +0000 Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for prompt Message-ID: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za> New submission from Keita Kita: On Python 3.4, input() does not use wrapped sys.stdout. For example, the following script should print "Wrapped stdout" by print() and input() because sys.stdout is replaced with Writer object. -------- import io import sys class Writer: def __getattr__(self, name): return getattr(sys.__stdout__, name) def write(self, data): if data != '\n': sys.__stdout__.write('Wrapped stdout\n') def fileno(): raise OSError() sys.stdout = Writer() print('print') input('input') ------ But the script does not print "Wrapped stdout" as prompt of input(). The script prints the following. ----- Wrapped stdout input ---- Although, when sys.stdin is also wrapped, input() will use sys.stdout for prompt. For example, the following script prints "Wrapped stdout" by print() and input(). ---- import io import sys class Writer: def __getattr__(self, name): return getattr(sys.__stdout__, name) def write(self, data): if data != '\n': sys.__stdout__.write('Wrapped stdout\n') def fileno(): raise OSError() class Reader: def __getattr__(self, name): return getattr(sys.__stdin__, name) def read(self, size): return sys.__stdin__.read(size) def fileno(): raise OSError() sys.stdout = Writer() sys.stdin = Reader() print('print') input('input') ---- The script prints the following. ----- Wrapped stdout Wrapped stdout ---- ---------- components: Interpreter Core messages: 244949 nosy: Keita Kita priority: normal severity: normal status: open title: input() uses sys.__stdout__ instead of sys.stdout for prompt type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 12:43:38 2015 From: report at bugs.python.org (Tim Graham) Date: Sun, 07 Jun 2015 10:43:38 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1433673817.98.0.309404675018.issue14373@psf.upfronthosting.co.za> Tim Graham added the comment: Thanks, that does resolve the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 12:58:41 2015 From: report at bugs.python.org (priska) Date: Sun, 07 Jun 2015 10:58:41 +0000 Subject: [issue24403] Missing fixer for changed round() behavior Message-ID: <1433674721.13.0.236886844827.issue24403@psf.upfronthosting.co.za> New submission from priska: The behavior of the round() function has changed between Python 2.x and Python3.x. >From the release notes of Python 3.0: "The round() function rounding strategy and return type have changed. Exact halfway cases are now rounded to the nearest even result instead of away from zero. (For example, round(2.5) now returns 2 rather than 3.) round(x[, n]) now delegates to x.__round__([n]) instead of always returning a float. It generally returns an integer when called with a single argument and a value of the same type as x when called with two arguments." 2to3 conversion does not take this into account and thereby changes code behavior. Suggested translations: round(n) -> float(math.floor(n + math.copysign(0.5, n))) or round(n) -> float(math.trunc(n + math.copysign(0.5, n))) ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 244951 nosy: priska priority: normal severity: normal status: open title: Missing fixer for changed round() behavior type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 13:51:34 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 07 Jun 2015 11:51:34 +0000 Subject: [issue24403] Missing fixer for changed round() behavior In-Reply-To: <1433674721.13.0.236886844827.issue24403@psf.upfronthosting.co.za> Message-ID: <1433677894.6.0.894860364466.issue24403@psf.upfronthosting.co.za> Mark Dickinson added the comment: This is a bit tricky. The first expression you suggest doesn't work at all for negative numbers (e.g., producing `-3.0` for `round(-1.8)`). The second expression *mostly* works as you want, but not entirely. Some examples: >>> def f(n): return float(math.trunc(n + math.copysign(0.5, n))) ... >>> x = 0.5 - 2**-54 >>> x 0.49999999999999994 >>> f(x) # should be 0.0 1.0 >>> x = 5e15 + 3.0 >>> x 5000000000000003.0 >>> f(x) # should be x again 5000000000000004.0 And neither of these addresses the two-argument case of `round`. It may be better to simply flag this as something that 2to3 can't handle, and that needs a manual check. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 14:39:49 2015 From: report at bugs.python.org (priska) Date: Sun, 07 Jun 2015 12:39:49 +0000 Subject: [issue24403] Missing fixer for changed round() behavior In-Reply-To: <1433674721.13.0.236886844827.issue24403@psf.upfronthosting.co.za> Message-ID: <1433680789.82.0.97108959581.issue24403@psf.upfronthosting.co.za> priska added the comment: Yes, those quick suggestions weren't thoroughly tested at all and turned out to be too short-sighted ? thanks for checking, but are you saying the old behavior cannot be emulated or that it is not desirable to to so? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 14:56:01 2015 From: report at bugs.python.org (Jakub Wilk) Date: Sun, 07 Jun 2015 12:56:01 +0000 Subject: [issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> Message-ID: <1433681761.19.0.789816507045.issue24305@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 15:04:56 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 07 Jun 2015 13:04:56 +0000 Subject: [issue24401] Windows 8.1 install gives DLL required to complete could not run In-Reply-To: <1433668228.61.0.22658051744.issue24401@psf.upfronthosting.co.za> Message-ID: <1433682296.72.0.910191484595.issue24401@psf.upfronthosting.co.za> Steve Dower added the comment: Did it fail for 3.3, 3.4 AND 3.5? Or was it not clear which version they were having trouble with? 3.5 is so different from earlier versions I'd be very surprised for this kind of failure to be the same. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 15:06:38 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 07 Jun 2015 13:06:38 +0000 Subject: [issue24264] imageop Unsafe Arithmetic In-Reply-To: <1432278063.26.0.673606816428.issue24264@psf.upfronthosting.co.za> Message-ID: <1433682398.34.0.710737026385.issue24264@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 15:19:30 2015 From: report at bugs.python.org (Laura Creighton) Date: Sun, 07 Jun 2015 13:19:30 +0000 Subject: [issue24401] Windows 8.1 install gives DLL required to complete could not run In-Reply-To: <1433668228.61.0.22658051744.issue24401@psf.upfronthosting.co.za> Message-ID: <1433683170.37.0.166883263029.issue24401@psf.upfronthosting.co.za> Laura Creighton added the comment: Definitely 3.3 and 3.4. I asked, got back '3.3 through the latest' so maybe 3.5 was not the latest where he was ... I will go ask again for 3.5 in particular. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 15:26:41 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 07 Jun 2015 13:26:41 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1433683601.31.0.206434566054.issue24325@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 15:32:16 2015 From: report at bugs.python.org (Geoff Shannon) Date: Sun, 07 Jun 2015 13:32:16 +0000 Subject: [issue22865] Document how to make pty.spawn not copy data In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za> Message-ID: <1433683936.43.0.0830036618056.issue22865@psf.upfronthosting.co.za> Geoff Shannon added the comment: Hey, pinging this issue. Hoping someone has time to take a look at it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 15:59:15 2015 From: report at bugs.python.org (eryksun) Date: Sun, 07 Jun 2015 13:59:15 +0000 Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for prompt In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za> Message-ID: <1433685555.5.0.170701389531.issue24402@psf.upfronthosting.co.za> eryksun added the comment: This looks like an oversight. In the implementation in [bltinmodule.c][1], if checking sys.stdout.fileno() fails, it clears the error without setting tty = 0. It's the [same in 3.5][2]. /* We should only use (GNU) readline if Python's sys.stdin and sys.stdout are the same as C's stdin and stdout, because we need to pass it those. */ tmp = _PyObject_CallMethodId(fin, &PyId_fileno, ""); if (tmp == NULL) { PyErr_Clear(); tty = 0; } else { fd = PyLong_AsLong(tmp); Py_DECREF(tmp); if (fd < 0 && PyErr_Occurred()) return NULL; tty = fd == fileno(stdin) && isatty(fd); } if (tty) { tmp = _PyObject_CallMethodId(fout, &PyId_fileno, ""); if (tmp == NULL) PyErr_Clear(); else { fd = PyLong_AsLong(tmp); Py_DECREF(tmp); if (fd < 0 && PyErr_Occurred()) return NULL; tty = fd == fileno(stdout) && isatty(fd); } } [1]: https://hg.python.org/cpython/file/b4cbecbc0781/Python/bltinmodule.c#l1709 [2]: https://hg.python.org/cpython/file/7a088af5615b/Python/bltinmodule.c#l1839 ---------- nosy: +eryksun versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 16:38:08 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 07 Jun 2015 14:38:08 +0000 Subject: [issue24391] Better repr for threading objects In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> Message-ID: <1433687888.58.0.00903851940929.issue24391@psf.upfronthosting.co.za> Larry Hastings added the comment: The world of reprs already isn't particularly consistent. If you make your reprs consistent with module X, it'll be *inconsistent* with module Y, and vice versa. I say let's just worry about making it nice and readable for humans. That said, I like the asyncio reprs. Specifically, I like how the interesting things (class, interesting values) are at the front and rear, and the address is in the middle. While it's occasionally helpful (or even crucial!) to show the address, I *almost* never need to look at it. Arranging the data in this way makes it easy to skip over the address when reading. However, I don't think the parentheses or square brackets are necessary. It's not like this is a computer-readable syntax, and for human beings it's just visual clutter. I suggest it's sufficient to have comma separated values with a space after each comma. Also: I definitely don't like the colon after the class name. So here's how *I* might reformat all your examples: p.s. Thank you for posting these samples of other approaches! It definitely shed some light into the discussion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 17:05:10 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Sun, 07 Jun 2015 15:05:10 +0000 Subject: [issue14003] __self__ on built-in functions is not as documented In-Reply-To: <1329159935.3.0.264942191971.issue14003@psf.upfronthosting.co.za> Message-ID: <1433689510.46.0.386297012309.issue14003@psf.upfronthosting.co.za> Changes by Dmitry Kazakov : ---------- nosy: +vlth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 17:13:32 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 07 Jun 2015 15:13:32 +0000 Subject: [issue22865] Document how to make pty.spawn not copy data In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za> Message-ID: <1433690012.19.0.541229003012.issue22865@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 17:34:15 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 07 Jun 2015 15:34:15 +0000 Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1) In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za> Message-ID: <1433691255.65.0.163422905088.issue19915@psf.upfronthosting.co.za> Changes by Steven D'Aprano : ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 17:39:00 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 07 Jun 2015 15:39:00 +0000 Subject: [issue18814] Add utilities to "clean" surrogate code points from strings In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za> Message-ID: <1433691540.26.0.751265556018.issue18814@psf.upfronthosting.co.za> Changes by Steven D'Aprano : ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 18:26:25 2015 From: report at bugs.python.org (Brandon Milam) Date: Sun, 07 Jun 2015 16:26:25 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1433694385.92.0.595971804344.issue8232@psf.upfronthosting.co.za> Brandon Milam added the comment: Moved the 64 bit browser list to its own loop and switched to browsers.append rather than +=. ---------- Added file: http://bugs.python.org/file39650/webbrowserfix6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 19:17:28 2015 From: report at bugs.python.org (Eryn Wells) Date: Sun, 07 Jun 2015 17:17:28 +0000 Subject: [issue24255] Replace debuglevel-related logic with logging In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za> Message-ID: <1433697448.84.0.00844705049734.issue24255@psf.upfronthosting.co.za> Eryn Wells added the comment: Here's a patch that replaces all the debuglevel stuff with logging. There's a single module-level logger that handles it all. I wasn't sure if it would be okay to break API compatibility, so I kept the debuglevel flag and the set_debuglevel() method even though they don't do anything. Most of the information that was being print()ed is still there, but I cleaned it up a little and added a few more messages. The INFO level messages are pretty sparse, with DEBUG providing a lot more raw data from the request. ---------- keywords: +patch Added file: http://bugs.python.org/file39651/http-client-logging.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 19:27:43 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 07 Jun 2015 17:27:43 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I think it's actually good feedback and we should fix this during the beta. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 19:45:25 2015 From: report at bugs.python.org (Fabian) Date: Sun, 07 Jun 2015 17:45:25 +0000 Subject: [issue24404] Python 2.7.0's BZ2File does not support with-statements Message-ID: <1433699124.98.0.649145124993.issue24404@psf.upfronthosting.co.za> New submission from Fabian: I had a weird bug recently where someone tried to use the with-statement on a BZ2File. According to the documentation it was added in 2.7 and looking at https://hg.python.org/cpython/rev/5d5d9074f4ca it looks like it was added together with the support in gzip. But after I've installed 2.7.0 I could use the with-statement on gzip but not in BZ2File: Python 2.7 (r27:82500, Jun 7 2015, 19:01:29) [GCC 4.8.3 20140911 (Red Hat 4.8.3-7)] on linux3 Type "help", "copyright", "credits" or "license" for more information. >>> import bz2 >>> with bz2.BZ2File('tests/data/xml/article-pyrus.xml.bz2') as f: ... c = f.read() ... Traceback (most recent call last): File "", line 1, in AttributeError: __exit__ So I've installed 2.7.1 and sure enough it works there: Python 2.7.1 (r271:86832, Jun 7 2015, 19:21:02) [GCC 4.8.3 20140911 (Red Hat 4.8.3-7)] on linux3 Type "help", "copyright", "credits" or "license" for more information. >>> import bz2 >>> with bz2.BZ2File('tests/data/xml/article-pyrus.xml.bz2') as f: ... c = f.read() ... >>> I guess the documentation needs be updated that since Python 2.7.1 BZ2File supports the with-statement. See also: https://phabricator.wikimedia.org/T101649 ---------- assignee: docs at python components: Documentation messages: 244962 nosy: docs at python, xZise priority: normal severity: normal status: open title: Python 2.7.0's BZ2File does not support with-statements versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 20:10:23 2015 From: report at bugs.python.org (eryksun) Date: Sun, 07 Jun 2015 18:10:23 +0000 Subject: [issue14003] __self__ on built-in functions is not as documented In-Reply-To: <1329159935.3.0.264942191971.issue14003@psf.upfronthosting.co.za> Message-ID: <1433700623.56.0.0396390927839.issue14003@psf.upfronthosting.co.za> eryksun added the comment: In Python 2 [Py_InitModule4][1] optionally allows setting __self__ on module functions, but no module in the standard library actually uses this. It's always None. This is no longer optional with Python 3's [PyModule_Create][2]. Built-in module functions instantiated the normal way can be considered as methods of the module in which they're defined. However, some modules may specially instantiate functions for which __self__ is None, such as codecs.strict_errors. >>> codecs.strict_errors.__self__ is None True [1]: https://docs.python.org/2/c-api/allocation.html#c.Py_InitModule4 [2]: https://docs.python.org/3/c-api/module.html#c.PyModule_Create ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 20:19:32 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_Buira?=) Date: Sun, 07 Jun 2015 18:19:32 +0000 Subject: [issue24397] Test asynchat makes wrong assumptions In-Reply-To: <1433611943.2.0.834798500483.issue24397@psf.upfronthosting.co.za> Message-ID: <1433701172.53.0.99609244583.issue24397@psf.upfronthosting.co.za> ?tienne Buira added the comment: The issue is that this buffer is also emptied at the end. Current version assumes that the server thread will not have enough opportunity to send the whole buffer before receiving a RST. But in reality, it's quite possible (happens reliably on a box) that: 1. many server sent chars get merged in one packet and/or 2. RST is yielded only once the server have put all its buffer in send queue. As a consequence, server's buffer is empty at the time it is checked, and the test is marked as failed although everything worked fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 20:25:29 2015 From: report at bugs.python.org (Christie) Date: Sun, 07 Jun 2015 18:25:29 +0000 Subject: [issue18576] Document test.support.script_helper In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za> Message-ID: <1433701529.44.0.528125522094.issue18576@psf.upfronthosting.co.za> Christie added the comment: > If you diffed your patch from a public revision in the main repository, there should be a nice ?Review? link. Ah, thanks @vadmium!!! I've been confused about why some patches get review links and others do not >.< I'll have a new patch up shortly which is diffed against a public revision and has your suggested changes. > For autodoc in particular, we prefer to avoid it for the main docs because "good docstring" and "good prose documentation" don't necessarily look alike. @ncoghlan for some reason I thought that the main docs were also auto generated from docstrings in the actual modules, but I can see now that that isn't the case. I'll reach out to docs at python.org to see how they feel about autogenerating the test.support docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 20:56:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 07 Jun 2015 18:56:06 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1433703366.19.0.341988024592.issue14373@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: test_lru_cache_threaded is randomly failed on PPC64 PowerLinux buildbot: http://buildbot.python.org/all/builders/PPC64%20PowerLinux%203.x/builds/3573/steps/test/logs/stdio ====================================================================== FAIL: test_lru_cache_threaded (test.test_functools.TestLRUPy) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/test_functools.py", line 1129, in test_lru_cache_threaded self.assertEqual(hits, 45) AssertionError: 43 != 45 ---------------------------------------------------------------------- The tests looks incorrect, it should fail when cached function is called simultaneously from different threads. Unfortunately it is hard reproduce the failure on other platform. Proposed patch fixes the test and adds other threaded test, specially for simultaneous call. ---------- Added file: http://bugs.python.org/file39652/test_lru_cache_threaded.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 20:58:17 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Jun 2015 18:58:17 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433703497.56.0.999570646627.issue18003@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This looks good to me. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 21:03:26 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 07 Jun 2015 19:03:26 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1433703806.96.0.819035278965.issue8232@psf.upfronthosting.co.za> Steve Dower added the comment: That looks good to me, I'll get it merged in when I'm at my desk. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 21:03:42 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 07 Jun 2015 19:03:42 +0000 Subject: [issue24362] Simplify the fast nodes resize logic in C OrderedDict. In-Reply-To: <1433253631.63.0.422253960427.issue24362@psf.upfronthosting.co.za> Message-ID: <1433703822.14.0.0273523770216.issue24362@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 21:23:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 07 Jun 2015 19:23:37 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433705017.76.0.693711259982.issue18003@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Perhaps this change is worth to mention in whatsnews. Could you add this Martin? It would be nice also add tests to ensure that next() after closing the file always raises ValueError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 21:58:34 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 07 Jun 2015 19:58:34 +0000 Subject: [issue24403] Missing fixer for changed round() behavior In-Reply-To: <1433674721.13.0.236886844827.issue24403@psf.upfronthosting.co.za> Message-ID: <1433707114.59.0.984217137899.issue24403@psf.upfronthosting.co.za> Mark Dickinson added the comment: The old behaviour certainly can be emulated, but doing that correctly would require 4 or 5 lines of code. I don't know enough about 2to3 to know whether it can handle that sort of translation, but even if it can, I'd guess that in a good proportion of cases the loss in readability (and possibly also in performance) wouldn't be worth it, and in many cases the difference in behaviour may not matter either. Given all that, I think it's probably better left as a judgement call on the part of the person doing the 2-to-3 porting. Here's a translation that's immune from the two issues I pointed out. def round_ties_away_from_zero(x): n = round(x) if abs(x - n) == 0.5: # x - n is exact; no rounding error return x + copysign(0.5, x) else: return float(n) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 22:38:36 2015 From: report at bugs.python.org (Tal Einat) Date: Sun, 07 Jun 2015 20:38:36 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1433709516.4.0.369576653978.issue20186@psf.upfronthosting.co.za> Tal Einat added the comment: Attached is a patch for all of _operator except for itemgetter, attrgetter and methodcaller. The entire test suite passes after applying this patch. Using AC has allowed the removal of all of the cryptic "spam*()" macros in the code, making it much more straightforward. In terms of readability, IMO this is a great improvement. I skipped itemgetter, attrgetter and methodcaller since they all support passing a variable number of arguments and treating those as a sequence of values. ---------- Added file: http://bugs.python.org/file39653/issue20186._operator.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 22:54:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 07 Jun 2015 20:54:35 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1433710475.27.0.859765802612.issue20186@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is there any performance difference? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 22:59:32 2015 From: report at bugs.python.org (Tal Einat) Date: Sun, 07 Jun 2015 20:59:32 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1433710772.02.0.813167015074.issue20186@psf.upfronthosting.co.za> Tal Einat added the comment: I tried running the pystone benchmark, but the results were inconclusive. I saw very large differences (up to 20%) between runs at different times, with no clear differences with or without the patch. However, a quick search shows that the operator module is almost completely unused by the rest of the code and the stdlib. So I really don't think performance is an issue here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 23:20:00 2015 From: report at bugs.python.org (Tal Einat) Date: Sun, 07 Jun 2015 21:20:00 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1433712000.73.0.055866458284.issue20186@psf.upfronthosting.co.za> Tal Einat added the comment: Attached a slightly revised patch thanks to Serhiy's review. In addition to Serhiy's remarks, I used "_operator._compare_digest = _operator.eq" to reduce a bit more boilerplate. ---------- Added file: http://bugs.python.org/file39654/issue20186._operator.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 23:36:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 07 Jun 2015 21:36:24 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1433712984.71.0.630037257612.issue20186@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The operator module is rarely used in the stdlib, but if it is used in user code (mainly with map(), reduce() or like) the performance often is important. You can use microbenchmarks like following (operator.add is twice faster than lambda x, y: x + y). ./python -m timeit -s "import operator; a = list(range(10000)); b = a[:]" -- "list(map(operator.add, a, b))" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 23:40:28 2015 From: report at bugs.python.org (Demian Brecht) Date: Sun, 07 Jun 2015 21:40:28 +0000 Subject: [issue23377] HTTPResponse may drop buffer holding next response In-Reply-To: <1422881776.12.0.998068930599.issue23377@psf.upfronthosting.co.za> Message-ID: <1433713228.35.0.372233037827.issue23377@psf.upfronthosting.co.za> Demian Brecht added the comment: Actually had a few free minutes so stuck a couple minor comments in Rietveld. Will have another go as soon as possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 23:41:47 2015 From: report at bugs.python.org (Tal Einat) Date: Sun, 07 Jun 2015 21:41:47 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1433713307.84.0.953558179783.issue20186@psf.upfronthosting.co.za> Tal Einat added the comment: I just ran such microbenchmarks for operator.add and operator.not_, and saw no significant difference with or without the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 7 23:48:31 2015 From: report at bugs.python.org (Tal Einat) Date: Sun, 07 Jun 2015 21:48:31 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1433713711.02.0.866460171944.issue20186@psf.upfronthosting.co.za> Tal Einat added the comment: Here's another complete conversion patch for _operator. As suggested by Serhiy, I changed the comparison operators to copy the signature from _operator.eq() instead of _operator.lt(), which is easier to understand. ---------- Added file: http://bugs.python.org/file39655/issue20186._operator.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 00:47:11 2015 From: report at bugs.python.org (Tal Einat) Date: Sun, 07 Jun 2015 22:47:11 +0000 Subject: [issue24384] difflib.SequenceMatcher faster quick_ratio with lower bound specification In-Reply-To: <1433448775.15.0.914528193485.issue24384@psf.upfronthosting.co.za> Message-ID: <1433717231.41.0.793178476559.issue24384@psf.upfronthosting.co.za> Tal Einat added the comment: Your second suggestion of adding a 'threshold' parameter to quick_ratio() is a bad idea in my opinion, since it would then be two significantly different functions crammed into one. The separate function would be possible. However, is there a compelling reason for this to be in the stdlib, rather than an online code recipe? ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 01:00:19 2015 From: report at bugs.python.org (Mathieu Bridon) Date: Sun, 07 Jun 2015 23:00:19 +0000 Subject: [issue14102] argparse: add ability to create a man page In-Reply-To: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za> Message-ID: <1433718019.03.0.596979446882.issue14102@psf.upfronthosting.co.za> Changes by Mathieu Bridon : ---------- nosy: +bochecha _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 01:06:55 2015 From: report at bugs.python.org (Tal Einat) Date: Sun, 07 Jun 2015 23:06:55 +0000 Subject: [issue23891] Tutorial doesn't mention either pip or virtualenv In-Reply-To: <1428521410.44.0.984619918633.issue23891@psf.upfronthosting.co.za> Message-ID: <1433718415.88.0.19758612893.issue23891@psf.upfronthosting.co.za> Tal Einat added the comment: modules.patch and tutorial.patch LGTM. venv.patch is looking good; I posted two relatively minor comments on Rietveld. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 01:30:42 2015 From: report at bugs.python.org (Mathieu Bridon) Date: Sun, 07 Jun 2015 23:30:42 +0000 Subject: [issue14102] argparse: add ability to create a man page In-Reply-To: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za> Message-ID: <1433719842.55.0.0946965867208.issue14102@psf.upfronthosting.co.za> Mathieu Bridon added the comment: Any news on this? The code posted by Oz Tiram (I took the latest from his github repo) works quite well, even with Python 3. (I just tested it) It would be great if argparse could include the formatter class, as well as the distutils command. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 02:11:11 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Jun 2015 00:11:11 +0000 Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for prompt In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za> Message-ID: <1433722271.5.0.194488480918.issue24402@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 02:12:37 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Jun 2015 00:12:37 +0000 Subject: [issue24403] Missing fixer for changed round() behavior In-Reply-To: <1433674721.13.0.236886844827.issue24403@psf.upfronthosting.co.za> Message-ID: <1433722357.88.0.447906155613.issue24403@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 02:24:17 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Jun 2015 00:24:17 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433723057.24.0.226475931948.issue24400@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- priority: normal -> release blocker stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 03:07:32 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Jun 2015 01:07:32 +0000 Subject: [issue24404] Python 2.7.0's BZ2File does not support with-statements In-Reply-To: <1433699124.98.0.649145124993.issue24404@psf.upfronthosting.co.za> Message-ID: <1433725652.03.0.765441905115.issue24404@psf.upfronthosting.co.za> Ned Deily added the comment: The misbehavior in Python 2.7 was due to a bug as documented in Issue9928, a bug that unfortunately was not discovered until just after 2.7 was initially released. The fix for Issue9928 was first included in 2.7.1 as you discovered. So the documentation has always been correct in intent. For Python versions in maintenance mode, like 2.7.x and 3.4.x, we only provide fixes for the most recent minor release of each (e.g. currently 2.7.10 and 3.4.3), so Python 2.7 was no longer supported once Python 2.7.1 was released and those events were nearly five years and many minor versions ago. It's a bit of a judgement call in this case but I don't think there's a compelling reason to change the documentation now. The current version of the 2.7 documentation is intended to reflect the current state of Python 2.7, e.g. 2.7.10, which it does. And we hope that no one is still using 2.7(.0). ---------- nosy: +ned.deily resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> weird oddity with bz2 context manager _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 03:55:31 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 08 Jun 2015 01:55:31 +0000 Subject: [issue24397] Test asynchat makes wrong assumptions In-Reply-To: <1433611943.2.0.834798500483.issue24397@psf.upfronthosting.co.za> Message-ID: <1433728531.19.0.00756695746813.issue24397@psf.upfronthosting.co.za> R. David Murray added the comment: The comments in the test indicate that this possibility was considered and dealt with. So that indicates it is a test bug in this particular test (test_close_when_done, for other readers), not in the fixture. It looks like the race condition still exists, the window is just reduced. Can you see any reason the assert shouldn't be moved to before the s.start_reserved_event.set()? (Since I missed the clearing of the buffer, I'm not confident in my reading of the test intent :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 04:06:16 2015 From: report at bugs.python.org (Martin Blais) Date: Mon, 08 Jun 2015 02:06:16 +0000 Subject: [issue24278] Docs on Parsing arguments should say something about mem mgmt for formatters returning C strings In-Reply-To: <1432481258.46.0.49462668629.issue24278@psf.upfronthosting.co.za> Message-ID: <1433729176.57.0.407888042767.issue24278@psf.upfronthosting.co.za> Martin Blais added the comment: LGTM! Thanks for making the change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 06:25:18 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 08 Jun 2015 04:25:18 +0000 Subject: [issue24252] IDLE removes elements from tracebacks. In-Reply-To: <1432169048.6.0.710293421877.issue24252@psf.upfronthosting.co.za> Message-ID: <1433737518.11.0.627138512405.issue24252@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Did you test my proposed patch? I am reluctant to make major changes in the absence of either documentation for why the code is as it is or test cases. So I do not know about trimming top versus bottom and the examples intended to show both are needed. I am not even sure that only top and bottom are 'correct'. That said, paying attention to the complete file name, or at least the prior directory ('idlelib' for idle files), seems plausible. But we have to attend to '/' versus Windows' '\'. "The only situation that this function would behave wrongly is when someone launches IDLE from the shell (Why would they do that?)" Which shell? I sometimes start Idle from both command line shell and python shell, for different reasons. I was already aware that pdb and Idle might not be the only things to subclass bdb (with bugs). I think the patch should be 'inverted' to only add bdb to the exclude list if idlelib/RemoteDebugger.py (or ...\...) is present in the traceback. The current code was moved from Executive.runcode 2003-05-08 by KBK. "2. run.py: move exception printing to toplevel to allow access from main()" A couple of months before, the exclude list was shorter: exclude = ("run.py", "rpc.py", "RemoteDebugger.py", "bdb.py") I did not find the reason for adding threading and queue. A little before, the exception printing code was in rpc.py. I will do more history tracing later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 06:38:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Jun 2015 04:38:13 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <20150608043810.104748.81013@psf.io> Roundup Robot added the comment: New changeset b75c600e1614 by Steve Dower in branch '3.5': Issue #8232: webbrowser support incomplete on Windows. Patch by Brandon Milam https://hg.python.org/cpython/rev/b75c600e1614 New changeset 63b6e150b635 by Steve Dower in branch 'default': Issue #8232: webbrowser support incomplete on Windows. Patch by Brandon Milam https://hg.python.org/cpython/rev/63b6e150b635 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 06:48:40 2015 From: report at bugs.python.org (Uche Ogbuji) Date: Mon, 08 Jun 2015 04:48:40 +0000 Subject: [issue17214] http.client.HTTPConnection.putrequest encode error In-Reply-To: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za> Message-ID: <1433738920.89.0.0327060520064.issue17214@psf.upfronthosting.co.za> Changes by Uche Ogbuji : ---------- nosy: +Uche Ogbuji _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 08:18:49 2015 From: report at bugs.python.org (Tal Einat) Date: Mon, 08 Jun 2015 06:18:49 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1433744329.29.0.876016035183.issue20186@psf.upfronthosting.co.za> Tal Einat added the comment: Here's another version of the _operator patch, with another small change after Serhiy's latest review. ---------- Added file: http://bugs.python.org/file39656/issue20186._operator.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 08:27:29 2015 From: report at bugs.python.org (Tal Einat) Date: Mon, 08 Jun 2015 06:27:29 +0000 Subject: [issue20346] Argument Clinic: missing entry in table mapping legacy convertors to real AC converters In-Reply-To: <1390405621.79.0.727900748758.issue20346@psf.upfronthosting.co.za> Message-ID: <1433744849.8.0.730366241879.issue20346@psf.upfronthosting.co.za> Tal Einat added the comment: This patch was applied in changeset 57a27aae7836. ---------- resolution: duplicate -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 08:42:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Jun 2015 06:42:02 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1433745722.91.0.85758480856.issue20186@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: issue20186._operator.v4.patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 09:18:11 2015 From: report at bugs.python.org (floyd) Date: Mon, 08 Jun 2015 07:18:11 +0000 Subject: [issue24384] difflib.SequenceMatcher faster quick_ratio with lower bound specification In-Reply-To: <1433448775.15.0.914528193485.issue24384@psf.upfronthosting.co.za> Message-ID: <1433747891.17.0.919557983606.issue24384@psf.upfronthosting.co.za> floyd added the comment: Agree with the separate function (especially as the return value would change from float to bool). In my experience this is one of the most often occuring use cases for difflib in practice. Another reason is that it is not obvious that the user can optimize it with the appended version. Some more opinions would be nice. If this suggestion is rejected we could include a performance warning for this use case in the docs and/or I'll write an online code recipe which can be linked to. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 09:36:44 2015 From: report at bugs.python.org (Tal Einat) Date: Mon, 08 Jun 2015 07:36:44 +0000 Subject: [issue24384] difflib.SequenceMatcher faster quick_ratio with lower bound specification In-Reply-To: <1433448775.15.0.914528193485.issue24384@psf.upfronthosting.co.za> Message-ID: <1433749004.83.0.894222659627.issue24384@psf.upfronthosting.co.za> Tal Einat added the comment: You should post this on the python-ideas mailing list if you think this should be added to the stdlib. Make sure to reference this issue if you do so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 10:21:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Jun 2015 08:21:11 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <20150608082108.11397.98021@psf.io> Roundup Robot added the comment: New changeset 19dbee688a30 by Serhiy Storchaka in branch '3.5': Issue #14373: Fixed threaded test for lru_cache(). Added new threaded test. https://hg.python.org/cpython/rev/19dbee688a30 New changeset da331f50aad4 by Serhiy Storchaka in branch 'default': Issue #14373: Fixed threaded test for lru_cache(). Added new threaded test. https://hg.python.org/cpython/rev/da331f50aad4 New changeset eff50d543c79 by Serhiy Storchaka in branch '3.5': Issue #14373: C implementation of functools.lru_cache() now can be used with https://hg.python.org/cpython/rev/eff50d543c79 New changeset f4b785d14792 by Serhiy Storchaka in branch 'default': Issue #14373: C implementation of functools.lru_cache() now can be used with https://hg.python.org/cpython/rev/f4b785d14792 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 10:36:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Jun 2015 08:36:49 +0000 Subject: [issue24299] 2.7.10 test__locale.py change breaks on Solaris In-Reply-To: <1432741411.37.0.656292350471.issue24299@psf.upfronthosting.co.za> Message-ID: <1433752609.9.0.620571925915.issue24299@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Does the patch fix the issue John? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 11:45:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Jun 2015 09:45:16 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <20150608094512.60936.96696@psf.io> Roundup Robot added the comment: New changeset c52f381fe674 by Serhiy Storchaka in branch '3.5': Issue #14373: Other attempt to fix threaded test for lru_cache(). https://hg.python.org/cpython/rev/c52f381fe674 New changeset 73acb8c187d4 by Serhiy Storchaka in branch 'default': Issue #14373: Other attempt to fix threaded test for lru_cache(). https://hg.python.org/cpython/rev/73acb8c187d4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 11:47:20 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 08 Jun 2015 09:47:20 +0000 Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for prompt In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za> Message-ID: <1433756840.79.0.897310233571.issue24402@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> needs patch versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 12:13:16 2015 From: report at bugs.python.org (Ivan Bykov) Date: Mon, 08 Jun 2015 10:13:16 +0000 Subject: [issue24390] Python 3.4.3 64 bits is not "high dpi aware" In-Reply-To: <1433582426.79.0.462452103713.issue24390@psf.upfronthosting.co.za> Message-ID: <1433758396.91.0.0521615246372.issue24390@psf.upfronthosting.co.za> Ivan Bykov added the comment: https://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).aspx#declaring_dpi_awareness true ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 12:43:29 2015 From: report at bugs.python.org (irdb) Date: Mon, 08 Jun 2015 10:43:29 +0000 Subject: [issue219960] Problems with Tcl/Tk and non-ASCII text entry Message-ID: <1433760209.33.0.218052310088.issue219960@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 13:21:15 2015 From: report at bugs.python.org (Gareth Rees) Date: Mon, 08 Jun 2015 11:21:15 +0000 Subject: [issue24405] Missing code markup in "Expressions" documentation Message-ID: <1433762475.42.0.565039564472.issue24405@psf.upfronthosting.co.za> New submission from Gareth Rees: The "Expressions" documentation contains the text: > * Sets and frozensets define comparison operators to mean subset and superset > tests. Those relations do not define total orderings (the two sets ``{1,2}`` > and {2,3} are not equal, nor subsets of one another, nor supersets of one > another). Here {2,3} should be marked up as code (like {1,2}) but is not. ---------- assignee: docs at python components: Documentation files: markup.patch keywords: patch messages: 244996 nosy: Gareth.Rees, docs at python priority: normal severity: normal status: open title: Missing code markup in "Expressions" documentation type: enhancement Added file: http://bugs.python.org/file39657/markup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 13:27:42 2015 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Mon, 08 Jun 2015 11:27:42 +0000 Subject: [issue13224] Change str(x) to return only the (qual)name for some types In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za> Message-ID: <1433762862.75.0.656491001442.issue13224@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: What's going on with this? It seems we have the patch, but discussions have just stopped - both on Python-ideas and here. The idea is great, BDFL-approved, and would simplify a lot of code, especially with new typehinting. ---------- nosy: +Vedran.?a?i? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 13:32:38 2015 From: report at bugs.python.org (Gareth Rees) Date: Mon, 08 Jun 2015 11:32:38 +0000 Subject: [issue24406] "Bulit-in Types" documentation doesn't explain how dictionaries are compared for equality Message-ID: <1433763158.1.0.945531416377.issue24406@psf.upfronthosting.co.za> New submission from Gareth Rees: The "Built-in Types" section of the library documentation does not explain how two dictionaries are compared for equality. The place where this is documented is under "Comparisons" in the Language Reference: > Mappings (dictionaries) compare equal if and only if they have the same (key, value) pairs. but it is not obvious from the section on dictionaries in "Built-in Types" that this is where to look. (Contrast with the situation for sequences and sets, where "Built-in Types" does explain how these objects are compared for equality.) I suggest that the "Built-in Types" section should explain how two dictionaries are tested for equality. ---------- assignee: docs at python components: Documentation files: dict-equality.patch keywords: patch messages: 244998 nosy: Gareth.Rees, docs at python priority: normal severity: normal status: open title: "Bulit-in Types" documentation doesn't explain how dictionaries are compared for equality type: enhancement Added file: http://bugs.python.org/file39658/dict-equality.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 13:33:51 2015 From: report at bugs.python.org (Gareth Rees) Date: Mon, 08 Jun 2015 11:33:51 +0000 Subject: [issue24406] "Built-in Types" documentation doesn't explain how dictionaries are compared for equality In-Reply-To: <1433763158.1.0.945531416377.issue24406@psf.upfronthosting.co.za> Message-ID: <1433763231.2.0.0419220288096.issue24406@psf.upfronthosting.co.za> Changes by Gareth Rees : ---------- title: "Bulit-in Types" documentation doesn't explain how dictionaries are compared for equality -> "Built-in Types" documentation doesn't explain how dictionaries are compared for equality _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 13:40:20 2015 From: report at bugs.python.org (ppperry) Date: Mon, 08 Jun 2015 11:40:20 +0000 Subject: [issue24252] IDLE removes elements from tracebacks. In-Reply-To: <1432169048.6.0.710293421877.issue24252@psf.upfronthosting.co.za> Message-ID: <1433763620.92.0.270582195051.issue24252@psf.upfronthosting.co.za> ppperry added the comment: Your proposed patch does not work in its current form on my IDLE, but it does if I change tr[0][:-6] to tr[0][-6:] in the pdb checking code. Additionally, my proposed cleanup function did distinguish the difference between the unix and windows directory seperators by using os.path.dirname. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 13:41:35 2015 From: report at bugs.python.org (ppperry) Date: Mon, 08 Jun 2015 11:41:35 +0000 Subject: [issue24252] IDLE removes elements from tracebacks. In-Reply-To: <1432169048.6.0.710293421877.issue24252@psf.upfronthosting.co.za> Message-ID: <1433763695.73.0.945902412841.issue24252@psf.upfronthosting.co.za> ppperry added the comment: I mean if someone starts a new copy of idle from within the IDLE python shell itself by "The only situation that this function would behave wrongly is when someone launches IDLE from the shell (Why would they do that?)". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 13:57:05 2015 From: report at bugs.python.org (paul) Date: Mon, 08 Jun 2015 11:57:05 +0000 Subject: [issue24407] Use after free in PyDict_merge Message-ID: <1433764625.15.0.894965258929.issue24407@psf.upfronthosting.co.za> New submission from paul: # PyDict_Merge: # # 1 for (i = 0, n = DK_SIZE(other->ma_keys); i < n; i++) { # ... # 3 entry = &other->ma_keys->dk_entries[i]; # ... # 2 if (insertdict(mp, entry->me_key, # entry->me_hash, # value) != 0) # return -1; # ... # } # # 1. n is set once # 2. it's possible to run a custom __eq__ method from inside the insertdict. # __eq__ clears the "other" dict. "n" variables is now out of date # 3. out of bounds read # # CRASH: # ------ # # * thread #1: tid = 27715, 0x080d1c1d python`insertdict(mp=0xb71d66f4, key=0x61682044, hash=543582496, value=0xb71d6664) + 132 at dictobject.c:819, name = 'python', stop reason = invalid address (fault address: 0x61682050) # frame #0: 0x080d1c1d python`insertdict(mp=0xb71d66f4, key=0x61682044, hash=543582496, value=0xb71d6664) + 132 at dictobject.c:819 # 816 if (ep == NULL) { # 817 return -1; # 818 } # -> 819 assert(PyUnicode_CheckExact(key) || mp->ma_keys->dk_lookup == lookdict); # 820 Py_INCREF(value); # 821 MAINTAIN_TRACKING(mp, key, value); # 822 old_value = *value_addr; # ---------- files: dict_merge.py messages: 245001 nosy: pkt priority: normal severity: normal status: open title: Use after free in PyDict_merge type: crash versions: Python 3.5 Added file: http://bugs.python.org/file39659/dict_merge.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 14:25:56 2015 From: report at bugs.python.org (John Beck) Date: Mon, 08 Jun 2015 12:25:56 +0000 Subject: [issue24299] 2.7.10 test__locale.py change breaks on Solaris In-Reply-To: <1432741411.37.0.656292350471.issue24299@psf.upfronthosting.co.za> Message-ID: <1433766356.9.0.175894934687.issue24299@psf.upfronthosting.co.za> John Beck added the comment: (Apologies for not responding on May 27 when you posted the patch; I failed to notice the "Added file:" line in the e-mail notification.) Yes! The patch you posted fixes the issue. Thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 15:22:17 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 08 Jun 2015 13:22:17 +0000 Subject: [issue24408] tkinter.font.Font.measure() broken in 3.5 Message-ID: <1433769737.94.0.512429608997.issue24408@psf.upfronthosting.co.za> New submission from Martin Panter: >>> import tkinter, tkinter.font >>> tk = tkinter.Tk() >>> tkinter.font.nametofont("TkHeadingFont").measure("string") Traceback (most recent call last): File "", line 1, in File "/home/proj/python/cpython/Lib/tkinter/font.py", line 154, in measure return self._root.tk.getint(self._call("font", "measure", self.name, *args)) AttributeError: 'Font' object has no attribute '_root' This appears to be broken by revision cb80dd82d3da, Issue 23880, which included this change at the end of the measure() method: -return int(self._call("font", "measure", self.name, *args)) +return self._root.tk.getint(self._call("font", "measure", self.name, *args)) The Font class does not have a ?_root? attribute. ---------- components: Tkinter messages: 245003 nosy: serhiy.storchaka, vadmium priority: normal severity: normal stage: needs patch status: open title: tkinter.font.Font.measure() broken in 3.5 type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 16:20:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Jun 2015 14:20:48 +0000 Subject: [issue24407] Use after free in PyDict_merge In-Reply-To: <1433764625.15.0.894965258929.issue24407@psf.upfronthosting.co.za> Message-ID: <1433773248.01.0.920492091657.issue24407@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Interpreter Core nosy: +rhettinger, serhiy.storchaka stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 16:31:54 2015 From: report at bugs.python.org (Brian Quinlan) Date: Mon, 08 Jun 2015 14:31:54 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1433773913.99.0.934479897228.issue24195@psf.upfronthosting.co.za> Brian Quinlan added the comment: Actually it immediately converts the iterable into a list. Recall: def filter(self, fn, iterable, timeout=None): l = list(iterable) # iterable => list return (item for (item, keep) in zip(l, self.map(fn, l, timeout)) if keep) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 17:29:46 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 08 Jun 2015 15:29:46 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433777386.87.0.450423600951.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: I think that the only proper way to solve this is to make coroutines a separate type. I've actually prototyped that before: https://github.com/1st1/cpython/commit/a3f1059590f496bf77b33edb023c8cdbc1d30798 ---------- assignee: -> yselivanov components: +Interpreter Core nosy: +ncoghlan versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 17:38:37 2015 From: report at bugs.python.org (nivin) Date: Mon, 08 Jun 2015 15:38:37 +0000 Subject: [issue24409] PythonPROD abrt Message-ID: <1433777917.0.0.0137238616785.issue24409@psf.upfronthosting.co.za> New submission from nivin: There is a cronjob running in every 3 minutes.For One or two days this works properly. After that Mysql service get crashed.Bulk data is inserted into database using the service . Following errors found in /var/log/messages (OS : RHEL 6) Jun 6 13:27:02 PythonPROD abrt: detected unhandled Python exception in '/var/www/html/CrossCDR/Cronjobs/cdrcollector/CdrCollector.py' Jun 6 13:27:02 PythonPROD abrtd: New client connected Jun 6 13:27:02 PythonPROD abrtd: Directory 'pyhook-2015-06-06-13:27:02-1796' creation detected Jun 6 13:27:02 PythonPROD abrt-server[1800]: Saved Python crash dump of pid 1796 to /var/spool/abrt/pyhook-2015-06-06-13:27:02-1796 Jun 6 13:27:07 PythonPROD kernel: Bridge firewalling registered Jun 6 13:28:07 PythonPROD abrtd: Sending an email... Jun 6 13:28:07 PythonPROD abrtd: Email was sent to: root at localhost Jun 6 13:28:07 PythonPROD abrtd: Duplicate: UUID Jun 6 13:28:07 PythonPROD abrtd: DUP_OF_DIR: /var/spool/abrt/pyhook-2015-06-04-00:48:02-1797 Jun 6 13:28:07 PythonPROD abrtd: Deleting problem directory pyhook-2015-06-06-13:27:02-1796 (dup of pyhook-2015-06-04-00:48:02-1797) Jun 6 13:28:07 PythonPROD abrtd: No actions are found for event 'notify-dup' ---------- messages: 245006 nosy: nivin priority: normal severity: normal status: open title: PythonPROD abrt type: crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 17:44:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Jun 2015 15:44:07 +0000 Subject: [issue24408] tkinter.font.Font.measure() broken in 3.5 In-Reply-To: <1433769737.94.0.512429608997.issue24408@psf.upfronthosting.co.za> Message-ID: <1433778247.49.0.984855817824.issue24408@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 17:44:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Jun 2015 15:44:58 +0000 Subject: [issue24408] tkinter.font.Font.measure() broken in 3.5 In-Reply-To: <1433769737.94.0.512429608997.issue24408@psf.upfronthosting.co.za> Message-ID: <20150608154450.1484.12872@psf.io> Roundup Robot added the comment: New changeset fb05c1355a90 by Serhiy Storchaka in branch '3.5': Issue #24408: Fixed AttributeError in measure() and metrics() methods of https://hg.python.org/cpython/rev/fb05c1355a90 New changeset 0dd70c2c44b4 by Serhiy Storchaka in branch 'default': Issue #24408: Fixed AttributeError in measure() and metrics() methods of https://hg.python.org/cpython/rev/0dd70c2c44b4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 17:46:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Jun 2015 15:46:59 +0000 Subject: [issue24408] tkinter.font.Font.measure() broken in 3.5 In-Reply-To: <1433769737.94.0.512429608997.issue24408@psf.upfronthosting.co.za> Message-ID: <1433778419.19.0.438516792733.issue24408@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your report Martin. Unfortunately tests for tkinter.Font are almost not existing. Here is a patch that adds more tests (it should be applied to all versions). ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file39660/tkinter_test_font.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 17:50:47 2015 From: report at bugs.python.org (Steve Zelaznik) Date: Mon, 08 Jun 2015 15:50:47 +0000 Subject: [issue24410] set.__eq__ returns False when it should return NotImplemented Message-ID: <1433778647.83.0.662569129582.issue24410@psf.upfronthosting.co.za> New submission from Steve Zelaznik: [in] >>> d = {'x':3,'y':4,'z':5} [in] >>> set(d.items()) == d.viewitems() [out] >>> False [in] >>> d.viewitems() == set(d.items()) [out] >>> True [in] >>> set(d.items()).__eq__(d.viewitems()) [out] >>> False The last line should return NotImplemented rather than False. This problem seems to have been addressed in Python3. ---------- components: Build messages: 245009 nosy: zelaznik priority: normal severity: normal status: open title: set.__eq__ returns False when it should return NotImplemented type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 17:50:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Jun 2015 15:50:54 +0000 Subject: [issue24299] 2.7.10 test__locale.py change breaks on Solaris In-Reply-To: <1432741411.37.0.656292350471.issue24299@psf.upfronthosting.co.za> Message-ID: <20150608155051.17693.57948@psf.io> Roundup Robot added the comment: New changeset 00f8804f559c by Serhiy Storchaka in branch '2.7': Issue #24299: Fixed test__locale on Solaris. https://hg.python.org/cpython/rev/00f8804f559c New changeset da642b5aaf79 by Serhiy Storchaka in branch '3.4': Issue #24299: Fixed test__locale on Solaris. https://hg.python.org/cpython/rev/da642b5aaf79 New changeset 0a1f1988fece by Serhiy Storchaka in branch '3.5': Issue #24299: Fixed test__locale on Solaris. https://hg.python.org/cpython/rev/0a1f1988fece New changeset 30d8b5b62245 by Serhiy Storchaka in branch 'default': Issue #24299: Fixed test__locale on Solaris. https://hg.python.org/cpython/rev/30d8b5b62245 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 17:51:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Jun 2015 15:51:52 +0000 Subject: [issue24410] set.__eq__ returns False when it should return NotImplemented In-Reply-To: <1433778647.83.0.662569129582.issue24410@psf.upfronthosting.co.za> Message-ID: <1433778712.29.0.837409938158.issue24410@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +rhettinger, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 17:52:22 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 08 Jun 2015 15:52:22 +0000 Subject: [issue13224] Change str(x) to return only the qualname for some types In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za> Message-ID: <1433778742.21.0.0632975406192.issue13224@psf.upfronthosting.co.za> ?ric Araujo added the comment: I am no longer an active core contributor. Someone should take this and apply it for the next version. ---------- assignee: eric.araujo -> stage: patch review -> commit review title: Change str(x) to return only the (qual)name for some types -> Change str(x) to return only the qualname for some types versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 17:56:24 2015 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 08 Jun 2015 15:56:24 +0000 Subject: [issue24409] PythonPROD abrt In-Reply-To: <1433777917.0.0.0137238616785.issue24409@psf.upfronthosting.co.za> Message-ID: <1433778984.12.0.509674911094.issue24409@psf.upfronthosting.co.za> Eric V. Smith added the comment: This doesn't appear to be a bug with Python, but rather with CrossCDR. If you can provide more information (such as a stacktrace, or a reproducible test using just Python's standard library), then please re-open this issue. ---------- nosy: +eric.smith resolution: -> not a bug stage: -> resolved status: open -> closed type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 17:56:26 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 08 Jun 2015 15:56:26 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433778986.86.0.000101168103902.issue24400@psf.upfronthosting.co.za> Stefan Behnel added the comment: I agree that the "extra bit" is a quirk. Ideally, Coroutine and Generator would share a common base class that has "send", "throw" and "close". Additionally, a Coroutine would be an Awaitable whereas a Generator is an Iterator. The internal implementation of generators and coroutines would (or at least, could) then follow by splitting them into separate types. The tricky bridge between the two is the types.coroutine() decorator, which is intended to say "this Generator is a Coroutine", i.e. it turns a Generator into an Awaitable Generator. As the current implementation shows, however, this can also be done without the internal flag. All this needs is a wrapper, and that could be implemented in C to make it fast and even special cased to further speed it up. In a way, the current implementation focusses on runtime optimisation, not on a clean design. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 17:58:57 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 08 Jun 2015 15:58:57 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433779137.15.0.696145935267.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: I'll have a patch soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 18:12:34 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 08 Jun 2015 16:12:34 +0000 Subject: [issue24385] libpython.a does not work for all MinGW forks In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433779954.94.0.285161057003.issue24385@psf.upfronthosting.co.za> Steve Dower added the comment: The fix for issue23199 "broke" 32-bit mingw because nobody agrees which fork of mingw should be supported. Before the next releases I intend to remove the lib completely and add a "libpython.txt" file in its place with commands or tools to try for generating the file with the fork/version you are currently using. Thanks for the info. @mrabarnett: are the `-L"C:\Python35" -lpython35` flags the ones that link to the DLL? (i.e. -L == search path, -l == link-to, and C:\Python35\python35.dll is the DLL) ---------- title: libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects -> libpython.a does not work for all MinGW forks versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 18:39:08 2015 From: report at bugs.python.org (Ethan Furman) Date: Mon, 08 Jun 2015 16:39:08 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1433781548.64.0.934978963419.issue24195@psf.upfronthosting.co.za> Ethan Furman added the comment: The recipe will work in simple situations. In more complex situations: - infinite iterator - really large iterator (millions of items) - high work load to produce next iteration the recipe will either have a severe impact on performance or fail entirely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 18:44:05 2015 From: report at bugs.python.org (Ram Rachum) Date: Mon, 08 Jun 2015 16:44:05 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1433781845.88.0.727517283866.issue24195@psf.upfronthosting.co.za> Ram Rachum added the comment: Ethan: That's what I also thought, but then I figured that you're creating N futures anyway with an item attached to each, so it's on the same scale as creating a list, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 18:48:13 2015 From: report at bugs.python.org (Benjamin Gilbert) Date: Mon, 08 Jun 2015 16:48:13 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433782093.61.0.650771511176.issue24385@psf.upfronthosting.co.za> Benjamin Gilbert added the comment: Steve, I don't think that's the right characterization of this bug. Putting 64-bit .o files in a 32-bit import library seems wrong for both MinGW and MinGW-w64. msg244874 says that if you use the dlltool from the *32-bit* MinGW-w64 to build the 32-bit import library, the problem does not occur. msg244875 says that you can even use the 64-bit MinGW-w64 dlltool by passing one additional command-line option. Why not pursue one of those solutions? ---------- title: libpython.a does not work for all MinGW forks -> libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 18:52:52 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 08 Jun 2015 16:52:52 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433782372.89.0.476981648542.issue24385@psf.upfronthosting.co.za> Steve Dower added the comment: Ah, I misread msg244875 and thought it was still requiring different tools. I'll add that option in for the next release then, and if there are still issues I'll come back to removing the libraries. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 18:56:21 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Jun 2015 16:56:21 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <20150608165618.60934.46023@psf.io> Roundup Robot added the comment: New changeset e4cde2f928fe by Steve Dower in branch '3.5': Issue 24385: Adds "--as-flags=--32" when generating 32-bit MinGW library. https://hg.python.org/cpython/rev/e4cde2f928fe New changeset 5fa77372e675 by Steve Dower in branch 'default': Issue 24385: Adds "--as-flags=--32" when generating 32-bit MinGW library. https://hg.python.org/cpython/rev/5fa77372e675 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 18:57:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Jun 2015 16:57:19 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <20150608165718.1463.75268@psf.io> Roundup Robot added the comment: New changeset 686f9a607b98 by Steve Dower in branch '2.7': Issue 24385: Adds "--as-flags=--32" when generating 32-bit MinGW library. https://hg.python.org/cpython/rev/686f9a607b98 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 18:58:03 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 08 Jun 2015 16:58:03 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433782683.94.0.672776910029.issue24385@psf.upfronthosting.co.za> Zachary Ware added the comment: If I'm not mistaken, if you're building an extension with some flavor of MinGW, you've got the tools to build the lib yourself, right? It strikes me as being much more reliable to provide hints towards how to do it yourself than to provide a binary for something that's only marginally supported anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 19:04:55 2015 From: report at bugs.python.org (Matthew Barnett) Date: Mon, 08 Jun 2015 17:04:55 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433783095.22.0.564870097839.issue24385@psf.upfronthosting.co.za> Matthew Barnett added the comment: @steve.dower: Yes. For Python 35, it appears that it'll link to libpython??.a or python??.dll, whichever it finds in the given folder, so it doesn't actually need libpython??.a anymore. Which is nice. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 19:07:58 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 08 Jun 2015 17:07:58 +0000 Subject: [issue24410] set.__eq__ returns False when it should return NotImplemented In-Reply-To: <1433778647.83.0.662569129582.issue24410@psf.upfronthosting.co.za> Message-ID: <1433783278.65.0.358899435337.issue24410@psf.upfronthosting.co.za> R. David Murray added the comment: See issue 21408 for the fix, which was indeed not applied to 2.7. Now we get to decide if it should be :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 19:10:15 2015 From: report at bugs.python.org (Ethan Furman) Date: Mon, 08 Jun 2015 17:10:15 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1433783415.87.0.702064824066.issue24195@psf.upfronthosting.co.za> Ethan Furman added the comment: The recipe creates a list before it ever starts processing, while Executor.filter() starts processing with the first item. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 19:11:33 2015 From: report at bugs.python.org (Ram Rachum) Date: Mon, 08 Jun 2015 17:11:33 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1433783493.7.0.695783215537.issue24195@psf.upfronthosting.co.za> Ram Rachum added the comment: Right, so it might be garbage-collecting the items before the futures are done being created, so the whole list wouldn't need to be saved in memory. I understand now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 19:15:24 2015 From: report at bugs.python.org (Benjamin Gilbert) Date: Mon, 08 Jun 2015 17:15:24 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433783724.45.0.941648594368.issue24385@psf.upfronthosting.co.za> Benjamin Gilbert added the comment: Zachary: gendef is an auxiliary tool; I'm not sure a basic installation of MinGW-w64 will have it. However, I've checked Cygwin and Fedora (my two points of reference) and a gendef package is available in both. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 19:29:57 2015 From: report at bugs.python.org (Paul Moore) Date: Mon, 08 Jun 2015 17:29:57 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433784597.68.0.44841113854.issue24385@psf.upfronthosting.co.za> Paul Moore added the comment: I'm still somewhat confused as to why we're looking at this in the context of manually building an extension. It's *certainly* true that anyone attempting to build a Python extension by hand (as per Matthew Barnett's instructions) should be able and willing to build the import libraries by hand. On the other hand, I've no *objection* to shipping the .a files (and I agree 100% that shipping a 64-bit library in a 32-bit installer is a bug). But if we do so, then we should be shipping whatever makes setup.py build_ext --compiler=mingw (i.e. distutils) happy. Distutils is the only way of building extensions that I think we should support (whether via shipping .a files, or in terms of how we handle any other bug reports). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 20:15:24 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_Buira?=) Date: Mon, 08 Jun 2015 18:15:24 +0000 Subject: [issue24397] Test asynchat makes wrong assumptions In-Reply-To: <1433611943.2.0.834798500483.issue24397@psf.upfronthosting.co.za> Message-ID: <1433787324.55.0.563550150996.issue24397@psf.upfronthosting.co.za> Changes by ?tienne Buira : Removed file: http://bugs.python.org/file39643/test_asynchat_check_received_len_if_received_len_matters.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 20:15:29 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 08 Jun 2015 18:15:29 +0000 Subject: [issue24411] Drop redundant lock in queue.Queue methods qsize(), empty() and full() Message-ID: <1433787329.63.0.683771277735.issue24411@psf.upfronthosting.co.za> New submission from Andrew Svetlov: Now those methods use lock for querying queue size, like def qsize(self): with self.mutex: return self._qsize() The lock is not necessary because thread context switch may be done *after* returning from mutex protected code but *before* getting result by calling side. All three methods (qsize(), empty() and full()) gives *approximated value*, so getting rid of lock doesn't make it less stringent. ---------- components: Library (Lib) messages: 245029 nosy: asvetlov priority: low severity: normal status: open title: Drop redundant lock in queue.Queue methods qsize(), empty() and full() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 20:15:46 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 08 Jun 2015 18:15:46 +0000 Subject: [issue24411] Drop redundant lock in queue.Queue methods qsize(), empty() and full() In-Reply-To: <1433787329.63.0.683771277735.issue24411@psf.upfronthosting.co.za> Message-ID: <1433787346.04.0.581792152345.issue24411@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 20:29:48 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 08 Jun 2015 18:29:48 +0000 Subject: [issue24411] Drop redundant lock in queue.Queue methods qsize(), empty() and full() In-Reply-To: <1433787329.63.0.683771277735.issue24411@psf.upfronthosting.co.za> Message-ID: <1433788188.08.0.702672310954.issue24411@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 20:31:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Jun 2015 18:31:10 +0000 Subject: [issue24299] 2.7.10 test__locale.py change breaks on Solaris In-Reply-To: <1432741411.37.0.656292350471.issue24299@psf.upfronthosting.co.za> Message-ID: <1433788270.05.0.337347960536.issue24299@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 20:31:39 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 08 Jun 2015 18:31:39 +0000 Subject: [issue24412] setUpClass equivalent for addCleanup Message-ID: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za> New submission from R. David Murray: Since tearDownClass isn't run if setUpClass fails, there is a need for the class level equivalent of addCleanup. addClassCleanup? ---------- components: Library (Lib) messages: 245030 nosy: ezio.melotti, michael.foord, r.david.murray, rbcollins priority: normal severity: normal stage: needs patch status: open title: setUpClass equivalent for addCleanup type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 20:37:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Jun 2015 18:37:48 +0000 Subject: [issue13224] Change str(x) to return only the qualname for some types In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za> Message-ID: <1433788668.08.0.720378871411.issue13224@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Other discussion: http://comments.gmane.org/gmane.comp.python.ideas/32192 . ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 20:47:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Jun 2015 18:47:33 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1433789253.95.0.114309999306.issue24120@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm not sure that Path.(r)glob() (and perhaps glob.glob()) should unconditionally ignore errors. Python has lover level than shell, and even bash has an option that controls this behavior. failglob If set, patterns which fail to match filenames during pathname expansion result in an expansion error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 20:52:50 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 08 Jun 2015 18:52:50 +0000 Subject: [issue24412] setUpClass equivalent for addCleanup In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za> Message-ID: <1433789570.33.0.416318910928.issue24412@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 21:00:41 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_Buira?=) Date: Mon, 08 Jun 2015 19:00:41 +0000 Subject: [issue24397] Test asynchat makes wrong assumptions In-Reply-To: <1433611943.2.0.834798500483.issue24397@psf.upfronthosting.co.za> Message-ID: <1433790041.71.0.643916763188.issue24397@psf.upfronthosting.co.za> ?tienne Buira added the comment: That would just race the other way around. However, I missed the fact that the check of client's contents had no chance to catch an issue, as the main thread were not entering asyncore.loop after allowing the server to send. Updated patch (against 3.3) follows (dunno why, file were not attachable). diff -r 035aa81c2ba8 Lib/test/test_asynchat.py --- a/Lib/test/test_asynchat.py Tue Jun 02 18:53:46 2015 -0400 +++ b/Lib/test/test_asynchat.py Mon Jun 08 20:14:27 2015 +0200 @@ -30,6 +30,7 @@ # This will be set if the client wants us to wait before echoing data # back. self.start_resend_event = None + self.received_len = 0 def run(self): self.sock.listen(1) @@ -41,6 +42,7 @@ data = conn.recv(1) if not data: break + self.received_len += len(data) self.buffer = self.buffer + data # remove the SERVER_QUIT message @@ -226,13 +228,14 @@ # where the server echoes all of its data before we can check that it # got any down below. s.start_resend_event.set() + asyncore.loop(use_poll=self.usepoll, count=300, timeout=.01) s.join() - self.assertEqual(c.contents, []) + self.assertEqual(len(c.contents), 0) # the server might have been able to send a byte or two back, but this # at least checks that it received something and didn't just fail # (which could still result in the client not having received anything) - self.assertGreater(len(s.buffer), 0) + self.assertGreater(s.received_len, 0) class TestAsynchat_WithPoll(TestAsynchat): ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 21:13:27 2015 From: report at bugs.python.org (Ethan Furman) Date: Mon, 08 Jun 2015 19:13:27 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1433790807.93.0.364170476752.issue24120@psf.upfronthosting.co.za> Ethan Furman added the comment: Failing to find any matches with a pattern is an entirely different class of error than finding matches but hitting permission problems or broken links or suddenly deleted files or ... If glob doesn't already have a 'failglob' option we could add that, but in a different issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 22:51:28 2015 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 08 Jun 2015 20:51:28 +0000 Subject: [issue24324] Remove -Wunreachable-code flag In-Reply-To: <1432907477.51.0.798249204562.issue24324@psf.upfronthosting.co.za> Message-ID: <1433796688.6.0.942102986774.issue24324@psf.upfronthosting.co.za> Skip Montanaro added the comment: I guess this is an autoconf thing. "@BASECFLAGS@" in Makefile.pre.in seems to expand to "-Wsign-compare -Wunreachable-code" in Makefile.pre. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 23:04:25 2015 From: report at bugs.python.org (Richard Futrell) Date: Mon, 08 Jun 2015 21:04:25 +0000 Subject: [issue24413] Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) raises NotImplementedError, but {}.keys().__or__(x) raises TypeError Message-ID: <1433797465.6.0.816569551411.issue24413@psf.upfronthosting.co.za> Changes by Richard Futrell : ---------- nosy: canjo priority: normal severity: normal status: open title: Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) raises NotImplementedError, but {}.keys().__or__(x) raises TypeError type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 23:11:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Jun 2015 21:11:49 +0000 Subject: [issue23891] Tutorial doesn't mention either pip or virtualenv In-Reply-To: <1428521410.44.0.984619918633.issue23891@psf.upfronthosting.co.za> Message-ID: <20150608211146.12091.21328@psf.io> Roundup Robot added the comment: New changeset a18615eb5aec by Andrew Kuchling in branch '3.4': #23891: describe a few more modules in the tutorial https://hg.python.org/cpython/rev/a18615eb5aec New changeset cffb6ac2bbe4 by Andrew Kuchling in branch '3.4': #23891: rework discussion of python-list a bit https://hg.python.org/cpython/rev/cffb6ac2bbe4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 23:39:20 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Jun 2015 21:39:20 +0000 Subject: [issue23891] Tutorial doesn't mention either pip or virtualenv In-Reply-To: <1428521410.44.0.984619918633.issue23891@psf.upfronthosting.co.za> Message-ID: <20150608213916.60948.81748@psf.io> Roundup Robot added the comment: New changeset 15ee0e7078e3 by Andrew Kuchling in branch '3.4': #23891: add a section to the Tutorial describing virtual environments and pip https://hg.python.org/cpython/rev/15ee0e7078e3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 23:44:11 2015 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 08 Jun 2015 21:44:11 +0000 Subject: [issue23891] Tutorial doesn't mention either pip or virtualenv In-Reply-To: <1428521410.44.0.984619918633.issue23891@psf.upfronthosting.co.za> Message-ID: <1433799851.31.0.123259470236.issue23891@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 23:44:34 2015 From: report at bugs.python.org (debohman) Date: Mon, 08 Jun 2015 21:44:34 +0000 Subject: [issue24414] MACOSX_DEPLOYMENT_TARGET set incorrectly by configure Message-ID: <1433799874.27.0.587161975864.issue24414@psf.upfronthosting.co.za> New submission from debohman: MACOSX_DEPLOYMENT_TARGET is not set correctly when building the 2.7.10 sources. This causes readline to not be included in the build. This appears to already be fixed in 3.4.3. I picked up the change to configure.ac from 3.4.3 and it resolved the problem. I am building on 10.9.5. In my case MACOSX_DEPLOYMENT_TARGET was chosen as 10.4. The configuration options I am using are: ./configure --enable-shared Attaching diffs. ---------- components: Build files: configure.ac_diffs.txt messages: 245038 nosy: debohman priority: normal severity: normal status: open title: MACOSX_DEPLOYMENT_TARGET set incorrectly by configure type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file39661/configure.ac_diffs.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 23:47:29 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Jun 2015 21:47:29 +0000 Subject: [issue24414] MACOSX_DEPLOYMENT_TARGET set incorrectly by configure In-Reply-To: <1433799874.27.0.587161975864.issue24414@psf.upfronthosting.co.za> Message-ID: <1433800049.92.0.763956259028.issue24414@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- assignee: -> ned.deily components: +Macintosh nosy: +ned.deily, ronaldoussoren type: compile error -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 8 23:55:52 2015 From: report at bugs.python.org (Tal Einat) Date: Mon, 08 Jun 2015 21:55:52 +0000 Subject: [issue23891] Tutorial doesn't mention either pip or virtualenv In-Reply-To: <1428521410.44.0.984619918633.issue23891@psf.upfronthosting.co.za> Message-ID: <1433800552.25.0.0177660694851.issue23891@psf.upfronthosting.co.za> Tal Einat added the comment: There is a dangling "If you" at the end of the 3rd paragraph under "Creating Virtual Environments". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 00:17:47 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Jun 2015 22:17:47 +0000 Subject: [issue23891] Tutorial doesn't mention either pip or virtualenv In-Reply-To: <1428521410.44.0.984619918633.issue23891@psf.upfronthosting.co.za> Message-ID: <20150608221743.60936.98691@psf.io> Roundup Robot added the comment: New changeset feae7fa3bb70 by Andrew Kuchling in branch '3.4': #23891: remove extra words https://hg.python.org/cpython/rev/feae7fa3bb70 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 00:40:47 2015 From: report at bugs.python.org (Steve Zelaznik) Date: Mon, 08 Jun 2015 22:40:47 +0000 Subject: [issue24410] set.__eq__ returns False when it should return NotImplemented In-Reply-To: <1433783278.65.0.358899435337.issue24410@psf.upfronthosting.co.za> Message-ID: Steve Zelaznik added the comment: On second thought, it looks like somebody may have caught the problem at or before Python 2.7.9. My PC at work has 2.7.6 which is where I spotted the problem. My mac at home has 2.7.9 where it worked fine. Steve Zelaznik 410.375.8414 Sent from either an iPhone or an Android > On Jun 8, 2015, at 1:07 PM, R. David Murray wrote: > > > R. David Murray added the comment: > > See issue 21408 for the fix, which was indeed not applied to 2.7. Now we get to decide if it should be :) > > ---------- > nosy: +r.david.murray > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 01:00:43 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 08 Jun 2015 23:00:43 +0000 Subject: [issue24413] Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) raises NotImplementedError, but {}.keys().__or__(x) raises TypeError Message-ID: <1433804443.38.0.273764414082.issue24413@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 01:13:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Jun 2015 23:13:37 +0000 Subject: [issue24410] set.__eq__ returns False when it should return NotImplemented In-Reply-To: <1433778647.83.0.662569129582.issue24410@psf.upfronthosting.co.za> Message-ID: <1433805217.63.0.610642150207.issue24410@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 05:46:34 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 09 Jun 2015 03:46:34 +0000 Subject: [issue24408] tkinter.font.Font.measure() broken in 3.5 In-Reply-To: <1433769737.94.0.512429608997.issue24408@psf.upfronthosting.co.za> Message-ID: <1433821594.88.0.830460449983.issue24408@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the prompt fix! The patch with the tests looks good. I left a query about the existing code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 06:22:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 09 Jun 2015 04:22:03 +0000 Subject: [issue24408] tkinter.font.Font.measure() broken in 3.5 In-Reply-To: <1433769737.94.0.512429608997.issue24408@psf.upfronthosting.co.za> Message-ID: <20150609042200.33388.32300@psf.io> Roundup Robot added the comment: New changeset 7e2a7f3fecdf by Serhiy Storchaka in branch '3.4': Issue #24408: Added more tkinter.Font tests. https://hg.python.org/cpython/rev/7e2a7f3fecdf New changeset 24bb564469b4 by Serhiy Storchaka in branch '3.5': Issue #24408: Added more tkinter.Font tests. https://hg.python.org/cpython/rev/24bb564469b4 New changeset 47f321ec69dc by Serhiy Storchaka in branch 'default': Issue #24408: Added more tkinter.Font tests. https://hg.python.org/cpython/rev/47f321ec69dc New changeset ae1bc5b65e65 by Serhiy Storchaka in branch '2.7': Issue #24408: Added more tkinter.Font tests. https://hg.python.org/cpython/rev/ae1bc5b65e65 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 06:28:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Jun 2015 04:28:02 +0000 Subject: [issue24408] tkinter.font.Font.measure() broken in 3.5 In-Reply-To: <1433769737.94.0.512429608997.issue24408@psf.upfronthosting.co.za> Message-ID: <1433824082.09.0.199721144007.issue24408@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 07:32:57 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Jun 2015 05:32:57 +0000 Subject: [issue24413] Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) raises NotImplementedError, but {}.keys().__or__(x) raises TypeError Message-ID: <1433827977.01.0.296186023212.issue24413@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The dictviews_or() function in Objects/dictobject.c is converting the keys to a set and calling the set.update() method with the given argument. The set.update() method doesn't return NotImplemented because it has no reflected operation. It looks like dictviews_or() should instead call set.__or__() to allow it a chance to return NotImplemented. The other dictview set operations are similarly afflicted. ---------- priority: normal -> low versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 07:33:41 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Jun 2015 05:33:41 +0000 Subject: [issue24411] Drop redundant lock in queue.Queue methods qsize(), empty() and full() In-Reply-To: <1433787329.63.0.683771277735.issue24411@psf.upfronthosting.co.za> Message-ID: <1433828021.45.0.802728804891.issue24411@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 07:38:30 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Jun 2015 05:38:30 +0000 Subject: [issue24411] Drop redundant lock in queue.Queue methods qsize(), empty() and full() In-Reply-To: <1433787329.63.0.683771277735.issue24411@psf.upfronthosting.co.za> Message-ID: <1433828310.65.0.246458435501.issue24411@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It may seem pointless to hold the lock, but it is guaranteed behavior (and has been so for a very, very long time). ''' # Override these methods to implement other queue organizations # (e.g. stack or priority queue). # These will only be called with appropriate locks held # Initialize the queue representation def _init(self, maxsize): self.queue = deque() def _qsize(self): return len(self.queue) # Put a new item in the queue def _put(self, item): self.queue.append(item) # Get an item from the queue def _get(self): return self.queue.popleft() ''' ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 08:06:16 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Jun 2015 06:06:16 +0000 Subject: [issue24413] Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) raises NotImplementedError, but {}.keys().__or__(x) raises TypeError In-Reply-To: <1433827977.01.0.296186023212.issue24413@psf.upfronthosting.co.za> Message-ID: <1433829976.69.0.560692636578.issue24413@psf.upfronthosting.co.za> Raymond Hettinger added the comment: One other thought: Returning NotImplemented may be an easy change but it isn't clear that it would provide a sensible capability for mapping views. The non-iterable *other* argument would need to have a __ror__() method than could do something useful with a KeysView or ItemsView argument. That seems like an improbable use case (which is why I presume this has never come up before). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 08:09:15 2015 From: report at bugs.python.org (Piotr Dobrogost) Date: Tue, 09 Jun 2015 06:09:15 +0000 Subject: [issue9427] logging.error('...', exc_info=True) should display upper frames, too In-Reply-To: <1280489148.4.0.967800282636.issue9427@psf.upfronthosting.co.za> Message-ID: <1433830155.62.0.658456817902.issue9427@psf.upfronthosting.co.za> Changes by Piotr Dobrogost : ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 10:03:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Jun 2015 08:03:57 +0000 Subject: [issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za> Message-ID: <1433837037.17.0.117102165199.issue19176@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Started topic on Python-Dev: http://comments.gmane.org/gmane.comp.python.devel/153655 . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 10:05:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Jun 2015 08:05:52 +0000 Subject: [issue13566] Increase pickle compatibility In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za> Message-ID: <1433837152.74.0.450524858567.issue13566@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Alexandre, Antoine, what are your thoughts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 10:23:06 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 09 Jun 2015 08:23:06 +0000 Subject: [issue13566] Increase pickle compatibility In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za> Message-ID: <1433838186.27.0.075228534134.issue13566@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Won't that fail if a Python 2 API accepts only unicode strings? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 10:32:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Jun 2015 08:32:04 +0000 Subject: [issue13566] Increase pickle compatibility In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za> Message-ID: <1433838724.76.0.554496091922.issue13566@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Does such API even exist? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 10:38:57 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 09 Jun 2015 08:38:57 +0000 Subject: [issue13566] Increase pickle compatibility In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za> Message-ID: <1433839137.98.0.488186685188.issue13566@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I wouldn't be very surprised if third-party libraries enforce such typing, yes. If your library has a clear text/bytes separation, it makes sense to enforce it at the API level, to avoid mistakes by users. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 11:05:28 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 09 Jun 2015 09:05:28 +0000 Subject: [issue24411] Drop redundant lock in queue.Queue methods qsize(), empty() and full() In-Reply-To: <1433787329.63.0.683771277735.issue24411@psf.upfronthosting.co.za> Message-ID: <1433840728.61.0.339073032164.issue24411@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Raymond, is there known custom third-party queue class derived from queue.Queue? I believe all those are in stdlib only. Also locking guarantee is promised by comment in source code only, documentation says nothing about it. I believe proposed change will not make any harm, but ok with closing as "wontfix" if you fill it's dangerous. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 11:26:08 2015 From: report at bugs.python.org (Ivan Bykov) Date: Tue, 09 Jun 2015 09:26:08 +0000 Subject: [issue24390] Python 3.4.3 64 bits is not "high dpi aware" In-Reply-To: <1433582426.79.0.462452103713.issue24390@psf.upfronthosting.co.za> Message-ID: <1433841968.09.0.0777619556798.issue24390@psf.upfronthosting.co.za> Ivan Bykov added the comment: Python 3.5.0b2 (v3.5.0b2:7a088af5615b, May 31 2015, 06:22:19) [MSC v.1900 64 bit (AMD64)] on win32 Type "copyright", "credits" or "license()" for more information. >>> import ctypes >>> ctypes.windll.user32.GetSystemMetrics(1) 1067 >>> #must be 1600 >>> #Python 3.5 also affected ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 11:35:53 2015 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 09 Jun 2015 09:35:53 +0000 Subject: [issue24390] Python 3.4.3 64 bits is not "high dpi aware" In-Reply-To: <1433582426.79.0.462452103713.issue24390@psf.upfronthosting.co.za> Message-ID: <1433842553.07.0.96080092909.issue24390@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The Python program itself has no UI and cannot be marked as "DPI aware". Instead, applications should call the win32 function "SetProcessDPIAwareness": https://msdn.microsoft.com/en-us/library/windows/desktop/dn302122 ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 12:04:36 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Jun 2015 10:04:36 +0000 Subject: [issue18885] handle EINTR in the stdlib In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za> Message-ID: <1433844276.35.0.270931175305.issue18885@psf.upfronthosting.co.za> STINNER Victor added the comment: > With PEP 475 now implemented (see Issue 23648), perhaps this could be closed? Or is there something else to be done? Yes, this issue was fully fixed by the implementation of the PEP 475 in Python 3.5. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 12:07:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Jun 2015 10:07:46 +0000 Subject: [issue13566] Increase pickle compatibility In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za> Message-ID: <1433844466.01.0.784147397562.issue13566@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Such libraries already have a problem. Both str and unicode pickled in Python 2 are unpickled as str in Python 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 12:08:12 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 09 Jun 2015 10:08:12 +0000 Subject: [issue13566] Increase pickle compatibility In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za> Message-ID: <1433844492.63.0.252157953657.issue13566@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It's not a problem, since str *is* unicode in Python 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 12:26:36 2015 From: report at bugs.python.org (Ivan Bykov) Date: Tue, 09 Jun 2015 10:26:36 +0000 Subject: [issue24390] Python 3.4.3 64 bits is not "high dpi aware" In-Reply-To: <1433582426.79.0.462452103713.issue24390@psf.upfronthosting.co.za> Message-ID: <1433845596.34.0.0833121621994.issue24390@psf.upfronthosting.co.za> Ivan Bykov added the comment: SetProcessDpiAwareness not available for Windows 7. For Windows 7 available SetProcessDPIAware, but: Note SetProcessDPIAware is subject to a possible *race* *condition* if a DLL caches dpi settings during initialization. For this reason, it is recommended that dpi-aware be set through the application (.exe) *manifest* rather than by calling SetProcessDPIAware. https://msdn.microsoft.com/en-us/library/windows/desktop/ms633543%28v=vs.85%29.aspx ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 12:33:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Jun 2015 10:33:06 +0000 Subject: [issue24411] Drop redundant lock in queue.Queue methods qsize(), empty() and full() In-Reply-To: <1433787329.63.0.683771277735.issue24411@psf.upfronthosting.co.za> Message-ID: <1433845986.28.0.358612856013.issue24411@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, there are. https://code.openhub.net/search?s=%22def%20_qsize%22%20%22import%20Queue%22&pp=0&ff=1&mp=1&ml=1&me=1&md=1&filterChecked=true ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 14:30:06 2015 From: report at bugs.python.org (ABalmosan) Date: Tue, 09 Jun 2015 12:30:06 +0000 Subject: [issue24415] SIGINT always reset to SIG_DFL by Py_Finalize() Message-ID: <1433853006.37.0.519208037884.issue24415@psf.upfronthosting.co.za> New submission from ABalmosan: We use the Python lib as part of a larger process. This process sets its own signal handlers to achieve the expected behavior of the process. We use Py_InitializeEx(0) to prevent Python to install its own signal handlers. On process reconfigure we shutdown Python with Py_Finalize() to call Py_InitializeEx(0) anew. Even so Py_InitializeEx(0) did not touch any signal and especially not SIGINT, Py_Finalize() resets unconditionally SIGINT to SIG_DFL. The result is that our process terminates immediately on SIGINT instead of execution its shutdown procedure which was handled by the orginal installed SIGINT handler. The problem is visible in the python code in Modules/signalmodule.c: static void finisignal(void) { int i; PyObject *func; PyOS_setsig(SIGINT, old_siginthandler); old_siginthandler = SIG_DFL; In Python/pythonrun.c Py_InitializeEx()I find: if (install_sigs) initsigs(); /* Signal handling stuff, including initintr() */ Also I wonder by whom PyOS_InitInterrupts() is called. It would unconditionally install the Python signal handler even if Py_InitializeEx(0) was once executed. ---------- components: Interpreter Core messages: 245060 nosy: ABalmosan priority: normal severity: normal status: open title: SIGINT always reset to SIG_DFL by Py_Finalize() type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 14:37:20 2015 From: report at bugs.python.org (Baptiste Mispelon) Date: Tue, 09 Jun 2015 12:37:20 +0000 Subject: [issue24416] Return a namedtuple from date.isocalendar() Message-ID: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za> New submission from Baptiste Mispelon: Currently, `date.isocalendar()` returns a plain tuple of (year, week, weekday). It would be a bit more useful if this tuple could be made into a namedtuple (with fields year, week and weekday). ---------- components: Library (Lib) messages: 245061 nosy: bmispelon priority: normal severity: normal status: open title: Return a namedtuple from date.isocalendar() versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 14:43:34 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 09 Jun 2015 12:43:34 +0000 Subject: [issue24415] SIGINT always reset to SIG_DFL by Py_Finalize() In-Reply-To: <1433853006.37.0.519208037884.issue24415@psf.upfronthosting.co.za> Message-ID: <1433853814.53.0.147233494915.issue24415@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 15:24:58 2015 From: report at bugs.python.org (Tal Einat) Date: Tue, 09 Jun 2015 13:24:58 +0000 Subject: [issue24356] venv documentation incorrect / misleading In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za> Message-ID: <1433856298.71.0.254932333699.issue24356@psf.upfronthosting.co.za> Tal Einat added the comment: See also the recent addition of a section on venv to the Tutorial section of the docs (Doc/tutorial/venv.rst, issue23891). The wording there and in the module docs should at least be consistent with each other. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 15:38:05 2015 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 09 Jun 2015 13:38:05 +0000 Subject: [issue24417] Type-specific documentation for __format__ methods Message-ID: <1433857085.94.0.53514781812.issue24417@psf.upfronthosting.co.za> New submission from Skip Montanaro: I am only now just prying my fingers off printf-style string formatting. The new syntax always seemed Perl-like to me, so I ignored it. Finally, yesterday, I got some cheat sheet pointers from comp.lang.python and dove in. I hit a minor roadblock when I couldn't find any type-specific documentation for the various __format__ methods. In the documentation on the format() builtin (https://docs.python.org/3.5/library/functions.html#format) I read, "The interpretation of format_spec will depend on the type of the value argument..." which led me to believe I would find something about (for example) float.__format__ in the section on floats (https://docs.python.org/3.5/library/stdtypes.html#typesnumeric). I realize now that the documentation for many formats is in the string documentation (https://docs.python.org/3.5/library/string.html#formatspec), but I think it would still be useful to have at least stubs in the documentation for the __format__ method of the various builtin types, even if all those stubs to is refer the reader to the string documentation. I started to work on a patch, but I quickly got myself confused about where to describe .__format__. Perhaps it's time that stdtypes.rst is broken into multiple files, with the structure of the documentation for the various builtin types made more uniform. For instance, int and float have sections describing methods, while list, tuple, set, and dict don't. ---------- assignee: docs at python components: Documentation messages: 245063 nosy: docs at python, skip.montanaro priority: normal severity: normal status: open title: Type-specific documentation for __format__ methods _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 15:41:12 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 09 Jun 2015 13:41:12 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433857272.84.0.707381448321.issue18003@psf.upfronthosting.co.za> Martin Panter added the comment: This patch adds an entry to the What?s New for 3.5 (though maybe it will have to be 3.6), and adds three tests to check that next() raises ValueError when the files have been closed. ---------- Added file: http://bugs.python.org/file39662/decomp-optim.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 16:05:15 2015 From: report at bugs.python.org (doz) Date: Tue, 09 Jun 2015 14:05:15 +0000 Subject: [issue24228] Interpreter triggers segmentation fault at the starting In-Reply-To: <1431964179.84.0.528825481324.issue24228@psf.upfronthosting.co.za> Message-ID: <1433858715.2.0.133520224133.issue24228@psf.upfronthosting.co.za> doz added the comment: The problem is only present with gcc optimization -Os . Not present with -O0 ,O1, O2, O3. Do you have an idea of the gcc pass responsible to that ? (I have also a similar problem with openssl) regards ---------- resolution: -> third party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 16:33:23 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 09 Jun 2015 14:33:23 +0000 Subject: [issue24417] Type-specific documentation for __format__ methods In-Reply-To: <1433857085.94.0.53514781812.issue24417@psf.upfronthosting.co.za> Message-ID: <1433860403.81.0.2088794188.issue24417@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 16:35:59 2015 From: report at bugs.python.org (Tim Pierce) Date: Tue, 09 Jun 2015 14:35:59 +0000 Subject: [issue22983] Cookie parsing should be more permissive In-Reply-To: <1417539577.52.0.585535774996.issue22983@psf.upfronthosting.co.za> Message-ID: <1433860559.36.0.0886727656777.issue22983@psf.upfronthosting.co.za> Changes by Tim Pierce : ---------- nosy: +Tim Pierce _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 16:51:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Jun 2015 14:51:16 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433861476.02.0.770991657332.issue18003@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Larry, do you accept the patch for 3.5? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 17:04:56 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 09 Jun 2015 15:04:56 +0000 Subject: [issue24416] Return a namedtuple from date.isocalendar() In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za> Message-ID: <1433862296.16.0.352971990119.issue24416@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 17:16:13 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 09 Jun 2015 15:16:13 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433862973.53.0.0940679339913.issue18003@psf.upfronthosting.co.za> Antoine Pitrou added the comment: He accepted it already: """A small last-minute optimization is not a release-blocker.""" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 17:18:54 2015 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 09 Jun 2015 15:18:54 +0000 Subject: [issue23891] Tutorial doesn't mention either pip or virtualenv In-Reply-To: <1428521410.44.0.984619918633.issue23891@psf.upfronthosting.co.za> Message-ID: <1433863134.21.0.945578541076.issue23891@psf.upfronthosting.co.za> Skip Montanaro added the comment: Small nit... The venv.patch file refers to "Python Packaging Index." It's the "Python Package Index." ---------- nosy: +skip.montanaro Added file: http://bugs.python.org/file39663/ppi.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 17:20:47 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Jun 2015 15:20:47 +0000 Subject: [issue24411] Drop redundant lock in queue.Queue methods qsize(), empty() and full() In-Reply-To: <1433787329.63.0.683771277735.issue24411@psf.upfronthosting.co.za> Message-ID: <1433863247.35.0.837284446868.issue24411@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 17:42:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 09 Jun 2015 15:42:48 +0000 Subject: [issue23891] Tutorial doesn't mention either pip or virtualenv In-Reply-To: <1428521410.44.0.984619918633.issue23891@psf.upfronthosting.co.za> Message-ID: <20150609154243.17681.72674@psf.io> Roundup Robot added the comment: New changeset bb51d486a899 by Tal Einat in branch '3.4': #23891: correctly refer to PyPI as "Python Package Index" https://hg.python.org/cpython/rev/bb51d486a899 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 18:00:03 2015 From: report at bugs.python.org (Tal Einat) Date: Tue, 09 Jun 2015 16:00:03 +0000 Subject: [issue24379] slice.literal notation In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1433865603.02.0.498712031209.issue24379@psf.upfronthosting.co.za> Tal Einat added the comment: (This should probably be discussed on the Python Ideas mailing list...) I definitely like the idea of being able to construct slices etc. using "[]" syntax. I think this should be considered even if it is decided not to change the repr() of slices. An important note here is that this is about more than slices: $ python3 Python 3.4.2 (default, Feb 23 2015, 21:16:28) [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... def __getitem__(self, *args): ... print(repr(args)) ... >>> a = A() >>> a[0] (0,) >>> a[0:1] (slice(0, 1, None),) >>> a[0:1, ..., 1:2] ((slice(0, 1, None), Ellipsis, slice(1, 2, None)),) >>> a[0:1, 2] ((slice(0, 1, None), 2),) Indeed, Joe's suggested slice.literal supports all of this, but we can't just modify slice to handle all of these cases. What I'm missing is a way to use such an object to actually index/slice something. The only way I can currently think of is using a.__getitem__(), but that's quite ugly IMO. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 18:02:59 2015 From: report at bugs.python.org (Tal Einat) Date: Tue, 09 Jun 2015 16:02:59 +0000 Subject: [issue24351] string.Template documentation incorrectly references "identifiers" In-Reply-To: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za> Message-ID: <1433865779.33.0.452501015763.issue24351@psf.upfronthosting.co.za> Tal Einat added the comment: +1 for keeping the current behavior and fixing the docs. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 18:05:59 2015 From: report at bugs.python.org (Joe Jevnik) Date: Tue, 09 Jun 2015 16:05:59 +0000 Subject: [issue24379] slice.literal notation In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1433865959.82.0.286141341523.issue24379@psf.upfronthosting.co.za> Joe Jevnik added the comment: > What I'm missing is a way to use such an object to actually index/slice something Sorry, I am not sure I understand what you mean by this? You can pass a slice object, or a tuple of slices in subscript notation. >>> [1, 2, 3, 4][slice(2)] [1, 2] Also, I am not currently subscribed to python-ideas; what is the common practice for posting new threads? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 18:45:36 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 09 Jun 2015 16:45:36 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433868336.65.0.282673856642.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: Please see the attached patch. Couple of notes: 1. It adds a new type: 'coroutine' (PyCoro_Type). The implementation is still heavily based on generators, there are no changes there. 2. Unfortunately, a new opcode needs to be added - GET_YIELD_FROM_ITER. The idea is that YIELD_FROM from generators decorated with @coroutine must accept 'async def' coroutines. But 'for' loops (iter(), etc) must throw an error on them. On the bright side, because of this new opcode, the ceval code became much easier to follow. 3. This change removes the need to use __instancecheck__ for 'async def' coroutines. BUT, it's still there for generators decorated with @coroutine. Stefan suggests to wrap generators in a thin wrapper with __await__ method, but I don't like this idea -- it will inevitably make existing asyncio code slower in 3.5; I'm -0.5 on this idea. 4. While this patch addresses initial request from Ben only partially (generator-based coroutines still require __instancecheck__), I believe that it's still a good idea to separate 'async def' coroutines & generators in 3.5. I'm fully confident that we shouldn't have any issues with that. ---------- keywords: +patch Added file: http://bugs.python.org/file39664/corotype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 19:09:16 2015 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 09 Jun 2015 17:09:16 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433869756.45.0.00752200055061.issue24400@psf.upfronthosting.co.za> Stefan Behnel added the comment: Looks good, simplifies the code visibly and makes the implementation quite similar to the one I wrote for Cython. I like the fact that it separates generators from coroutines at an isinstance() level. The fact that "async def" functions currently have the same type as yield-based generators smells too much like an implementation detail to keep it visible at the language level. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 19:11:27 2015 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 09 Jun 2015 17:11:27 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1433869887.02.0.84839320579.issue24017@psf.upfronthosting.co.za> Stefan Behnel added the comment: See issue 24400 regarding a split of yield-based generators and async-def coroutines at a type level. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 19:35:11 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 09 Jun 2015 17:35:11 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433871311.14.0.751964502094.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: Cleaned up the patch a little bit. ---------- Added file: http://bugs.python.org/file39665/corotype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 19:39:10 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 09 Jun 2015 17:39:10 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433871550.94.0.416550619092.issue24400@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- hgrepos: +312 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 19:49:23 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 09 Jun 2015 17:49:23 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433872163.46.0.230862684147.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: One more patch fixing minor bug in types.coroutine + a unittest for that. The patch should be ready for reviews. ---------- Added file: http://bugs.python.org/file39666/corotype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 20:01:53 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 09 Jun 2015 18:01:53 +0000 Subject: [issue24418] "make install" will not install pip if already present in user site-packages Message-ID: <1433872913.68.0.595008906061.issue24418@psf.upfronthosting.co.za> New submission from Antoine Pitrou: This is what happens when building Python with conda-build (which implies doing "make install" with a custom prefix): [...] if test "xupgrade" != "xno" ; then \ case upgrade in \ upgrade) ensurepip="--upgrade" ;; \ install|*) ensurepip="" ;; \ esac; \ LD_LIBRARY_PATH=/home/antoine/miniconda3/conda-bld/work/cpython-default ./python -E -m ensurepip \ $ensurepip --root=/ ; \ fi Ignoring indexes: https://pypi.python.org/simple/ Requirement already up-to-date: setuptools in /home/antoine/.local/lib/python3.5/site-packages Requirement already up-to-date: pip in /home/antoine/.local/lib/python3.5/site-packages [...] Note that conda-build *does* set PYTHONNOUSERSITE to make builds as isolated as possible, but the Python Makefile deliberately ignores it using "python -E"! ---------- components: Build messages: 245078 nosy: dstufft, ncoghlan, pitrou priority: normal severity: normal status: open title: "make install" will not install pip if already present in user site-packages type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 20:06:11 2015 From: report at bugs.python.org (Donald Stufft) Date: Tue, 09 Jun 2015 18:06:11 +0000 Subject: [issue24418] "make install" will not install pip if already present in user site-packages In-Reply-To: <1433872913.68.0.595008906061.issue24418@psf.upfronthosting.co.za> Message-ID: <1433873171.38.0.679871663195.issue24418@psf.upfronthosting.co.za> Donald Stufft added the comment: We should probably pass ``-s`` to the ensurepip call. Adding 2.7 here as well because I think this will probably affect more than just the Makefile, probably the Windows installers and OSX installers too. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 20:24:47 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 09 Jun 2015 18:24:47 +0000 Subject: [issue24351] string.Template documentation incorrectly references "identifiers" In-Reply-To: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za> Message-ID: <20150609182444.17685.65607@psf.io> Roundup Robot added the comment: New changeset 20bf84cd38bc by Barry Warsaw in branch '3.4': - Issue #24351: Clarify what is meant by "identifier" in the context of https://hg.python.org/cpython/rev/20bf84cd38bc New changeset 0fa48f581fe3 by Barry Warsaw in branch '3.5': - Issue #24351: Clarify what is meant by "identifier" in the context of https://hg.python.org/cpython/rev/0fa48f581fe3 New changeset 1cdedc9a9e9f by Barry Warsaw in branch 'default': - Issue #24351: Clarify what is meant by "identifier" in the context of https://hg.python.org/cpython/rev/1cdedc9a9e9f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 20:27:19 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 09 Jun 2015 18:27:19 +0000 Subject: [issue24351] string.Template documentation incorrectly references "identifiers" In-Reply-To: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za> Message-ID: <1433874439.1.0.227081274285.issue24351@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 20:40:57 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 09 Jun 2015 18:40:57 +0000 Subject: [issue24418] "make install" will not install pip if already present in user site-packages In-Reply-To: <1433872913.68.0.595008906061.issue24418@psf.upfronthosting.co.za> Message-ID: <1433875257.94.0.19368784305.issue24418@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Do we need to add Steve and Ned for the installers? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 20:41:27 2015 From: report at bugs.python.org (Aaron Meurer) Date: Tue, 09 Jun 2015 18:41:27 +0000 Subject: [issue24418] "make install" will not install pip if already present in user site-packages In-Reply-To: <1433872913.68.0.595008906061.issue24418@psf.upfronthosting.co.za> Message-ID: <1433875287.0.0.934934214681.issue24418@psf.upfronthosting.co.za> Changes by Aaron Meurer : ---------- nosy: +Aaron.Meurer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 20:53:29 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 09 Jun 2015 18:53:29 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433876009.13.0.0737719192033.issue24400@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 21:17:04 2015 From: report at bugs.python.org (Tal Einat) Date: Tue, 09 Jun 2015 19:17:04 +0000 Subject: [issue24379] slice.literal notation In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1433877424.34.0.506143746411.issue24379@psf.upfronthosting.co.za> Tal Einat added the comment: (see https://mail.python.org/mailman/listinfo/python-ideas) But for x = [1,2,3,4], how will x[y] work for all of the following values of y? y = slice.literal[0] y = slice.literal[1:2] y = slice.literal[0:1, ..., 3] NumPy's s_ "magic object" is a factory, returning objects of different types depending on the given input. If you want an actual slice.literal class, then you'll have to supply a way to convert it into an object usable for indexing/slicing, e.g.: y = slice.literal[0:1] [1,2,3,4][y.as_indexer] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 21:25:50 2015 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 09 Jun 2015 19:25:50 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433877950.98.0.617267962943.issue24400@psf.upfronthosting.co.za> Stefan Behnel added the comment: I added some review comments. The main thing is that the coroutine type should be awaitable. For reference, here's my current implementation for Cython. It's a bit more involved as it needs to support Python 2.6+. I may also add some special casing for CPython's own coroutine type when compiling in Py3.5 if this change makes it in. https://github.com/cython/cython/blob/bb0dec2fab91cbde443e6756c3dc29ee009caba7/Cython/Utility/Coroutine.c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 21:29:06 2015 From: report at bugs.python.org (Tal Einat) Date: Tue, 09 Jun 2015 19:29:06 +0000 Subject: [issue24416] Return a namedtuple from date.isocalendar() In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za> Message-ID: <1433878146.42.0.872455926375.issue24416@psf.upfronthosting.co.za> Tal Einat added the comment: Is there any way that this could break existing code? ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 21:31:12 2015 From: report at bugs.python.org (Baptiste Mispelon) Date: Tue, 09 Jun 2015 19:31:12 +0000 Subject: [issue24416] Return a namedtuple from date.isocalendar() In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za> Message-ID: <1433878272.59.0.797985244798.issue24416@psf.upfronthosting.co.za> Baptiste Mispelon added the comment: As far as I know, using a namedtuple in place of a tuple is fully backwards-compatible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 21:36:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Jun 2015 19:36:33 +0000 Subject: [issue24416] Return a namedtuple from date.isocalendar() In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za> Message-ID: <1433878593.13.0.964116901393.issue24416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, it is not fully backwards-compatible. First, if pickle a namedtuple, it can't be unpickled in previous versions. Second, namedtuple is slower and larger than tuple, so it shouldn't be used in memory or performance critical code. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 21:51:36 2015 From: report at bugs.python.org (Tal Einat) Date: Tue, 09 Jun 2015 19:51:36 +0000 Subject: [issue24416] Return a namedtuple from date.isocalendar() In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za> Message-ID: <1433879496.84.0.065645463415.issue24416@psf.upfronthosting.co.za> Tal Einat added the comment: > First, if pickle a namedtuple, it can't be unpickled in previous versions. True, but I don't think Python goes as far as to promise that objects pickled in one version can be unpickled in previous versions. > Second, namedtuple is slower and larger than tuple, so it shouldn't be used in memory or performance critical code. True, but I doubt that such tuples are often used extensively in performance-critical areas of code. Also, code which does care about this could immediately convert these namedtuples into plain tuples, which would be backwards compatible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 21:52:40 2015 From: report at bugs.python.org (Baptiste Mispelon) Date: Tue, 09 Jun 2015 19:52:40 +0000 Subject: [issue24416] Return a namedtuple from date.isocalendar() In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za> Message-ID: <1433879560.74.0.890428403598.issue24416@psf.upfronthosting.co.za> Baptiste Mispelon added the comment: I didn't know about issues with pickling. As for the performance issue, is date.isocalendar() really performance critical? I found a precedent for replacing a tuple by a namedtuple: https://hg.python.org/cpython/rev/ef72142eb8a2 I'm trying my hand at writing a patch (I'm a new contributor) but it seems the code is implemented twice: both in Lib/ (python) and in Modules/ (C). I'm having a hard time figuring out how to conjure up a namedutple from the C code. Any hepl is appreciated. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 22:10:39 2015 From: report at bugs.python.org (Tal Einat) Date: Tue, 09 Jun 2015 20:10:39 +0000 Subject: [issue24416] Return a namedtuple from date.isocalendar() In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za> Message-ID: <1433880639.07.0.997068779431.issue24416@psf.upfronthosting.co.za> Tal Einat added the comment: You can take a look at lru_cache_cache_info in Modules/_functoolsmodule.c for an example of namedtuple instantiation in C code. But that code gets the namedtuple class as a parameter. This is not my area of expertise, but you could try using PyObject_CallFunction to call the Python collections.namedtuple function, keep the result as a module attribute, and then call that whenever you want to create an instance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 22:16:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Jun 2015 20:16:29 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433880989.82.0.690388317678.issue18003@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch is not so harmless. First, my change in BZ2File is not correct, because reading every line should be guarded with a lock (BZ2File is threading-safe). Second, for now all three compressing files are not only iterables, but iterators. iter(f) returns f, and changing this can have non-obvious effects. I think the patch is too complex for 3.5, we should have more time to analyze all consequences. ---------- stage: commit review -> patch review versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 22:18:54 2015 From: report at bugs.python.org (Carl Kleffner) Date: Tue, 09 Jun 2015 20:18:54 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433881134.45.0.0435220522394.issue24385@psf.upfronthosting.co.za> Carl Kleffner added the comment: The most robust way to support a specific mingw-w64 distribution is to copy a python import library generated by this specific toolchain and the provided import library for the corresponding msvcrXX.dll runtime into the libs folder. This has to be performed by the user with the help of gendef and dlltool. Another atempt is to install and use a specific mingw-toolchain that copies these files into the libs folder during install. Such a toolchain will be provided in the near future as 'mingwpy' toolchain for python2.7-3.4. ---------- nosy: +carlkl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 23:06:36 2015 From: report at bugs.python.org (Baptiste Mispelon) Date: Tue, 09 Jun 2015 21:06:36 +0000 Subject: [issue24416] Return a namedtuple from date.isocalendar() In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za> Message-ID: <1433883996.78.0.903187892901.issue24416@psf.upfronthosting.co.za> Baptiste Mispelon added the comment: Here's a second attempt at a patch which seems to work. I don't know C at all but I used _decimal.c to try and figure out how to use namedtuple in C. The code compiles and the datetime test suite runs. I've added a test for the new feature and a note in Misc/NEWS as well as a versionadded note in the relevant documentation. Let me know if I've missed anything. ---------- keywords: +patch Added file: http://bugs.python.org/file39667/issue24416_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 23:32:48 2015 From: report at bugs.python.org (Baptiste Mispelon) Date: Tue, 09 Jun 2015 21:32:48 +0000 Subject: [issue24416] Return a namedtuple from date.isocalendar() In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za> Message-ID: <1433885568.5.0.200521409679.issue24416@psf.upfronthosting.co.za> Baptiste Mispelon added the comment: Some C code cleanups suggested by haypo. ---------- Added file: http://bugs.python.org/file39668/issue24416_3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 23:35:32 2015 From: report at bugs.python.org (Tal Einat) Date: Tue, 09 Jun 2015 21:35:32 +0000 Subject: [issue24416] Return a namedtuple from date.isocalendar() In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za> Message-ID: <1433885732.65.0.0112131718588.issue24416@psf.upfronthosting.co.za> Tal Einat added the comment: Now for the color of the bike-shed: What should the namedtuple returned by date.isocalendar() be named? Perhaps CalendarDate or DateTuple? Baptiste's patches use ISOCalendarResult. In my opinion that is a poor name since it does not tell you anything about what it represents (you have to know or look up what isocalendar() returns). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 9 23:38:56 2015 From: report at bugs.python.org (Baptiste Mispelon) Date: Tue, 09 Jun 2015 21:38:56 +0000 Subject: [issue24416] Return a namedtuple from date.isocalendar() In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za> Message-ID: <1433885936.24.0.359483983748.issue24416@psf.upfronthosting.co.za> Baptiste Mispelon added the comment: For the name, I took (un)inspiration from ParseResult: https://docs.python.org/3/library/urllib.parse.html?highlight=urlparse#urllib.parse.ParseResult Any better suggestion is welcome of course. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 00:06:58 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 09 Jun 2015 22:06:58 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433887618.48.0.119866125057.issue18003@psf.upfronthosting.co.za> Larry Hastings added the comment: Sounds good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 00:08:27 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 09 Jun 2015 22:08:27 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433887707.29.0.791200234121.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: Please find attached a new patch. Stefan, while working on the patch, I (re-)discovered that __await__ for coroutines should return an iterator that also implements '.send', '.throw', and '.close', to comply with PEP 380 yield from implementation: https://www.python.org/dev/peps/pep-0380/#proposal Please try to compile this python file: https://gist.github.com/1st1/4ee1d072309068dd2798 ---------- Added file: http://bugs.python.org/file39669/corotype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 00:11:17 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 09 Jun 2015 22:11:17 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433887877.46.0.203379157456.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, Guido, I think we should commit this. While working on this I'm getting more and more confident that it's the right thing to do. I like that coroutines implement __await__ in the latest patch -- PEP 492 just now "clicks" with PEP 380. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 00:32:06 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 09 Jun 2015 22:32:06 +0000 Subject: [issue24418] "make install" will not install pip if already present in user site-packages In-Reply-To: <1433872913.68.0.595008906061.issue24418@psf.upfronthosting.co.za> Message-ID: <1433889126.96.0.556155188056.issue24418@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ned.deily stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 01:05:09 2015 From: report at bugs.python.org (py.user) Date: Tue, 09 Jun 2015 23:05:09 +0000 Subject: [issue24419] In argparse action append_const doesn't work for positional arguments Message-ID: <1433891109.51.0.989129061245.issue24419@psf.upfronthosting.co.za> New submission from py.user: Action append_const works for options: >>> import argparse >>> >>> parser = argparse.ArgumentParser() >>> _ = parser.add_argument('--foo', dest='x', action='append_const', const=42) >>> _ = parser.add_argument('--bar', dest='x', action='append_const', const=43) >>> parser.parse_args('--foo --bar'.split()) Namespace(x=[42, 43]) >>> Action append_const works for single positionals: >>> import argparse >>> >>> parser = argparse.ArgumentParser() >>> _ = parser.add_argument('foo', action='append_const', const=42) >>> _ = parser.add_argument('bar', action='append_const', const=43) >>> parser.parse_args([]) Namespace(bar=[43], foo=[42]) >>> Action append_const doesn't work for positionals in one list: >>> import argparse >>> >>> parser = argparse.ArgumentParser() >>> _ = parser.add_argument('foo', dest='x', action='append_const', const=42) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.3/site-packages/argparse-1.1-py3.3.egg/argparse.py", line 1282, in add_argument """ ValueError: dest supplied twice for positional argument >>> _ = parser.add_argument('bar', dest='x', action='append_const', const=43) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.3/site-packages/argparse-1.1-py3.3.egg/argparse.py", line 1282, in add_argument """ ValueError: dest supplied twice for positional argument >>> parser.parse_args([]) Namespace() >>> The reason is that a positional argument can't accept dest: >>> import argparse >>> >>> parser = argparse.ArgumentParser() >>> parser.add_argument('foo', dest='x') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.3/site-packages/argparse-1.1-py3.3.egg/argparse.py", line 1282, in add_argument """ ValueError: dest supplied twice for positional argument >>> ---------- components: Library (Lib) messages: 245099 nosy: py.user priority: normal severity: normal status: open title: In argparse action append_const doesn't work for positional arguments type: behavior versions: Python 3.3, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 01:28:43 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 09 Jun 2015 23:28:43 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433887877.46.0.203379157456.issue24400@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: A quick scan of which files have been modified suggests the new opcode still needs docs (although I think the PEP 492 docs in general are still pending, in which case, this could just be rolled into that) I'll review the full patch later today (too big to review on my phone) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 01:32:21 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 09 Jun 2015 23:32:21 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: Message-ID: <17BE3446-D7CD-40FE-84F5-BD794A5AAE8C@gmail.com> Yury Selivanov added the comment: > Nick Coghlan added the comment: > > A quick scan of which files have been modified suggests the new opcode > still needs docs (although I think the PEP 492 docs in general are still > pending, in which case, this could just be rolled into that) Sure. If the patch looks good I'll update it with the docs! ---------- nosy: +Yury.Selivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 01:36:59 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 09 Jun 2015 23:36:59 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: Message-ID: Yury Selivanov added the comment: > (although I think the PEP 492 docs in general are still pending, in which case, this could just be rolled into that) Actually most of pep 492 docs are merged already (including new opcodes) via issue24180. They can be definitely improved though (I'll try to reserve some time just for that closer to the rc) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 03:47:01 2015 From: report at bugs.python.org (Ben Darnell) Date: Wed, 10 Jun 2015 01:47:01 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433900821.37.0.652662761253.issue24400@psf.upfronthosting.co.za> Ben Darnell added the comment: > 4. While this patch addresses initial request from Ben only partially > (generator-based coroutines still require __instancecheck__), A partial solution doesn't mean much to me: as long as the __instancecheck__ is sometimes necessary, I'll have to use inspect.iscoroutine all the time instead of using singledispatch with Awaitable. If anything, this just magnifies the risk of mysterious failures as things will work with async def but not yield from. I think I'd rather not have the ABC than have one with this kind of quirk. All this checking for coroutine-ness feels very strange to me. It's anti-duck-typing: all generators have all the methods necessary to satisfy the coroutine interface, but you can't use them as coroutines without some magical indication that that's what you meant. Prior to 3.5, a coroutine was just a callable returning a generator. Now, not only must it return a generator with the special coroutine flag, the callable itself must be of the right type, which causes problems when the underlying generator function is wrapped in complex ways (https://github.com/tornadoweb/tornado/blob/2971e857104f8d02fa9107a0e13f50170eb4f30d/tornado/testing.py#L476). Attempting to divide generators into awaitable and non-awaitable subsets is a complex solution to a problem that I'm not convinced is real. Was there a problem in practice with Python 3.4's asyncio in which people used "yield from" in a coroutine with generators that were intended to be iterators instead? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 04:02:06 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 10 Jun 2015 02:02:06 +0000 Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in __repr__ In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za> Message-ID: <1433901726.86.0.685214630448.issue22836@psf.upfronthosting.co.za> Martin Panter added the comment: Updated the patch to address an oversight in the new test cases. I think Issue 6294 is probably the same underlying issue. The patch there could be used as the basis for a Python 2 patch. My patches here are for Python 3, and I suspect the code is significantly different in each version, because the error messages are different. Comparison (for bikeshedding etc) with the message produced by the ?traceback? module when str() fails: >>> try: ... raise BrokenStrException("message") ... except BrokenStrException: ... print_exc() ... raise ... Traceback (most recent call last): File "", line 2, in BrokenStrException: Traceback (most recent call last): File "", line 2, in __main__.BrokenStrException: ---------- stage: -> patch review versions: +Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39670/unraisable-continue.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 04:12:10 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 10 Jun 2015 02:12:10 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433902330.22.0.173275925288.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: > All this checking for coroutine-ness feels very strange to me. It's anti-duck-typing: [..] Why is it "anti-duck-typing"? Awaitable is an object that implements __await__. With this patch coroutines are a separate type with __await__ (although, ceval doesn't use it to make things faster). In asyncio we check for "coroutine-ness" only to raise errors if someone passes a wrong object, or to make @asyncio.coroutine work (which will go away eventually). > Now, not only must it return a generator with the special coroutine flag, the callable itself must be of the right type [..] Not sure what you mean here. It doesn't matter what callable is. It only matters if it returns a native coroutine, a generator-based coroutine, or an object with "__await__". > Attempting to divide generators into awaitable and non-awaitable subsets is a complex solution to a problem that I'm not convinced is real. Well, 'await' expression is a new operator, and it makes total sense to limit its usage only to awaitables. Awaiting on a generator that yields a fibonacci sequence just doesn't make any sense, and *is* error prone. I think it would be a major mistake to allow this just to make things a little bit more convenient during the transition period. This particular patch does not divide generators in awaitables and non-awaitables, it introduces a new type for 'async def' coroutines. All confusion with old generator-based coroutines and @coroutine decorator is here only because we try to be backwards compatible; the compatibility layer can be removed in 3.7 or 3.8. > Was there a problem in practice with Python 3.4's asyncio in which people used "yield from" in a coroutine with generators that were intended to be iterators instead? Yes, a lot of people were confused where they have coroutines and where they have generators, and this was even mentioned in the Rationale section of the PEP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 04:57:27 2015 From: report at bugs.python.org (Benjamin Gilbert) Date: Wed, 10 Jun 2015 02:57:27 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433905047.1.0.74182328695.issue24385@psf.upfronthosting.co.za> Benjamin Gilbert added the comment: Is there any reason an import library generated by a particular MinGW version shouldn't be usable by any other MinGW version? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 05:07:25 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 10 Jun 2015 03:07:25 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1433905645.22.0.923846653636.issue18003@psf.upfronthosting.co.za> Martin Panter added the comment: The BufferedReader class is documented as being thread safe: . Some experimentation suggests that checking the ?raw.closed? property is not actually serialized, but that raw.readinto() calls are serialized. I don?t think this is a big problem in practice, so I think BZ2File would remain as thread-safe as BufferedReader is. But Serhiy?s point is definitely valid about the classes breaking the iterator protocol. FWIW I originally made this patch to satisfy my personal curiosity about why wrapping a second BufferedReader made things so much faster. Now I accept it is partly due to the overhead of the extra LZMAFile.readline() to BufferedReader.readline() delegation. Maybe it is not even worth optimizing around this kind of overhead, so I would even be happy to drop this patch and close the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 05:11:09 2015 From: report at bugs.python.org (Ben Darnell) Date: Wed, 10 Jun 2015 03:11:09 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433902330.22.0.173275925288.issue24400@psf.upfronthosting.co.za> Message-ID: Ben Darnell added the comment: On Tue, Jun 9, 2015 at 10:12 PM, Yury Selivanov wrote: > > Yury Selivanov added the comment: > > > All this checking for coroutine-ness feels very strange to me. It's > anti-duck-typing: [..] > > Why is it "anti-duck-typing"? Awaitable is an object that implements > __await__. With this patch coroutines are a separate type with __await__ > (although, ceval doesn't use it to make things faster). > Anti-duck-typing isn't quite the right word. What I meant was that Python 3.4 had generators that were used as coroutines. When we introduced __await__ in 3.5, we could have added __await__ as a method for all generators, since all generators have the necessary send/throw/close methods. But we didn't, and now we require an explicit marker that a given object was intended for a particular use instead of inferring that intention from the set of methods available. > > In asyncio we check for "coroutine-ness" only to raise errors if someone > passes a wrong object, or to make @asyncio.coroutine work (which will go > away eventually). > The check for coroutine-ness is not just in asyncio; it happens in the core interpreter. Tornado has to adapt to this check in order to interoperate with 'async def' coroutines. > > > Now, not only must it return a generator with the special coroutine > flag, the callable itself must be of the right type [..] > > Not sure what you mean here. It doesn't matter what callable is. It only > matters if it returns a native coroutine, a generator-based coroutine, or > an object with "__await__". > The type of the callable matters for the types.coroutine decorator. In order to get a coroutine object instead of a generator object, I must apply types.coroutine to the actual underlying generator, and not any wrapper. > > > Attempting to divide generators into awaitable and non-awaitable subsets > is a complex solution to a problem that I'm not convinced is real. > > Well, 'await' expression is a new operator, and it makes total sense to > limit its usage only to awaitables. Awaiting on a generator that yields a > fibonacci sequence just doesn't make any sense, and *is* error prone. I > think it would be a major mistake to allow this just to make things a > little bit more convenient during the transition period. > > This particular patch does not divide generators in awaitables and > non-awaitables, it introduces a new type for 'async def' coroutines. All > confusion with old generator-based coroutines and @coroutine decorator is > here only because we try to be backwards compatible; the compatibility > layer can be removed in 3.7 or 3.8. > There are three eras of coroutines to consider: 'async def' in 3.5+, 'yield from' in 3.3-3.4, and 'yield' in 2.5+. I'm trying to provide a path from 'yield' to 'async def'; this compatibility layer will remain relevant as long as people are migrating from 2.7. > > > Was there a problem in practice with Python 3.4's asyncio in which > people used "yield from" in a coroutine with generators that were intended > to be iterators instead? > > Yes, a lot of people were confused where they have coroutines and where > they have generators, and this was even mentioned in the Rationale section > of the PEP. > I understand that yield-based coroutines can be confusing, but is this particular kind of confusion bad enough that if someone writes 'await fibonacci_generator()' we have to raise "TypeError: object generator can't be used in 'await' expression" instead of "RuntimeError: Task got bad yield: 1"? (that error message from asyncio could definitely be improved, but the fact that no one has improved it suggests that the problem isn't that severe) My goal here is to make it possible for Tornado applications running on 3.5 to use 'async def' and 'await' even though Tornado itself must remain compatible with 2.7 (as do many of the libraries that make up the Tornado ecosystem; I don't want libraries to have to update for compatibility with this feature). This is doable (I think) but non-trivial in the current design; making all generators awaitable would make it easier. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 05:39:07 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 10 Jun 2015 03:39:07 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: Message-ID: Yury Selivanov added the comment: On June 9, 2015 at 11:11:11 PM, Ben Darnell (report at bugs.python.org) wrote: [..] > The type of the callable matters for the types.coroutine decorator. In > order to get a coroutine object instead of a generator object, I must apply > types.coroutine to the actual underlying generator, and not any wrapper. I get it now, thanks for explaining. FWIW, I?ve recently updated types.coroutine: https://github.com/python/cpython/blob/eae2bd7c0718b8e4333bd16134e37810e32c050c/Lib/types.py#L164 Instead of unwrapping the callable, it wraps its result with a special object with __await__. ?For instance, this enables regular functions (not generator functions) that are decorated with @types.coruoutine and return a generator, or a generator-like object compiled with Cython to work with ?await?. ?Maybe this is something you can use in Tornado? There is also?issue24325 ? to implement most of types.coroutine in C to make it faster. > I understand that yield-based coroutines can be confusing, but is this > particular kind of confusion bad enough that if someone writes 'await > fibonacci_generator()' we have to raise "TypeError: object generator can't > be used in 'await' expression" instead of "RuntimeError: Task got bad > yield: 1"? (that error message from asyncio could definitely be improved, > but the fact that no one has improved it suggests that the problem isn't > that severe) > > My goal here is to make it possible for Tornado applications running on 3.5 > to use 'async def' and 'await' even though Tornado itself must remain > compatible with 2.7 (as do many of the libraries that make up the Tornado > ecosystem; I don't want libraries to have to update for compatibility with > this feature). This is doable (I think) but non-trivial in the current > design; making all generators awaitable would make it easier. I understand. ?My line of thoughts here is: we are introducing a new? operator. ?However we define it now, will be set in stone after 3.5 is released. ?We should try to solve possible backwards compatibility issues without making its semantics less strict just to make things easier. Please take a look at the recently refactored types.coroutine (there is a link above). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 05:51:49 2015 From: report at bugs.python.org (koobs) Date: Wed, 10 Jun 2015 03:51:49 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <1433908309.26.0.566868186081.issue22359@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 05:57:19 2015 From: report at bugs.python.org (koobs) Date: Wed, 10 Jun 2015 03:57:19 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <1433908639.74.0.911321465954.issue22359@psf.upfronthosting.co.za> koobs added the comment: We've (FreeBSD) seen and received several random and intermittent reports of failures during this stage of the build for all versions of Python, resulting in errors such as, among others: Parser/pgen.o: file not recognized: File truncated *** [Parser/pgen] Error code 1 pgenmain.c:(.text+0x258): undefined reference to `_Py_pgen' *** [Parser/pgen] Error code 1 1 error *** [Include/graminit.h] Error code 2 See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200622 Given the existing patch breaks cross-builds, is there an alternative or safer way to make this section of the build more robust in order to make progress? ---------- versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 06:04:16 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 10 Jun 2015 04:04:16 +0000 Subject: [issue24420] Documentation regressions from adding subprocess.run() Message-ID: <1433909056.73.0.964707918197.issue24420@psf.upfronthosting.co.za> New submission from Martin Panter: After the documentation was rearranged by Issue 23342 (revision f0a00ee094ff), the ?older high-level APIs? lost the paragraphs that said ?The arguments shown above are merely the most common ones?. Given the limited signatures of call(), check_call() and check_output(), it is now too easy to assume that these functions do not accept the less-common Popen arguments. Also, in that issue I discovered an awkward edge case: there is actually no default value for the check_output() input parameter. Without an ?input? parameter, the subprocess inherits its parent?s input, but input=None is equivalent to passing an empty string of the correct type. This patch hopefully fixes both problems. ---------- assignee: docs at python components: Documentation files: high-args.patch keywords: patch messages: 245111 nosy: docs at python, takluyver, vadmium priority: normal severity: normal status: open title: Documentation regressions from adding subprocess.run() type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39671/high-args.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 06:16:05 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 10 Jun 2015 04:16:05 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <1433909765.37.0.492986015251.issue22359@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW two times recently I saw strange intermittent build errors. I use ?make -j2? on Linux. The one time that I investigated was a Python module (math or cmath perhaps?) failing to build because some dependency was zero bytes, and looking through the build log, I saw duplicate compiler commands lines printed out one after the other to build that dependency. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 06:38:58 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 10 Jun 2015 04:38:58 +0000 Subject: [issue24420] Documentation regressions from adding subprocess.run() In-Reply-To: <1433909056.73.0.964707918197.issue24420@psf.upfronthosting.co.za> Message-ID: <1433911138.71.0.811185820754.issue24420@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 06:43:32 2015 From: report at bugs.python.org (Ben Darnell) Date: Wed, 10 Jun 2015 04:43:32 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433911412.96.0.662326119235.issue24400@psf.upfronthosting.co.za> Ben Darnell added the comment: GeneratorWrapper helps, but it fails when applied to non-generator functions that return a value (while both tornado.gen.coroutine and asyncio.coroutine take pains to support such usage). The "raise TypeError" should be removed; just return the result without wrapping if it's not a generator. GeneratorWrapper also runs afoul of some places where I do explicit type checking instead of duck typing (isinstance(x, types.GeneratorType)). Using the Generator ABC doesn't work because the generator methods are set as attributes on __init__ instead of defined on the class. The methods should be defined on the class, even if they're overwritten with instance attributes later for speed. (related: inspect.iscoroutine is defined in terms of collections.abc.Coroutine. Should inspect.isgenerator be redefined to use the new collections.abc.Generator?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 07:08:23 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 10 Jun 2015 05:08:23 +0000 Subject: [issue24413] Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) raises NotImplementedError, but {}.keys().__or__(x) raises TypeError In-Reply-To: <1433827977.01.0.296186023212.issue24413@psf.upfronthosting.co.za> Message-ID: <1433912903.71.0.698344712928.issue24413@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 07:10:17 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 10 Jun 2015 05:10:17 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433913017.8.0.498657279623.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: > GeneratorWrapper helps, but it fails when applied to non-generator functions that return a value (while both tornado.gen.coroutine and asyncio.coroutine take pains to support such usage). The "raise TypeError" should be removed; just return the result without wrapping if it's not a generator. I think this is reasonable. I'll try it tomorrow to see if there are any corner cases, but I doubt there are any. > GeneratorWrapper also runs afoul of some places where I do explicit type checking instead of duck typing (isinstance(x, types.GeneratorType)). Using the Generator ABC doesn't work because the generator methods are set as attributes on __init__ instead of defined on the class. The methods should be defined on the class, even if they're overwritten with instance attributes later for speed. Sure, this can be fixed too. Could you please update types.coroutine locally and verify that it will work for Tornado? > (related: inspect.iscoroutine is defined in terms of collections.abc.Coroutine. Should inspect.isgenerator be redefined to use the new collections.abc.Generator?) Since abc.Generator is a new thing I guess we still can do that. Do you have a good use case for it? We need a good one to convince Larry to include this post-beta. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 08:16:39 2015 From: report at bugs.python.org (Tal Einat) Date: Wed, 10 Jun 2015 06:16:39 +0000 Subject: [issue24416] Return a namedtuple from date.isocalendar() In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za> Message-ID: <1433916999.34.0.147528869555.issue24416@psf.upfronthosting.co.za> Tal Einat added the comment: How about IsoCalendarDate? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 08:18:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 10 Jun 2015 06:18:00 +0000 Subject: [issue21907] Update Windows build batch scripts In-Reply-To: <1404328602.32.0.540869349126.issue21907@psf.upfronthosting.co.za> Message-ID: <20150610061757.66764.91215@psf.io> Roundup Robot added the comment: New changeset 4890a55c62ab by Zachary Ware in branch '2.7': Clean up/refactor the batch scripts used for building on Windows. https://hg.python.org/cpython/rev/4890a55c62ab New changeset a6ceb631c747 by Zachary Ware in branch '3.4': Clean up/refactor the batch scripts used for building on Windows. https://hg.python.org/cpython/rev/a6ceb631c747 New changeset e6a95bda2943 by Zachary Ware in branch '3.5': Merge forward extras beyond #21907 backport. https://hg.python.org/cpython/rev/e6a95bda2943 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 08:26:02 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 10 Jun 2015 06:26:02 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <1433917562.07.0.999944025419.issue22359@psf.upfronthosting.co.za> Martin Panter added the comment: koobs: It sounds like applying the fix for this bug to the Python 2 branch might satisfy you, right? It only seems to have been applied to 3.5+ so far. Matt: It sounds like you are trying to pre-compile $(PGEN) for the host, and then rely on it not being rebuilt. Maybe there is a better way, like changing the $(PGEN) command line to use a $(HOST_CC) or something. (I?m not familiar with the build system; certainly not when cross compiling.) But you could also try and identify the dependency that is causing $(PGEN) to be rebuilt, for example with Gnu Make: $ make --debug=b Parser/pgen Updating goal targets.... Prerequisite `Include/Python.h' is newer than target `Parser/acceler.o'. Must remake target `Parser/acceler.o'. [. . .] Prerequisite `Parser/acceler.o' is newer than target `Parser/pgen'. [. . .] Must remake target `Parser/pgen'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 09:26:00 2015 From: report at bugs.python.org (Carl Kleffner) Date: Wed, 10 Jun 2015 07:26:00 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433921160.06.0.107852554211.issue24385@psf.upfronthosting.co.za> Carl Kleffner added the comment: I experienced this behaviour by accident several times. Most likely this is due to inconsistenticies in different binutils and mingw-runtime versions/patches. See i.e. http://article.gmane.org/gmane.comp.gnu.binutils/46799 A robust solution is to exclusively use import libraries created by the toolchain used for building python extensions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 09:38:28 2015 From: report at bugs.python.org (koobs) Date: Wed, 10 Jun 2015 07:38:28 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <1433921908.6.0.443183639697.issue22359@psf.upfronthosting.co.za> koobs added the comment: martin: yes, if the incorrect usage of recursive make is in the 2.7 and 3.4 branches and the fix is relevant to the issues I reported. Of course all subsequent changes (fixing cross-builds) should be applied there too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 09:45:49 2015 From: report at bugs.python.org (Jens Diemer) Date: Wed, 10 Jun 2015 07:45:49 +0000 Subject: [issue24086] Configparser interpolation is unexpected In-Reply-To: <1430421130.2.0.837084015548.issue24086@psf.upfronthosting.co.za> Message-ID: <1433922349.98.0.941164242622.issue24086@psf.upfronthosting.co.za> Jens Diemer added the comment: IMHO i ran into the same bug, try to "./setup.py upload" with my new password in ~/.pypirc: configparser.InterpolationSyntaxError: '%' must be followed by '%' or '(', found: "%foobar" This is a limitation of the configparser... But what's about to validate this on the "set PyPi password view" ? So that's impossible to set a PyPi password which can't be parsed by configparser ? ---------- nosy: +jens _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 10:06:40 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 10 Jun 2015 08:06:40 +0000 Subject: [issue24421] Race condition compiling Modules/_math.c Message-ID: <1433923600.68.0.73894537311.issue24421@psf.upfronthosting.co.za> New submission from Martin Panter: Once or twice I have had the math or cmath modules fail to build. There seems to be a race condition, because the _math.c file seems to be compiled twice, once for each module. Attached is a GCC wrapper that should help reproduce this fairly consistently. First, build Python normally: $ ./configure $ make -j2 Then force Modules/_math.c to be recompiled using my wrapper script to amplify the race condition: $ touch Modules/_math.c $ rm build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o $ make -j2 CC=./slow-cc.py running build running build_ext building 'cmath' extension compiling for cmath ./slow-cc.py [. . .]/Modules/cmathmodule.o building 'math' extension ./slow-cc.py [. . .]/Modules/mathmodule.o ./slow-cc.py -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. -IInclude -I/usr/local/include -I/media/disk/home/proj/python/cpython/Include -I/media/disk/home/proj/python/cpython -c /media/disk/home/proj/python/cpython/Modules/_math.c -o build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o INITIAL COMPILE ./slow-cc.py -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. -IInclude -I/usr/local/include -I/media/disk/home/proj/python/cpython/Include -I/media/disk/home/proj/python/cpython -c /media/disk/home/proj/python/cpython/Modules/_math.c -o build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o RECOMPILE RECOMPIILE TRUNCATING INITIAL COMPILE FINISHED ./slow-cc.py -shared build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/mathmodule.o build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o -L/usr/local/lib -lm -o build/lib.linux-x86_64-3.6/math.cpython-36m-x86_64-linux-gnu.so build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o: file not recognized: File truncated collect2: error: ld returned 1 exit status RECOMPILE FINISHED ./slow-cc.py -shared build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/cmathmodule.o build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o -L/usr/local/lib -lm -o build/lib.linux-x86_64-3.6/cmath.cpython-36m-x86_64-linux-gnu.so Failed to build these modules: math ---------- components: Build files: slow-cc.py messages: 245121 nosy: vadmium priority: normal severity: normal status: open title: Race condition compiling Modules/_math.c type: behavior Added file: http://bugs.python.org/file39672/slow-cc.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 10:30:19 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 10 Jun 2015 08:30:19 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <1433925019.48.0.837026285405.issue22359@psf.upfronthosting.co.za> Martin Panter added the comment: My math and cmath issue seems to be completely separate. I opened Issue 24421 for that, so sorry for the noise here :) I think the patch here should be applied (or adapted if necessary) to the 3.4 and 2.7 branches. If it breaks cross compilation, then the cross compilation technique needs improving instead; perhaps see Issue 22625 for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 11:56:19 2015 From: report at bugs.python.org (Hector Cloud) Date: Wed, 10 Jun 2015 09:56:19 +0000 Subject: [issue24422] base64 not encode correctly Message-ID: <1433930179.84.0.22171571246.issue24422@psf.upfronthosting.co.za> New submission from Hector Cloud: I use Python 3.4.0 now. But its base64 encoding is not as expected. ---------------------------- import base64 ascii = base64.b64encode(u"YAU-interview-revised20120921".encode(), b'-_') print(ascii) ---------------------------- The result is b'WUFVLWludGVydmlldy1yZXZpc2VkMjAxMjA5MjE='. There is a character '=' at the end which is not expected. In my opinion, the result should contain characters [A-Za-z0-9] and '-_'. The '=' should not be in the encoding result. Is it a bug? ---------- components: Library (Lib) messages: 245123 nosy: Hector Cloud priority: normal severity: normal status: open title: base64 not encode correctly type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 12:02:59 2015 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 10 Jun 2015 10:02:59 +0000 Subject: [issue24422] base64 not encode correctly In-Reply-To: <1433930179.84.0.22171571246.issue24422@psf.upfronthosting.co.za> Message-ID: <1433930579.37.0.957149426895.issue24422@psf.upfronthosting.co.za> Ezio Melotti added the comment: No, this is expected. See http://en.wikipedia.org/wiki/Base64#Padding ---------- nosy: +ezio.melotti resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 12:48:17 2015 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 10 Jun 2015 10:48:17 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433913017.8.0.498657279623.issue24400@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: A couple of high level observations: 1. As Yury notes, more clearly separating coroutines and generators is the intent of the PEP. The computer could clearly cope with them being the same class, but humans tended to get confused. We were still blurring that line too much in the initial implementation, this patch aims to fix that by *really* introducing a separate class for native coroutines. 2. Missing integrations in other modules that are likely to result in misbehaviour in user code (such as the inspect module not accounting for the new ABCs) are good candidates for filing as behaviour bugs - finding that kind of gap in PEP implementations is one of the benefits of the beta period. 3. Integrating nicely with both asyncio and Tornado is a good pragmatic design goal to avoid making too many asyncio specific assumptions ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 13:38:56 2015 From: report at bugs.python.org (Jan Harkes) Date: Wed, 10 Jun 2015 11:38:56 +0000 Subject: [issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects In-Reply-To: <1433451133.89.0.124950032775.issue24385@psf.upfronthosting.co.za> Message-ID: <1433936336.24.0.892739018962.issue24385@psf.upfronthosting.co.za> Jan Harkes added the comment: @Carl.Kleffner: that is an interesting message but it discusses using binutils(/mingw?) generated import libraries with the MS linker. This bugreport was about two 64-bit objects that were accidentally included in an otherwise 32-bit library and it has been resolved. I am not entirely sure why people are anticipating possible problems for which I have seen no actual bug reports or build failures. Searching this bugtracker for mingw related reports shows 187 reports over the past 13.5 years and at first glance I don't see any about compatibility issues between versions. There are only 3 for mingw+libpython, one of which is this report. The various windows forks of mingw, maybe in an attempt to reach Visual C compatibility, may have as stable a format but the only failure I have personally seen was this 64-bit objects in a 32-bit library problem, which does look to me like a tool chain bug but luckily there was a relatively simple "--as-flags=--32" workaround. I just reread my comment and I it reads ruder than I meant it to be, I'm truly sorry for that. I appreciated reading the link you included to see some of those demons lurking in the depths. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 14:34:37 2015 From: report at bugs.python.org (Stefan Tatschner) Date: Wed, 10 Jun 2015 12:34:37 +0000 Subject: [issue24423] Fix wrong indentation in Doc/whatsnew/3.5.rst Message-ID: <1433939677.74.0.149159718564.issue24423@psf.upfronthosting.co.za> New submission from Stefan Tatschner: A list item which describes the changes of #22631 is badly indented. The attached (trivial) patch fixes that problem. ---------- assignee: docs at python components: Documentation files: fix-indentation.patch keywords: patch messages: 245127 nosy: docs at python, rumpelsepp priority: normal severity: normal status: open title: Fix wrong indentation in Doc/whatsnew/3.5.rst versions: Python 3.5 Added file: http://bugs.python.org/file39673/fix-indentation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 15:29:16 2015 From: report at bugs.python.org (Robert Haschke) Date: Wed, 10 Jun 2015 13:29:16 +0000 Subject: [issue24424] xml.dom.minidom: performance issue with Node.insertBefore() Message-ID: <1433942956.66.0.599460998017.issue24424@psf.upfronthosting.co.za> New submission from Robert Haschke: Node.insertBefore() has a serious performance issue: Using self.childNodes.index(refChild) it searches for the correct index in childNodes where the newChild should be inserted. However, index() is linear in time w.r.t. the size of childNodes. Hence, if there are many children, runtime dramatically increases. Adding a simple caching mechanism (caching the previously used reference) I was able to reduce runtime in my particular case from 16s to 1.6s, i.e. a factor of 10! ---------- components: XML files: minidom.insertBefore.patch keywords: patch messages: 245128 nosy: Robert Haschke priority: normal severity: normal status: open title: xml.dom.minidom: performance issue with Node.insertBefore() type: performance versions: Python 2.7 Added file: http://bugs.python.org/file39674/minidom.insertBefore.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 16:26:08 2015 From: report at bugs.python.org (Boris) Date: Wed, 10 Jun 2015 14:26:08 +0000 Subject: [issue672115] Assignment to __bases__ of direct object subclasses Message-ID: <1433946368.95.0.658011957982.issue672115@psf.upfronthosting.co.za> Changes by Boris : ---------- nosy: +borisompol _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 16:31:10 2015 From: report at bugs.python.org (Ben Darnell) Date: Wed, 10 Jun 2015 14:31:10 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433946670.84.0.727602826969.issue24400@psf.upfronthosting.co.za> Ben Darnell added the comment: With the two changes I described things appear to be working, although I've only done light testing so far. For inspect.isgenerator(), my use case is here: https://github.com/tornadoweb/tornado/blob/2971e857104f8d02fa9107a0e13f50170eb4f30d/tornado/gen.py#L222 I currently do isinstance(x, types.GeneratorType), which will fail if x is actually a GeneratorWrapper. I can change this to use collections.abc.Generator when it exists, but then I'd have to have some conditional logic to switch between collections.abc and types depending on what version I'm running on. It would be nice if that were encapsulated in inspect.isgenerator(). More generally, the inconsistency between isgenerator() and iscoroutine() is kind of odd. I would expect that either all inspect functions or none of them would use a suitable ABC if one exists. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 17:12:09 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 10 Jun 2015 15:12:09 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1433949129.93.0.450410568196.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: > With the two changes I described things appear to be working, although I've only done light testing so far. Glad to hear that! I've attached a new patch fixing types.coroutine per your request. > More generally, the inconsistency between isgenerator() and iscoroutine() is kind of odd. I would expect that either all inspect functions or none of them would use a suitable ABC if one exists. iscoroutine() is just a newer API than isgenerator(). I'll create a new issue for this soon. ---------- Added file: http://bugs.python.org/file39675/corotype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 17:24:22 2015 From: report at bugs.python.org (Joe Jevnik) Date: Wed, 10 Jun 2015 15:24:22 +0000 Subject: [issue24379] slice.literal notation In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1433949862.52.0.556556844252.issue24379@psf.upfronthosting.co.za> Joe Jevnik added the comment: >>> slice.literal[0] 0 >>> y = slice.literal[1:2] slice(1, 2, None) >>> slice.literal[0:1, ..., 3] (slice(0, 1, None), Ellipsis, 3) The way this object works right now does not create instances of some inner class of slice, instead, indexing it returns the key without modification. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 17:44:21 2015 From: report at bugs.python.org (Hayden Young) Date: Wed, 10 Jun 2015 15:44:21 +0000 Subject: [issue24425] Installer Vender Issue Message-ID: <1433951061.45.0.0884040195007.issue24425@psf.upfronthosting.co.za> New submission from Hayden Young: For some reason, my Python installer won't run properly. When I click install, after DISabling PIP in the installer (And with pip on), it tells me the following: "There is a problem with this windows installer package. A program required for this install to complete cannot be run. Contact your support personnel or package vendor." Can anyone help me here? I really need Python for school, but my laptop won't run this properly. If it's to do with my specs, they are this: Laptop: Dell Latitude E6230 (Non-SSD) Core: Intel i5 Processor PLEASE HELP! ---------- components: Installation messages: 245132 nosy: Hayden Young priority: normal severity: normal status: open title: Installer Vender Issue versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 17:52:53 2015 From: report at bugs.python.org (Tal Einat) Date: Wed, 10 Jun 2015 15:52:53 +0000 Subject: [issue24379] slice.literal notation In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1433951573.86.0.141302404496.issue24379@psf.upfronthosting.co.za> Tal Einat added the comment: So, is this in any ways different than NumPy's s_? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 17:57:31 2015 From: report at bugs.python.org (Joe Jevnik) Date: Wed, 10 Jun 2015 15:57:31 +0000 Subject: [issue24379] slice.literal notation In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1433951851.58.0.614749770846.issue24379@psf.upfronthosting.co.za> Joe Jevnik added the comment: It is a singleton, does not accept the `maketuple` flag, and is written in C. I did not know about the s_ attribute of numpy before writing this; however, I still think that moving this object to slice improves code clarity (s_ is not a super clear name). I also think that this behaviour belongs on the slice object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 18:20:03 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 10 Jun 2015 16:20:03 +0000 Subject: [issue24425] Installer Vender Issue In-Reply-To: <1433951061.45.0.0884040195007.issue24425@psf.upfronthosting.co.za> Message-ID: <1433953203.71.0.327838406561.issue24425@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +Extension Modules, Windows -Installation nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 18:28:13 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 10 Jun 2015 16:28:13 +0000 Subject: [issue24425] Installer Vender Issue In-Reply-To: <1433951061.45.0.0884040195007.issue24425@psf.upfronthosting.co.za> Message-ID: <1433953693.95.0.952999377821.issue24425@psf.upfronthosting.co.za> Steve Dower added the comment: Can you run the following command and then post the log.txt file it generates: msiexec /l*vx log.txt /i ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 18:49:22 2015 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 10 Jun 2015 16:49:22 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433946670.84.0.727602826969.issue24400@psf.upfronthosting.co.za> Message-ID: <55786A90.10005@behnel.de> Stefan Behnel added the comment: > I currently do isinstance(x, types.GeneratorType), which will fail if x > is actually a GeneratorWrapper. I can change this to use > collections.abc.Generator when it exists, but then I'd have to have some > conditional logic to switch between collections.abc and types depending > on what version I'm running on. I originally planned to make the next Cython release patch the Generator and Coroutine ABCs into collections.abc, but I now think it would be worth uploading an "abc_backports" package to PyPI instead that does that and on which asyncio, tornado and other packages could simply depend with a try-import. > It would be nice if that were > encapsulated in inspect.isgenerator(). +1, code that needs exactly a generator, e.g. for "gi_running" and friends, can still test for isinstance(obj, types.GeneratorType) in a completely backwards compatible way, which is more explicit anyway. > More generally, the inconsistency between isgenerator() and > iscoroutine() is kind of odd. I would expect that either all inspect > functions or none of them would use a suitable ABC if one exists. Yes, it's odd. Either way would work ("types is for types only" vs. "types includes protocols"), but having both disagree seems wrong. I think the mere fact that there is a higher level function than isinstance() suggests that it should really be more high level and not just doing exactly the same for all times. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 20:53:09 2015 From: report at bugs.python.org (Patrick Maupin) Date: Wed, 10 Jun 2015 18:53:09 +0000 Subject: [issue24426] re.split performance degraded significantly by capturing group Message-ID: <1433962389.05.0.538082969488.issue24426@psf.upfronthosting.co.za> New submission from Patrick Maupin: The addition of a capturing group in a re.split() pattern, e.g. using '(\n)' instead of '\n', causes a factor of 10 performance degradation. I use re.split a() lot, but never noticed the issue before. It was extremely noticeable on 1000 patterns in a 5BG file, though, requiring 40 seconds instead of 4. I have attached a script demonstrating the issue. I have tested on 2.7 and 3.4, but have no reason to believe it doesn't exist on other vesions as well. Thanks, Pat ---------- components: Regular Expressions files: splitter2.py messages: 245137 nosy: Patrick Maupin, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: re.split performance degraded significantly by capturing group type: performance versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file39676/splitter2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 20:54:25 2015 From: report at bugs.python.org (Jakub Wilk) Date: Wed, 10 Jun 2015 18:54:25 +0000 Subject: [issue7267] format method: c presentation type broken in 2.7 In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za> Message-ID: <1433962465.84.0.535574809117.issue7267@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 20:55:07 2015 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 10 Jun 2015 18:55:07 +0000 Subject: [issue24426] re.split performance degraded significantly by capturing group In-Reply-To: <1433962389.05.0.538082969488.issue24426@psf.upfronthosting.co.za> Message-ID: <1433962507.37.0.00871664916566.issue24426@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 21:04:04 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Wed, 10 Jun 2015 19:04:04 +0000 Subject: [issue24420] Documentation regressions from adding subprocess.run() In-Reply-To: <1433909056.73.0.964707918197.issue24420@psf.upfronthosting.co.za> Message-ID: <1433963044.0.0.807363564143.issue24420@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Thanks, this looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 21:18:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 10 Jun 2015 19:18:48 +0000 Subject: [issue24426] re.split performance degraded significantly by capturing group In-Reply-To: <1433962389.05.0.538082969488.issue24426@psf.upfronthosting.co.za> Message-ID: <1433963928.15.0.35706737942.issue24426@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Regular expression is optimized for the case when it starts with constant string or charset. It is no degradation when using '(\n)', but rather an optimization of '\n'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 21:26:56 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 10 Jun 2015 19:26:56 +0000 Subject: [issue24427] subclass of multiprocessing Connection segfault upon attribute acces Message-ID: <1433964415.99.0.226244144163.issue24427@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: The following segfaults in _PyObject_GenericGetAttrWithDict: """ from socket import socketpair from _multiprocessing import Connection class Crash(Connection): pass _, w = socketpair() Crash(w.fileno()).bar """ #0 _PyObject_GenericGetAttrWithDict (dict=0xa6b001c, name=0xb7281020, obj=0x8c12478) at Objects/object.c:1427 #1 PyObject_GenericGetAttr (obj=0x8c12478, name=0xb7281020) at Objects/object.c:1461 (gdb) p *(obj + obj->ob_type->tp_dictoffset) $8 = {ob_refcnt = 0, ob_type = 0x0} It's probably not specific to this example, but I'm not familiar enough with object construction/descriptors to know what's going on here. Note that the following atch fixes the crash, but I don't know why: """ --- a/Modules/_multiprocessing/connection.h Wed Apr 15 19:30:38 2015 +0100 +++ b/Modules/_multiprocessing/connection.h Wed Jun 10 20:25:15 2015 +0100 @@ -58,7 +58,7 @@ return NULL; } - self = PyObject_New(ConnectionObject, type); + self = type->tp_alloc(type, 0); if (self == NULL) return NULL; @@ -86,7 +86,7 @@ CLOSE(self->handle); Py_END_ALLOW_THREADS } - PyObject_Del(self); + Py_TYPE(self)->tp_free((PyObject*)self); } /* """ ---------- messages: 245140 nosy: neologix, pitrou priority: normal severity: normal stage: needs patch status: open title: subclass of multiprocessing Connection segfault upon attribute acces _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 21:34:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 10 Jun 2015 19:34:35 +0000 Subject: [issue24426] re.split performance degraded significantly by capturing group In-Reply-To: <1433962389.05.0.538082969488.issue24426@psf.upfronthosting.co.za> Message-ID: <1433964875.66.0.586634541722.issue24426@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Splitting with pattern '\n(?<=(\n))' produces the same result as with pattern '(\n)' and is as fast as with pattern '\n'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 21:42:08 2015 From: report at bugs.python.org (venkata suresh gummadillli) Date: Wed, 10 Jun 2015 19:42:08 +0000 Subject: [issue24428] Import sys,getopt is having issue while taking inputs Message-ID: <1433965328.43.0.612100341004.issue24428@psf.upfronthosting.co.za> New submission from venkata suresh gummadillli: [@outsidetried ~]$ python validate_json_adj.py [@outsidetried ~]$ python validate_json_adj.py -h validate_json.py -i [@outsidetried ~]$ python validate_json_adj.py -i hello.txt Input JSON file provided for verification: hello.txt [@outsidetried ~]$ python validate_json_adj.py -i firstfile Input JSON file provided for verification: firstfile [@outsidetried ~]$ python validate_json_adj.py -i -bash: syntax error near unexpected token `newline' [sureshgv at outsidetried ~]$ python validate_json_adj.py -i ?? Input JSON file provided for verification: ci [@outsidetried ~]$ python validate_json_adj.py -i ??? Input JSON file provided for verification: bf1 [@outsidetried ~]$ python validate_json_adj.py -i $#@% Input JSON file provided for verification: 0@% [@outsidetried ~]$ cat validate_json_adj.py #!/usr/bin/python """ """ import sys,getopt """ """ def main(argv): inputfile = '' try: opts, args = getopt.getopt(argv,"hi:",["input_file="]) except getopt.GetoptError: print 'validate_json.py -i ' sys.exit(2) for opt, arg in opts: if opt == '-h': print 'validate_json.py -i ' sys.exit() elif opt in ("-i", "--input_file"): inputfile = arg print 'Input JSON file provided for verification:', inputfile if __name__ == "__main__": main(sys.argv[1:]) ---------- components: Library (Lib) messages: 245142 nosy: venkata suresh gummadillli priority: normal severity: normal status: open title: Import sys,getopt is having issue while taking inputs type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 21:47:10 2015 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 10 Jun 2015 19:47:10 +0000 Subject: [issue24428] Import sys,getopt is having issue while taking inputs In-Reply-To: <1433965328.43.0.612100341004.issue24428@psf.upfronthosting.co.za> Message-ID: <1433965630.62.0.646313792022.issue24428@psf.upfronthosting.co.za> Eric V. Smith added the comment: This is not a problem with python, but rather with how bash interprets your program arguments. Try putting the arguments in single quotes, like: python validate_json_adj.py -i '$#@%' ---------- nosy: +eric.smith resolution: -> not a bug stage: -> resolved status: open -> closed type: behavior -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 22:16:59 2015 From: report at bugs.python.org (Patrick Maupin) Date: Wed, 10 Jun 2015 20:16:59 +0000 Subject: [issue24426] re.split performance degraded significantly by capturing group In-Reply-To: <1433962389.05.0.538082969488.issue24426@psf.upfronthosting.co.za> Message-ID: <1433967419.61.0.656860695251.issue24426@psf.upfronthosting.co.za> Patrick Maupin added the comment: 1) I have obviously oversimplified my test case, to the point where a developer thinks I'm silly enough to reach for the regex module just to split on a linefeed. 2) '\n(?<=(\n))' -- yes, of course, any casual user of the re module would immediately choose that as the most obvious thing to do. 3) My real regex is r'( [a-zA-Z0-9_]+ \[[0-9]+\][0-9:]+\].*\n)' because I am taking nasty broken output from a Cadence tool, fixing it up, and dumping it back out to a file. Yes, I'm sure this could be optimized, as well, but when I can just remove the parentheses and get a 10X speedup, and then figure out the string I meant to capture by looking at string lengths, shouldn't there at least be a warning that the re module has performance issues with capturing groups with split(), and casual users like me should figure out what the matching strings are some other way? I assumed that, since I saw almost exactly the same performance degradation with \n as I did with this, that that was a valid testcase. If that was a bad assumption and this is insufficient to debug it, I can submit a bigger testcase. But if this issue is going to be wontfixed for some reason, there should certainly be a documentation note added, because it is not intuitive that splitting 5GB of data into 1000 strings of around 5MB each should be 10X faster than doing the same thing, but also capturing the 1K ten-byte strings inbetween the big ones. Thanks, Pat ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 10 23:28:44 2015 From: report at bugs.python.org (Patrick Maupin) Date: Wed, 10 Jun 2015 21:28:44 +0000 Subject: [issue24426] re.split performance degraded significantly by capturing group In-Reply-To: <1433962389.05.0.538082969488.issue24426@psf.upfronthosting.co.za> Message-ID: <1433971724.82.0.333197218447.issue24426@psf.upfronthosting.co.za> Patrick Maupin added the comment: Just to be perfectly clear, this is no exaggeration: My original file was slightly over 5GB. I have approximately 1050 bad strings in it, averaging around 11 characters per string. If I split it without capturing those 1050 strings, it takes 3.7 seconds. If I split it and capture those 1050 strings, it takes 39 seconds. ISTM that 33 ms to create a capture group with a single 11 character string is excessive, so there is probably something else going on like excessive object copying, that just isn't noticeable on a smaller source string. In the small example I posted, if I replace the line: data = 100 * (200000 * ' ' + '\n') with data = 1000 * (500000 * ' ' + '\n') then I get approximately the same 3.7 second vs 39 second results on that (somewhat older) machine. I didn't start out with that in the example, because I thought the problem should still be obvious from the scaled down example. Obviously, your CPU numbers will be somewhat different. The question remains, though, why it takes around 60 million CPU cycles for each and every returned capture group. Or, to put it another way, why can I stop doing the capture group, and grab the same string with pure Python by looking at the string lengths of the intervening strings, well over 100 times faster than it takes for the re module to give me that group? Thanks, Pat ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 00:25:13 2015 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 10 Jun 2015 22:25:13 +0000 Subject: [issue17310] Ctypes callbacks shows problem on Windows Python (64bit) In-Reply-To: <1361980274.18.0.791136497364.issue17310@psf.upfronthosting.co.za> Message-ID: <1433975113.51.0.20953299694.issue17310@psf.upfronthosting.co.za> Vinay Sajip added the comment: Although Matt was able to work around his problem, this problem seems to still be present in 2.7 as well as all 3.x versions. I think I've found the cause of the problem: in 64-bit code, the calling conventions for passing structures by value are different. From this page: https://msdn.microsoft.com/en-us/library/zthk2dkh(v=vs.90).aspx I would point to "Structs/unions of size 8, 16, 32, or 64 bits and __m64 will be passed as if they were integers of the same size. Structs/unions other than these sizes will be passed as a pointer to memory allocated by the caller. For these aggregate types passed as a pointer (including __m128), the caller-allocated temporary memory will be 16-byte aligned." The code in ffi_prep_incoming_args_SYSV (see https://hg.python.org/cpython/file/a1b76c1c3be8/Modules/_ctypes/libffi_msvc/ffi.c#l368) assumes (see lines 399, 402) that all value parameters are always passed inline on the stack - which is plainly not as per the documentation I linked to, for 64-bit code. ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 00:28:19 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 10 Jun 2015 22:28:19 +0000 Subject: [issue24408] tkinter.font.Font.measure() broken in 3.5 In-Reply-To: <1433769737.94.0.512429608997.issue24408@psf.upfronthosting.co.za> Message-ID: <1433975299.81.0.850847766286.issue24408@psf.upfronthosting.co.za> Ned Deily added the comment: Test fails on OS X (10.10) with Cocoa Tk 8.6(.4) and 8.5(.18): ====================================================================== FAIL: test_families (test_tkinter.test_font.FontTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/27/root/fwd/Library/Frameworks/pytest_10.10.framework/Versions/2.7/lib/python2.7/lib-tk/test/test_tkinter/test_font.py", line 79, in test_families self.assertIn(self.font.actual('family'), families) AssertionError: '.Helvetica Neue DeskInterface' not found in ('Academy Engraved LET', 'Al Bayan', 'Al Nile', 'Al Tarikh', 'American Typewriter', 'Andale Mono', 'Arial', 'Arial Black', 'Arial Hebrew', 'Arial Hebrew Scholar', 'Arial Narrow', 'Arial Rounded MT Bold', 'Arial Unicode MS', 'Athelas', 'Avenir', 'Avenir Next', 'Avenir Next Condensed', 'Ayuthaya', 'Baghdad', 'Bangla MN', 'Bangla Sangam MN', 'Bank Gothic', 'Baoli SC', 'Baskerville', 'Beirut', 'Big Caslon', 'Blackmoor LET', 'BlairMdITC TT', 'Bodoni 72', 'Bodoni 72 Oldstyle', 'Bodoni 72 Smallcaps', 'Bodoni Ornaments', 'Bordeaux Roman Bold LET', 'Bradley Hand', 'Brush Script MT', 'Capitals', 'Chalkboard', 'Chalkboard SE', 'Chalkduster', 'Charter', 'Cochin', 'Comic Sans MS', 'Copperplate', 'Corsiva Hebrew', 'Courier', 'Courier New', 'Damascus', 'DecoType Naskh', 'Devanagari MT', 'Devanagari Sangam MN', 'Didot', 'DIN Alternate', 'DIN Condensed', 'Diwan Kufi', 'Diwan Thuluth', 'Euphemia UCAS', 'Farah', 'Farisi', 'Futura', 'GB18030 Bitmap', 'Geeza Pro', 'Geneva', 'Georgia', 'Gill Sans', 'Gujarati MT', 'Gujarati Sangam MN', 'GungSeo', 'Gurmukhi MN', 'Gurmukhi MT', 'Gurmukhi Sangam MN', 'Hannotate SC', 'Hannotate TC', 'HanziPen SC', 'HanziPen TC', 'HeadLineA', 'Heiti SC', 'Heiti TC', 'Helvetica', 'Helvetica Neue', 'Herculanum', 'Hiragino Kaku Gothic Pro', [...] ---------- nosy: +ned.deily resolution: fixed -> stage: resolved -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 00:30:43 2015 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 10 Jun 2015 22:30:43 +0000 Subject: [issue17310] Ctypes callbacks shows problem on Windows Python (64bit) In-Reply-To: <1361980274.18.0.791136497364.issue17310@psf.upfronthosting.co.za> Message-ID: <1433975443.56.0.719890695952.issue17310@psf.upfronthosting.co.za> Vinay Sajip added the comment: I note that the code for CFFI has a fix in ffi_prep_incoming_args_SYSV, as follows: #ifdef _WIN64 if (z > 8) { /* On Win64, if a single argument takes more than 8 bytes, then it is always passed by reference. */ *p_argv = *((void**) argp); z = 8; } else #endif *p_argv = (void*) argp; /* The original code, works for 32-bit */ (Source: https://bitbucket.org/cffi/cffi/src/abc8ff5b2885b3d9f22bbb314a011b8dd63c9e14/c/libffi_msvc/ffi.c?at=default) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 00:44:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 10 Jun 2015 22:44:44 +0000 Subject: [issue24423] Fix wrong indentation in Doc/whatsnew/3.5.rst In-Reply-To: <1433939677.74.0.149159718564.issue24423@psf.upfronthosting.co.za> Message-ID: <20150610224441.40314.83058@psf.io> Roundup Robot added the comment: New changeset 4e7dcf64bba7 by Ned Deily in branch '3.5': Issue #24423: Fix formatting error in 3.5 whatsnew https://hg.python.org/cpython/rev/4e7dcf64bba7 New changeset 3156dd82df2d by Ned Deily in branch 'default': Issue #24423: merger from 3.5 https://hg.python.org/cpython/rev/3156dd82df2d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 00:45:20 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 10 Jun 2015 22:45:20 +0000 Subject: [issue24423] Fix wrong indentation in Doc/whatsnew/3.5.rst In-Reply-To: <1433939677.74.0.149159718564.issue24423@psf.upfronthosting.co.za> Message-ID: <1433976320.66.0.334203153785.issue24423@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report! ---------- nosy: +ned.deily resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 00:46:15 2015 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 10 Jun 2015 22:46:15 +0000 Subject: [issue17310] Ctypes callbacks shows problem on Windows Python (64bit) In-Reply-To: <1361980274.18.0.791136497364.issue17310@psf.upfronthosting.co.za> Message-ID: <1433976375.01.0.47690569171.issue17310@psf.upfronthosting.co.za> Vinay Sajip added the comment: I can confirm that the CFFI patch works as expected on Python 2.7.10. ---------- stage: -> test needed versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 01:12:08 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 10 Jun 2015 23:12:08 +0000 Subject: [issue24408] tkinter.font.Font.measure() broken in 3.5 In-Reply-To: <1433769737.94.0.512429608997.issue24408@psf.upfronthosting.co.za> Message-ID: <1433977928.04.0.605455613876.issue24408@psf.upfronthosting.co.za> Martin Panter added the comment: Some quick googling suggests this ?.Helvetica Neue DeskInterface? font is real, and because it begins with a full stop it may be normally hidden from the normal list of fonts. Perhaps the test could be modified to just check the two functions separately: * families() returns a non-trivial sequence of font names * actual("family") returns a non-trivial string ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 02:56:57 2015 From: report at bugs.python.org (Alex Lord) Date: Thu, 11 Jun 2015 00:56:57 +0000 Subject: [issue16864] sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement In-Reply-To: <1357320260.32.0.764505068506.issue16864@psf.upfronthosting.co.za> Message-ID: <1433984217.59.0.747482920835.issue16864@psf.upfronthosting.co.za> Alex Lord added the comment: Adding a patch for 3.6 since 3.5 is in beta. ---------- versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file39677/replace_lastrowid_3_6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 06:40:54 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 11 Jun 2015 04:40:54 +0000 Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments disappeared In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za> Message-ID: <1433997654.03.0.334834953151.issue23391@psf.upfronthosting.co.za> Martin Panter added the comment: New patch with the following changes. Let me know what you think. * Added extra markup for OSError attributes and constructor signature * Explained how ?winerror? works with and without Windows * Added ?filename2? argument * Update tests for filename2 defaulting to None For reference, the argument handling seems to be in oserror_parse_args(), at Objects/exceptions.c:724, and related functions. ---------- versions: +Python 3.6 Added file: http://bugs.python.org/file39678/os-error-args.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 06:45:46 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 11 Jun 2015 04:45:46 +0000 Subject: [issue24324] Remove -Wunreachable-code flag In-Reply-To: <1432907477.51.0.798249204562.issue24324@psf.upfronthosting.co.za> Message-ID: <1433997946.55.0.983725021577.issue24324@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 06:46:03 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 11 Jun 2015 04:46:03 +0000 Subject: [issue24324] Remove -Wunreachable-code flag In-Reply-To: <1432907477.51.0.798249204562.issue24324@psf.upfronthosting.co.za> Message-ID: <1433997963.97.0.186916045079.issue24324@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 07:50:58 2015 From: report at bugs.python.org (koobs) Date: Thu, 11 Jun 2015 05:50:58 +0000 Subject: [issue24175] Consistent test_utime() failures on FreeBSD In-Reply-To: <1431521100.95.0.772714139961.issue24175@psf.upfronthosting.co.za> Message-ID: <1434001858.59.0.810299153878.issue24175@psf.upfronthosting.co.za> koobs added the comment: test_utime is now consistently failing on 3.4, 3.5 and default ---------- priority: normal -> high title: Sporadic test_utime() failures on FreeBSD -> Consistent test_utime() failures on FreeBSD versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 08:04:20 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 11 Jun 2015 06:04:20 +0000 Subject: [issue24175] Consistent test_utime() failures on FreeBSD In-Reply-To: <1431521100.95.0.772714139961.issue24175@psf.upfronthosting.co.za> Message-ID: <1434002660.13.0.677773247103.issue24175@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 08:11:51 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 11 Jun 2015 06:11:51 +0000 Subject: [issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping. In-Reply-To: <1432750979.18.0.523128349285.issue24303@psf.upfronthosting.co.za> Message-ID: <1434003111.04.0.923663920813.issue24303@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Here's a patch against 2.7 using _PyOS_URandom(): it should apply as-is to 3.3. ---------- keywords: +patch nosy: +neologix versions: +Python 3.3 Added file: http://bugs.python.org/file39679/mp_sem_race.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 09:01:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Jun 2015 07:01:29 +0000 Subject: [issue24420] Documentation regressions from adding subprocess.run() In-Reply-To: <1433909056.73.0.964707918197.issue24420@psf.upfronthosting.co.za> Message-ID: <1434006089.17.0.466789404656.issue24420@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 09:06:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Jun 2015 07:06:34 +0000 Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments disappeared In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za> Message-ID: <1434006394.25.0.0130446694977.issue23391@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 09:34:54 2015 From: report at bugs.python.org (Suzumizaki) Date: Thu, 11 Jun 2015 07:34:54 +0000 Subject: [issue24307] pip error on windows whose current user name contains non-ascii characters In-Reply-To: <1432779659.79.0.171307025039.issue24307@psf.upfronthosting.co.za> Message-ID: <1434008094.22.0.80245460039.issue24307@psf.upfronthosting.co.za> Changes by Suzumizaki : ---------- nosy: +Suzumizaki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 09:36:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Jun 2015 07:36:50 +0000 Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments disappeared In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za> Message-ID: <1434008210.74.0.705479189976.issue23391@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It should be documented (if still not) that OSError() constructor can return an instance of OSError subclass, depending on errno value. >>> OSError(errno.ENOENT, 'no such file') FileNotFoundError(2, 'no such file') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 10:08:06 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 11 Jun 2015 08:08:06 +0000 Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments disappeared In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za> Message-ID: <1434010086.18.0.472046505737.issue23391@psf.upfronthosting.co.za> Martin Panter added the comment: Good point Serhiy about returning subclasses. I?ll see about making that more explicit if I can?t find it already documented somewhere. Regarding the number of arguments, I resisted documenting what happens to extra arguments since the behaviour has changed over time, and it doesn?t seem that it would be very useful. IMO it would be better to say passing extra arguments is not supported. But if others disagree, I can have a go at documenting the existing and/or past behaviour. Python 3.3.3 under Wine: >>> OSError(None, "Not found", "file", 3).args (2, 'Not found', 'file', 3) >>> OSError(ENOENT, "Not found", "file", None).args (2, 'Not found', 'file', None) Python 3.6.0a0 under Linux: >>> OSError(ENOENT, "Not found", "file", None).args (2, 'Not found') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 10:18:50 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 11 Jun 2015 08:18:50 +0000 Subject: [issue1260171] subprocess: more general (non-buffering) communication Message-ID: <1434010730.13.0.837072664282.issue1260171@psf.upfronthosting.co.za> Martin Panter added the comment: The non-blocking read and write features proposed in Issue 1191964 wouldn?t be sufficient. Perhaps they might be useful for implementing this feature on Windows though; I?m not sure. And a non-blocking write on Posix may be slightly more efficient as well, removing the limitation of copying in chunks of PIPE_BUF bytes. Ian?s original patch posted here proposes a version of communicate() which accepts a file reader for the subprocess?s input, and file writers for the subprocess?s outputs. Another option could be something like my SubprocessWriter class . It provides a file writer interface for the caller to write to the subprocess?s input, while copying data from the subprocess?s output behind the scenes. I used it to stream a tar file, as it is written by the ?tarfile? module, into a GPG subprocess to create a digital signature, while writing the output of GPG into a BytesIO buffer. Using Unix command pipeline pseudocode, it is used a bit like this: tarfile.open(mode="w|") | Popen("gpg") | BytesIO() ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 10:57:50 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 11 Jun 2015 08:57:50 +0000 Subject: [issue12833] raw_input misbehaves when readline is imported In-Reply-To: <1314205212.4.0.313319940132.issue12833@psf.upfronthosting.co.za> Message-ID: <1434013070.11.0.25163221808.issue12833@psf.upfronthosting.co.za> Martin Panter added the comment: The patch looks find for Python 3. The sample code should probably be adapted to raw_input() for Python 2. ---------- nosy: +vadmium stage: needs patch -> commit review versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 11:07:39 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 11 Jun 2015 09:07:39 +0000 Subject: [issue12833] raw_input misbehaves when readline is imported In-Reply-To: <1314205212.4.0.313319940132.issue12833@psf.upfronthosting.co.za> Message-ID: <1434013659.6.0.712584403453.issue12833@psf.upfronthosting.co.za> Martin Panter added the comment: Actually, there should either be a space before the double-colons, or the full stops should be removed. So either of these options: . . . when a backspace is typed. :: . . . when a backspace is typed:: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 12:26:13 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 11 Jun 2015 10:26:13 +0000 Subject: [issue672115] Assignment to __bases__ of direct object subclasses Message-ID: <1434018373.14.0.804320026042.issue672115@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- type: behavior -> enhancement versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 12:59:30 2015 From: report at bugs.python.org (erik flister) Date: Thu, 11 Jun 2015 10:59:30 +0000 Subject: [issue24429] msvcrt error when embedded Message-ID: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> New submission from erik flister: normally, CDLL(find_library('c')) is fine. but when running embedded in a context that uses a different runtime version, this will cause an error (example: http://stackoverflow.com/questions/30771380/how-use-ctypes-with-msvc-dll-from-within-matlab-on-windows/). using ctypes.cdll.msvcrt apparently finds the correct runtime. i was surprised by this, i thought this was supposed to be identical to find_library('c'). in any case, some libraries (uuid.py) use the one that breaks. can you either switch everything to ctypes.cdll.msvcrt, or have find_library('c') change to be identical to it? ---------- components: Library (Lib), Windows, ctypes messages: 245162 nosy: erik flister, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: msvcrt error when embedded type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 14:37:16 2015 From: report at bugs.python.org (koobs) Date: Thu, 11 Jun 2015 12:37:16 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1434026236.75.0.712352989741.issue15745@psf.upfronthosting.co.za> koobs added the comment: I have tested both patches (test_os by trent) and almostequaltime by harrison on the default branch, and *both* result in test_os passing. They also resolve the test_utime failure reported in bug 24175 and very likely 16287 (born from this issue) ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 14:38:54 2015 From: report at bugs.python.org (koobs) Date: Thu, 11 Jun 2015 12:38:54 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1434026334.59.0.949478389651.issue15745@psf.upfronthosting.co.za> koobs added the comment: Hmm, that was supposed to be: issue 24175 and very likely issue 16287 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 15:53:41 2015 From: report at bugs.python.org (era) Date: Thu, 11 Jun 2015 13:53:41 +0000 Subject: [issue24430] ZipFile.read() cannot decrypt multiple members from Windows 7zfm Message-ID: <1434030821.12.0.415764944762.issue24430@psf.upfronthosting.co.za> New submission from era: The attached archive from the Windows version of the 7z file manager (7zFM version 9.20) cannot be decrypted into memory. The first file succeeds, but the second one fails. The following small program is able to unzip other encrypted zip archives (tried one created by Linux 7z version 9.04 on Debian from the package p7zip-full, and one from plain zip 3.0-3 which comes from the InfoZip distribution, as well as a number of archives of unknown provenance) but fails on the attached one. from zipfile import ZipFile from sys import argv container = ZipFile(argv[1]) for member in container.namelist(): print("member %s" % member) try: extracted = container.read(member) print("extracted %s" % repr(extracted)[0:64]) except RuntimeError, err: extracted = container.read(member, 'hello') container.setpassword('hello') print("extracted with password 'hello': %s" % repr(extracted)[0:64]) Here is the output and backtrace: member hello/ extracted '' member hello/goodbye.txt Traceback (most recent call last): File "./nst.py", line 13, in extracted = container.read(member, 'hello') File "/usr/lib/python2.6/zipfile.py", line 834, in read return self.open(name, "r", pwd).read() File "/usr/lib/python2.6/zipfile.py", line 901, in open raise RuntimeError("Bad password for file", name) RuntimeError: ('Bad password for file', 'hello/goodbye.txt') The 7z command is able to extract it just fine: $ 7z -phello x /tmp/hello.zip 7-Zip 9.04 beta Copyright (c) 1999-2009 Igor Pavlov 2009-05-30 p7zip Version 9.04 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,1 CPU) Processing archive: /tmp/hello.zip Extracting hello Extracting hello/goodbye.txt Extracting hello/hello.txt Everything is Ok Folders: 1 Files: 2 Size: 15 Compressed: 560 ---------- files: hello.zip messages: 245165 nosy: era priority: normal severity: normal status: open title: ZipFile.read() cannot decrypt multiple members from Windows 7zfm Added file: http://bugs.python.org/file39680/hello.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 15:54:33 2015 From: report at bugs.python.org (era) Date: Thu, 11 Jun 2015 13:54:33 +0000 Subject: [issue24430] ZipFile.read() cannot decrypt multiple members from Windows 7zFM In-Reply-To: <1434030821.12.0.415764944762.issue24430@psf.upfronthosting.co.za> Message-ID: <1434030873.61.0.636635735069.issue24430@psf.upfronthosting.co.za> Changes by era : ---------- components: +Library (Lib) title: ZipFile.read() cannot decrypt multiple members from Windows 7zfm -> ZipFile.read() cannot decrypt multiple members from Windows 7zFM type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 16:00:09 2015 From: report at bugs.python.org (era) Date: Thu, 11 Jun 2015 14:00:09 +0000 Subject: [issue24430] ZipFile.read() cannot decrypt multiple members from Windows 7zFM In-Reply-To: <1434030821.12.0.415764944762.issue24430@psf.upfronthosting.co.za> Message-ID: <1434031209.31.0.752404681968.issue24430@psf.upfronthosting.co.za> era added the comment: The call to .setpassword() doesn't seem to make any difference. I was hoping it would offer a workaround, but it didn't. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 16:29:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Jun 2015 14:29:22 +0000 Subject: [issue24430] ZipFile.read() cannot decrypt multiple members from Windows 7zFM In-Reply-To: <1434030821.12.0.415764944762.issue24430@psf.upfronthosting.co.za> Message-ID: <1434032962.03.0.291746689531.issue24430@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The file looks not conforming ZIP file specification. The 12th byte of an encryption header doesn't match the MSB of the CRC, therefore the error. And even ignoring it, compression type 99 is not supported by the zipfile module and even is not mentioned in the specification. With what command this archive was created? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 16:30:09 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 11 Jun 2015 14:30:09 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1434033009.9.0.574728987696.issue15745@psf.upfronthosting.co.za> Larry Hastings added the comment: Of the two I prefer Harrison Grundy's patch, simply because it's shorter. What OS / filesystem did you run the test on, koobs? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 16:40:01 2015 From: report at bugs.python.org (koobs) Date: Thu, 11 Jun 2015 14:40:01 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1434033601.89.0.607791870475.issue15745@psf.upfronthosting.co.za> koobs added the comment: Larry: The same two hosts that the FreeBSD Python buildslaves run on :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 16:41:19 2015 From: report at bugs.python.org (koobs) Date: Thu, 11 Jun 2015 14:41:19 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1434033679.38.0.307053493667.issue15745@psf.upfronthosting.co.za> koobs added the comment: Additionally on koobs-freebsd9, in my home directory (which is on ZFS) The buildbot home directories are on UFS ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 16:54:14 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 11 Jun 2015 14:54:14 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1434034454.68.0.974696807567.issue15745@psf.upfronthosting.co.za> R. David Murray added the comment: Note that the shorter patch means that the test is not actually testing what the comments say it is testing, so either the comments should admit we are checking that the result is "something close to what we set", or the longer fix should be used so as to continue to use the more rigorous test on platforms that support it. Ideally the latter. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 16:59:12 2015 From: report at bugs.python.org (Martin Teichmann) Date: Thu, 11 Jun 2015 14:59:12 +0000 Subject: [issue24431] StreamWriter.drain is not callable concurrently Message-ID: <1434034752.25.0.200116855736.issue24431@psf.upfronthosting.co.za> New submission from Martin Teichmann: Currently there is an assert statement asserting that no two tasks (asyncio tasks, that is) can use StreamWriter.drain at the same time. This is a weird limitiation, if there are two tasks writing to the same network socket, there is no reason why not both of them should drain the socket after (or before) writing to it. A simple bug fix is attached. ---------- components: asyncio files: patch messages: 245172 nosy: Martin.Teichmann, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: StreamWriter.drain is not callable concurrently type: behavior versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39681/patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 17:05:25 2015 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 11 Jun 2015 15:05:25 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b Message-ID: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> New submission from Alex Gaynor: https://www.openssl.org/news/secadv_20150611.txt ---------- components: Library (Lib) keywords: security_issue messages: 245173 nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, paul.moore, pitrou, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Upgrade windows builds to use OpenSSL 1.0.2b _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 17:25:25 2015 From: report at bugs.python.org (koobs) Date: Thu, 11 Jun 2015 15:25:25 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1434036325.1.0.769089489911.issue15745@psf.upfronthosting.co.za> koobs added the comment: Can a test be made to show a message (similar to a skipIf reason=) mentioning that a reduced precision is being used for certain tests? It would be nice not to have to remember this issue as platform support changes (reads: improves) over time. Not withstanding, it's also apparent that there may be an underlying rounding bug or race condition that ultimately causes some of the assertions in this tests to be false, which is the premise behind Harrisons assertAlmostEqual patch (matching other tests) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 18:10:34 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 11 Jun 2015 16:10:34 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434039034.62.0.549605414939.issue24429@psf.upfronthosting.co.za> Steve Dower added the comment: msvcrt isn't the right version, it just happens to load. It's actually an old, basically unsupported version. The problem would seem to be that Python 2.7 does not activate its activation context before loading msvcrt90 via ctypes. Eryksun (nosied - hope you're the same one :) ) posted a comment on the SO post with a link to a separate answer that shows how to do it, but it would be better for MATLAB to embed the manifest in their host executable if they're going to load the DLL directly. We could probably also condition uuid to not do that check on Windows, since I don't think those functions will ever exist, at least against 2.7 they won't. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 18:32:20 2015 From: report at bugs.python.org (=?utf-8?b?0J7Qu9C10LMg0JjQstCw0L3QvtCy?=) Date: Thu, 11 Jun 2015 16:32:20 +0000 Subject: [issue24433] There is no asyncio.ensure_future in Python 3.4.3 Message-ID: <1434040340.54.0.582208217128.issue24433@psf.upfronthosting.co.za> New submission from ???? ??????: Docs claims there there is asyncio.ensure_future https://docs.python.org/3/library/asyncio-task.html?highlight=ensure_future#asyncio.ensure_future but example from docs does'nt work: import asyncio loop = asyncio.get_event_loop() tasks = [ asyncio.ensure_future(print("asasda")), ] loop.run_until_complete(asyncio.wait(tasks)) loop.close() Fails with: AttributeError: 'module' object has no attribute 'ensure_future' ---------- assignee: docs at python components: Documentation messages: 245176 nosy: docs at python, ???? ?????? priority: normal severity: normal status: open title: There is no asyncio.ensure_future in Python 3.4.3 type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 18:38:10 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 11 Jun 2015 16:38:10 +0000 Subject: [issue24433] There is no asyncio.ensure_future in Python 3.4.3 In-Reply-To: <1434040340.54.0.582208217128.issue24433@psf.upfronthosting.co.za> Message-ID: <1434040690.48.0.4119663846.issue24433@psf.upfronthosting.co.za> Zachary Ware added the comment: The docs also say "New in version 3.4.4" :) ---------- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 19:56:31 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 11 Jun 2015 17:56:31 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1434045391.87.0.308758772517.issue24432@psf.upfronthosting.co.za> Ned Deily added the comment: Marking as release blocker for 3.5.0 ---------- nosy: +benjamin.peterson, larry, ned.deily priority: normal -> release blocker stage: -> needs patch versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 20:07:09 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 11 Jun 2015 18:07:09 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <55786A90.10005@behnel.de> Message-ID: Guido van Rossum added the comment: FYI I am on vacation and don't have the bandwidth to look into this, so I hope you will all work together to find a solution without my help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 20:57:53 2015 From: report at bugs.python.org (Caleb Levy) Date: Thu, 11 Jun 2015 18:57:53 +0000 Subject: [issue24434] ItemsView.__contains__ does not mimic dict_items Message-ID: <1434049073.59.0.107157683253.issue24434@psf.upfronthosting.co.za> Changes by Caleb Levy : ---------- components: Library (Lib) nosy: clevy, rhettinger, stutzbach priority: normal severity: normal status: open title: ItemsView.__contains__ does not mimic dict_items type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 21:07:34 2015 From: report at bugs.python.org (Chris Angelico) Date: Thu, 11 Jun 2015 19:07:34 +0000 Subject: [issue24435] Grammar/Grammar points to outdated guide Message-ID: <1434049654.36.0.351948731258.issue24435@psf.upfronthosting.co.za> New submission from Chris Angelico: Grammar/Grammar points to PEP 306, which points instead to the dev guide. The exact link is not provided, but it'd be useful to skip the PEP altogether and just link to https://docs.python.org/devguide/grammar.html in the file. ---------- messages: 245180 nosy: Rosuav priority: normal severity: normal status: open title: Grammar/Grammar points to outdated guide _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 21:19:32 2015 From: report at bugs.python.org (Andrew) Date: Thu, 11 Jun 2015 19:19:32 +0000 Subject: [issue22483] Copyright infringement on PyPI In-Reply-To: <1411575168.32.0.637271338488.issue22483@psf.upfronthosting.co.za> Message-ID: <1434050372.33.0.204095014889.issue22483@psf.upfronthosting.co.za> Andrew added the comment: So, I think I need to explain the situation. At first, changes in package was made by me, but package was intended for use in internal pypi (in scope of company). I don't know how it appeared here. Why did I do that? Original package was not installable via pip at all. What was changed? MANIFEST.in (just one line) and nothing more. ---------- nosy: +andrew.pypi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 21:20:51 2015 From: report at bugs.python.org (Caleb Levy) Date: Thu, 11 Jun 2015 19:20:51 +0000 Subject: [issue24434] ItemsView.__contains__ does not mimic dict_items Message-ID: <1434050451.28.0.415875303865.issue24434@psf.upfronthosting.co.za> New submission from Caleb Levy: The current implementation ItemsView.__contains__ reads class ItemsView(MappingView, Set): ... def __contains__(self, item): key, value = item try: v = self._mapping[key] except KeyError: return False else: return v == value ... This poses several problems. First, any non-iterable or iterable not having exactly two elements will raise an error instead of returning false. Second, an ItemsView object is roughly the same as a set of tuple-pairs hashed by the first element. Thus, for example, ["a", 1] in d.items() will return False for any dict d, yet in the current ItemsView implementation, this is True. The patch changes behavior to immediately return false for non-tuple items and tuples not of length 2, avoiding unnecessary exceptions. It also adds tests to collections which fail under the old behavior and pass with the update. ---------- keywords: +patch Added file: http://bugs.python.org/file39682/ItemsView_contains.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 21:21:11 2015 From: report at bugs.python.org (Neale Ferguson) Date: Thu, 11 Jun 2015 19:21:11 +0000 Subject: [issue23830] Add AF_IUCV support to sockets In-Reply-To: <1427828484.47.0.0998681334057.issue23830@psf.upfronthosting.co.za> Message-ID: <1434050471.36.0.144496550857.issue23830@psf.upfronthosting.co.za> Neale Ferguson added the comment: Updated patch against head (96580:3156dd82df2d). Built on s390x and x86_64. Test suite ran on both - tests successfully ignored on x86_64 and passed on s390x. ---------- versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file39683/af_iucv_cpython.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 22:22:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Jun 2015 20:22:51 +0000 Subject: [issue24426] re.split performance degraded significantly by capturing group In-Reply-To: <1433962389.05.0.538082969488.issue24426@psf.upfronthosting.co.za> Message-ID: <1434054171.6.0.295017496904.issue24426@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that adds more optimizations for searching patterns that starts with a literal string and groups. In particular it includes a case when a pattern starts with a group containing single character. Examples: $ ./python -m timeit -s "import re; p = re.compile('(\n)'); s = ('a'*100 + '\n')*1000" -- "p.split(s)" Unpatched: 100 loops, best of 3: 4.58 msec per loop Patched : 1000 loops, best of 3: 562 usec per loop $ ./python -m timeit -s "import re; p = re.compile('(\n\r)'); s = ('a'*100 + '\n\r')*1000" -- "p.split(s)" Unpatched: 100 loops, best of 3: 3.1 msec per loop Patched : 1000 loops, best of 3: 663 usec per loop For comparison: $ ./python -m timeit -s "import re; p = re.compile('\n'); s = ('a'*100 + '\n')*1000" -- "p.split(s)" 1000 loops, best of 3: 329 usec per loop $ ./python -m timeit -s "import re; p = re.compile('\n\r'); s = ('a'*100 + '\n\r')*1000" -- "p.split(s)" 1000 loops, best of 3: 338 usec per loop Optimized also more complex but rare cases, such as '\n()\r' or '((\n)(\r))'. Fast searching no longer can be disabled. ---------- assignee: -> serhiy.storchaka keywords: +patch stage: -> patch review versions: +Python 3.6 -Python 2.7, Python 3.4 Added file: http://bugs.python.org/file39684/re_literal_prefix_with_groups.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 22:24:52 2015 From: report at bugs.python.org (Michael Ensslin) Date: Thu, 11 Jun 2015 20:24:52 +0000 Subject: [issue24436] _PyTraceback_Add has no const qualifier for its char * arguments Message-ID: <1434054292.35.0.944686887599.issue24436@psf.upfronthosting.co.za> New submission from Michael Ensslin: The prototype for the public API function _PyTraceback_Add is declared _PyTraceback_Add(char *, char *, int); Internally, its char * arguments are passed verbatim to PyCode_NewEmpty, which takes const char * arguments. The missing 'const' qualifier for the arguments of _PyTraceback_Add thus serves no purpose, and means that C++ code can't invoke the method with const char * arguments. I've attached a proposed patch. I can't think of any negative consequences from adding the 'const' qualifier (famous last words). ---------- components: Interpreter Core files: const.patch keywords: patch messages: 245185 nosy: mic-e priority: normal severity: normal status: open title: _PyTraceback_Add has no const qualifier for its char * arguments versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39685/const.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 22:25:44 2015 From: report at bugs.python.org (Michael Ensslin) Date: Thu, 11 Jun 2015 20:25:44 +0000 Subject: [issue24436] _PyTraceback_Add has no const qualifier for its char * arguments In-Reply-To: <1434054292.35.0.944686887599.issue24436@psf.upfronthosting.co.za> Message-ID: <1434054344.52.0.355110781834.issue24436@psf.upfronthosting.co.za> Changes by Michael Ensslin : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 23:09:35 2015 From: report at bugs.python.org (erik flister) Date: Thu, 11 Jun 2015 21:09:35 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434056975.86.0.310297835719.issue24429@psf.upfronthosting.co.za> erik flister added the comment: > it would be better for MATLAB to embed the manifest in their host executable if they're going to load the DLL directly. can you help me understand? as far as i could tell, we need python to use the msvcr*.dll that comes with matlab, not v/v. it's hard (as a customer) to get mathworks (matlab's author) to do anything, but if the fix would best be done by them, they might listen to "official python muckity-mucks," especially since their python integration is relatively new... no idea how to find out who to contact there though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 23:12:50 2015 From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Freitas?=) Date: Thu, 11 Jun 2015 21:12:50 +0000 Subject: [issue24330] Idle doc: explain "Configure Idle" not in "Options" on OSX, etc. In-Reply-To: <1432962360.31.0.591497904103.issue24330@psf.upfronthosting.co.za> Message-ID: <1434057170.37.0.47119155852.issue24330@psf.upfronthosting.co.za> Andr? Freitas added the comment: I have added the explanation in the Docs and IDLE help file. Found also that IDLE help.txt is out of sync with the Docs and needs to be fixed. I will open a new Issue. ---------- keywords: +patch nosy: +Andr? Freitas Added file: http://bugs.python.org/file39686/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 23:18:17 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 11 Jun 2015 21:18:17 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434057497.49.0.0447540985136.issue24429@psf.upfronthosting.co.za> Steve Dower added the comment: Python needs to be recompiled to use a different CRT, and that will break all existing extension modules (.pyd's). That said, in some situations it is the right answer, typically because existing extension modules would be broken anyway, but I don't think that applies here. To load msvcr90.dll, you need to declare in your executable which version you want to use using a manifest. This enables side-by-side use of the CRT, so different programs can use different versions and they are all managed by the operating system (for security fixes, etc.). Otherwise, you get hundreds of copies of the CRT and they are likely to be lacking the latest patches. A way to hack in the manifest is to put it alongside the executable. You could take the file from http://stackoverflow.com/questions/27389227/how-do-i-load-a-c-dll-from-the-sxs-in-python/27392347#27392347 and put it alongside the MATLAB executable as "matlab.exe.manifest" or whatever, which avoids having to get Mathworks involved, and that might allow you to load msvcr90.dll. If they've already embedded a manifest into the executable (which is very likely), then I don't know which one will win or what effects may occur if the original one is ignored. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 23:31:40 2015 From: report at bugs.python.org (erik flister) Date: Thu, 11 Jun 2015 21:31:40 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434058300.48.0.464232852878.issue24429@psf.upfronthosting.co.za> erik flister added the comment: thanks - i still don't understand tho. if python would have to be recompiled to use a different crt, why wouldn't matlab? if a manifest could fix matlab, why couldn't one fix python? i ran into all this trying to get shapely to load in matlab, and using msvcrt instead of find_library('c') solved it there: https://github.com/Toblerity/Shapely/issues/104#issuecomment-111050335 that solution seems so much easier than any of this manifest/sxs stuff -- but you're saying it's wrong? sorry i'm slow, never dealt with any of this stuff before... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 23:35:43 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 11 Jun 2015 21:35:43 +0000 Subject: [issue24437] Add information about the buildbot console view and irc notices to devguide Message-ID: <1434058543.2.0.729414223223.issue24437@psf.upfronthosting.co.za> New submission from R. David Murray: Here is a proposed addition to the devguide talking about the buildbot console interface (which I find far more useful than the waterfall view), and mentioning the notifications posted to #python-dev (which is a good way to find out if you broke the buildbots). ---------- components: Devguide files: buildbot-console-irc.patch keywords: patch messages: 245190 nosy: ezio.melotti, ncoghlan, r.david.murray, willingc priority: normal severity: normal stage: patch review status: open title: Add information about the buildbot console view and irc notices to devguide Added file: http://bugs.python.org/file39687/buildbot-console-irc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 11 23:57:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Jun 2015 21:57:22 +0000 Subject: [issue24436] _PyTraceback_Add has no const qualifier for its char * arguments In-Reply-To: <1434054292.35.0.944686887599.issue24436@psf.upfronthosting.co.za> Message-ID: <1434059842.22.0.136106169591.issue24436@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- nosy: +Mark.Shannon, pitrou, serhiy.storchaka stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 00:04:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Jun 2015 22:04:10 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1434060250.05.0.334693642589.issue15745@psf.upfronthosting.co.za> STINNER Victor added the comment: almostequaltime.diff is wrong: it allows a different of 10 seconds, whereas the issue is a difference of less than 1000 nanoseconds. test_os.patch looks more correct, but I didn't review the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 00:14:20 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 11 Jun 2015 22:14:20 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434060860.39.0.0178057342517.issue24429@psf.upfronthosting.co.za> Steve Dower added the comment: python.exe already has the manifest it needs, but it can't be embedded into python27.dll - it has to go into the exe file. That's why Python can't make it so that msvcr90.dll is loaded. Depending on what you're using it for, the C Runtime may keep some state in between function calls. For things like string copying (with no locale) you'll be okay, but most of the complication stuff assumes that every call into the CRT is calling into the *same* CRT. When you load different CRTs at the same time (as is happening here already, or when you load mscvrt.dll directly), you have to be very careful not to intermix them together at all. The most obvious example is open file handles. If you open a file with CRT 9.0 (msvcr90.dll) and then try and read from it with CRT 6.0 (msvcrt.dll), you'll probably crash or at least corrupt something. The same goes for memory allocations - if CRT 9.0 does a malloc() and then CRT 10.0 does the free(), you're almost certainly going to corrupt something because they are not compatible. I suspect Mathworks is relying on people installing Python themselves so they don't have to redistribute it as part of MATLAB, which is totally fine, but you have to be prepared to deal with this situation. If they make their own build, they need to distribute it themselves (easy) and explain to people why numpy doesn't work anymore unless you use their special build of numpy too (ie. because it uses a different CRT). Like I said initially, we would probably accept a patch for uuid.py to skip the CRT scan on Windows, and similar changes like that where appropriate. If you need to be able to load the DLL yourself, you either need to carefully consider how the functions you call may interact with other implementations/versions that may be loaded, or set up the manifest so you can load msvcr90.dll. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 00:24:00 2015 From: report at bugs.python.org (erik flister) Date: Thu, 11 Jun 2015 22:24:00 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434061440.28.0.764851743933.issue24429@psf.upfronthosting.co.za> erik flister added the comment: am i reading this wrong, that you can put the manifest into the .dll? https://msdn.microsoft.com/en-us/library/ms235560(v=vs.90).aspx ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 00:26:31 2015 From: report at bugs.python.org (erik flister) Date: Thu, 11 Jun 2015 22:26:31 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434061591.23.0.688216842961.issue24429@psf.upfronthosting.co.za> erik flister added the comment: if it can't go into your .dll, what are libraries like shapely supposed to do? tell their users to do all this manifest stuff if they're running embedded? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 00:27:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Jun 2015 22:27:56 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1434061676.66.0.286737351677.issue15745@psf.upfronthosting.co.za> STINNER Victor added the comment: The resolution of os.utime()+os.stat() depends on two things: - resolution of the timestamp on the filesystem used to run test_os (where TESTFN is written) - resolution of the C internal function used by os.utime() os.utime() can have a resolution of 1 ns (ex: it's usually the case on Linux), whereas the FAT filesystem has as resolution of 2 seconds. os.utime() can have a resolution of 1 us (ex: FreeBSD) whereas the ZFS filesystem has a resolution of 1 ns. Currently, test_os.test_*utime*_ns checks that os.utime() is able to copy the timestamp of a file 1 to a file 2. Problem: we don't know the resolution of the timestamp of the file 2. We can get the resolution of the C internal function used by os.utime(). It is implemented in the attached test_os.patch. But it's much more complex to get the timestamp resolution of the filesystem, in a portable way. Random thoughts: * use a timestamp with a resolution of 1 us, smaller than 2^24 to avoid rounding issues. Example: (atime=1.002003, mtime=4.005006)? * compute the effective utime resolution: call os.utime() with a well known timestamp with a resolution of 1 nanosecond (smaller than 2^24 to avoid rounding issues) and call os.stat() to check which digits were preserved test_os must not depend too much on the filesystem. I don't think that we should implement complex code just to check a simple field in the os.stat_result structure. The first idea (call utime with a fixed number, don't rely on an unknown file timestamp) is probably enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 00:28:54 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 11 Jun 2015 22:28:54 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434061734.28.0.740071325976.issue24429@psf.upfronthosting.co.za> Steve Dower added the comment: Ah, it can go into the DLL, and it's already there. The problem may be that there is conflicting information about which resource ID - https://msdn.microsoft.com/en-us/library/aa374224(v=vs.90).aspx says it should be 1 while your link says 2. python27.dll has the manifest as resource 2, so if that is incorrect, then that could be a reason why it's not working. (Looking at the search paths in that link above, there are other potential reasons if it's finding a compatible assembly in the MATLAB folder, but it sounds like that's not the case.) I guess we need someone with the patience to go through and figure out exactly whether it should be 1 or 2. That person is not me, sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 00:54:09 2015 From: report at bugs.python.org (Patrick Maupin) Date: Thu, 11 Jun 2015 22:54:09 +0000 Subject: [issue24426] re.split performance degraded significantly by capturing group In-Reply-To: <1433962389.05.0.538082969488.issue24426@psf.upfronthosting.co.za> Message-ID: <1434063249.51.0.71406024444.issue24426@psf.upfronthosting.co.za> Patrick Maupin added the comment: Thank you for the quick response, Serhiy. I had started investigating and come to the conclusion that it was a problem with the compiler rather than the C engine. Interestingly, my next step was going to be to use names for the compiler constants, and then I noticed you did that exact same thing in the 3.6 tree. I will try this out on my use-case tomorrow to make sure it fixes my issue, but now I'm intrigued by the inner workings of this, so I have two questions: 1) Do you know if anybody maintains a patched version of the Python code anywhere? I could put a package up on github/PyPI, if not. 2) Do you know if anybody has done a good writeup on the behavior of the instruction stream to the C engine? I could try to do some work on this and put it with the package, if not, or point to it if so. Thanks and best regards, Pat ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 00:55:47 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Jun 2015 22:55:47 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1434063347.82.0.10299307769.issue15745@psf.upfronthosting.co.za> STINNER Victor added the comment: test_utime_ns.patch: rewrite _test_utime_ns(). It now uses constant timestamps for atime and mtime with a resolution of 1 us. The test will fail if the internal function of os.utime() has a resolution of 1 sec (utime() with time_t) of if the resolution of filesystem timestamp is worse than 1 us. In practice on buildbots, it looks like the effective resolution of 1 us (FreeBSD, Solaris), 100 ns (Windows) or 1 ns (Linux). So 1 us should work on all buildbot slaves. test_utime_ns.patch doesn't call os.utime() on directories, only on a regular file. I don't understand the purpose of testing with a directory. Are we testing the OS or Python? ---------- Added file: http://bugs.python.org/file39688/test_utime_ns.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 00:56:18 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 11 Jun 2015 22:56:18 +0000 Subject: [issue24434] ItemsView.__contains__ does not mimic dict_items In-Reply-To: <1434050451.28.0.415875303865.issue24434@psf.upfronthosting.co.za> Message-ID: <1434063378.76.0.235348323414.issue24434@psf.upfronthosting.co.za> Martin Panter added the comment: Added a couple suggestions for the test case on Reitveld. ---------- nosy: +vadmium stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 01:50:17 2015 From: report at bugs.python.org (erik flister) Date: Thu, 11 Jun 2015 23:50:17 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434066617.77.0.223296125291.issue24429@psf.upfronthosting.co.za> erik flister added the comment: relevant: http://stackoverflow.com/questions/30771380/how-use-ctypes-with-msvc-dll-from-within-matlab-on-windows/#comment49619037_30771380 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 02:39:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Jun 2015 00:39:42 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1434069582.03.0.456015193913.issue15745@psf.upfronthosting.co.za> STINNER Victor added the comment: test_utime.patch: a much larger patch which rewrites all unit tests on os.utime(). Changes: * Use a fixed timestamp instead of copying timestamps from an existing file. If the timestamp of the original file can have a resolution of 1 nanosecond, os.utime() rounds to a resolution of 1 us on some platforms (when the C function uses a structure with a resolutionf of 1 us). * Use a fixed timestamp with a resolution of 1 us instead of a resolution of 1 ms. * Remove test_1565150(): it's now redundant with test_utime() and many other test_utime_*() tests * Use self.fname instead of __file__ to check if the filesystem supports subsecond resolution: these two files may be in two different filesystems * test_large_time() now checks the filesystem when it is executed, not when the class is defined. This change is to ensure that we are testing the right filesystem. * replace support.TESTFN with self.dirname for readability * move all os.utime() tests in a new dedicated class * _test_utime_current() now get the system clock using time.time() and tolerate a delta of 10 ms instead of 10 seconds: we may increase the delta because of slow buildbots, but I hope that we can find a value smaller than 10 seconds! * Avoid tricky getattr(), it's no more needed * Merge duplicated test_utime_*() and test_utime_subsecond_*() functions * Test also st_atime on when testing os.utime() on a directory * etc. ---------- Added file: http://bugs.python.org/file39689/test_utime.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 03:48:53 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 12 Jun 2015 01:48:53 +0000 Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments disappeared In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za> Message-ID: <1434073733.12.0.425867143119.issue23391@psf.upfronthosting.co.za> Martin Panter added the comment: New patch, clarifying that the constructor can raise a subclass. If you still think I need to add something about extra arguments, or how the ?args? attribute is set, let me know. ---------- Added file: http://bugs.python.org/file39690/os-error-args.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 03:53:43 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 12 Jun 2015 01:53:43 +0000 Subject: [issue24434] ItemsView.__contains__ does not mimic dict_items In-Reply-To: <1434050451.28.0.415875303865.issue24434@psf.upfronthosting.co.za> Message-ID: <1434074023.46.0.15649760501.issue24434@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 04:18:53 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 12 Jun 2015 02:18:53 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: <1434075533.25.0.414734658485.issue11245@psf.upfronthosting.co.za> R. David Murray added the comment: Are you volunteering to be maintainer, and/or is Piers? If he's changed his mind about the threading, that's good enough for me (and by now he has a lot more experience with the library in actual use). The biggest barrier to inclusion, IMO, is tests and backward compatibility. There have been enough changes that making sure we don't break backward compatibility will be important, and almost certainly requires more tests than we have now. Does imaplib2 have a test suite? We would need to get approval from python-dev, though. We have ongoing problems with packages that are maintained outside the stdlib...but updating to imaplib2 may be better than leaving it without a maintainer at all. Can we get Piers involved in this conversation directly? ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 04:54:04 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 12 Jun 2015 02:54:04 +0000 Subject: [issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za> Message-ID: <1434077644.53.0.833847240771.issue19176@psf.upfronthosting.co.za> Martin Panter added the comment: Ideally I guess the Python native behaviour is better: only call target.doctype() if available. It might allow you to easily implement doctype() in both the old and new versions of the API, without worrying about the API being called twice, and without experiencing any DeprecationWarning. But I do not have a real-world use case to demonstrate this, and I don?t think this decision should hold up committing inherit-doctype.v2.patch. They are separate bugs. BTW: Another difference between the implementations is that the C version accepts my test case, but the Python version ignores it. It only works with a more elaborate case like . I?m no expert, but I think my original XML should be allowed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 04:58:07 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 12 Jun 2015 02:58:07 +0000 Subject: [issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za> Message-ID: <1434077887.61.0.854055374801.issue19176@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- components: +XML -Extension Modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 04:58:27 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 12 Jun 2015 02:58:27 +0000 Subject: [issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za> Message-ID: <1434077907.97.0.519569048456.issue19176@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- components: +Extension Modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 06:40:08 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 12 Jun 2015 04:40:08 +0000 Subject: [issue23760] Tkinter in Python 3.4 on Windows don't post internal clipboard data to the Windows clipboard on exit In-Reply-To: <1427194076.59.0.225721138053.issue23760@psf.upfronthosting.co.za> Message-ID: <1434084008.76.0.161429204393.issue23760@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware -vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 06:49:58 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 12 Jun 2015 04:49:58 +0000 Subject: [issue23760] Tkinter in Python 3.4 on Windows don't post internal clipboard data to the Windows clipboard on exit In-Reply-To: <1427194076.59.0.225721138053.issue23760@psf.upfronthosting.co.za> Message-ID: <1434084598.82.0.588382064952.issue23760@psf.upfronthosting.co.za> Zachary Ware added the comment: I don't believe there's anything Python can do about this, unless it can be confirmed that this is a bug that's been fixed in a more recent version of Tcl/Tk 8.6, in which case we can update our dependency. The easy test for whether updating Tcl/Tk in 3.4 (which uses 8.6.1) will do any good is to try this out with 3.5.0b2 (which uses the latest 8.6.4). ---------- resolution: -> third party status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 06:58:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 12 Jun 2015 04:58:40 +0000 Subject: [issue24434] ItemsView.__contains__ does not mimic dict_items In-Reply-To: <1434050451.28.0.415875303865.issue24434@psf.upfronthosting.co.za> Message-ID: <1434085120.58.0.110082450445.issue24434@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Additional check hits performance. First issue can be resolved by changing code to try: key, value = item except TypeError: return False Second issue can be resolved by comparing not v with value, but (key, v) with item. However I'm not sure that fixing it is worth such complication of the code. ---------- nosy: +serhiy.storchaka versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 07:09:57 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 12 Jun 2015 05:09:57 +0000 Subject: [issue24437] Add information about the buildbot console view and irc notices to devguide In-Reply-To: <1434058543.2.0.729414223223.issue24437@psf.upfronthosting.co.za> Message-ID: <1434085797.43.0.228272438938.issue24437@psf.upfronthosting.co.za> Zachary Ware added the comment: Due to lack of Rietveld, comments in-line (? lines) below: @@ -42,6 +42,24 @@ bbreport.py -q 3.x +* The buildbot "console" interface at http://buildbot.python.org/all/console + (this link will take a while to load), which provides a summary view of all ? I think it can be assumed that most pages from buildbot.python.org will be slow to load :) ? Perhaps add that comment in the 'The Web interface...' paragraph above? + builders and all branches. This works best on a wide, high resolution + monitor. You can enter the your mercurial username ("your name ? s/the your/your/ + ") in the 'personalized for' box in the upper right corner to see + the results just for changesets submitted by you. Clicking on the colored + circles will allow you to open a new page containing whatever information + about that particular build is of interest to you. You can also access + builder information by clicking on the builder status bubbles in the top + line. + +If you like IRC, having an irc client open to the #python-dev channel on ? Should 'irc' be capitalized? +irc.freenode.net is useful. If a build fails (and the previous build by the +same builder did not) then a message is posted to the channel. Likewise if a +build passes when the previous one did not, a message is posted. Keeping an ? I think this could be simplified to 'Any time a builder switches from passing ? to failing (or vice versa), a message is posted to the channel.' ? 'switches from passing to failing' is still a bit iffy, though. Maybe ? 'fails a build after a successful build'? Or a simpler 'switches from green to red'? ? That could be construed as color-blind-ist, though :) +eye on the channel after pushing a changeset is a simple way to get notified +that there is something you should look in to. + Some buildbots are much faster than others. Over time, you will learn which ones produce the quickest results after a build, and which ones take the longest time. I had not used the console view before, that's pretty nice! ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 07:35:13 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 12 Jun 2015 05:35:13 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1434087313.45.0.47926827724.issue23996@psf.upfronthosting.co.za> Stefan Behnel added the comment: Here are two patches that fix this case, one with special casing, one without. Please choose and apply one. ---------- Added file: http://bugs.python.org/file39691/fix_stopiteration_value_slow.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 07:35:39 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 12 Jun 2015 05:35:39 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1434087339.15.0.936730543697.issue23996@psf.upfronthosting.co.za> Changes by Stefan Behnel : Added file: http://bugs.python.org/file39692/fix_stopiteration_value.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 07:46:45 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 12 Jun 2015 05:46:45 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434088005.75.0.236214578639.issue24400@psf.upfronthosting.co.za> Nick Coghlan added the comment: Low level review sent. Regarding the new opcode, it appears the main thing it provides is early detection of yielding from a coroutine in a normal generator, which is never going to work properly (a for loop or other iterative construct can't drive a coroutine as it expects to be driven), but would be incredibly painful to debug if you did it accidentally. For me, that counts as a good enough reason to add a new opcode during the beta period (just as adding the new types is necessary to fix various problems with the original not-actually-a-different-type implementation). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 07:48:18 2015 From: report at bugs.python.org (Caleb Levy) Date: Fri, 12 Jun 2015 05:48:18 +0000 Subject: [issue24434] ItemsView.__contains__ does not mimic dict_items In-Reply-To: <1434050451.28.0.415875303865.issue24434@psf.upfronthosting.co.za> Message-ID: <1434088098.0.0.470030121622.issue24434@psf.upfronthosting.co.za> Caleb Levy added the comment: @serhiy.storchaka: I don't think that will work. First of all, x, y = item will raise a ValueError if fed an iterable whose length is not exactly 2, so you would have to check for that. Moreover, if item is something like a dict, for example, then: {"a": 1, "b": 2} in DictLikeMapping(a="b") could return True, which I don't think would be expected behavior. I'm not terribly fond of the instance check myself, but in this case I can't see any other way to do it: the built in dict_items necessarily consists of *tuples* of key-value pairs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 07:52:41 2015 From: report at bugs.python.org (Caleb Levy) Date: Fri, 12 Jun 2015 05:52:41 +0000 Subject: [issue24434] ItemsView.__contains__ does not mimic dict_items In-Reply-To: <1434050451.28.0.415875303865.issue24434@psf.upfronthosting.co.za> Message-ID: <1434088361.75.0.880814156347.issue24434@psf.upfronthosting.co.za> Caleb Levy added the comment: Sorry; that should be DictLikeMapping(a="b").items(), where DictLikeMapping is defined in the patch unit tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 15:09:41 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 12 Jun 2015 13:09:41 +0000 Subject: [issue24431] StreamWriter.drain is not callable concurrently In-Reply-To: <1434034752.25.0.200116855736.issue24431@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Note that Glyph recommends against this fix (see mailing list). On Thu, Jun 11, 2015 at 7:59 AM, Martin Teichmann wrote: > > New submission from Martin Teichmann: > > Currently there is an assert statement asserting that no two > tasks (asyncio tasks, that is) can use StreamWriter.drain at > the same time. This is a weird limitiation, if there are two > tasks writing to the same network socket, there is no reason > why not both of them should drain the socket after (or before) > writing to it. > > A simple bug fix is attached. > > ---------- > components: asyncio > files: patch > messages: 245172 > nosy: Martin.Teichmann, gvanrossum, haypo, yselivanov > priority: normal > severity: normal > status: open > title: StreamWriter.drain is not callable concurrently > type: behavior > versions: Python 3.4, Python 3.5, Python 3.6 > Added file: http://bugs.python.org/file39681/patch > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 15:22:04 2015 From: report at bugs.python.org (F Malina) Date: Fri, 12 Jun 2015 13:22:04 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: F Malina added the comment: I am in for my part and I emailed Piers to come and join us and he surely will when the bug tracker is responsive again. Imaplib2 does have an up to date test suite and compatibility wise imaplib2 can be substituted for imaplib in existing clients with no changes in the code. On top of that I have a private IDLE test suite for common tasks such as - instant bounce processing, - email photo upload to web service, - unsubscribe processing via list-unsubscribe headers and feedback loops of major email providers. I am looking to make it part of an external project https://github.com/fmalina/emails, but need to extract much of the recipes first out of a working application in a reusable manner as I need it in other projects and will do for years to come. ---------- nosy: +F.Malina _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 15:22:58 2015 From: report at bugs.python.org (Alex Monk) Date: Fri, 12 Jun 2015 13:22:58 +0000 Subject: [issue24438] Strange behaviour when multiplying imaginary inf by 1 Message-ID: <1434115378.51.0.752150988215.issue24438@psf.upfronthosting.co.za> New submission from Alex Monk: alex at alex-laptop:~$ python3 Python 3.4.3 (default, Mar 26 2015, 22:03:40) [GCC 4.9.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> infj = complex(0, float("inf")) >>> infj infj >>> infj*1 (nan+infj) >>> infj*1*1 (nan+nanj) ---------- messages: 245247 nosy: Alex Monk priority: normal severity: normal status: open title: Strange behaviour when multiplying imaginary inf by 1 type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 15:23:18 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 12 Jun 2015 13:23:18 +0000 Subject: [issue24437] Add information about the buildbot console view and irc notices to devguide In-Reply-To: <1434058543.2.0.729414223223.issue24437@psf.upfronthosting.co.za> Message-ID: <1434115398.85.0.416733961992.issue24437@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the review. Here is an updated patch. ---------- Added file: http://bugs.python.org/file39693/buildbot-console-irc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 15:27:39 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 12 Jun 2015 13:27:39 +0000 Subject: [issue24438] Strange behaviour when multiplying imaginary inf by 1 In-Reply-To: <1434115378.51.0.752150988215.issue24438@psf.upfronthosting.co.za> Message-ID: <1434115659.21.0.376197739139.issue24438@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 15:31:32 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 12 Jun 2015 13:31:32 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: <1434115892.29.0.421681451461.issue11245@psf.upfronthosting.co.za> R. David Murray added the comment: This is great. When you say it is fully compatible, though, is that testing against imaplib in python2 or python3? It is the python3 decisions about string/bytes handling where the discrepancies are most likely to arise, unless the python3 port was modeled on the stdlib version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 15:36:45 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 12 Jun 2015 13:36:45 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1434116205.5.0.595907974321.issue23996@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Have you tried benchmarking the "slow" solution? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 15:40:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 12 Jun 2015 13:40:59 +0000 Subject: [issue23760] Tkinter in Python 3.4 on Windows don't post internal clipboard data to the Windows clipboard on exit In-Reply-To: <1434084598.82.0.588382064952.issue23760@psf.upfronthosting.co.za> Message-ID: <1444629.sLlROQJXoQ@raxxla> Serhiy Storchaka added the comment: Here is minimal reproducer on Tcl/Tk. I don't have a workaround. ---------- status: pending -> open Added file: http://bugs.python.org/file39694/issue23760.tcl _______________________________________ Python tracker _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: issue23760.tcl Type: text/x-tcl Size: 58 bytes Desc: not available URL: From report at bugs.python.org Fri Jun 12 15:45:06 2015 From: report at bugs.python.org (F Malina) Date: Fri, 12 Jun 2015 13:45:06 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1434115892.29.0.421681451461.issue11245@psf.upfronthosting.co.za> Message-ID: <8E2757DC-5E37-4B89-A5B0-3E14E2FDEB9E@gmail.com> F Malina added the comment: I just wen?t through my repo looking at relevant commits to double check and I didn?t have to change a line in my user level code when upgrading from python2 to 3. There was only one way to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 15:46:56 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 12 Jun 2015 13:46:56 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: <1434116816.75.0.370803500236.issue11245@psf.upfronthosting.co.za> R. David Murray added the comment: Do you have any tests that use non-ascii passwords? I think that was the most significant bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 16:04:26 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 12 Jun 2015 14:04:26 +0000 Subject: [issue24087] Documentation doesn't explain the term "coroutine" (PEP 342) In-Reply-To: <1430425552.31.0.779606074615.issue24087@psf.upfronthosting.co.za> Message-ID: <1434117866.22.0.673247885342.issue24087@psf.upfronthosting.co.za> Martin Panter added the comment: I suspect the patch is out of date due to PEP 492 and Issue 24180 (?await? syntax for coroutines). But maybe the current glossary entry could be refined to also mention generators. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 16:08:55 2015 From: report at bugs.python.org (F Malina) Date: Fri, 12 Jun 2015 14:08:55 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1434116816.75.0.370803500236.issue11245@psf.upfronthosting.co.za> Message-ID: <0AD02E65-9DE7-42D5-8FE3-D4D626E57BA9@gmail.com> F Malina added the comment: I don?t have a test for it, neither has stdlib imaplib. We just need to port over the encode fix. Copy over the fixed version of _CRAM_MD5_AUTH. from line 599 in python3.5 imaplib https://github.com/python/cpython/blob/master/Lib/imaplib.py#L599 corresponding to line 884 in imaplib2 https://github.com/bcoe/imaplib2/blob/master/imaplib2/imaplib2.py#L884 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 16:46:06 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 12 Jun 2015 14:46:06 +0000 Subject: [issue24439] Feedback for awaitable coroutine documentation Message-ID: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za> New submission from Martin Panter: Today I tried playing with the new ?async def? functionality in the interactive interpreter, based on reading the documentation. Here are some bits that surprised me, so could be the focus of further documentation. (Initial documentation added in Issue 24180.) 1. Confusion between coroutine and generator terms AttributeError: 'generator' object has no attribute '__await__' TypeError: coroutine-objects do not support iteration TypeError: can't send non-None value to a just-started generator Is it a coroutine object, or a generator object? The error messages etc seem to be split between the two terms. I guess the underlying implementation is closely shared between the two types, so old error messages still say ?generator?, while new ones say ?coroutine?. So there may not be an easy fix, but it was initially disconcerting. Perhaps a statement somewhere explaining coroutine instances are (based on / modified / a kind of / evolved from) generator instance objects, as appropriate. 2. Properties of a coroutine instance object suggests that a coroutine instance should implement __await__(), but it apparently does not. How to drive through the coroutine?s await points? This should be documented, and linked from relevant places in the documentation; perhaps the ?coroutine? glossary entry, ?async? statement, and ?await? expression. The best clue that I found in the current documentation was , suggesting to use send(). Without having studied the PEP recently, I was expecting __await__() to be implemented, and invoking it would be similar to calling next() on an old-skool generator-iterator. Instead I see that calling __await__() is semantically more like __iter__(): it is only invoked once per ?await? expression, and the return value is iterated over. 3. Allergic reaction to ?await? on the same line as ?async def? >>> async def f(): await A(()) SyntaxError: invalid syntax I see this is mentioned in the PEP that this is necessary so that ?await? doesn?t have to be made a strict language keyword. But it should also be in the documentation. 4. Coroutine instances don?t implement the Coroutine ABC >>> isinstance(c, Coroutine) True >>> hasattr(Coroutine, "__await__") True >>> hasattr(c, "__await__") False Reading closely, the documentation says ?coroutine compatible classes?, but given the liberal use of ?coroutine? everywhere, I think there should be a more obvious warning of how much a coroutine is a Coroutine. ---------- assignee: docs at python components: Documentation messages: 245256 nosy: docs at python, vadmium, yselivanov priority: normal severity: normal status: open title: Feedback for awaitable coroutine documentation type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 16:48:54 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 12 Jun 2015 14:48:54 +0000 Subject: [issue24438] Strange behaviour when multiplying imaginary inf by 1 In-Reply-To: <1434115378.51.0.752150988215.issue24438@psf.upfronthosting.co.za> Message-ID: <1434120534.2.0.00377825377563.issue24438@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I've found the same behaviour going back to Python 1.5. I think what happens here is that (0+?j)*1 evaluates the multiplication by implicitly coercing the int to a complex: (0+?j)*(1+0j) => (0*1 + ?j*1 + 0*0j + ?j*0j) => (0-NAN + ?j+0j) => (NAN + ?j) rather than using the "simple" way (1*0 + 1*?j) => (0+?j). The problem here is that while there is no mathematical difference between multiplying by 1 or (1+0j), once you involve NANs and INFs, it does. So even though they give different answers, both methods are correct, for some value of "correct". I don't see that this is necessarily a bug to be fixed, it might count as a change in behaviour needing to go through a deprecation period first. Perhaps it should be discussed on python-ideas first? My personal feeling is that Python should multiply a complex by a non-complex in the "simple" way, rather than implicitly converting the int to a complex. Anyone who wants the old behaviour can easily get it by explicitly converting 1 to a complex first. So I guess this is a +1 to "fixing" this. (Oh, the same applies to the / operator.) ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 16:54:37 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 12 Jun 2015 14:54:37 +0000 Subject: [issue24437] Add information about the buildbot console view and irc notices to devguide In-Reply-To: <1434115398.85.0.416733961992.issue24437@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 17:45:02 2015 From: report at bugs.python.org (Carol Willing) Date: Fri, 12 Jun 2015 15:45:02 +0000 Subject: [issue24437] Add information about the buildbot console view and irc notices to devguide In-Reply-To: <1434058543.2.0.729414223223.issue24437@psf.upfronthosting.co.za> Message-ID: <1434123902.14.0.0533303251969.issue24437@psf.upfronthosting.co.za> Carol Willing added the comment: Thank you R. David and Zach. The patch looks good to me too, and the info will be helpful to others. Please commit and let's get this good info out to others :) (I don't have privileges or I would do so.) ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 17:48:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 12 Jun 2015 15:48:38 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <20150612154834.11401.36602@psf.io> Roundup Robot added the comment: New changeset 4335d898be59 by Victor Stinner in branch 'default': Issue #15745: Rewrite os.utime() tests in test_os https://hg.python.org/cpython/rev/4335d898be59 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 17:54:09 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Jun 2015 15:54:09 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1434124449.49.0.720650215945.issue15745@psf.upfronthosting.co.za> STINNER Victor added the comment: I pushed test_utime.patch with minor updates: * _test_utime_current() now also checks if the FS supports subsecond * use a delta of 20 ms in _test_utime_current(), instead of 10 ms, for Windows I will wait for FreeBSD and Solaris buildbots to see if my changes fixes failures on os.utime() tests. If it's a success, I will backport the change to Python 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 18:03:59 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 12 Jun 2015 16:03:59 +0000 Subject: [issue24440] Move the buildslave setup information from the wiki to the devguide Message-ID: <1434125039.92.0.983765868474.issue24440@psf.upfronthosting.co.za> New submission from R. David Murray: I propose that we move the information on setting up a buildslave from the wiki to the devguide. The attached patch is my rewrite (hopefully an improvement) of the information from the wiki. Note that there are a couple of TBD pieces (setup on Windows, restart at boot on windows and mac). I'll be filling in the mac stuff as I set up the Intel ICC mac buildbot and figure out what all is missing from the docs. ---------- components: Devguide messages: 245262 nosy: ezio.melotti, ncoghlan, pitrou, r.david.murray, willingc, zach.ware priority: normal severity: normal stage: patch review status: open title: Move the buildslave setup information from the wiki to the devguide type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 18:25:36 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 12 Jun 2015 16:25:36 +0000 Subject: [issue24440] Move the buildslave setup information from the wiki to the devguide In-Reply-To: <1434125039.92.0.983765868474.issue24440@psf.upfronthosting.co.za> Message-ID: <1434126336.29.0.0765395202439.issue24440@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- keywords: +patch Added file: http://bugs.python.org/file39695/buildslave.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 18:29:17 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 12 Jun 2015 16:29:17 +0000 Subject: [issue24437] Add information about the buildbot console view and irc notices to devguide In-Reply-To: <1434058543.2.0.729414223223.issue24437@psf.upfronthosting.co.za> Message-ID: <1434126557.53.0.489273043111.issue24437@psf.upfronthosting.co.za> R. David Murray added the comment: Oops, forgot to put the issue number in the commit message: bff43c5c8c4f ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 18:41:22 2015 From: report at bugs.python.org (Carol Willing) Date: Fri, 12 Jun 2015 16:41:22 +0000 Subject: [issue24440] Move the buildslave setup information from the wiki to the devguide In-Reply-To: <1434125039.92.0.983765868474.issue24440@psf.upfronthosting.co.za> Message-ID: <1434127282.11.0.332483788663.issue24440@psf.upfronthosting.co.za> Carol Willing added the comment: R. David, this will be an excellent addition to the devguide. Great clarity in the text. I particularly like your discussion of what are buildbots and who provides and maintains them. It also encourages those interested in a particular os to consider maintaining a buildbot suitable for their needs. I can see this being helpful to those individuals on the core mentorship list looking for testing issues to resolve. Nicely done :) I will do a more thorough grammar/style review later. I will defer to others on the technical review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 19:34:24 2015 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 12 Jun 2015 17:34:24 +0000 Subject: [issue24438] Strange behaviour when multiplying imaginary inf by 1 In-Reply-To: <1434115378.51.0.752150988215.issue24438@psf.upfronthosting.co.za> Message-ID: <1434130464.47.0.565631118449.issue24438@psf.upfronthosting.co.za> Mark Dickinson added the comment: There's no bug here: as Steven explained, this is simply the result of the usual arithmetic conversions when performing a mixed-type operation. > Python should multiply a complex by a non-complex in the "simple" way I think this would just be adding unnecessary complication. -1 from me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 19:38:52 2015 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 12 Jun 2015 17:38:52 +0000 Subject: [issue24438] Strange behaviour when multiplying imaginary inf by 1 In-Reply-To: <1434115378.51.0.752150988215.issue24438@psf.upfronthosting.co.za> Message-ID: <1434130732.3.0.563717116327.issue24438@psf.upfronthosting.co.za> Mark Dickinson added the comment: Closing as not a bug; for the suggestion of changing the mixed-type arithmetic behaviour, I think that's something that should be discussed on the python-ideas mailing list. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 20:39:44 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Jun 2015 18:39:44 +0000 Subject: [issue24391] Better repr for threading objects In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> Message-ID: <1434134384.67.0.0164047870385.issue24391@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The Semaphore and BoundedSemphore examples show why including the module is helpful. I prefer the function-call syntax, as long as it is accurate, even though the string as a whole cannot be eval()-ed. In any case, threading and multiprocessing are somewhat 'parallel' modules, so their reps should follow the same pattern. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 21:07:12 2015 From: report at bugs.python.org (Piers Lauder) Date: Fri, 12 Jun 2015 19:07:12 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: <1434136032.24.0.544915190438.issue11245@psf.upfronthosting.co.za> Changes by Piers Lauder : ---------- nosy: +piers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 21:22:20 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Jun 2015 19:22:20 +0000 Subject: [issue24403] Missing fixer for changed round() behavior In-Reply-To: <1433674721.13.0.236886844827.issue24403@psf.upfronthosting.co.za> Message-ID: <1434136940.85.0.220216374074.issue24403@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The fix would be to add a 'round' function at the top of a module, after the imports. This is more the provenance of 2 & 3 compatibility modules, such as 6, which might have both round2 and round3 functions. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 21:23:11 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 12 Jun 2015 19:23:11 +0000 Subject: [issue24431] StreamWriter.drain is not callable concurrently In-Reply-To: <1434034752.25.0.200116855736.issue24431@psf.upfronthosting.co.za> Message-ID: <1434136991.47.0.345698565862.issue24431@psf.upfronthosting.co.za> Guido van Rossum added the comment: See mailing list discussion. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 21:32:26 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Jun 2015 19:32:26 +0000 Subject: [issue24405] Missing code markup in "Expressions" documentation In-Reply-To: <1433762475.42.0.565039564472.issue24405@psf.upfronthosting.co.za> Message-ID: <1434137546.79.0.395762177319.issue24405@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This is Py3 only (Py 2 has no set displays) in Reference Manual, 6.9. Comparisons. (Please provide such info with reports.) Will fix. ---------- nosy: +terry.reedy stage: -> needs patch versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 21:46:20 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 12 Jun 2015 19:46:20 +0000 Subject: [issue24405] Missing code markup in "Expressions" documentation In-Reply-To: <1433762475.42.0.565039564472.issue24405@psf.upfronthosting.co.za> Message-ID: <20150612194617.19332.4526@psf.io> Roundup Robot added the comment: New changeset ccb0f43964e0 by Terry Jan Reedy in branch '3.4': Closes issue #24405: mark set display as code. https://hg.python.org/cpython/rev/ccb0f43964e0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 21:46:58 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Jun 2015 19:46:58 +0000 Subject: [issue24405] Missing code markup in "Expressions" documentation In-Reply-To: <1433762475.42.0.565039564472.issue24405@psf.upfronthosting.co.za> Message-ID: <1434138418.58.0.699283348361.issue24405@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: needs patch -> resolved type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 22:03:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 12 Jun 2015 20:03:52 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <20150612200349.20225.95333@psf.io> Roundup Robot added the comment: New changeset 50ec3fb126dd by Victor Stinner in branch '3.4': Issue #15745: Rewrite os.utime() tests in test_os https://hg.python.org/cpython/rev/50ec3fb126dd New changeset 744c96cd57da by Victor Stinner in branch '3.5': (Merge 3.4) Issue #15745: Rewrite os.utime() tests in test_os https://hg.python.org/cpython/rev/744c96cd57da ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 22:08:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Jun 2015 20:08:18 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1434139698.48.0.478274139957.issue15745@psf.upfronthosting.co.za> STINNER Victor added the comment: I applied the fix to Python 3.4 and 3.5 too. Python 2.7 doesn't look to be affected by the issue, I don't see any test copying the timestamp of a file to another, nor test on timestamp using nanosecond resolution. ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 22:12:48 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Jun 2015 20:12:48 +0000 Subject: [issue24406] "Built-in Types" doc doesn't explain dict comparison. In-Reply-To: <1433763158.1.0.945531416377.issue24406@psf.upfronthosting.co.za> Message-ID: <1434139968.23.0.467252935777.issue24406@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The 3.4 sequence section also has this: "Sequences of the same type also support comparisons. In particular, tuples and lists are compared lexicographically by comparing corresponding elements." I agree that dicts should have a similar sentence or two. Neither the sequence or (frozen)set sections reference the language manual, so I will leave that out. ---------- nosy: +terry.reedy title: "Built-in Types" documentation doesn't explain how dictionaries are compared for equality -> "Built-in Types" doc doesn't explain dict comparison. versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 22:49:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 12 Jun 2015 20:49:33 +0000 Subject: [issue24406] "Built-in Types" doc doesn't explain dict comparison. In-Reply-To: <1433763158.1.0.945531416377.issue24406@psf.upfronthosting.co.za> Message-ID: <20150612204930.20445.8184@psf.io> Roundup Robot added the comment: New changeset d775fad1db43 by Terry Jan Reedy in branch '2.7': Issue #24406: Add sentences on dict comparisons, similar to those for Sequence https://hg.python.org/cpython/rev/d775fad1db43 New changeset 4e816c324846 by Terry Jan Reedy in branch '3.4': Issue #24406: Add sentences on dict comparisons, similar to those for Sequence https://hg.python.org/cpython/rev/4e816c324846 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 22:52:34 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 12 Jun 2015 20:52:34 +0000 Subject: [issue24406] "Built-in Types" doc doesn't explain dict comparison. In-Reply-To: <1433763158.1.0.945531416377.issue24406@psf.upfronthosting.co.za> Message-ID: <1434142354.64.0.428471992253.issue24406@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 23:23:19 2015 From: report at bugs.python.org (Tal Einat) Date: Fri, 12 Jun 2015 21:23:19 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1434144199.28.0.89186451379.issue20186@psf.upfronthosting.co.za> Tal Einat added the comment: Attached is a revised patch for Modules/mathmodule.c incorporating changes suggested by Serhiy in his review. The major change is the reformatting of the doc-strings of most of the functions in the module to use the same format as doc-strings generated by AC. ---------- Added file: http://bugs.python.org/file39696/issue20186.mathmodule.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 23:41:11 2015 From: report at bugs.python.org (py.user) Date: Fri, 12 Jun 2015 21:41:11 +0000 Subject: [issue24441] In argparse add_argument() allows the empty choices argument Message-ID: <1434145271.17.0.0249492593034.issue24441@psf.upfronthosting.co.za> New submission from py.user: A script, configuring argparse to have no choices: #!/usr/bin/env python3 import argparse parser = argparse.ArgumentParser() parser.add_argument('foo', choices=[]) args = parser.parse_args() print(args) Running it: [guest at localhost args]$ ./t.py usage: t.py [-h] {} t.py: error: too few arguments [guest at localhost args]$ ./t.py a usage: t.py [-h] {} t.py: error: argument foo: invalid choice: 'a' (choose from ) [guest at localhost args]$ ./t.py "" usage: t.py [-h] {} t.py: error: argument foo: invalid choice: '' (choose from ) [guest at localhost args]$ [guest at localhost args]$ ./t.py -h usage: t.py [-h] {} positional arguments: {} optional arguments: -h, --help show this help message and exit [guest at localhost args]$ ISTM, it should throw an exception about empty choices rather than show help with empty choices. ---------- components: Library (Lib) messages: 245277 nosy: py.user priority: normal severity: normal status: open title: In argparse add_argument() allows the empty choices argument type: behavior versions: Python 3.3, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 23:48:33 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 12 Jun 2015 21:48:33 +0000 Subject: [issue24441] In argparse add_argument() allows the empty choices argument In-Reply-To: <1434145271.17.0.0249492593034.issue24441@psf.upfronthosting.co.za> Message-ID: <1434145713.03.0.508108767053.issue24441@psf.upfronthosting.co.za> R. David Murray added the comment: There's no real reason to throw an error here, and to do so would break backward compatibility and, arguably, functionality: someone autogenerating a choices list might depend on the empty list working. ---------- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 23:49:33 2015 From: report at bugs.python.org (Tal Einat) Date: Fri, 12 Jun 2015 21:49:33 +0000 Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for prompt In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za> Message-ID: <1434145773.77.0.413556402078.issue24402@psf.upfronthosting.co.za> Tal Einat added the comment: Okay, so the change is straightforward. With this change the entire test suite passes on my machine. We'll need a test for this for the test suite, and that's far less straightforward. It seems that test.test_builtin.BuiltinTest.check_input_tty() could be a starting point. Could someone come up with a working test for this? ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 12 23:51:13 2015 From: report at bugs.python.org (Tal Einat) Date: Fri, 12 Jun 2015 21:51:13 +0000 Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for prompt In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za> Message-ID: <1434145873.71.0.485974299475.issue24402@psf.upfronthosting.co.za> Tal Einat added the comment: Here's a patch with just the required fix (no tests). ---------- keywords: +patch Added file: http://bugs.python.org/file39697/issue24402.fix_only.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 01:17:25 2015 From: report at bugs.python.org (Milan Oberkirch) Date: Fri, 12 Jun 2015 23:17:25 +0000 Subject: [issue22158] RFC 6531 (SMTPUTF8) support in smtpd.PureProxy In-Reply-To: <1407352076.6.0.272779806488.issue22158@psf.upfronthosting.co.za> Message-ID: <1434151045.86.0.137983086195.issue22158@psf.upfronthosting.co.za> Milan Oberkirch added the comment: I just wanted to note that this patch works with the current default repo as expected. I will try to come up with some tests now (PureProxy is not tested at all right now). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 02:08:22 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 13 Jun 2015 00:08:22 +0000 Subject: [issue24405] Missing code markup in "Expressions" documentation In-Reply-To: <1433762475.42.0.565039564472.issue24405@psf.upfronthosting.co.za> Message-ID: <1434154102.77.0.991926921967.issue24405@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 02:41:04 2015 From: report at bugs.python.org (erik flister) Date: Sat, 13 Jun 2015 00:41:04 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434156064.82.0.198267348777.issue24429@psf.upfronthosting.co.za> erik flister added the comment: well i can confirm @eryksun's method works, so it's not a problem with how the manifest is included in the dll. to me, the real issue is that ctypes.cdll.msvcrt and find_library('c') aren't correct. the first returns something "old and unsupported," or "officially off-limits" (depending who you ask), and the second doesn't work when running embedded. imho, both of them should use @eryksun's method to activate the dll's context, look in the included manifest, and return the msvcr* found there. why isn't this the correct design? why should every library have to reimplement the method just to allow running embedded, which they can't be responsible for knowing about? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 04:01:51 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 13 Jun 2015 02:01:51 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1434160911.75.0.859775787911.issue24432@psf.upfronthosting.co.za> Ned Deily added the comment: Make that OpenSSL 1.0.2c now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 04:04:52 2015 From: report at bugs.python.org (Piers Lauder) Date: Sat, 13 Jun 2015 02:04:52 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: <1434161092.6.0.176038982205.issue11245@psf.upfronthosting.co.za> Piers Lauder added the comment: Hi, apologies for not responding to the "pierslauder" pings, but i don't own that login, or at least have forgotten all about it, and its email address is invalid (or there is another pierslauder out there). I maintain imaplib2 on sourceforge (as piersrlauder) at https://sourceforge.net/projects/imaplib2/ and that version has just been modified to incorporate the CRAM_MD5_AUTH change from python3.6. It is regularly updated with bug fixes and it also has built-in tests for the IDLE function. I originally intended for imaplib2 to be incorporated into pythonlib, leaving the original module in place (a la urllib/2). Then people wouldn't be forced into a switch using threads except by choice. Anyway, happy to help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 04:57:57 2015 From: report at bugs.python.org (Perry Randall) Date: Sat, 13 Jun 2015 02:57:57 +0000 Subject: [issue24442] Readline Bindings Don't Report Any Error On Completer Function Exception Message-ID: <1434164276.99.0.684259947249.issue24442@psf.upfronthosting.co.za> New submission from Perry Randall: Noticed this while writing a non-trivial completion function for readline.set_completer. When an exception is thrown in the completion function readline doesnt do anything, squashes the error, this should not be the case. ---------- components: Interpreter Core files: readline_exception.patch keywords: patch messages: 245285 nosy: Perry Randall priority: normal severity: normal status: open title: Readline Bindings Don't Report Any Error On Completer Function Exception type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39698/readline_exception.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 05:32:09 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 13 Jun 2015 03:32:09 +0000 Subject: [issue24442] Readline Bindings Don't Report Any Error On Completer Function Exception In-Reply-To: <1434164276.99.0.684259947249.issue24442@psf.upfronthosting.co.za> Message-ID: <1434166329.69.0.662057506231.issue24442@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I disagree that it "should not be the case", I think Python's current behaviour is correct. Although it makes debugging completer functions harder, it would not be good for a bug in the completer to raise an exception and break line editing. This is one case where errors should be silenced. Instead, my completion functions log errors to a file, and I watch the log file in another terminal window. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 05:41:37 2015 From: report at bugs.python.org (Perry Randall) Date: Sat, 13 Jun 2015 03:41:37 +0000 Subject: [issue24442] Readline Bindings Don't Report Any Error On Completer Function Exception In-Reply-To: <1434164276.99.0.684259947249.issue24442@psf.upfronthosting.co.za> Message-ID: <1434166897.44.0.443164210904.issue24442@psf.upfronthosting.co.za> Perry Randall added the comment: Ah yeah you're correct, on second thought I think an addition to the readline documentation is warranted, not a code change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 05:52:09 2015 From: report at bugs.python.org (Milan Oberkirch) Date: Sat, 13 Jun 2015 03:52:09 +0000 Subject: [issue22158] RFC 6531 (SMTPUTF8) support in smtpd.PureProxy In-Reply-To: <1407352076.6.0.272779806488.issue22158@psf.upfronthosting.co.za> Message-ID: <1434167529.8.0.602652368528.issue22158@psf.upfronthosting.co.za> Milan Oberkirch added the comment: After looking at this patch and how we implemented SMTPUTF8 in the parent class again, I think we can come up with a more generic solution. Haven't it figured out quite yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 06:10:12 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 13 Jun 2015 04:10:12 +0000 Subject: [issue24442] Readline Bindings Don't Report Any Error On Completer Function Exception In-Reply-To: <1434164276.99.0.684259947249.issue24442@psf.upfronthosting.co.za> Message-ID: <1434168612.03.0.472547345983.issue24442@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- assignee: -> docs at python components: +Documentation -Interpreter Core nosy: +docs at python versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 06:14:23 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 13 Jun 2015 04:14:23 +0000 Subject: [issue24175] Consistent test_utime() failures on FreeBSD In-Reply-To: <1431521100.95.0.772714139961.issue24175@psf.upfronthosting.co.za> Message-ID: <1434168863.49.0.619583115649.issue24175@psf.upfronthosting.co.za> Zachary Ware added the comment: This appears to have been fixed in #15745. ---------- resolution: -> fixed stage: -> resolved status: open -> closed superseder: -> Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 06:31:17 2015 From: report at bugs.python.org (Milan Oberkirch) Date: Sat, 13 Jun 2015 04:31:17 +0000 Subject: [issue21783] smtpd.py does not allow multiple helo/ehlo commands In-Reply-To: <1402950477.07.0.805297062536.issue21783@psf.upfronthosting.co.za> Message-ID: <1434169877.27.0.173842823424.issue21783@psf.upfronthosting.co.za> Milan Oberkirch added the comment: Here is the patch how it should look like at some point. Question being: How should we handle backwards-compatibility? ---------- keywords: +patch Added file: http://bugs.python.org/file39699/issue21783.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 06:56:30 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 13 Jun 2015 04:56:30 +0000 Subject: [issue24442] Readline Bindings Don't Report Any Error On Completer Function Exception In-Reply-To: <1434164276.99.0.684259947249.issue24442@psf.upfronthosting.co.za> Message-ID: <1434171390.2.0.0883349827671.issue24442@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 07:11:49 2015 From: report at bugs.python.org (Milan Oberkirch) Date: Sat, 13 Jun 2015 05:11:49 +0000 Subject: [issue22872] multiprocessing.Queue raises AssertionError In-Reply-To: <1415986488.54.0.734820295311.issue22872@psf.upfronthosting.co.za> Message-ID: <1434172309.89.0.137592958294.issue22872@psf.upfronthosting.co.za> Milan Oberkirch added the comment: Here is the trivial patch for that :) ---------- keywords: +patch nosy: +zvyn Added file: http://bugs.python.org/file39700/issue22872.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 08:14:33 2015 From: report at bugs.python.org (Milan Oberkirch) Date: Sat, 13 Jun 2015 06:14:33 +0000 Subject: [issue795081] email.Message param parsing problem II Message-ID: <1434176073.69.0.603785164355.issue795081@psf.upfronthosting.co.za> Milan Oberkirch added the comment: Is this still relevant? I just made a patch based on the suggestions discussed and it does not change the behavior of the original bug report (but fixed the bug regarding '\\\\' mentioned by tony_nelson). Maybe I'm missing something? ---------- keywords: +patch nosy: +zvyn Added file: http://bugs.python.org/file39701/issue795081.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 08:31:31 2015 From: report at bugs.python.org (Tal Einat) Date: Sat, 13 Jun 2015 06:31:31 +0000 Subject: [issue24412] setUpClass equivalent for addCleanup In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za> Message-ID: <1434177091.63.0.421485077525.issue24412@psf.upfronthosting.co.za> Tal Einat added the comment: Is this really needed? One can use try/except/raise, and since addClassCleanup() would only be called from setUpClass(), I don't quite see the utility of it. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 08:41:15 2015 From: report at bugs.python.org (Jaivish Kothari) Date: Sat, 13 Jun 2015 06:41:15 +0000 Subject: [issue24443] Link for clear and wait missing in EventObjects Message-ID: <1434177675.51.0.151907138721.issue24443@psf.upfronthosting.co.za> New submission from Jaivish Kothari: https://docs.python.org/2/library/threading.html#threading.Event.set links missing for wait and clear . set() is linked though. Line: " An event object manages an internal flag that can be set to true with the set() method and reset to false with the clear() method. The wait() method blocks until the flag is true. " ---------- assignee: docs at python components: Documentation files: Fix_link.patch keywords: patch messages: 245294 nosy: berker.peksag, docs at python, georg.brandl, janonymous, janonymous, tim.golden, willingc priority: normal severity: normal status: open title: Link for clear and wait missing in EventObjects type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file39702/Fix_link.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 08:43:10 2015 From: report at bugs.python.org (Robert Collins) Date: Sat, 13 Jun 2015 06:43:10 +0000 Subject: [issue24412] setUpClass equivalent for addCleanup In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za> Message-ID: <1434177790.9.0.429410237119.issue24412@psf.upfronthosting.co.za> Robert Collins added the comment: It would be nice for symmetry. I mean, setUpClass isn't needed either, and we have it ;). however, we actually have two contexts this would be called from - setUpClass and setUpModule; both share their internals. So we probably need a decoupled cleanups implementation, and two new binding points to it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 08:45:22 2015 From: report at bugs.python.org (Tal Einat) Date: Sat, 13 Jun 2015 06:45:22 +0000 Subject: [issue24403] Missing fixer for changed round() behavior In-Reply-To: <1433674721.13.0.236886844827.issue24403@psf.upfronthosting.co.za> Message-ID: <1434177922.13.0.433460334874.issue24403@psf.upfronthosting.co.za> Tal Einat added the comment: See the existing issue and discussion about this on the six library's issue tracker (opened nearly a year ago): https://bitbucket.org/gutworth/six/issue/94/introduce-sixround ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 08:47:02 2015 From: report at bugs.python.org (py.user) Date: Sat, 13 Jun 2015 06:47:02 +0000 Subject: [issue24444] In argparse empty choices cannot be printed in the help Message-ID: <1434178022.79.0.230343884775.issue24444@psf.upfronthosting.co.za> New submission from py.user: >>> import argparse >>> >>> parser = argparse.ArgumentParser() >>> _ = parser.add_argument('foo', choices=[], help='%(choices)s') >>> parser.print_help() Traceback (most recent call last): File "", line 1, in File "/home/guest/tmp/tests/misc/git/example/cpython/main/Lib/argparse.py", line 2358, in print_help self._print_message(self.format_help(), file) File "/home/guest/tmp/tests/misc/git/example/cpython/main/Lib/argparse.py", line 2342, in format_help return formatter.format_help() File "/home/guest/tmp/tests/misc/git/example/cpython/main/Lib/argparse.py", line 278, in format_help help = self._root_section.format_help() File "/home/guest/tmp/tests/misc/git/example/cpython/main/Lib/argparse.py", line 208, in format_help func(*args) File "/home/guest/tmp/tests/misc/git/example/cpython/main/Lib/argparse.py", line 208, in format_help func(*args) File "/home/guest/tmp/tests/misc/git/example/cpython/main/Lib/argparse.py", line 517, in _format_action parts.append('%*s%s\n' % (indent_first, '', help_lines[0])) IndexError: list index out of range >>> It's not very useful to print empty choices, but the choices list could be formed dynamically. So the command-line user can't figure out what's happen. ---------- components: Library (Lib) messages: 245297 nosy: py.user priority: normal severity: normal status: open title: In argparse empty choices cannot be printed in the help type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 08:51:15 2015 From: report at bugs.python.org (Tal Einat) Date: Sat, 13 Jun 2015 06:51:15 +0000 Subject: [issue24421] Race condition compiling Modules/_math.c In-Reply-To: <1433923600.68.0.73894537311.issue24421@psf.upfronthosting.co.za> Message-ID: <1434178275.51.0.43090087342.issue24421@psf.upfronthosting.co.za> Tal Einat added the comment: Confirmed on OSX 10.10. Here's my output: running build running build_ext building 'cmath' extension ./slow-cc.py -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. -IInclude -I/usr/local/include -I/Users/taleinat/dev/cpython/Include -I/Users/taleinat/dev/cpython -c /Users/taleinat/dev/cpython/Modules/cmathmodule.c -o build/temp.macosx-10.10-x86_64-3.6/Users/taleinat/dev/cpython/Modules/cmathmodule.o building 'math' extension ./slow-cc.py -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. -IInclude -I/usr/local/include -I/Users/taleinat/dev/cpython/Include -I/Users/taleinat/dev/cpython -c /Users/taleinat/dev/cpython/Modules/mathmodule.c -o build/temp.macosx-10.10-x86_64-3.6/Users/taleinat/dev/cpython/Modules/mathmodule.o ./slow-cc.py -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. -IInclude -I/usr/local/include -I/Users/taleinat/dev/cpython/Include -I/Users/taleinat/dev/cpython -c /Users/taleinat/dev/cpython/Modules/_math.c -o build/temp.macosx-10.10-x86_64-3.6/Users/taleinat/dev/cpython/Modules/_math.o ./slow-cc.py -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. -IInclude -I/usr/local/include -I/Users/taleinat/dev/cpython/Include -I/Users/taleinat/dev/cpython -c /Users/taleinat/dev/cpython/Modules/_math.c -o build/temp.macosx-10.10-x86_64-3.6/Users/taleinat/dev/cpython/Modules/_math.o INITIAL COMPILE RECOMPILE RECOMPIILE TRUNCATING INITIAL COMPILE FINISHED ./slow-cc.py -bundle -undefined dynamic_lookup build/temp.macosx-10.10-x86_64-3.6/Users/taleinat/dev/cpython/Modules/mathmodule.o build/temp.macosx-10.10-x86_64-3.6/Users/taleinat/dev/cpython/Modules/_math.o -L/usr/local/lib -o build/lib.macosx-10.10-x86_64-3.6/math.cpython-36m-darwin.so ld: file too small (length=0) file 'build/temp.macosx-10.10-x86_64-3.6/Users/taleinat/dev/cpython/Modules/_math.o' for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) RECOMPILE FINISHED ./slow-cc.py -bundle -undefined dynamic_lookup build/temp.macosx-10.10-x86_64-3.6/Users/taleinat/dev/cpython/Modules/cmathmodule.o build/temp.macosx-10.10-x86_64-3.6/Users/taleinat/dev/cpython/Modules/_math.o -L/usr/local/lib -o build/lib.macosx-10.10-x86_64-3.6/cmath.cpython-36m-darwin.so ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 09:02:53 2015 From: report at bugs.python.org (Tal Einat) Date: Sat, 13 Jun 2015 07:02:53 +0000 Subject: [issue24412] setUpClass equivalent for addCleanup In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za> Message-ID: <1434178973.85.0.946754970545.issue24412@psf.upfronthosting.co.za> Tal Einat added the comment: I'm not convinced this would be worth the effort required to implement and maintain it. Can someone find examples from existing test suites where this would clearly be useful? For example, a setUpClass() or setUpModule() function with multiple try/finally clauses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 09:16:38 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 13 Jun 2015 07:16:38 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434179798.36.0.44641926346.issue24400@psf.upfronthosting.co.za> Nick Coghlan added the comment: Regarding the idea of doing a typedef for the new coro type at the C level: looking further at the way the new type integrates with the eval loop, it's essential that they actually retain the exact same memory layout if we don't want to rewrite a whole lot of code. I still like the idea of adding the typedef so we can at least make the distinction in cases where the C level handling *isn't* shared between the two types, it would just need a great big disclaimer saying that the memory layout of the coroutine struct can't be altered independently of the generator layout. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 09:23:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 13 Jun 2015 07:23:01 +0000 Subject: [issue24412] setUpClass equivalent for addCleanup In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za> Message-ID: <1434180181.57.0.881936874902.issue24412@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: addCleanup() is helpful because it can be used in test methods. addClassCleanup() and addModuleCleanup() can't be used in test methods, and setUpClass() and setUpModule() are used less than setUp(), therefore the benefit of these methods are less than of addCleanup(). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 10:05:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 13 Jun 2015 08:05:33 +0000 Subject: [issue24443] Link for clear and wait missing in EventObjects In-Reply-To: <1434177675.51.0.151907138721.issue24443@psf.upfronthosting.co.za> Message-ID: <20150613080530.91498.48646@psf.io> Roundup Robot added the comment: New changeset a985b6455fde by Berker Peksag in branch '2.7': Issue #24443: Fix links for Event.clear() and Event.wait() methods. https://hg.python.org/cpython/rev/a985b6455fde ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 10:06:22 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 13 Jun 2015 08:06:22 +0000 Subject: [issue24443] Link for clear and wait missing in EventObjects In-Reply-To: <1434177675.51.0.151907138721.issue24443@psf.upfronthosting.co.za> Message-ID: <1434182782.68.0.567118323924.issue24443@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks Jaivish! ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 10:18:50 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 13 Jun 2015 08:18:50 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1434179798.36.0.44641926346.issue24400@psf.upfronthosting.co.za> Message-ID: <557BE765.9010501@behnel.de> Stefan Behnel added the comment: I agree that a typedef is a good idea. It doesn't cost anything but gives us more freedom for future changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 10:19:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 13 Jun 2015 08:19:46 +0000 Subject: [issue24435] Grammar/Grammar points to outdated guide In-Reply-To: <1434049654.36.0.351948731258.issue24435@psf.upfronthosting.co.za> Message-ID: <20150613081943.126036.85424@psf.io> Roundup Robot added the comment: New changeset 4ba334ed3bb7 by Berker Peksag in branch '3.4': Issue #24435: Use the devguide link instead of PEP 306 in Grammar/Grammar. https://hg.python.org/cpython/rev/4ba334ed3bb7 New changeset 1622bc1af766 by Berker Peksag in branch '3.5': Issue #24435: Use the devguide link instead of PEP 306 in Grammar/Grammar. https://hg.python.org/cpython/rev/1622bc1af766 New changeset a9c34db88d79 by Berker Peksag in branch 'default': Issue #24435: Use the devguide link instead of PEP 306 in Grammar/Grammar. https://hg.python.org/cpython/rev/a9c34db88d79 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 10:20:44 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 13 Jun 2015 08:20:44 +0000 Subject: [issue24435] Grammar/Grammar points to outdated guide In-Reply-To: <1434049654.36.0.351948731258.issue24435@psf.upfronthosting.co.za> Message-ID: <1434183644.2.0.422791524863.issue24435@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, Chris. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 10:49:50 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 13 Jun 2015 08:49:50 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434185390.59.0.174440387526.issue24400@psf.upfronthosting.co.za> Nick Coghlan added the comment: Also worth noting: *adding* state to coroutines that isn't present on generators would be fine, they just need to *start* with a layout that exactly matches PyGenObject, since we'll sometimes process them as one. We don't need that now, but separating the types provides the future option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 10:53:17 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 13 Jun 2015 08:53:17 +0000 Subject: [issue22872] multiprocessing.Queue raises AssertionError In-Reply-To: <1415986488.54.0.734820295311.issue22872@psf.upfronthosting.co.za> Message-ID: <1434185597.66.0.780880489077.issue22872@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 11:03:46 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 13 Jun 2015 09:03:46 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1434186226.29.0.251654614823.issue23275@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the reviews. Here is an updated patch. ---------- Added file: http://bugs.python.org/file39703/issue23275_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 11:05:26 2015 From: report at bugs.python.org (Jaivish Kothari) Date: Sat, 13 Jun 2015 09:05:26 +0000 Subject: [issue24443] Link for clear and wait missing in EventObjects In-Reply-To: <1434177675.51.0.151907138721.issue24443@psf.upfronthosting.co.za> Message-ID: <1434186326.01.0.904529804067.issue24443@psf.upfronthosting.co.za> Jaivish Kothari added the comment: My Pleasure sir :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 13:12:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 13 Jun 2015 11:12:38 +0000 Subject: [issue24426] re.split performance degraded significantly by capturing group In-Reply-To: <1433962389.05.0.538082969488.issue24426@psf.upfronthosting.co.za> Message-ID: <1434193958.62.0.638871759418.issue24426@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > 1) Do you know if anybody maintains a patched version of the Python code anywhere? I could put a package up on github/PyPI, if not. Sorry, perhaps I misunderstood you. There are unofficial mirrors of CPython on Bitbucket [1] and GitHub [2]. They don't contain unofficial patches, but perhaps there are private clones with additional patches. Of course different Linux distributives can provide Python with own patches. And you can maintain private fork of CPython with your patches for your own or your company needs. But if you needs only optimized regular expressions, I suggest you to look on the regex module [3]. It is more powerful and better supports Unicode. Results of the same mickrobenchmarks for regex: $ ./python -m timeit -s "import regex as re; p = re.compile('\n'); s = ('a'*100 + '\n')*1000" -- "p.split(s)" 1000 loops, best of 3: 544 usec per loop $ ./python -m timeit -s "import regex as re; p = re.compile('(\n)'); s = ('a'*100 + '\n')*1000" -- "p.split(s)" 1000 loops, best of 3: 661 usec per loop $ ./python -m timeit -s "import regex as re; p = re.compile('\n\r'); s = ('a'*100 + '\n\r')*1000" -- "p.split(s)" 1000 loops, best of 3: 521 usec per loop $ ./python -m timeit -s "import regex as re; p = re.compile('(\n\r)'); s = ('a'*100 + '\n\r')*1000" -- "p.split(s)" 1000 loops, best of 3: 743 usec per loop regex is slightly slower than optimized re in these cases, but is much faster than non-optimized re in the case of splitting with capturing group. > 2) Do you know if anybody has done a good writeup on the behavior of the instruction stream to the C engine? I could try to do some work on this and put it with the package, if not, or point to it if so. Sorry, I don't understood you. Do you mean documenting codes of compiled re pattern? This is implementation detail and will be changed in future. [1] https://bitbucket.org/mirror/cpython [2] https://github.com/python/cpython [3] https://pypi.python.org/pypi/regex ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 15:18:19 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 13 Jun 2015 13:18:19 +0000 Subject: [issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping. In-Reply-To: <1432750979.18.0.523128349285.issue24303@psf.upfronthosting.co.za> Message-ID: <1434201499.03.0.367499925941.issue24303@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- keywords: +needs review nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 15:29:53 2015 From: report at bugs.python.org (o1da) Date: Sat, 13 Jun 2015 13:29:53 +0000 Subject: [issue24445] rstrip strips what it doesn't have to Message-ID: <1434202193.55.0.291762155512.issue24445@psf.upfronthosting.co.za> New submission from o1da: Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> text = 'test1/1.jp2' >>> text.rstrip('.jp2') 'test1/1' >>> text = 'test1.jp2' >>> text.rstrip('.jp2') 'test1' >>> text = 'test1/2.jp2' >>> text.rstrip('.jp2') 'test1/' >>> Why the rstrip function stripped '2' from the last example? I think that it is a bug. ---------- messages: 245311 nosy: o1da priority: normal severity: normal status: open title: rstrip strips what it doesn't have to versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 15:46:38 2015 From: report at bugs.python.org (Patrick Maupin) Date: Sat, 13 Jun 2015 13:46:38 +0000 Subject: [issue24445] rstrip strips what it doesn't have to In-Reply-To: <1434202193.55.0.291762155512.issue24445@psf.upfronthosting.co.za> Message-ID: <1434203198.58.0.533131248027.issue24445@psf.upfronthosting.co.za> Patrick Maupin added the comment: I think you misunderstand rstrip -- it works from the right, and checks to see if the right-most character is in the string you have given it. As long as it is, then it will remove the character and loop ---------- nosy: +Patrick Maupin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 15:47:55 2015 From: report at bugs.python.org (Patrick Maupin) Date: Sat, 13 Jun 2015 13:47:55 +0000 Subject: [issue24445] rstrip strips what it doesn't have to In-Reply-To: <1434202193.55.0.291762155512.issue24445@psf.upfronthosting.co.za> Message-ID: <1434203275.5.0.440735958669.issue24445@psf.upfronthosting.co.za> Patrick Maupin added the comment: Example >>> text = 'test1/1.jp2' >>> text.rstrip('.2jp') 'test1/1' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 15:51:58 2015 From: report at bugs.python.org (o1da) Date: Sat, 13 Jun 2015 13:51:58 +0000 Subject: [issue24445] rstrip strips what it doesn't have to In-Reply-To: <1434202193.55.0.291762155512.issue24445@psf.upfronthosting.co.za> Message-ID: <1434203518.39.0.158910423513.issue24445@psf.upfronthosting.co.za> o1da added the comment: Ok, thank you. I thought it trims whole sequence or nothing. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 16:00:13 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 13 Jun 2015 14:00:13 +0000 Subject: [issue24445] rstrip strips what it doesn't have to In-Reply-To: <1434202193.55.0.291762155512.issue24445@psf.upfronthosting.co.za> Message-ID: <1434204013.23.0.340087328942.issue24445@psf.upfronthosting.co.za> Martin Panter added the comment: The 3.5 documentation of str.strip() was recently modified in Issue 24204 due to this kind of misunderstanding. Perhaps other versions should be modified as well, or the str.l/rstrip() methods, or the bytes() and bytearray() methods. See also Issue 23560 proposing to group the documentation of these methods together. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 16:04:36 2015 From: report at bugs.python.org (Patrick Maupin) Date: Sat, 13 Jun 2015 14:04:36 +0000 Subject: [issue24426] re.split performance degraded significantly by capturing group In-Reply-To: <1433962389.05.0.538082969488.issue24426@psf.upfronthosting.co.za> Message-ID: <1434204276.56.0.601257315047.issue24426@psf.upfronthosting.co.za> Patrick Maupin added the comment: > (stuff about cPython) No, I was curious about whether somebody maintained pure-Python fixes (e.g. to the re parser and compiler). Those could be in a regular package that fixed some corner cases such as the capture group you just applied a patch for. > ... regex is more powerful and better supports Unicode. Unfortunately, it is still not competitive. For example, for one package I maintain (github.com/pmaupin/pdfrw), I have one unittest which reads in and parses several PDF files, and then outputs them to new PDF files: Python 2.7 with re -- 5.9 s Python 2.7 with regex -- 6.9 s Python 3.4 with re -- 7.2 s Python 3.4 with regex -- 8.2 s A large reason for the difference between 2.7 and 3.4 is the fact that I'm too lazy, or it seems too error-prone, to put the b'xxx' in front of every string, so the package uses the same source code for 2.7 and 3.4, which means unicode strings for 3.4 and byte strings for 2.7. Nonetheless, when you consider all the other work going on in the package, a 14% _overall_ slowdown to change to a "better" re package seems like going the wrong direction, especially when stacked on top of the 22% slowdown for switching to Python3. > Do you mean documenting codes of compiled re pattern? Yes. > This is implementation detail and will be changed in future. Understood, and that's fine. If the documentation existed, it would have helped if I want to create a pure-python package that simply performed optimizations (like the one in your patch) against existing Python implementations, for use until regex (which is a HUGE undertaking) is ready. Thanks, Pat ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 16:51:48 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 13 Jun 2015 14:51:48 +0000 Subject: [issue795081] email.Message param parsing problem II Message-ID: <1434207108.73.0.680237368587.issue795081@psf.upfronthosting.co.za> R. David Murray added the comment: It think the thing to do is to turn it into a test case for both the old and the new parser, and the decide what we want the behavior to be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 16:57:16 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 13 Jun 2015 14:57:16 +0000 Subject: [issue24412] setUpClass equivalent for addCleanup In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za> Message-ID: <1434207436.02.0.942240060547.issue24412@psf.upfronthosting.co.za> R. David Murray added the comment: Not having addClassCleanup means that my setUpClass method will have four try/excepts in it, as will my tearDownClass (I have four fixtures I'm setting up for the tests). So, no, it isn't strictly needed, but it is prettier :). As Robert says, though, it makes for a nice symmetry in the API. Basically, I like to see tearDown deprecated, as I find the setup/addcleanup pattern much easier to write and, more importantly, to read. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 17:11:24 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 13 Jun 2015 15:11:24 +0000 Subject: [issue23992] multiprocessing: MapResult shouldn't fail fast upon exception In-Reply-To: <1429347621.56.0.157795358647.issue23992@psf.upfronthosting.co.za> Message-ID: <1434208284.41.0.700664617976.issue23992@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- keywords: +needs review nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 17:51:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 13 Jun 2015 15:51:36 +0000 Subject: [issue24426] re.split performance degraded significantly by capturing group In-Reply-To: <1433962389.05.0.538082969488.issue24426@psf.upfronthosting.co.za> Message-ID: <1434210696.72.0.35383346889.issue24426@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a reason to file a feature request to regex. In 3.3 re was slower than regex in some cases: $ ./python -m timeit -s "import re; p = re.compile('\n\r'); s = ('a'*100 + '\n\r')*1000" -- "p.split(s)" Python 3.3 re : 1000 loops, best of 3: 952 usec per loop Python 3.4 regex: 1000 loops, best of 3: 757 usec per loop Python 3.4 re : 1000 loops, best of 3: 323 usec per loop And this optimization (issue18685 or others) can be applied to regex. As for this particular issue, the optimization of splitting with 1-character capturing group needs changes to C part of re engine. Python part of my patch is not needed for this, it is here only for generalizing support of other corner cases. So this issue can't be fixed with patching only Python code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 18:43:24 2015 From: report at bugs.python.org (Henrik Heimbuerger) Date: Sat, 13 Jun 2015 16:43:24 +0000 Subject: [issue24127] Fatal error in launcher: Job information querying failed In-Reply-To: <1430827026.9.0.339920575451.issue24127@psf.upfronthosting.co.za> Message-ID: <1434213804.26.0.0355120627811.issue24127@psf.upfronthosting.co.za> Henrik Heimbuerger added the comment: I can still reproduce this on the just released Windows 10 build 10130, after "python -m pip uninstall pip" and then "python get-pip.py" (which recreated the pip.exe binary for pip 7.0.3). Is there anything else I need to do to make this work now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 18:50:02 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 13 Jun 2015 16:50:02 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434214202.47.0.193091923569.issue24429@psf.upfronthosting.co.za> Steve Dower added the comment: About the only possible solution here would be to special case ctypes to detect msvcr90 as a parameter (later versions of the CRT don't need it) and also whether another activation context already exists. We could also document the need for a complete manifest in the embedding docs. All of this really only affects 2.7, as later versions of Python don't necessarily suffer the same limitation (unless someone wants to load msvcr90 explicitly). What functionality do you need that you can't get some other way (such as the msvcrt module)? Or is it just the uuid issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 20:15:15 2015 From: report at bugs.python.org (erik flister) Date: Sat, 13 Jun 2015 18:15:15 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434219315.28.0.871752264992.issue24429@psf.upfronthosting.co.za> erik flister added the comment: > About the only possible solution here would be to special case ctypes to detect msvcr90 as a parameter (later versions of the CRT don't need it) and also whether another activation context already exists. We could also document the need for a complete manifest in the embedding docs. i'm not following why it's a special case, or why later versions wouldn't have the same problem? isn't this a problem for any DLLs that the embedding context may have loaded that would conflict with DLLs that python depends on? python's DLL already has the necessary "complete manifest," right? as long as CDLL does the proper context manipulations, client code shouldn't have to worry about whether it's running embedded, right? what is the purpose of ctypes.cdll.msvcrt if no one is supposed to use it? there is also "import msvcrt" which is apparently a subset of what you get from find_library('c'), so would need the same fix? > All of this really only affects 2.7, as later versions of Python don't necessarily suffer the same limitation (unless someone wants to load msvcr90 explicitly). what changed that avoids the problem? perhaps that fix can be applied to 2.7? > What functionality do you need that you can't get some other way (such as the msvcrt module)? Or is it just the uuid issue? innocent ol' me was just trying to import shapely from matlab - they call find_library('c') and need the 'free' function. i don't think they ever malloc -- they depend on a geos_c.dll, which must do the allocations and is built on whatever msvcrt was used for python? probably a better design would be for geos_c.dll to export its own free function? but afaiu, geos_c.dll comes from a totally different (more legacy?) project, not python related... shapely is a dependency of the library i actually need, which also uses uuid. uuid is the only case i can find in the standard libraries that also calls find_library('c'). manually changing those calls allowed me to successfully import everything from matlab. ctypes and distutils also mention msvc* a lot, obviously... getpass.py and multiprocessing and subprocess use "import msvcrt". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 20:30:36 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 13 Jun 2015 18:30:36 +0000 Subject: [issue24445] rstrip strips what it doesn't have to In-Reply-To: <1434202193.55.0.291762155512.issue24445@psf.upfronthosting.co.za> Message-ID: <1434220236.47.0.651084855601.issue24445@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- resolution: -> not a bug stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 21:06:56 2015 From: report at bugs.python.org (Tal Einat) Date: Sat, 13 Jun 2015 19:06:56 +0000 Subject: [issue24412] setUpClass equivalent for addCleanup In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za> Message-ID: <1434222416.67.0.118779730706.issue24412@psf.upfronthosting.co.za> Tal Einat added the comment: Ahh, that makes sense. Sounds good to me! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 21:41:07 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 13 Jun 2015 19:41:07 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1434224467.97.0.754687168146.issue23996@psf.upfronthosting.co.za> Stefan Behnel added the comment: No. It's more that it feels wrong to spend actual time on the second most common case that can occur instead of just handling it in no time at all. The third case that it's really required to instantiate the StopIteration exception (if user code didn't do so already, see case 1) should almost never occur in practice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 21:42:50 2015 From: report at bugs.python.org (Victor Varvariuc) Date: Sat, 13 Jun 2015 19:42:50 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1434224570.97.0.293604630775.issue5845@psf.upfronthosting.co.za> Victor Varvariuc added the comment: Here is the new issue (putting the link here for reference): http://bugs.python.org/issue22086 ---------- nosy: +Victor.Varvariuc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 21:48:40 2015 From: report at bugs.python.org (Patrick Maupin) Date: Sat, 13 Jun 2015 19:48:40 +0000 Subject: [issue24426] re.split performance degraded significantly by capturing group In-Reply-To: <1433962389.05.0.538082969488.issue24426@psf.upfronthosting.co.za> Message-ID: <1434224920.28.0.718450031382.issue24426@psf.upfronthosting.co.za> Patrick Maupin added the comment: OK, thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 22:07:46 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 13 Jun 2015 20:07:46 +0000 Subject: [issue22086] Tab indent no longer works in interpreter In-Reply-To: <1406396060.4.0.777513387491.issue22086@psf.upfronthosting.co.za> Message-ID: <1434226066.53.0.764433785012.issue22086@psf.upfronthosting.co.za> R. David Murray added the comment: In between this issue being opened and that fact being noted on the original issue, issue 23441 was opened, and I noticed that one and set it to release blocker. That issue has a patch, as noted, so I'm closing this one as a duplicate. ---------- nosy: +r.david.murray resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> rlcompleter: tab on empty prefix => insert spaces _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 13 22:09:00 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 13 Jun 2015 20:09:00 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1434226140.88.0.11305987887.issue5845@psf.upfronthosting.co.za> R. David Murray added the comment: The active issue for this is now 23441. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 00:05:16 2015 From: report at bugs.python.org (Ernesto Alfonso) Date: Sat, 13 Jun 2015 22:05:16 +0000 Subject: [issue24446] imap and map inconsistent behaviour Message-ID: <1434233116.75.0.429169275547.issue24446@psf.upfronthosting.co.za> New submission from Ernesto Alfonso: itertools.imap and map in Python 2.7 produces inconsistent behaviour when mapping the null (None) function over multiple sequences. >>> [a for a in map(None, list("abcd"), range(3))] [('a', 0), ('b', 1), ('c', 2), ('d', None)] >>> from itertools import imap >>> [a for a in imap(None, list("abcd"), range(3))] [('a', 0), ('b', 1), ('c', 2)] >>> [a for a in map(None, list("abcd"), range(3))] == [a for a in imap(None, list("abcd"), range(3))] False >>> This inconsistent and unintuitive behvaiour caused a bug in my program ---------- components: Interpreter Core, Library (Lib) messages: 245329 nosy: Ernesto Alfonso priority: normal severity: normal status: open title: imap and map inconsistent behaviour type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 00:12:59 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 13 Jun 2015 22:12:59 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434233579.82.0.482436121281.issue24429@psf.upfronthosting.co.za> Steve Dower added the comment: > i'm not following why it's a special case, or why later versions wouldn't have the same problem? The Microsoft C Runtime 9.0 required an activation context to allow multiple versions to load side by side. This turned out to be more trouble than it was worth, and so version 10.0 removed that requirement. > isn't this a problem for any DLLs that the embedding context may have loaded that would conflict with DLLs that python depends on? For any DLL that requires a version specification in the current activation context, yes. These are fairly rare, but if the DLL checks, then the context needs to be created for it. (MSVCRT 9.0 requires it and checks - hence the error when it isn't set up.) > python's DLL already has the necessary "complete manifest," right? In theory yes, but apparently it isn't working in this case. It needs more investigation to figure out why. > what is the purpose of ctypes.cdll.msvcrt if no one is supposed to use it? ctypes.cdll.msvcrt doesn't really exist - ctypes.cdll turns it into a LoadLibrary("msvcrt") call that works because Windows keeps shipping msvcrt.dll for backwards compatibility (for applications that rely on msvcrt.dll entirely - not piecemeal). > there is also "import msvcrt" which is apparently a subset of what you get from find_library('c'), so would need the same fix? No, because this module is built into Python's DLL (and does properly conversion from Python types to C types, which occasionally differ from the ctypes conversions). If you've been able to load Python, these functions will be fine. > what changed that avoids the problem? perhaps that fix can be applied to 2.7? Python 3.0-3.2 are also affected, but Python 3.3 and later use newer versions of the CRT that do not have the manifest requirement. It's been discussed in the past and has been decided that the official builds of Python will not change compiler version without a version bump (in this case, 2.7->2.8 would be required, but has been ruled out). > innocent ol' me was just trying to import shapely from matlab - they call find_library('c') and need the 'free' function. i don't think they ever malloc -- they depend on a geos_c.dll, which must do the allocations and is built on whatever msvcrt was used for python? probably a better design would be for geos_c.dll to export its own free function? but afaiu, geos_c.dll comes from a totally different (more legacy?) project, not python related... Yeah, geos_c.dll really should have exported its own free() function. find_library('c') is probably the wrong approach here - if geos_c.dll is being rebuilt with different CRTs at all then the free() function should be added to it, and if it's truly legacy and is no longer being rebuilt then the version of the CRT it uses should be loaded explicitly. It isn't automatically getting the same version as whatever version of Python is running, that's for sure. > uuid is the only case i can find in the standard libraries that also calls find_library('c'). As I said earlier, I'm sure we'd accept a patch to uuid.py to avoid that call on Windows (or completely remove it - I was sure at one point that ctypes was considered off-limits for the stdlib). Everything ought to be going through "import msvcrt" or their own extension modules, and it sounds like they mostly are. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 02:43:40 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 14 Jun 2015 00:43:40 +0000 Subject: [issue24446] imap and map inconsistent behaviour In-Reply-To: <1434233116.75.0.429169275547.issue24446@psf.upfronthosting.co.za> Message-ID: <1434242620.17.0.0619439676842.issue24446@psf.upfronthosting.co.za> Ned Deily added the comment: This is a documented behavior difference in itertools.imap: "If function is set to None, then imap() returns the arguments as a tuple. Like map() but stops when the shortest iterable is exhausted instead of filling in None for shorter iterables. The reason for the difference is that infinite iterator arguments are typically an error for map() (because the output is fully evaluated) but represent a common and useful way of supplying arguments to imap()." https://docs.python.org/2/library/itertools.html#itertools.imap ---------- nosy: +ned.deily resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 02:48:02 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 14 Jun 2015 00:48:02 +0000 Subject: [issue24446] imap and map inconsistent behaviour In-Reply-To: <1434233116.75.0.429169275547.issue24446@psf.upfronthosting.co.za> Message-ID: <1434242882.21.0.95152738663.issue24446@psf.upfronthosting.co.za> Ned Deily added the comment: Also note that the behavior of map() in Python 3 has been changed to also stop with the termination of the shortest iterator. https://docs.python.org/3.4/whatsnew/3.0.html#views-and-iterators-instead-of-lists ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 05:33:14 2015 From: report at bugs.python.org (Dingyuan Wang) Date: Sun, 14 Jun 2015 03:33:14 +0000 Subject: [issue24447] tab indentation breaks in tokenize.untokenize Message-ID: <1434252794.24.0.0112893923697.issue24447@psf.upfronthosting.co.za> New submission from Dingyuan Wang: If a script uses tabs for indentation, tokenize.untokenize won't restore original indentation correctly from the second line of the indentation level, and thus breaks the file. This affects all Python versions. Test code: python2 -c 'import sys, tokenize; sys.stdout.write(tokenize.untokenize(tokenize.generate_tokens(sys.stdin.readline)))' < tab.py python3 -c 'import sys, tokenize; sys.stdout.buffer.write(tokenize.untokenize(tokenize.tokenize(sys.stdin.buffer.readline)))' < tab.py Out: def foo(): pass pass if 1: pass pass ---------- components: Library (Lib) files: tab.py messages: 245333 nosy: gumblex priority: normal severity: normal status: open title: tab indentation breaks in tokenize.untokenize type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file39704/tab.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 08:16:17 2015 From: report at bugs.python.org (irdb) Date: Sun, 14 Jun 2015 06:16:17 +0000 Subject: [issue24448] Syntax highlighting marks multiline comments as strings Message-ID: <1434262576.97.0.123947261736.issue24448@psf.upfronthosting.co.za> New submission from irdb: It has been suggested by BDFL to use triple-quoted strings as multiline comments.[1] Allegedly, some editors already makes a distinction between these kind of comments and docstring and highlight them differently. It would be nice if IDLE could also highlight these kind of comments with the same color as the other single-line comments. [1]: https://stackoverflow.com/posts/7696966/revisions ---------- components: IDLE messages: 245334 nosy: irdb priority: normal severity: normal status: open title: Syntax highlighting marks multiline comments as strings type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 09:09:58 2015 From: report at bugs.python.org (eryksun) Date: Sun, 14 Jun 2015 07:09:58 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434265798.42.0.368737926402.issue24429@psf.upfronthosting.co.za> eryksun added the comment: >> python's DLL already has the necessary "complete manifest," right? > > In theory yes, but apparently it isn't working in this case. It > needs more investigation to figure out why. The manifest in the DLL is stored as resource ID 2. This secondary manifest is used by the loader to create a temporary activation context while python27.dll is loaded. Thus allows it to load msvcr90.dll. [python27!DllMain][1] stores the current activation context. This gets reactivated when loading extension modules. Thus when Python 2.7 is embedded, there's no problem loading extensions that depend on msvcr90.dll, such as _ctypes.pyd. If _Py_ActivateActCtx and _Py_DeactivateActCtx were exported, they could be called in [_ctypes!load_library][2]. That should solve this problem with using ctypes.CDLL('msvcr90') in embedded Python. > Windows keeps shipping msvcrt.dll for backwards compatibility (for > applications that rely on msvcrt.dll entirely - not piecemeal). Windows itself is the primary user of msvcrt.dll. A Windows 7 installation has over 1500 DLLs and over 350 executables in System32 that depend on msvcrt.dll. Windows developers such as Raymond Chen get a bit annoyed when projects link directly with msvcrt.dll. See [Windows is not a Microsoft Visual C/C++ Run-Time delivery channel][3]. > Yeah, geos_c.dll really should have exported its own free() > function. Each CRT uses a private heap, so mismatching free() and malloc() from different CRTs is wrong. geos_c really should export a free() function. Actually, it really should have the user allocate data. [1]: https://hg.python.org/cpython/file/15c95b7d81dc/PC/dl_nt.c#l79 [2]: https://hg.python.org/cpython/file/15c95b7d81dc/Modules/_ctypes/callproc.c#l1267 [3]: http://blogs.msdn.com/b/oldnewthing/archive/2014/04/11/10516280.aspx ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 09:50:50 2015 From: report at bugs.python.org (Paul Sokolovsky) Date: Sun, 14 Jun 2015 07:50:50 +0000 Subject: [issue24449] Please add async write method to asyncio.StreamWriter Message-ID: <1434268250.18.0.99884254892.issue24449@psf.upfronthosting.co.za> New submission from Paul Sokolovsky: This issue was brought is somewhat sporadic manner on python-tulip mailing list, hence this ticket. The discussion on the ML: https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/knMvVGxp2WsJ (all other messages below threaded from this) https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/lGqT54yupOIJ https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/U0NBC1jLGSgJ https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/zIx59jj8krsJ https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/zSpjGKv23ioJ https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/3mfGI8HIe_gJ https://groups.google.com/d/msg/python-tulip/JA0-FC_pliA/rM4fyA9qlY4J Summary of arguments: 1. This would make such async_write() (a tentative name) symmetrical in usage with read() method (i.e. be a coroutine to be used with "yield from"/"await"), which certainly reduce user confusion and will help novices to learn/use asyncio. 2. write() method is described (by transitively referring to WriteTransport.write()) as "This method does not block; it buffers the data and arranges for it to be sent out asynchronously." Such description implies requirement of unlimited data buffering. E.g., being fed with 1TB of data, it still must buffer it. Bufferings of such size can't/won't work in practice - they only will lead to excessive swapping and/or termination due to out of memory conditions. Thus, providing only synchronous high-level write operation goes against basic system reliability/security principles. 3. The whole concept of synchronous write in an asynchronous I/O framework stems from: 1) the way it was done in some pre-existing Python async I/O frameworks ("pre-existing" means brought up with older versions of Python and based on concepts available at that time; many people use word "legacy" in such contexts); 2) on PEP3153, which essentially captures ideas used in the aforementioned pre-existing Python frameworks. PEP3153 was rejected; it also contains some "interesting" claims like "Considered API alternatives - Generators as producers - [...] - nobody produced actually working code demonstrating how they could be used." That wasn't true at the time of PEP writing (http://www.dabeaz.com/generators/ , 2008, 2009), and asyncio is actually *the* framework which uses generators as producers. asyncio also made a very honorable step of uniting generators/coroutine and Transport paradigm - note that as PEP3153 shows, Transport proponents contrasted it with coroutine-based design. But asyncio also blocked (in both senses) high-level I/O on Transport paradigm. What I'm arguing is not that Transports are good or bad, but that there should be a way to consistently use coroutine paradigm for I/O in asyncio - for people who may appreciate it. This will also enable alternative implementations of asyncio subsets without Transport layer, with less code size, and thus more suitable for constrained environments. Proposed change is to add following to asyncio.StreamWriter implementation: @coroutine def async_write(self, data): self.write(data) I.e. default implementation will be just coroutine version of synchronous write() method. The messages linked above discuss alternative implementations (which are really interesting for complete alternative implementations of asyncio). The above changes are implemented in MicroPython's uasyncio package, which asyncio subset for memory-constrained systems. Thanks for your consideration! ---------- components: asyncio messages: 245336 nosy: gvanrossum, haypo, pfalcon, yselivanov priority: normal severity: normal status: open title: Please add async write method to asyncio.StreamWriter versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 11:39:41 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Jun 2015 09:39:41 +0000 Subject: [issue24449] Please add async write method to asyncio.StreamWriter In-Reply-To: <1434268250.18.0.99884254892.issue24449@psf.upfronthosting.co.za> Message-ID: <1434274781.59.0.752007838907.issue24449@psf.upfronthosting.co.za> Guido van Rossum added the comment: Paul, you have brought this up many times before, and you have been refuted each time. Reading and writing just aren't symmetric operations. If you need awrite(), it's a two-line helper function you can easily write yourself. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 12:29:47 2015 From: report at bugs.python.org (Benno Leslie) Date: Sun, 14 Jun 2015 10:29:47 +0000 Subject: [issue24450] Add gi_yieldfrom calculated property to generator object Message-ID: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> New submission from Benno Leslie: When a co-routine has delegated computation to another co-routine via "yield from", it is useful to be able to access the delegated-to co-routine. This proposed enhancement would add a new calculated property to the generator object called "gi_yieldfrom", which returns the delegated-to co-routine (or None). ---------- components: Interpreter Core messages: 245338 nosy: bennoleslie priority: normal severity: normal status: open title: Add gi_yieldfrom calculated property to generator object type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 12:42:58 2015 From: report at bugs.python.org (Baptiste Mispelon) Date: Sun, 14 Jun 2015 10:42:58 +0000 Subject: [issue24416] Return a namedtuple from date.isocalendar() In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za> Message-ID: <1434278578.56.0.502667898171.issue24416@psf.upfronthosting.co.za> Baptiste Mispelon added the comment: Here's a new patch with the name `IsoCalendarDate` used (it also fixes a wrong version in the `versionadded` section in the docs). Thanks ---------- Added file: http://bugs.python.org/file39705/issue24416_4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 12:48:39 2015 From: report at bugs.python.org (Benno Leslie) Date: Sun, 14 Jun 2015 10:48:39 +0000 Subject: [issue24450] Add gi_yieldfrom calculated property to generator object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1434278919.07.0.430797359177.issue24450@psf.upfronthosting.co.za> Benno Leslie added the comment: Attached is my first attempt at implementing this feature. It includes to implementation, updates to documentation, and added test cases. I'm not a regular contributor so look forward to any feedback on improving the patch. ---------- keywords: +patch Added file: http://bugs.python.org/file39706/gi_yieldfrom.v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 13:43:10 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 14 Jun 2015 11:43:10 +0000 Subject: [issue24450] Add gi_yieldfrom calculated property to generator object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1434282190.33.0.463189503225.issue24450@psf.upfronthosting.co.za> Martin Panter added the comment: I left some comments on Reitveld. Does this also apply to the new ?async def? native coroutines? If not, I think it should be made to. ---------- nosy: +vadmium stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 14:46:39 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 14 Jun 2015 12:46:39 +0000 Subject: [issue24087] Documentation doesn't explain the term "coroutine" (PEP 342) In-Reply-To: <1430425552.31.0.779606074615.issue24087@psf.upfronthosting.co.za> Message-ID: <1434285999.32.0.0575830762335.issue24087@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a new patch: * Clarified some recent instances of ?coroutine? as ?native coroutine? (term taken from PEP 492) * Put ?coroutine? before ?coroutine function? in the glossary. * Merge ?Use as coroutines? section into new coroutine compound statement documentation * Add links to glossary entry * Added one mention of the new ?async? coroutines to ?asyncio?. I understand this is meant to be supported in 3.5, but still needs more documentation work. ---------- versions: +Python 3.6 Added file: http://bugs.python.org/file39707/coroutine_docs.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 15:55:08 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 14 Jun 2015 13:55:08 +0000 Subject: [issue5209] nntplib needs updating to RFC 3977 In-Reply-To: <1234294968.88.0.213485994333.issue5209@psf.upfronthosting.co.za> Message-ID: <1434290108.98.0.271747296252.issue5209@psf.upfronthosting.co.za> Martin Panter added the comment: General RFC 3977 support was added as part of Issue 9360 (revision 0077ee30134c), so I am closing this one. For the record there are a couple bits of the patch that someone might still find useful: * New NNTP(bind=...) parameter * More lenient checking for successful authentication status ---------- nosy: +vadmium resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 18:26:36 2015 From: report at bugs.python.org (Paul Sokolovsky) Date: Sun, 14 Jun 2015 16:26:36 +0000 Subject: [issue24449] Please add async write method to asyncio.StreamWriter In-Reply-To: <1434268250.18.0.99884254892.issue24449@psf.upfronthosting.co.za> Message-ID: <1434299196.08.0.0912738698449.issue24449@psf.upfronthosting.co.za> Paul Sokolovsky added the comment: No, I haven't brought this "many times before". Discussion on the mailing list last week was first time I brought up *this* issue. But it's indeed not the first time I provide feedback regarding various aspects of asyncio, so I wonder if this issue was closed because of "this" in "this issue" or because of "many times before"... > If you need awrite(), it's a two-line helper function you can easily write yourself. Yes, and I have it, but I don't see how that helps anybody else. If it's 2-liner, why don't you want to add it? Can there please be discussion of the arguments provided in the description? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 19:16:11 2015 From: report at bugs.python.org (Joshua Harlow) Date: Sun, 14 Jun 2015 17:16:11 +0000 Subject: [issue24451] Add metrics to future objects (concurrent or asyncio?) Message-ID: <1434302171.22.0.0439382195068.issue24451@psf.upfronthosting.co.za> New submission from Joshua Harlow: It would be quite useful to have some types of metrics attached to future objects so that callers could use them for various activities (scheduling repeated runs, post-analysis and such): Some of the ones that I can think would be useful: - 'submitted_at' (when the callback was submitted to the executor responsible for executing it) - 'started_at' (when the executor actually started executing the callback, which is typically sometime after it was submitted) - 'finished_at' (when the executor finished calling the callback) - elapsed [finished_at - started_at] (the elapsed runtime of the callback) Do others feel this would be useful (if so I can put up some patches)? Right now getting this information is pretty hard to get at (since the executors that exist currently do not expose this information and it is quite hard to obtain it in a reliable manner). ---------- components: Library (Lib) messages: 245345 nosy: Joshua.Harlow priority: normal severity: normal status: open title: Add metrics to future objects (concurrent or asyncio?) type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 19:26:42 2015 From: report at bugs.python.org (Christie) Date: Sun, 14 Jun 2015 17:26:42 +0000 Subject: [issue23981] Update test_unicodedata.py to use script_helpers In-Reply-To: <1429228835.0.0.167852596687.issue23981@psf.upfronthosting.co.za> Message-ID: <1434302802.06.0.0479507973592.issue23981@psf.upfronthosting.co.za> Christie added the comment: Uploading a new patch, diffed against a public revision so it's reviewable. ---------- Added file: http://bugs.python.org/file39708/issue23981_test_unicode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 19:31:15 2015 From: report at bugs.python.org (Christie) Date: Sun, 14 Jun 2015 17:31:15 +0000 Subject: [issue24279] Update test_base64 to use test.support.script_helper In-Reply-To: <1432498391.21.0.154907178378.issue24279@psf.upfronthosting.co.za> Message-ID: <1434303075.89.0.498578300809.issue24279@psf.upfronthosting.co.za> Christie added the comment: Uploading a new patch, diffed against a public revision so it's reviewable. ---------- Added file: http://bugs.python.org/file39709/issue24279_base64.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 20:39:44 2015 From: report at bugs.python.org (Christie) Date: Sun, 14 Jun 2015 18:39:44 +0000 Subject: [issue24033] Update _test_multiprocessing.py to use script helpers In-Reply-To: <1429748807.96.0.769250379827.issue24033@psf.upfronthosting.co.za> Message-ID: <1434307184.49.0.101131687792.issue24033@psf.upfronthosting.co.za> Christie added the comment: Now using existing function spawn_python instead of creating a new function. ---------- Added file: http://bugs.python.org/file39710/issue24033_multi.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 20:47:42 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 14 Jun 2015 18:47:42 +0000 Subject: [issue24449] Please add async write method to asyncio.StreamWriter In-Reply-To: <1434268250.18.0.99884254892.issue24449@psf.upfronthosting.co.za> Message-ID: <1434307662.23.0.25067753859.issue24449@psf.upfronthosting.co.za> Guido van Rossum added the comment: Most people actually are better off with just write(), and an API with more choices is not necessarily better. I'm sure this has come up before, I could've sworn it was you, sorry if it wasn't. Here's one reason why I don't like your proposed API. The read() and write() calls *aren't* symmetric: When you call read(), you are interested in the return value. If you forget the "yield from" (or 'async') your use of the return value will most likely raise an exception immediately, so you will notice (and pinpoint) the bug in your code instantly. But with write() there is no natural return value, so if write() was a coroutine, the common mistake (amongst beginners) of forgetting the "yield from" or 'async' would be much harder to debug -- your program happily proceeds, but now it's likely hung, waiting for a response that it won't get (because the other side didn't get what you meant to write) or perhaps you get a cryptic error (because the other side saw the thing you wrote next). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 21:09:06 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 14 Jun 2015 19:09:06 +0000 Subject: [issue24448] Syntax highlighting marks multiline comments as strings In-Reply-To: <1434262576.97.0.123947261736.issue24448@psf.upfronthosting.co.za> Message-ID: <1434308946.08.0.992565422725.issue24448@psf.upfronthosting.co.za> Raymond Hettinger added the comment: -1 on changing the syntax highlighting for strings used as comments. Whether used as comments or for other purposes, they are still strings and the distinction is important for teaching Python. ---------- nosy: +rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 14 23:33:26 2015 From: report at bugs.python.org (Ned Batchelder) Date: Sun, 14 Jun 2015 21:33:26 +0000 Subject: [issue24452] Make webbrowser support Chrome on Mac OS/X Message-ID: <1434317605.99.0.218705045555.issue24452@psf.upfronthosting.co.za> New submission from Ned Batchelder: This doesn't work on Python 3.4 on a Mac with Yosemite and Chrome installed: import webbrowser webbrowser.get("chrome") This patch makes it work: ``` *** /usr/local/pythonz/pythons/CPython-3.4.1/lib/python3.4/webbrowser.py 2014-09-21 16:37:46.000000000 -0400 --- /Users/ned/foo/webbrowser.py 2015-06-14 17:31:28.000000000 -0400 *************** *** 605,614 **** --- 605,615 ---- # Don't clear _tryorder or _browsers since OS X can use above Unix support # (but we prefer using the OS X specific stuff) register("safari", None, MacOSXOSAScript('safari'), -1) register("firefox", None, MacOSXOSAScript('firefox'), -1) + register("chrome", None, MacOSXOSAScript('chrome'), -1) register("MacOSX", None, MacOSXOSAScript('default'), -1) # OK, now that we know what the default preference orders for each # platform are, allow user to override them with the BROWSER variable. ``` ---------- components: Library (Lib) messages: 245351 nosy: nedbat priority: normal severity: normal status: open title: Make webbrowser support Chrome on Mac OS/X versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 00:06:55 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 14 Jun 2015 22:06:55 +0000 Subject: [issue24452] Make webbrowser support Chrome on Mac OS X In-Reply-To: <1434317605.99.0.218705045555.issue24452@psf.upfronthosting.co.za> Message-ID: <1434319615.85.0.989158722166.issue24452@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: +Macintosh nosy: +ned.deily, ronaldoussoren stage: -> patch review title: Make webbrowser support Chrome on Mac OS/X -> Make webbrowser support Chrome on Mac OS X versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 00:14:20 2015 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Sun, 14 Jun 2015 22:14:20 +0000 Subject: [issue24453] A typo of doubled "the" words in the doc (easy fix) Message-ID: <1434320060.96.0.386004077097.issue24453@psf.upfronthosting.co.za> New submission from Bo?tjan Mejak: https://docs.python.org/3.4/library/webbrowser.html#module-webbrowser Visit the link and read the first sentence of the 3rd paragraph. You'll notice that there are two "the" words by the end of that sentence. That's obviously a typo. Please fix it. The typo, however, is not present in the documentation for Python 3.5. Don't know why the 3.4 branch of the docs wasn't fixed as well. ---------- assignee: docs at python components: Documentation messages: 245352 nosy: Pikec, docs at python priority: normal severity: normal status: open title: A typo of doubled "the" words in the doc (easy fix) versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 01:05:53 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 14 Jun 2015 23:05:53 +0000 Subject: [issue24453] A typo of doubled "the" words in the doc (easy fix) In-Reply-To: <1434320060.96.0.386004077097.issue24453@psf.upfronthosting.co.za> Message-ID: <1434323153.86.0.951367708099.issue24453@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 01:06:01 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 14 Jun 2015 23:06:01 +0000 Subject: [issue24453] A typo of doubled "the" words in the doc (easy fix) In-Reply-To: <1434320060.96.0.386004077097.issue24453@psf.upfronthosting.co.za> Message-ID: <1434323161.14.0.738612233485.issue24453@psf.upfronthosting.co.za> Senthil Kumaran added the comment: The default version was fixed in issue21528, changeset db302b88fdb6. perhaps it simply needs to be backported. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 01:07:41 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 14 Jun 2015 23:07:41 +0000 Subject: [issue24453] A typo of doubled "the" words in the doc (easy fix) In-Reply-To: <1434320060.96.0.386004077097.issue24453@psf.upfronthosting.co.za> Message-ID: <1434323261.19.0.98459756294.issue24453@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 01:09:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 14 Jun 2015 23:09:15 +0000 Subject: [issue24453] A typo of doubled "the" words in the doc (easy fix) In-Reply-To: <1434320060.96.0.386004077097.issue24453@psf.upfronthosting.co.za> Message-ID: <20150614230912.112065.49459@psf.io> Roundup Robot added the comment: New changeset 7b74a89b9c26 by Raymond Hettinger in branch '3.4': Issue #24453: Fix doubled word. https://hg.python.org/cpython/rev/7b74a89b9c26 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 01:13:10 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 14 Jun 2015 23:13:10 +0000 Subject: [issue24453] A typo of doubled "the" words in the doc (easy fix) In-Reply-To: <1434320060.96.0.386004077097.issue24453@psf.upfronthosting.co.za> Message-ID: <1434323590.29.0.546442419745.issue24453@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 01:16:14 2015 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Sun, 14 Jun 2015 23:16:14 +0000 Subject: [issue24452] Make webbrowser support Chrome on Mac OS X In-Reply-To: <1434317605.99.0.218705045555.issue24452@psf.upfronthosting.co.za> Message-ID: <1434323774.75.0.218356254154.issue24452@psf.upfronthosting.co.za> Bo?tjan Mejak added the comment: I must add that it doesn't work on Windows 7, Python 3.4.3, either. I do have chrome.exe on the %PATH% and executing 'chrome' in Windows Command Prompt opens up the Chrome browser nicely, but it doesn't work so nicely by doing this: import webbrowser webbrowser.get("chrome") I get this error message: Traceback (most recent call last): File "", line 1, in File "C:\Program Files\Python 3.4\lib\webbrowser.py", line 51, in get raise Error("could not locate runnable browser") webbrowser.Error: could not locate runnable browser ---------- nosy: +Pikec _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 01:49:45 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 14 Jun 2015 23:49:45 +0000 Subject: [issue9939] Add a pipe type (FIFO) to the io module In-Reply-To: <1285341562.44.0.992846065146.issue9939@psf.upfronthosting.co.za> Message-ID: <1434325785.66.0.606172681805.issue9939@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 02:32:21 2015 From: report at bugs.python.org (Rose Ames) Date: Mon, 15 Jun 2015 00:32:21 +0000 Subject: [issue24427] subclass of multiprocessing Connection segfault upon attribute acces In-Reply-To: <1433964415.99.0.226244144163.issue24427@psf.upfronthosting.co.za> Message-ID: <1434328341.21.0.738739802401.issue24427@psf.upfronthosting.co.za> Rose Ames added the comment: Reproduced - the crash exists and the patch fixes it. ---------- nosy: +superluser versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 02:37:24 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 15 Jun 2015 00:37:24 +0000 Subject: [issue24453] A typo of doubled "the" words in the doc (easy fix) In-Reply-To: <1434320060.96.0.386004077097.issue24453@psf.upfronthosting.co.za> Message-ID: <20150615003716.1354.74716@psf.io> Roundup Robot added the comment: New changeset 3ded282f9615 by Senthil Kumaran in branch '3.4': Back porting changeset db302b88fdb6 to 3.4 branch, which fixed multiple documentation typos. https://hg.python.org/cpython/rev/3ded282f9615 New changeset 9a0c5ffe7420 by Senthil Kumaran in branch 'default': null merge with 3.4 https://hg.python.org/cpython/rev/9a0c5ffe7420 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 02:37:24 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 15 Jun 2015 00:37:24 +0000 Subject: [issue21528] Fix a number of typos in the documentation In-Reply-To: <1400456947.04.0.361173205763.issue21528@psf.upfronthosting.co.za> Message-ID: <20150615003716.1354.5512@psf.io> Roundup Robot added the comment: New changeset 3ded282f9615 by Senthil Kumaran in branch '3.4': Back porting changeset db302b88fdb6 to 3.4 branch, which fixed multiple documentation typos. https://hg.python.org/cpython/rev/3ded282f9615 New changeset 9a0c5ffe7420 by Senthil Kumaran in branch 'default': null merge with 3.4 https://hg.python.org/cpython/rev/9a0c5ffe7420 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 03:17:39 2015 From: report at bugs.python.org (Brandon Milam) Date: Mon, 15 Jun 2015 01:17:39 +0000 Subject: [issue24452] Make webbrowser support Chrome on Mac OS X In-Reply-To: <1434317605.99.0.218705045555.issue24452@psf.upfronthosting.co.za> Message-ID: <1434331059.97.0.136869564336.issue24452@psf.upfronthosting.co.za> Brandon Milam added the comment: Bo?tjan Mejak the windows issue has been addressed in issue 8232 and recently patched for 3.5. http://bugs.python.org/issue8232 ---------- nosy: +jbmilam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 04:06:12 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 15 Jun 2015 02:06:12 +0000 Subject: [issue24451] Add metrics to future objects (concurrent or asyncio?) In-Reply-To: <1434302171.22.0.0439382195068.issue24451@psf.upfronthosting.co.za> Message-ID: <1434333972.55.0.10864737473.issue24451@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +bquinlan, giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 04:06:48 2015 From: report at bugs.python.org (Ethan Furman) Date: Mon, 15 Jun 2015 02:06:48 +0000 Subject: [issue24450] Add gi_yieldfrom calculated property to generator object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1434334008.22.0.808015446095.issue24450@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 05:02:23 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 15 Jun 2015 03:02:23 +0000 Subject: [issue14780] urllib.request could use the default CA store In-Reply-To: <1336695133.95.0.45377603567.issue14780@psf.upfronthosting.co.za> Message-ID: <1434337343.6.0.038544556079.issue14780@psf.upfronthosting.co.za> Martin Panter added the comment: The documentation of the default value ?cadefault=False? was fixed in Issue 17977. A later change seems to have made this paramter redundant. Anyway I think this can be closed. ---------- nosy: +vadmium status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 05:47:52 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 15 Jun 2015 03:47:52 +0000 Subject: [issue24454] Improve the usability of the match object named group API Message-ID: <1434340072.54.0.23336337946.issue24454@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The usability, learnability, and readability of match object code would be improved by giving it a more Pythonic API (inspired by ElementTree). Given a search like: data = 'Answer found on row 8 column 12.' mo = re.search(r'row (?P\d+) column (?P\d+)', data) We currently access results with: print(mo.group('col')) print(len(mo.groups()) A better way would look like this: print(mo['col']) print(len(mo)) This would work nicely with string formatting: print('Located coordinate at (%(row)s, %(col)s)' % mo) print('Located coordinate at ({row}, {col})'.format_map(mo)) ---------- components: Library (Lib) messages: 245361 nosy: rhettinger priority: low severity: normal status: open title: Improve the usability of the match object named group API type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 06:29:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Jun 2015 04:29:28 +0000 Subject: [issue24454] Improve the usability of the match object named group API In-Reply-To: <1434340072.54.0.23336337946.issue24454@psf.upfronthosting.co.za> Message-ID: <1434342568.32.0.199956771478.issue24454@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You can use mo.groupdict(). print('Located coordinate at (%(row)s, %(col)s)' % mo.groupdict()) print('Located coordinate at ({row}, {col})'.format_map(mo.groupdict())) As for len(mo), this is ambiguous, as well as indexing with integer indices. You suggest len(mo) be equal len(mo.groups()) and this looks reasonable to me, but in regex len(mo) equals to len(mo.groups())+1 (because mo[1] equals to mo.group(1) or mo.groups()[0]). If indexing will work only with named groups, it would be expected that len(mo) will be equal to len(mo.groupdict()). ---------- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 06:39:52 2015 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 15 Jun 2015 04:39:52 +0000 Subject: [issue24454] Improve the usability of the match object named group API In-Reply-To: <1434340072.54.0.23336337946.issue24454@psf.upfronthosting.co.za> Message-ID: <1434343192.35.0.669769429197.issue24454@psf.upfronthosting.co.za> Ezio Melotti added the comment: > print(mo['col']) > print(len(mo)) This has already been discussed in another issue. As Serhiy mentioned, len(mo) and mo[num] would be ambiguous because of the group 0, but mo[name] might be ok. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 07:01:39 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 15 Jun 2015 05:01:39 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434344499.51.0.796664882796.issue8232@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Official spelling of name of one of these browsers is "Firefox", not "FireFox". I suggest to rename WinFireFox class accordingly. ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 07:49:13 2015 From: report at bugs.python.org (koobs) Date: Mon, 15 Jun 2015 05:49:13 +0000 Subject: [issue7352] pythonx.y-config --ldflags out of /usr and missing -L In-Reply-To: <1258578467.08.0.137292547946.issue7352@psf.upfronthosting.co.za> Message-ID: <1434347353.4.0.509038632535.issue7352@psf.upfronthosting.co.za> Changes by koobs : ---------- components: +Build keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 07:57:25 2015 From: report at bugs.python.org (koobs) Date: Mon, 15 Jun 2015 05:57:25 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <1434347845.52.0.430277788425.issue22359@psf.upfronthosting.co.za> koobs added the comment: Initial commit to default is done. Backport to 2.7 & 3.4 branches remains to do ---------- components: -Cross-Build keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 07:59:22 2015 From: report at bugs.python.org (koobs) Date: Mon, 15 Jun 2015 05:59:22 +0000 Subject: [issue22359] Remove incorrect uses of recursive make In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za> Message-ID: <1434347962.39.0.509053351649.issue22359@psf.upfronthosting.co.za> koobs added the comment: Add 3.5 to list of versions merging required for ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 08:01:17 2015 From: report at bugs.python.org (koobs) Date: Mon, 15 Jun 2015 06:01:17 +0000 Subject: =?utf-8?q?=5Bissue22625=5D_When_cross-compiling=2C_don=E2=80=99t_try_to_e?= =?utf-8?q?xecute_binaries?= In-Reply-To: <1413226219.68.0.732560661241.issue22625@psf.upfronthosting.co.za> Message-ID: <1434348077.51.0.983087719571.issue22625@psf.upfronthosting.co.za> koobs added the comment: Incorrect recursive use of make will be fixed in default, 3.5, 3.4 (?), 2.7 in issue 22359, reflect the versions correctly here so they're not forgotten. ---------- nosy: +koobs versions: +Python 2.7, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 08:12:26 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 15 Jun 2015 06:12:26 +0000 Subject: [issue7352] pythonx.y-config --ldflags out of /usr and missing -L In-Reply-To: <1258578467.08.0.137292547946.issue7352@psf.upfronthosting.co.za> Message-ID: <1434348746.24.0.0862678757125.issue7352@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 08:17:57 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 15 Jun 2015 06:17:57 +0000 Subject: [issue24427] subclass of multiprocessing Connection segfault upon attribute acces In-Reply-To: <1433964415.99.0.226244144163.issue24427@psf.upfronthosting.co.za> Message-ID: <1434349077.54.0.683976528318.issue24427@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 08:27:21 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 15 Jun 2015 06:27:21 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434349641.08.0.703515023481.issue24400@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 08:57:51 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 15 Jun 2015 06:57:51 +0000 Subject: [issue24351] string.Template documentation incorrectly references "identifiers" In-Reply-To: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za> Message-ID: <1434351471.03.0.18135416378.issue24351@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 08:58:54 2015 From: report at bugs.python.org (Nick Czeczulin) Date: Mon, 15 Jun 2015 06:58:54 +0000 Subject: [issue24301] gzip module failing to decompress valid compressed file In-Reply-To: <1432742343.38.0.978535326882.issue24301@psf.upfronthosting.co.za> Message-ID: <1434351534.33.0.29525164967.issue24301@psf.upfronthosting.co.za> Nick Czeczulin added the comment: The spec allows for multi-member files. Some libraries and utilities seem to solve this problem (incorrectly?) by simply ignoring everything past the first member -- even when valid (e.g., DotNetZip, 7-Zip) For 2.7 and 3.4, the data that has been decompressed but not yet read before the exception was raised is still available: Modifying Martin's example slightly: >>> f = BytesIO() >>> with GzipFile(fileobj=f, mode="wb") as z: ... z.write(b"data") ... 4 >>> f.write(b"garbage") 7 >>> f.seek(0) 0 >>> with GzipFile(fileobj=f, mode="rb") as z: ... try: ... z.read(1) ... z.read() ... except OSError as e: ... z.extrabuf[z.offset - z.extrastart:] ... e ... b'd' b'ata' OSError('Not a gzipped file',) My issue is that catching and handling this specific exception is a little more involved because there are 3(?) different OSErrors (IOError on 2.7) that could potentially be raised during the read. But mostly: OSError('CRC check failed 0x447ba3f9 != 0x225cb2a3',) -- would be bad one to mistake for it. Maybe a specific Exception type to catch for an invalid header, and a better method to read the remaining buffer when handling it? ---------- nosy: +nczeczulin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 10:17:58 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 15 Jun 2015 08:17:58 +0000 Subject: [issue24301] gzip module failing to decompress valid compressed file In-Reply-To: <1432742343.38.0.978535326882.issue24301@psf.upfronthosting.co.za> Message-ID: <1434356278.2.0.229127853524.issue24301@psf.upfronthosting.co.za> Martin Panter added the comment: Just noticed in my previous message I mentioned Issue 1508475 a few times when I meant to say Issue 1159051. In Python 3.5, a workaround is not so easy because we would need to access the internal buffer of a BufferedReader. One potential workaround is to use read1(): >>> z.read1(1) b'd' >>> z.read1() b'ata' >>> z.read1() OSError: Not a gzipped file (b'ga') The only practical way to allow for an exception and read() returning all the data is to defer the exception until close() is called. Another option might be to store a list of defects, similar to ?email.message.Message.defects?. ---------- components: +Library (Lib) -Extension Modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 11:32:12 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Jun 2015 09:32:12 +0000 Subject: [issue24451] Add metrics to future objects (concurrent or asyncio?) In-Reply-To: <1434333972.61.0.7559037727.issue24451@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I'm not sure about concurrent.futures, but for asyncio I think this would cost too much overhead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 11:35:09 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 15 Jun 2015 09:35:09 +0000 Subject: [issue24451] Add metrics to future objects (concurrent or asyncio?) In-Reply-To: <1434302171.22.0.0439382195068.issue24451@psf.upfronthosting.co.za> Message-ID: <1434360909.16.0.349781860444.issue24451@psf.upfronthosting.co.za> STINNER Victor added the comment: asyncio must be as fast as possible in the default configuration. timestamps look more as a debug feature for me, or a specific use case. I suggested to make asyncio/concurrent.futures "pluggable/hookable" instead of modifying the default configuration. For example, in debug mode, asyncio uses a CoroWrapper class for coroutines which stores more information (ex: traceback where it was created), useless for debug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 11:43:12 2015 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Mon, 15 Jun 2015 09:43:12 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434361392.58.0.792501641476.issue8232@psf.upfronthosting.co.za> Bo?tjan Mejak added the comment: I agree with Arfrever Frehtes Taifersar Arahesis (oh my god, you have the longest name, dude!) to rename the class WinFireFox() to WinFirefox(). Okay, so since the branch '3.5' already got its patch webbrowserfix6 applied -- are you, Brandon Milam, willing to make a new webbrowserfix7 patch with the added WinFireFox() -> WinFirefox() classname change and then apply this new patch to the '3.4' branch as well as to the '3.5' branch? ---------- nosy: +Pikec _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 12:27:29 2015 From: report at bugs.python.org (Waldemar Parzonka) Date: Mon, 15 Jun 2015 10:27:29 +0000 Subject: [issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za> Message-ID: <1434364049.07.0.846566414063.issue6766@psf.upfronthosting.co.za> Changes by Waldemar Parzonka : ---------- nosy: +Waldemar.Parzonka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 12:36:05 2015 From: report at bugs.python.org (Paul Sokolovsky) Date: Mon, 15 Jun 2015 10:36:05 +0000 Subject: [issue24449] Please add async write method to asyncio.StreamWriter In-Reply-To: <1434268250.18.0.99884254892.issue24449@psf.upfronthosting.co.za> Message-ID: <1434364565.88.0.783870183056.issue24449@psf.upfronthosting.co.za> Paul Sokolovsky added the comment: Thanks for the response. > and an API with more choices is not necessarily better. I certainly agree, and that's why I try to implement MicroPython's uasyncio solely in terms of coroutines, without Futures and Transports. But I of course can't argue for dropping Transports in asyncio, so the only argument I'm left with is consistency of API (letting use coroutines everywhere). > I'm sure this has come up before, I could've sworn it was you, sorry if it wasn't. No, I brought issue of Futures dependency (yes, that was wide and long discussion), then about yielding a coroutine instance as a way to schedule it. But during the time I'm on python-tulip, I didn't remember someone bringing up issue of asymmetry between read & write, but I would imagine someone would have done that before me. (Which might hint that the issue exists ;-) ). > the common mistake (amongst beginners) of forgetting the "yield from" or 'async' would be much harder to debug So, this is not first time you provide this argument for different cases, one would think that this pin-points pretty serious flaw in the language and it's priority to find a solution for it, and yet PEP3152 which does exactly that was rejected, so maybe it's not that *serious*. Indeed, it's common sense that it's possible to make a hard to debug mistake in any program, and in any concurrent program (doesn't matter of which paradigm) it's order of magnitude easier to do one and harder to debug respectively. But asyncio does have tools to debug such issue. And one would think that easiest way to preclude mistake is to avoid inconsistencies in the API. I know there's a very find balance between all the arguments, and only you can know where it lies, but kindly accept external feedback that the above explanation (syntax is more prone to mistakes) looks like universal objectivized rejection in rather subjective cases. What saddens me here is that this decision puts pretty high lower bound for asyncio memory usage (and I tried hard to prove that asyncio is suitable paradigm even for smaller, IoT-class devices). It's also hard to argue that Python isn't worse than Go, Rust and other new kids on the block - because indeed, how one can argue that, if even the language author uses argument "language syntax, while exists, isn't good enough to do the obvious things". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 13:20:35 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 15 Jun 2015 11:20:35 +0000 Subject: [issue24454] Improve the usability of the match object named group API In-Reply-To: <1434340072.54.0.23336337946.issue24454@psf.upfronthosting.co.za> Message-ID: <1434367235.42.0.575189721253.issue24454@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 15:05:38 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 15 Jun 2015 13:05:38 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434373538.75.0.292189841327.issue8232@psf.upfronthosting.co.za> Steve Dower added the comment: If it existed in 3.4 then we can only alias it now and not fix it. 3.5 and 3.6 can have the fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 15:47:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Jun 2015 13:47:00 +0000 Subject: [issue9939] Add a pipe type (FIFO) to the io module In-Reply-To: <1285341562.44.0.992846065146.issue9939@psf.upfronthosting.co.za> Message-ID: <1434376020.14.0.26029900114.issue9939@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 15:50:13 2015 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 15 Jun 2015 13:50:13 +0000 Subject: [issue24454] Improve the usability of the match object named group API In-Reply-To: <1434340072.54.0.23336337946.issue24454@psf.upfronthosting.co.za> Message-ID: <1434376213.29.0.930620523236.issue24454@psf.upfronthosting.co.za> Eric V. Smith added the comment: I'd definitely be for mo['col']. I can't say I've ever used len(mo.groups()). I do have lots of code like: return mo.group('col'), mo.group('row'), mo.group('foo') Using groupdict there is doable but not great. But: return mo['col'], mo['row'], mo['foo'] would be a definite improvement. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 16:14:00 2015 From: report at bugs.python.org (Matthew Barnett) Date: Mon, 15 Jun 2015 14:14:00 +0000 Subject: [issue24454] Improve the usability of the match object named group API In-Reply-To: <1434340072.54.0.23336337946.issue24454@psf.upfronthosting.co.za> Message-ID: <1434377640.85.0.637613890789.issue24454@psf.upfronthosting.co.za> Matthew Barnett added the comment: I agree that it would be nice if len(mo) == len(mo.groups()), but Serhiy has explained why that's not the case in the regex module. The regex module does support mo[name], so: print('Located coordinate at (%(row)s, %(col)s)' % mo) print('Located coordinate at ({row}, {col})'.format_map(mo)) already work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 16:34:27 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 15 Jun 2015 14:34:27 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434378867.21.0.0023361257613.issue8232@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Steve Dower: Maybe thou hast already forgotten, but WinFireFox class was added by thee (only in 3.5 and 3.6) just 7 days ago :) . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 16:47:29 2015 From: report at bugs.python.org (Paul Moore) Date: Mon, 15 Jun 2015 14:47:29 +0000 Subject: [issue24087] Documentation doesn't explain the term "coroutine" (PEP 342) In-Reply-To: <1430425552.31.0.779606074615.issue24087@psf.upfronthosting.co.za> Message-ID: <1434379649.13.0.924897072812.issue24087@psf.upfronthosting.co.za> Paul Moore added the comment: Personally, I'm OK with the wording in the 3.5.0b2 docs, as far as basic terminology and glossary-style information goes. I think coroutines, async, and event loops are badly under-documented in the broader context, though - there is very little in the docs explaining the concepts and constraints[1] of Python's async features. Unfortunately, the people with the knowledge of the subject are likely to be too close to the details to be able to write beginner-level documentation, and beginners don't know enough (by definition) to do so. I'm trying to do some playing round with creating my own async framework to get a better understanding of how things should work, but it's slow going and honestly I don't feel I've got anything much I could write up at this point. [1] For example, how Python's implementation differs from other languages or "theoretical" discussions of coroutines in the literature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 16:47:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Jun 2015 14:47:43 +0000 Subject: [issue24454] Improve the usability of the match object named group API In-Reply-To: <1434340072.54.0.23336337946.issue24454@psf.upfronthosting.co.za> Message-ID: <1434379663.24.0.575404624547.issue24454@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The disadvantage of supporting len() is its ambiguousness. Supporting indexing with group name also has disadvantages (benefits already was mentioned above). 1. Indexing with string keys is a part of mapping protocol, and it would be expected that other parts of the protocol if not all are supported (at least len() and iteration), but they are not. 2. If indexing with group names would be supported, it would be expected the support of integer indexes. But this is ambiguous too. This feature would improve the access to named groups (6 characters less to type for every case and better readability), but may be implementing access via attributes would be even better? mo.groupnamespace().col or mo.ns.col? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 17:19:15 2015 From: report at bugs.python.org (Andrew Stormont) Date: Mon, 15 Jun 2015 15:19:15 +0000 Subject: [issue23895] python socket module fails to build on Solaris when -zignore is in LDFLAGS In-Reply-To: <1428586985.69.0.885305793504.issue23895@psf.upfronthosting.co.za> Message-ID: <1434381555.26.0.743768159472.issue23895@psf.upfronthosting.co.za> Andrew Stormont added the comment: Bump. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 17:36:54 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 15 Jun 2015 15:36:54 +0000 Subject: [issue24454] Improve the usability of the match object named group API In-Reply-To: <1434340072.54.0.23336337946.issue24454@psf.upfronthosting.co.za> Message-ID: <1434382614.38.0.203701683716.issue24454@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > but may be implementing access via attributes would > be even better? mo.groupnamespace().col or mo.ns.col? The whole point is to eliminate the unnecessary extra level. Contrast using DOM with using ElementTree. The difference in usability and readability is huge. If you do much in the way of regex work, this will be a win: mo['name'], mo['rank'], mo['serialnumber'] There are several problems with trying to turn this into attribute access. One of the usual ones are the conflict between the user fieldnames and the actual methods and attributes of the objects (that is why named tuples have the irritating leading underscore for its own attributes and methods). The other problem is that it interferes with usability when the fieldname is stored in a variable. Contrast, "fieldname='rank'; print(mo[fieldname])" with "fieldname='rank'; print(getattr(mo, fieldname))". I'm happy to abandon the "len(mo)" suggestion, but mo[groupname] would be really nice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 17:39:12 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 15 Jun 2015 15:39:12 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434382752.02.0.554655079961.issue8232@psf.upfronthosting.co.za> Steve Dower added the comment: That's what I thought, but I wasn't 100% sure it wasn't moved/rewritten in the patch and was on my phone so I didn't check :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 17:54:31 2015 From: report at bugs.python.org (Joshua Harlow) Date: Mon, 15 Jun 2015 15:54:31 +0000 Subject: [issue24451] Add metrics to future objects (concurrent or asyncio?) In-Reply-To: <1434302171.22.0.0439382195068.issue24451@psf.upfronthosting.co.za> Message-ID: <1434383671.74.0.473521567318.issue24451@psf.upfronthosting.co.za> Joshua Harlow added the comment: I like the pluggable/hookable idea, that would be nice (I'm siding on the side of hookable, since I think that would be more 'elegant'). If these are just callbacks that can be hooked in for these specific 'events' that would allow me to gather the timing information that is needed (and/or other information as well). Sound like a decent plan to add these? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 17:57:31 2015 From: report at bugs.python.org (irdb) Date: Mon, 15 Jun 2015 15:57:31 +0000 Subject: [issue24455] IDLE debugger causes crash if not quitted properly before next run Message-ID: <1434383850.99.0.136251358232.issue24455@psf.upfronthosting.co.za> New submission from irdb: # Open a module using IDLE # Run the module (Press F5) # Activate the debugger ([DEBUG ON]) # Set a breakpoint in the module # Run the module again # Run the module for the third time # Hit the Quit button in Debug Control window (twice, as the first click appears to do nothing) Congratulations! You got yourself a crash! After a while, a window dialogue appears asking "Do you want to end this process?". Click "End Process" (As there doesn't seem to be any other way). One way to avoid this crash is to press quit before the third run. But even without it, this shouldn't happen. Sometimes the programmer may simply forget that there is an active debugger running... I'm using Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:43:06) [MSC v.1600 32 bit (Intel)] on win32 (Windows 8.1) ---------- components: IDLE messages: 245384 nosy: irdb priority: normal severity: normal status: open title: IDLE debugger causes crash if not quitted properly before next run versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 18:11:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 15 Jun 2015 16:11:56 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <20150615161153.112079.19179@psf.io> Roundup Robot added the comment: New changeset 0d54a78861cf by Steve Dower in branch '3.5': Issue #8232: Renamed WinFireFox to WinFirefox https://hg.python.org/cpython/rev/0d54a78861cf New changeset 8667c26e2bec by Steve Dower in branch 'default': Issue #8232: Renamed WinFireFox to WinFirefox https://hg.python.org/cpython/rev/8667c26e2bec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 18:12:47 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 15 Jun 2015 16:12:47 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434384767.95.0.887670819533.issue8232@psf.upfronthosting.co.za> Steve Dower added the comment: I'll close this as fixed, but feel free to speak up if you spot anything else that needs fixing. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 18:16:18 2015 From: report at bugs.python.org (irdb) Date: Mon, 15 Jun 2015 16:16:18 +0000 Subject: [issue24455] IDLE debugger causes crash if not quitted properly before next run In-Reply-To: <1434383850.99.0.136251358232.issue24455@psf.upfronthosting.co.za> Message-ID: <1434384978.71.0.146593665081.issue24455@psf.upfronthosting.co.za> Changes by irdb : ---------- type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 18:20:43 2015 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Mon, 15 Jun 2015 16:20:43 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434385243.52.0.637623940225.issue8232@psf.upfronthosting.co.za> Bo?tjan Mejak added the comment: Now that this bug is completely fixed, can you backport this to the '3.4' branch, so that we'll be able to use webbrowser. get() in Python 3.4.4 when it becomes available? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 18:30:56 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 15 Jun 2015 16:30:56 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434385856.41.0.827037435386.issue8232@psf.upfronthosting.co.za> Steve Dower added the comment: The 3.4 RM is already nosied - what say you, sir? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 18:33:51 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 15 Jun 2015 16:33:51 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434386031.64.0.175311211529.issue8232@psf.upfronthosting.co.za> Larry Hastings added the comment: Sorry, but I think this is more accurately described as a "new feature" than a "bugfix". Please don't backport this to 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 18:37:22 2015 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Mon, 15 Jun 2015 16:37:22 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434386242.37.0.00520582183415.issue8232@psf.upfronthosting.co.za> Bo?tjan Mejak added the comment: No, Larry, this is not a new feature. The feature, as it stands, is broken in Python 3.4, so we need to fix it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 18:38:32 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 15 Jun 2015 16:38:32 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434386312.74.0.208337379184.issue8232@psf.upfronthosting.co.za> Larry Hastings added the comment: This is not a bugfix to existing code. This is new code to implement a missing feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 18:41:16 2015 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Mon, 15 Jun 2015 16:41:16 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434386476.15.0.986079240859.issue8232@psf.upfronthosting.co.za> Bo?tjan Mejak added the comment: Sure, let's have a broken feature in Python 3.4, who cares. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 18:44:32 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 15 Jun 2015 16:44:32 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434386672.24.0.531387000828.issue8232@psf.upfronthosting.co.za> Larry Hastings added the comment: Rules like this are there for a reason. People rely on Python being consistent. We've added harmless new features to point releases in the past and broken people's code. So, we don't do it anymore. It's not because we don't care, it's because stability is more important than new features. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 19:09:25 2015 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Mon, 15 Jun 2015 17:09:25 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434388165.79.0.343211187869.issue8232@psf.upfronthosting.co.za> Bo?tjan Mejak added the comment: I understand. I know that Python 3.4 is way past feature freeze. But if we document the new stuff in the documentation, saying "Added to Python 3.4.4", people would know about and be able to use the new stuff. And we won't break people's code. In fact, people might benefit from this particular new feature. People's Python 3.4 code like webbrowser.get("chrome") would then start to work, plus they'd benefit from this new stuff added by Brandon Milam. Don't you find that a great thing to be? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 19:14:11 2015 From: report at bugs.python.org (Ed Maste) Date: Mon, 15 Jun 2015 17:14:11 +0000 Subject: [issue13501] Make libedit support more generic; port readline / libedit to FreeBSD In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za> Message-ID: <1434388451.65.0.854378673068.issue13501@psf.upfronthosting.co.za> Ed Maste added the comment: It looks like rust developers hit the issue in Issue24388 with lldb on Ubuntu 15.04 as well: https://github.com/rust-lang/rust/issues/26297 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 19:18:02 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 15 Jun 2015 17:18:02 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434388682.67.0.24660406729.issue8232@psf.upfronthosting.co.za> Larry Hastings added the comment: Yes, which is why I permitted a feature freeze exception for it for 3.5. But it's simply far, far too late to add a feature like this to 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 19:23:10 2015 From: report at bugs.python.org (Ed Maste) Date: Mon, 15 Jun 2015 17:23:10 +0000 Subject: [issue13501] Make libedit support more generic; port readline / libedit to FreeBSD In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za> Message-ID: <1434388990.94.0.416858108277.issue13501@psf.upfronthosting.co.za> Ed Maste added the comment: Actually, in msg245395 I should claim the issue is with libedit / GNU readline compatibility and/or the workarounds in Python's readline module, not that it's specifically Issue24388. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 19:26:45 2015 From: report at bugs.python.org (koobs) Date: Mon, 15 Jun 2015 17:26:45 +0000 Subject: [issue13501] Make libedit support more generic; port readline / libedit to FreeBSD In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za> Message-ID: <1434389205.43.0.979166063059.issue13501@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 19:36:05 2015 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Mon, 15 Jun 2015 17:36:05 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434389765.01.0.0122718170374.issue8232@psf.upfronthosting.co.za> Bo?tjan Mejak added the comment: I understand. But then webbrowser.get("chrome") won't ever work in Python 3.4. Is there no other way to fix this bug in Python 3.4 without adding the new feature? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 19:38:24 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 15 Jun 2015 17:38:24 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434389904.76.0.499898879833.issue8232@psf.upfronthosting.co.za> Steve Dower added the comment: Fairly sure webbrowser.py is stand-alone enough that you could redist it with your package easily enough. None of the rest of the stdlib should depend on the internals, AFAIK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 19:55:21 2015 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Mon, 15 Jun 2015 17:55:21 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434390921.68.0.88330124446.issue8232@psf.upfronthosting.co.za> Bo?tjan Mejak added the comment: Steve, I know. But it's a hassle for a newcomer to fix Python first before he/she uses it. I'm not a newcomer, but even I don't know how to fix webbrowser.py, more specifically the webbrowser.get() method, to be able to use it. Maybe I should copy webbrowser.py from Python 3.5 and paste it to my Python 3.4.3. Sounds good, right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 20:10:07 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 15 Jun 2015 18:10:07 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434391806.99.0.417764529789.issue8232@psf.upfronthosting.co.za> Steve Dower added the comment: Sure, you can do that. You can also copy-paste it into your project to get the same effect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 20:42:59 2015 From: report at bugs.python.org (Joshua Harlow) Date: Mon, 15 Jun 2015 18:42:59 +0000 Subject: [issue24451] Add metrics to future objects (concurrent or asyncio?) In-Reply-To: <1434302171.22.0.0439382195068.issue24451@psf.upfronthosting.co.za> Message-ID: <1434393779.16.0.170996984511.issue24451@psf.upfronthosting.co.za> Joshua Harlow added the comment: A prototype (WIP) of how this could work, initial thoughts welcome :-) ---------- keywords: +patch Added file: http://bugs.python.org/file39711/prototype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 21:36:08 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Jun 2015 19:36:08 +0000 Subject: [issue24449] Please add async write method to asyncio.StreamWriter In-Reply-To: <1434268250.18.0.99884254892.issue24449@psf.upfronthosting.co.za> Message-ID: <1434396968.11.0.994615091749.issue24449@psf.upfronthosting.co.za> Guido van Rossum added the comment: Good pontificating, Paul. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 21:41:31 2015 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Mon, 15 Jun 2015 19:41:31 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434397291.96.0.68102421102.issue8232@psf.upfronthosting.co.za> Bo?tjan Mejak added the comment: Ah, interesting! But which webbrowser module would Python import if I have one webbrowser.py in my interpreter's directory and one webbrowser.py in the directory of my application? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 22:31:17 2015 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Mon, 15 Jun 2015 20:31:17 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1434400277.1.0.00189389863938.issue8232@psf.upfronthosting.co.za> Bo?tjan Mejak added the comment: No need to answer. Python used the webbrowser module that was located in the directory of my application and not the one from the interpreter's directory. That's great! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 22:36:47 2015 From: report at bugs.python.org (Carl Kleffner) Date: Mon, 15 Jun 2015 20:36:47 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434400607.92.0.280553794078.issue24429@psf.upfronthosting.co.za> Carl Kleffner added the comment: > Windows itself is the primary user of msvcrt.dll. > A Windows 7 installation has over 1500 DLLs and over > 350 executables in System32 that depend on msvcrt.dll. > Windows developers such as Raymond Chen get a bit annoyed > when projects link directly with msvcrt.dll. In case of mingw32 or mingw-w64 msvcrt linkage is the usual standard due to licensing reasons. The CRT has to be stated as a 'System' library, see http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL. This is case for msvcrt.dll only. VC runtimes can be linked as well, but this runtime DLLs should'nt deployed alongsinde with the application in this case. As described above python binary extensions has to be linked against the very same VC runtime that is used for Python itself to avoid mixing runtimes in one application. Mixing is considered as evil, see http://siomsystems.com/mixing-visual-studio-versions An important question for Steve concerning python-3.5: python-3.5b2 is linked against the newly introduced 'universal CRT', that is without any doubt a SYSTEM LIBRARY. However, heap memory managment functions and other functions are linked against VCRUNTIME140.dll instead of the ucrtbase.dll. Is this the intended behavior? The symbol memset: this symbol is exposed from ucrtbase.dll as well as vcruntime140.dll. Is it necessary to link python binaries against vcruntime140.dll as well, or is linkage against ucrtbase.dll sufficient? ---------- nosy: +carlkl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 22:57:26 2015 From: report at bugs.python.org (JohnLeitch) Date: Mon, 15 Jun 2015 20:57:26 +0000 Subject: [issue24456] audioop.adpcm2lin Buffer Over-read Message-ID: <1434401846.51.0.0422696666136.issue24456@psf.upfronthosting.co.za> New submission from JohnLeitch: The audioop.adpcm2lin function suffers from a buffer over-read caused by unchecked access to stepsizeTable at line 1545 of Modules\audioop.c: } else if ( !PyArg_ParseTuple(state, "ii", &valpred, &index) ) return 0; step = stepsizeTable[index]; Because the index variable can be controlled via the third parameter of audioop.adpcm2lin, this behavior could potentially be exploited to disclose arbitrary memory, should an application expose the parameter to the attack surface. 0:000> r eax=01f13474 ebx=00000000 ecx=00000002 edx=01f13460 esi=01f13460 edi=00000001 eip=1e01c4f0 esp=0027fcdc ebp=7e86ecdd iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202 python27!audioop_adpcm2lin+0xe0: 1e01c4f0 8b04adb0dd1f1e mov eax,dword ptr python27!stepsizeTable (1e1fddb0)[ebp*4] ss:002b:183b9124=???????? 0:000> k ChildEBP RetAddr 0027fd18 1e0aafd7 python27!audioop_adpcm2lin+0xe0 0027fd30 1e0edd10 python27!PyCFunction_Call+0x47 0027fd5c 1e0f017a python27!call_function+0x2b0 0027fdcc 1e0f1150 python27!PyEval_EvalFrameEx+0x239a 0027fe00 1e0f11b2 python27!PyEval_EvalCodeEx+0x690 0027fe2c 1e11707a python27!PyEval_EvalCode+0x22 0027fe44 1e1181c5 python27!run_mod+0x2a 0027fe64 1e118760 python27!PyRun_FileExFlags+0x75 0027fea4 1e1190d9 python27!PyRun_SimpleFileExFlags+0x190 0027fec0 1e038d35 python27!PyRun_AnyFileExFlags+0x59 0027ff3c 1d00116d python27!Py_Main+0x965 0027ff80 76477c04 python!__tmainCRTStartup+0x10f 0027ff94 7799ad1f KERNEL32!BaseThreadInitThunk+0x24 0027ffdc 7799acea ntdll!__RtlUserThreadStart+0x2f 0027ffec 00000000 ntdll!_RtlUserThreadStart+0x1b 0:000> To fix this issue, it is recommended that bounds checking be performed prior to accessing stepsizeTable. ---------- files: audioop.adpcm2lin_buffer_over-read.py messages: 245407 nosy: JohnLeitch priority: normal severity: normal status: open title: audioop.adpcm2lin Buffer Over-read type: security versions: Python 2.7 Added file: http://bugs.python.org/file39712/audioop.adpcm2lin_buffer_over-read.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 22:58:26 2015 From: report at bugs.python.org (JohnLeitch) Date: Mon, 15 Jun 2015 20:58:26 +0000 Subject: [issue24457] audioop.lin2adpcm Buffer Over-read Message-ID: <1434401906.27.0.811918052895.issue24457@psf.upfronthosting.co.za> New submission from JohnLeitch: The audioop.lin2adpcm function suffers from a buffer over-read caused by unchecked access to stepsizeTable at line 1436 of Modules\audioop.c: } else if ( !PyArg_ParseTuple(state, "ii", &valpred, &index) ) return 0; step = stepsizeTable[index]; Because the index variable can be controlled via the third parameter of audioop.lin2adpcm, this behavior could potentially be exploited to disclose arbitrary memory, should an application expose the parameter to the attack surface. 0:000> r eax=00000001 ebx=00000001 ecx=2fd921bb edx=00000002 esi=00000001 edi=01e79160 eip=1e01c286 esp=0027fcdc ebp=df531970 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202 python27!audioop_lin2adpcm+0xd6: 1e01c286 8b34adb0dd1f1e mov esi,dword ptr python27!stepsizeTable (1e1fddb0)[ebp*4] ss:002b:9b6c4370=???????? 0:000> k ChildEBP RetAddr 0027fd18 1e0aafd7 python27!audioop_lin2adpcm+0xd6 0027fd30 1e0edd10 python27!PyCFunction_Call+0x47 0027fd5c 1e0f017a python27!call_function+0x2b0 0027fdcc 1e0f1150 python27!PyEval_EvalFrameEx+0x239a 0027fe00 1e0f11b2 python27!PyEval_EvalCodeEx+0x690 0027fe2c 1e11707a python27!PyEval_EvalCode+0x22 0027fe44 1e1181c5 python27!run_mod+0x2a 0027fe64 1e118760 python27!PyRun_FileExFlags+0x75 0027fea4 1e1190d9 python27!PyRun_SimpleFileExFlags+0x190 0027fec0 1e038d35 python27!PyRun_AnyFileExFlags+0x59 0027ff3c 1d00116d python27!Py_Main+0x965 0027ff80 76477c04 python!__tmainCRTStartup+0x10f 0027ff94 7799ad1f KERNEL32!BaseThreadInitThunk+0x24 0027ffdc 7799acea ntdll!__RtlUserThreadStart+0x2f 0027ffec 00000000 ntdll!_RtlUserThreadStart+0x1b 0:000> To fix this issue, it is recommended that bounds checking be performed prior to accessing stepsizeTable. ---------- files: audioop.lin2adpcm_buffer_over-read.py messages: 245408 nosy: JohnLeitch priority: normal severity: normal status: open title: audioop.lin2adpcm Buffer Over-read type: security versions: Python 2.7 Added file: http://bugs.python.org/file39713/audioop.lin2adpcm_buffer_over-read.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 23:04:03 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 15 Jun 2015 21:04:03 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434402243.68.0.227871999674.issue24429@psf.upfronthosting.co.za> Steve Dower added the comment: > python-3.5b2 is linked against the newly introduced 'universal CRT', that is without any doubt a SYSTEM LIBRARY. However, heap memory managment functions and other functions are linked against VCRUNTIME140.dll instead of the ucrtbase.dll. Is this the intended behavior? AFAICT, all of the "public" functions exported from vcruntime140.dll are also exported from api-ms-win-crt-string-l1-1-0.dll (which forwards to ucrtbase.dll), which would make them available as part of the stable ABI. I'm not sure why vcruntime140.dll has its own versions or why they are used in preference, but it may be to do with inlining or intrinsics. vcruntime140.dll exists and is not guaranteed stable because it provides functionality that needs intimate knowledge of the compiler (stack unwinding, etc.). Those string APIs don't make much sense here, so I'd guess they're dependencies that had to be pulled in, and the linker may just be prioritizing those ones by accident. I would not be at all surprised if MinGW had to replace vcruntime140.dll entirely. Nothing from ucrtbase.dll can depend on it, so replacing it is probably for the best. Then just link against either the ucrtbase.dll or the api-ms-win-crt-*.dll libraries. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 15 23:33:44 2015 From: report at bugs.python.org (Dan Bjorge) Date: Mon, 15 Jun 2015 21:33:44 +0000 Subject: [issue24127] Fatal error in launcher: Job information querying failed In-Reply-To: <1430827026.9.0.339920575451.issue24127@psf.upfronthosting.co.za> Message-ID: <1434404024.01.0.326154313423.issue24127@psf.upfronthosting.co.za> Dan Bjorge added the comment: No, it just takes a long time between us making a fix in early internal builds and the fix propagating to public builds. I think 10135 is the first build number expected to have the fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 00:59:04 2015 From: report at bugs.python.org (Perry Randall) Date: Mon, 15 Jun 2015 22:59:04 +0000 Subject: [issue24442] Readline Bindings Don't Report Any Error On Completer Function Exception In-Reply-To: <1434164276.99.0.684259947249.issue24442@psf.upfronthosting.co.za> Message-ID: <1434409144.31.0.176950452539.issue24442@psf.upfronthosting.co.za> Perry Randall added the comment: Decided to update the documentation instead ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 01:13:02 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 15 Jun 2015 23:13:02 +0000 Subject: [issue13501] Make libedit support more generic; port readline / libedit to FreeBSD In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za> Message-ID: <1434409982.94.0.0736932746799.issue13501@psf.upfronthosting.co.za> Martin Panter added the comment: Maybe I am missing something, but is it possible to use a newer version of Editline (libedit) that fixes the compatibility bug, as mentioned in Issue 18458? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 01:39:48 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 15 Jun 2015 23:39:48 +0000 Subject: [issue24087] Documentation doesn't explain the term "coroutine" (PEP 342) In-Reply-To: <1430425552.31.0.779606074615.issue24087@psf.upfronthosting.co.za> Message-ID: <1434411588.78.0.5893234948.issue24087@psf.upfronthosting.co.za> Martin Panter added the comment: Okay. The biggest thing that concerns me at the moment to do with the term is that there are too many related but different, specific meanings, that I suspect could be confusing, including: 1. Generators (and presumably also the new ?async? native coroutines), compatible with ?asyncio?: 2. PEP 492 ?native? coroutines: Okay maybe some of the new wording is not needed any more. I plan to try documenting some basic stuff about the new PEP 492 coroutines in Issue 24439. Maybe I will incorporate the ?native coroutine? clarifications from my patch here at the same time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 03:27:45 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 16 Jun 2015 01:27:45 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434418065.81.0.0861155583966.issue24400@psf.upfronthosting.co.za> Martin Panter added the comment: One problem with 2015-06-10?s patch (x86-64 Linux): >>> async def f(): ... pass ... >>> c = f() >>> w = c.__await__() >>> w >>> dir(w) TypeError: object does not provide __dir__ >>> type(w) Segmentation fault (core dumped) [Exit 139] Strangely, if I call w.__dir__() first, everything seems to start behaving properly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 05:41:52 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 16 Jun 2015 03:41:52 +0000 Subject: [issue24439] Feedback for awaitable coroutine documentation In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za> Message-ID: <1434426112.48.0.163613846281.issue24439@psf.upfronthosting.co.za> Martin Panter added the comment: It seems that Issue 24400 may implement __await__() for native coroutine instances, making points 1, 2 and 4 mainly redundant. This would also bypass a fifth problem: the need for the mandatory yet largely useless send(None) argument. I am posting async-doc.patch, with these changes: * Distinguish between PEP 492?s ?native coroutines? and other coroutines such as those already supported by asyncio and PEP 342 (?yield? expression and generator cleanup) * Move ?coroutine? before ?coroutine function? in the glossary. * Add links to ?coroutine? glossary * Point 3: Explain about ?async? and ?await? becoming reserved keywords after a ?def? header line * Part of point 2: List native coroutine instance methods and hint at relationship with generator iterator instances Still to do: how to drive an awaitable coroutine. Currently it seems you have to call coro.send(None), but if the current patch for Issue 24400 were applied, I think it would become next(coro), so I will leave this for later. ---------- dependencies: +Awaitable ABC incompatible with functools.singledispatch keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file39714/async-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 06:23:41 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 16 Jun 2015 04:23:41 +0000 Subject: [issue24434] ItemsView.__contains__ does not mimic dict_items In-Reply-To: <1434050451.28.0.415875303865.issue24434@psf.upfronthosting.co.za> Message-ID: <1434428621.33.0.697939004145.issue24434@psf.upfronthosting.co.za> Martin Panter added the comment: The trouble with Serhiy?s suggestion is that it would still try to iterate the argument: >>> i = iter(lambda: print("ITERATION"), "infinity") >>> i in dict() # No iteration False >>> i in ItemsView(dict()) ITERATION ITERATION ITERATION False ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 09:22:51 2015 From: report at bugs.python.org (Henrik Heimbuerger) Date: Tue, 16 Jun 2015 07:22:51 +0000 Subject: [issue24127] Fatal error in launcher: Job information querying failed In-Reply-To: <1430827026.9.0.339920575451.issue24127@psf.upfronthosting.co.za> Message-ID: <1434439371.51.0.758614150194.issue24127@psf.upfronthosting.co.za> Henrik Heimbuerger added the comment: Great, thanks for letting us know, Dan! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 12:49:43 2015 From: report at bugs.python.org (Petr Viktorin) Date: Tue, 16 Jun 2015 10:49:43 +0000 Subject: [issue23642] Interaction of ModuleSpec and C Extension Modules In-Reply-To: <1426086531.98.0.531682777516.issue23642@psf.upfronthosting.co.za> Message-ID: <1434451783.83.0.227312584654.issue23642@psf.upfronthosting.co.za> Petr Viktorin added the comment: ping; this issue can be closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 13:07:47 2015 From: report at bugs.python.org (Petr Viktorin) Date: Tue, 16 Jun 2015 11:07:47 +0000 Subject: [issue24458] Documentation for PEP 489 Message-ID: <1434452866.14.0.181014085851.issue24458@psf.upfronthosting.co.za> New submission from Petr Viktorin: Hello, Here is a patch documenting PEP 489. I don't feel comfortable rewriting the tutorial [0] yet: before the issue with callbacks/module state [1] is solved, which is 3.6 material, multi-phase init is not suitable for all modules. So everything in PEP 489 is described in reference-style documentation. [0] https://docs.python.org/3/extending/extending.html [1] https://www.python.org/dev/peps/pep-0489/#module-state-and-c-level-callbacks ---------- assignee: docs at python components: Documentation files: pep489-docs.patch keywords: patch messages: 245419 nosy: brett.cannon, docs at python, encukou, eric.snow, ncoghlan priority: normal severity: normal status: open title: Documentation for PEP 489 versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39715/pep489-docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 15:23:08 2015 From: report at bugs.python.org (Ed Maste) Date: Tue, 16 Jun 2015 13:23:08 +0000 Subject: [issue13501] Make libedit support more generic; port readline / libedit to FreeBSD In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za> Message-ID: <1434460988.22.0.204439164564.issue13501@psf.upfronthosting.co.za> Ed Maste added the comment: I believe the 0-based vs 1-based history is only one of a few different inconsistencies between libedit and readline. Workarounds will be necessary until a fixed libedit is deployed on all operating systems / distros of interest, but yes I agree that eventually they should not be needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 15:26:28 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Tue, 16 Jun 2015 13:26:28 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1434461188.75.0.294028984441.issue23883@psf.upfronthosting.co.za> Jacek Ko?odziej added the comment: Hi! This is my first attempt at contributing so as always, feedback will be well appreciated. :) I meant to start small so I took a shot with csv module. In test, initial expected set contains QUOTE_* because they don't provide __module__ attribute, and __doc/version__ because they are already in csv.__all__ (should they?). I've made a few PEP8-related fixes just around code I've touched (so they aren't completely unrelated). Is that ok? ---------- nosy: +Unit03 Added file: http://bugs.python.org/file39716/Issue23883_csv_all.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 15:41:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 16 Jun 2015 13:41:31 +0000 Subject: [issue24457] audioop.lin2adpcm Buffer Over-read In-Reply-To: <1434401906.27.0.811918052895.issue24457@psf.upfronthosting.co.za> Message-ID: <1434462091.18.0.72210857164.issue24457@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 15:41:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 16 Jun 2015 13:41:38 +0000 Subject: [issue24456] audioop.adpcm2lin Buffer Over-read In-Reply-To: <1434401846.51.0.0422696666136.issue24456@psf.upfronthosting.co.za> Message-ID: <1434462098.14.0.975200213416.issue24456@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 18:09:17 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Tue, 16 Jun 2015 16:09:17 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1434470957.92.0.654926293121.issue23883@psf.upfronthosting.co.za> Changes by Jacek Ko?odziej : Removed file: http://bugs.python.org/file39716/Issue23883_csv_all.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 18:11:34 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Tue, 16 Jun 2015 16:11:34 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1434471094.49.0.98022846406.issue23883@psf.upfronthosting.co.za> Changes by Jacek Ko?odziej : Added file: http://bugs.python.org/file39717/Issue23883_csv_all.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 22:51:35 2015 From: report at bugs.python.org (Antony Lee) Date: Tue, 16 Jun 2015 20:51:35 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page Message-ID: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> New submission from Antony Lee: The man page doesn't mention PYTHONFAULTHANDER in the list of environment variables (I haven't thoroughly checked that everyone else is there, either). I would also suggest reordering the environment variables in alphabetical order. ---------- assignee: docs at python components: Documentation messages: 245422 nosy: Antony.Lee, docs at python priority: normal severity: normal status: open title: Mention PYTHONFAULTHANDLER in the man page versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 23:06:55 2015 From: report at bugs.python.org (erik flister) Date: Tue, 16 Jun 2015 21:06:55 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434488815.45.0.380131820781.issue24429@psf.upfronthosting.co.za> erik flister added the comment: thanks a lot for the detailed info steve, very clearly stated! > Yeah, geos_c.dll really should have exported its own free() function. find_library('c') is probably the wrong approach here - if geos_c.dll is being rebuilt with different CRTs at all then the free() function should be added to it, and if it's truly legacy and is no longer being rebuilt then the version of the CRT it uses should be loaded explicitly. It isn't automatically getting the same version as whatever version of Python is running, that's for sure. well, shapely's installation instructions from windows are to use chris gohlke's prebuilt binaries from here: http://www.lfd.uci.edu/~gohlke/pythonlibs/ i assume he's coordinating the crt versions? apparently a lot of people use these. i'm not clear on why gohlke's stuff is necessary, and why pypi/pip/distutils is not adequate -- shapely is the only library i've run into that needed gohlke's binaries. of course, i didn't try to install numpy/scipy manually, the internet said that this is hard on windows, and to just use something like winpython/pythonxy. are these problems all related to this crt issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 23:07:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Jun 2015 21:07:21 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1434488841.53.0.761849027289.issue24459@psf.upfronthosting.co.za> STINNER Victor added the comment: PYTHONASYNCIODEBUG and PYTHONTRACEMALLOC are also missing. I didn't know that Python has a manual page :-) (Misc/python.man) Note: I added these 3 environment variables ;-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 23:11:28 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Jun 2015 21:11:28 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1434489088.31.0.97902142755.issue15745@psf.upfronthosting.co.za> STINNER Victor added the comment: The issue looks to be fixed on Python 3.4, 3.5 and 3.6. I checked quickly buildbots. I close the issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 23:14:41 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Jun 2015 21:14:41 +0000 Subject: [issue23187] Segmentation fault, possibly asyncio related In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za> Message-ID: <1434489281.36.0.962655866581.issue23187@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm sorry, but even if it's a real bug, we don't have enough information nor any scenario to reproduce the bug, so it's not possible to investigate the bug. I close the issue. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 16 23:19:11 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 16 Jun 2015 21:19:11 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434489551.34.0.102954395421.issue24429@psf.upfronthosting.co.za> Steve Dower added the comment: > i assume he's coordinating the crt versions? apparently a lot of people use these. So do I :) He's definitely got access to the correct compiler versions, so I'm sure he's using them (via distutils/setuptools, which will always try to use the correct one). > i'm not clear on why gohlke's stuff is necessary, and why pypi/pip/distutils is not adequate It's not necessarily easy to get exactly the right compiler, and since Python generally relies on old and outdated ones (because 2.7 lives forever and cannot change) people often need multiple versions installed at the same time. pip+wheel is adequate once library developers publish wheels (or republish Gohlke's wheel of their library). pip+distutils is very fiddly. > shapely is the only library i've run into that needed gohlke's binaries. of course, i didn't try to install numpy/scipy manually, the internet said that this is hard on windows, and to just use something like winpython/pythonxy. are these problems all related to this crt issue? numpy and scipy are due to requiring a Fortran compiler. The Intel compiler is compatible with MSVC, but does not have a Free(tm) license, while gfortran (gcc) does and is not strictly compatible with MSVC (there are some MinGW forks that are very close though). So in effect, yes, the fact that the CRT has to match in every pre-built binary is the problem (less of a problem on Linux because nobody ever imagines that the C runtime might be compatible, and so everyone needs a compiler all the time - therefore, compiling is easier than distribution, whereas on Windows distribution is easier than compiling ). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 04:42:16 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Jun 2015 02:42:16 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1434508936.46.0.640176455585.issue23883@psf.upfronthosting.co.za> Martin Panter added the comment: Reviews of the patches waiting here: tarfile, calendar (Joel): Look mainly good; I added minor suggestions about the test cases to Reitveld. fileinput (Mauro): Looks pretty good; one minor comment on Rietveld. csv (Jacek): Pretty good; couple minor suggestions. In a perfect world, I don?t think __doc/version__ should be there, but since they are already there it is probably safer to leave them. In general, I think style fixes in related code are okay; although in this case I have no problem with the original single blank lines. There is nothing seriously wrong with the patches so far. They could be committed, perhaps with a few of the tweaks I suggested. Summary of other things mentioned here left to do: * Common test.support helper function * gettext: Module fixed, but no changes to test suite * Remaining modules from Serhiy?s list: cgi, configparser, doctest, enum, ftplib, http.cookies, logging, mailbox, mimetypes, optparse, pickletools, plistlib, pydoc, smtpd, subprocess, threading, tkinter.ttk, tokenize, wave, xml.etree.ElementTree. One outstanding question is what to do about module-level constants that are only briefly mentioned in the documentation. IMO they should be included in __all__. Examples: http.client statuses , tarfile member types , calendar weekdays . Precedent of similar constants that are already included, in native Python modules: io SEEK_ constants; lzma FORMAT_, CHECK_, PRESET_ etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 05:46:41 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Jun 2015 03:46:41 +0000 Subject: [issue24421] Race condition compiling Modules/_math.c In-Reply-To: <1433923600.68.0.73894537311.issue24421@psf.upfronthosting.co.za> Message-ID: <1434512800.99.0.0694165358367.issue24421@psf.upfronthosting.co.za> Martin Panter added the comment: I think this may have been introduced when _math.c was added as a source file of the ?cmath? module in r76978 (Issue 7518). In /setup.py:585 there are two distutils.core.Extension objects, both mentioning _math.c. In the build_ext._build_extensions_parallel() method at /Lib/distutils/command/build_ext.py:449, it appears to be invoking build_extension() in two concurrent threads, once for each module, including math and cmath. I don?t know how this code is meant to work, but it looks like either the ?build_ext? class should not be creating the same object file in two different threads, or /setup.py should not be giving it the same _math.c file for two different modules. ---------- components: +Distutils nosy: +dstufft, eric.araujo versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 05:49:27 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Jun 2015 03:49:27 +0000 Subject: [issue7518] Some functions in pymath.c should be moved elsewhere. In-Reply-To: <1260904788.96.0.184476026521.issue7518@psf.upfronthosting.co.za> Message-ID: <1434512967.94.0.907836191415.issue7518@psf.upfronthosting.co.za> Martin Panter added the comment: I suspect the change here causes _math.c to be compiled to the same object file twice, and there is a race condition when the compilations are concurrent. See Issue 24421. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 08:48:42 2015 From: report at bugs.python.org (David Rueter) Date: Wed, 17 Jun 2015 06:48:42 +0000 Subject: [issue24460] urlencode() of dictionary not as expected Message-ID: <1434523722.13.0.839663684524.issue24460@psf.upfronthosting.co.za> New submission from David Rueter: In Python 3.4 I would like to serialize a dictionary into a URL-encoded string. Given a dictionary like this: >>> thisDict = {'SomeVar1': [b'abc'], 'SomeVar2': [b'def'], 'SomeVar3': [b'ghi']} I would like to be able to return this string: SomeVar1=abc&SomeVar2=def&SomeVar3=ghi I thought that urllib.parse.urlencode would work for me, but it does not: >>> print(urllib.parse.urlencode(thisDict)) SomeVar1=%5Bb%27abc%27%5D&SomeVar2=%5Bb%27def%27%5D&SomeVar3=%5Bb%27ghi%27%5D In other words, urlencode on the dictionary is performing a URL encode on the string that is returned when the dictionary is cast to a string...and is including the square brackets (escaped) and the byte literal "b" indicator. {'SomeVar1': [b'abc'], 'SomeVar2': [b'def'], 'SomeVar3': [b'ghi']} I can obtain the desired string with this: >>> '&'.join("{!s}={!s}".format(key,urllib.parse.quote_plus(str(val[0],'utf-8'))) for (key,val) in thisDict.items()) Is the behavior of urllib.parse.urlencode() on a dictionary intentional? When would the current behavior ever be useful? Would it make sense to change the behavior of urllib.parse.urlencode such that it works as described above? ---------- components: Library (Lib) messages: 245431 nosy: drueter at assyst.com priority: normal severity: normal status: open title: urlencode() of dictionary not as expected type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 10:53:38 2015 From: report at bugs.python.org (Gareth Rees) Date: Wed, 17 Jun 2015 08:53:38 +0000 Subject: [issue24460] urlencode() of dictionary not as expected In-Reply-To: <1434523722.13.0.839663684524.issue24460@psf.upfronthosting.co.za> Message-ID: <1434531218.47.0.128599472889.issue24460@psf.upfronthosting.co.za> Gareth Rees added the comment: If you read the documentation for urllib.parse.urlencode [1], you'll see that it says: The value element in itself can be a sequence and in that case, if the optional parameter doseq is evaluates to True, individual key=value pairs separated by '&' are generated for each element of the value sequence for the key. So you need to write: >>> urllib.parse.urlencode(thisDict, doseq=True) 'SomeVar3=ghi&SomeVar1=abc&SomeVar2=def' [1]: https://docs.python.org/3/library/urllib.parse.html#urllib.parse.urlencode ---------- nosy: +Gareth.Rees _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 11:31:15 2015 From: report at bugs.python.org (Torsten Bronger) Date: Wed, 17 Jun 2015 09:31:15 +0000 Subject: [issue20362] longMessage attribute is ignored in unittest.TestCase.assertRegexpMatches etc In-Reply-To: <1390469977.33.0.983072297482.issue20362@psf.upfronthosting.co.za> Message-ID: <1434533475.1.0.645763745285.issue20362@psf.upfronthosting.co.za> Changes by Torsten Bronger : ---------- nosy: +bronger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 11:51:02 2015 From: report at bugs.python.org (=?utf-8?b?6L+b6ZmG?=) Date: Wed, 17 Jun 2015 09:51:02 +0000 Subject: [issue24461] os.environ.get treats Environt variant with double quotation marks wrong Message-ID: <1434534662.14.0.922780196773.issue24461@psf.upfronthosting.co.za> New submission from ??: On windows, if a Directory/Filename has SPACE, double quotation mark should be used. For example, "R:\just a test\hello.bat" has only one line "@echo hello world", so in the dos prompt [quote] R:\just a test>hello.bat hello world R:\just a test>cd .. R:\>set dir1="R:\just a test" R:\>set dir2=R:\just a test R:\>%dir1%\hello.bat hello world R:\>%dir2%\hello.bat 'R:\just' is not recognized as an internal or external command [/quote] Then, in python (it seems to be a common problem in all(?) python version) [quote] dir1= os.environ.get('dir1') print (dir1) print (os.path.isdir(dir1)) print (os.path.isdir(dir1.replace('"', ''))) print ('*'*10) dir2= os.environ.get('dir2') print (dir2) print (os.path.isdir(dir2)) print (os.path.isdir(dir2.replace('"', ''))) [/quote] displays [quote] "R:\just a test" False <--obviously, the double quotation marks is treated as the part of the directory name by python, so the answer is wrong True ********** R:\just a test True True [/quote] the patched method is simple [quote] if os.name=='nt': res=res.replace('"', '') [/quote] but the not simple thing is that os.py for python 3.4.3 changes a lot than os.py for python 2.7, I get lost while reading os.py for python 3.4.3 by no IDE. So I just report this issue, sorry. ---------- components: Library (Lib) messages: 245433 nosy: ?? priority: normal severity: normal status: open title: os.environ.get treats Environt variant with double quotation marks wrong type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 11:59:07 2015 From: report at bugs.python.org (=?utf-8?b?6L+b6ZmG?=) Date: Wed, 17 Jun 2015 09:59:07 +0000 Subject: [issue24461] os.environ.get treats Environt variant with double quotation marks wrong In-Reply-To: <1434534662.14.0.922780196773.issue24461@psf.upfronthosting.co.za> Message-ID: <1434535147.29.0.532535696725.issue24461@psf.upfronthosting.co.za> ?? added the comment: the patched method should be [quote] if os.name=='nt' and res: res=res.replace('"', '') [/quote] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 15:20:44 2015 From: report at bugs.python.org (Mauro S. M. Rodrigues) Date: Wed, 17 Jun 2015 13:20:44 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1434547244.02.0.267578951016.issue23883@psf.upfronthosting.co.za> Changes by Mauro S. M. Rodrigues : Added file: http://bugs.python.org/file39718/issue23883_fileinput.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 15:24:58 2015 From: report at bugs.python.org (Mauro S. M. Rodrigues) Date: Wed, 17 Jun 2015 13:24:58 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1434547498.93.0.327787115319.issue23883@psf.upfronthosting.co.za> Changes by Mauro S. M. Rodrigues : Removed file: http://bugs.python.org/file39140/issue23883_fileinput.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 16:16:02 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 17 Jun 2015 14:16:02 +0000 Subject: [issue24460] urlencode() of dictionary not as expected In-Reply-To: <1434523722.13.0.839663684524.issue24460@psf.upfronthosting.co.za> Message-ID: <1434550562.85.0.377691802986.issue24460@psf.upfronthosting.co.za> R. David Murray added the comment: That behavior is complex enough that I think it would be worth adding an example of it to the examples section (and maybe linking directly from the doseq explanation to that specific example). ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, r.david.murray versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 16:26:39 2015 From: report at bugs.python.org (JohnLeitch) Date: Wed, 17 Jun 2015 14:26:39 +0000 Subject: [issue24462] bytearray.find Buffer Over-read Message-ID: <1434551199.93.0.25363766054.issue24462@psf.upfronthosting.co.za> New submission from JohnLeitch: The bytearray.find method suffers from a buffer over-read that can be triggered by passing a string equal in length to the buffer. The result is a read off the end of the buffer, which could potentially be exploited to disclose the contents of adjacent memory. Repro: var_kcjtxvgr = bytearray([0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44,0x41,0x42,0x43,0x44]) var_kcjtxvgr.find("\x41" * 0x58) Exception: 0:000> r eax=00000002 ebx=00000058 ecx=071adf41 edx=00000000 esi=071f2264 edi=00000057 eip=1e081cf9 esp=0027fc2c ebp=071ae000 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 python27!stringlib_find+0x169: 1e081cf9 0fbe0c2a movsx ecx,byte ptr [edx+ebp] ds:002b:071ae000=?? 0:000> dV str = 0x071adfa8 "ABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCD" str_len = 0n2 sub = 0x071f2264 "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" sub_len = 0n88 offset = 0n0 0:000> db ebp-0x10 071adff0 41 42 43 44 41 42 43 44-41 42 43 44 41 42 43 44 ABCDABCDABCDABCD 071ae000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071ae010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071ae020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071ae030 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071ae040 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071ae050 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071ae060 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 0:000> !analyze -v -nodb ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* FAULTING_IP: python27!stringlib_find+169 [c:\build27\cpython\objects\stringlib\find.h @ 22] 1e081cf9 0fbe0c2a movsx ecx,byte ptr [edx+ebp] EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 1e081cf9 (python27!stringlib_find+0x00000169) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: 071ae000 Attempt to read from address 071ae000 CONTEXT: 00000000 -- (.cxr 0x0;r) eax=00000002 ebx=00000058 ecx=071adf41 edx=00000000 esi=071f2264 edi=00000057 eip=1e081cf9 esp=0027fc2c ebp=071ae000 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 python27!stringlib_find+0x169: 1e081cf9 0fbe0c2a movsx ecx,byte ptr [edx+ebp] ds:002b:071ae000=?? FAULTING_THREAD: 00001e90 DEFAULT_BUCKET_ID: INVALID_POINTER_READ PROCESS_NAME: pythonw.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: 00000000 EXCEPTION_PARAMETER2: 071ae000 READ_ADDRESS: 071ae000 FOLLOWUP_IP: python27!stringlib_find+169 [c:\build27\cpython\objects\stringlib\find.h @ 22] 1e081cf9 0fbe0c2a movsx ecx,byte ptr [edx+ebp] NTGLOBALFLAG: 2000000 APPLICATION_VERIFIER_FLAGS: 0 APP: pythonw.exe ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ BUGCHECK_STR: APPLICATION_FAULT_INVALID_POINTER_READ LAST_CONTROL_TRANSFER: from 1e081ee5 to 1e081cf9 STACK_TEXT: 0027fc48 1e081ee5 071adfa8 071f2264 00000058 python27!stringlib_find+0x169 0027fc5c 1e083ac1 071adfa8 071f2264 00000058 python27!stringlib_find_slice+0x35 0027fcb4 1e083b20 00000001 1e083b10 1e0aafd7 python27!bytearray_find_internal+0x81 0027fcc0 1e0aafd7 070880c8 071d7a10 07086170 python27!bytearray_find+0x10 0027fcd8 1e0edd10 07086170 071d7a10 00000000 python27!PyCFunction_Call+0x47 0027fd04 1e0f017a 0027fd5c 06cc7c80 06cc7c80 python27!call_function+0x2b0 0027fd74 1e0f1150 07060d60 00000000 06cc7c80 python27!PyEval_EvalFrameEx+0x239a 0027fda8 1e0f11b2 06cc7c80 07060d60 06ccba50 python27!PyEval_EvalCodeEx+0x690 0027fdd4 1e11707a 06cc7c80 06ccba50 06ccba50 python27!PyEval_EvalCode+0x22 0027fdec 1e1181c5 0710ee20 06ccba50 06ccba50 python27!run_mod+0x2a 0027fe0c 1e118760 623a7408 06c87fa4 00000101 python27!PyRun_FileExFlags+0x75 0027fe4c 1e1190d9 623a7408 06c87fa4 00000001 python27!PyRun_SimpleFileExFlags+0x190 0027fe68 1e038d35 623a7408 06c87fa4 00000001 python27!PyRun_AnyFileExFlags+0x59 0027fee4 1d001017 00000002 06c87f80 1d0011b6 python27!Py_Main+0x965 0027fef0 1d0011b6 1d000000 00000000 03bdffa0 pythonw!WinMain+0x17 0027ff80 76477c04 7ffde000 76477be0 c4cc721a pythonw!__tmainCRTStartup+0x140 0027ff94 7799ad1f 7ffde000 c53e80b9 00000000 KERNEL32!BaseThreadInitThunk+0x24 0027ffdc 7799acea ffffffff 77980232 00000000 ntdll!__RtlUserThreadStart+0x2f 0027ffec 00000000 1d001395 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b STACK_COMMAND: .cxr 0x0 ; kb FAULTING_SOURCE_LINE: c:\build27\cpython\objects\stringlib\find.h FAULTING_SOURCE_FILE: c:\build27\cpython\objects\stringlib\find.h FAULTING_SOURCE_LINE_NUMBER: 22 FAULTING_SOURCE_CODE: 18: return -1; 19: if (sub_len == 0) 20: return offset; 21: > 22: pos = fastsearch(str, str_len, sub, sub_len, -1, FAST_SEARCH); 23: 24: if (pos >= 0) 25: pos += offset; 26: 27: return pos; SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: python27!stringlib_find+169 FOLLOWUP_NAME: MachineOwner MODULE_NAME: python27 IMAGE_NAME: python27.dll DEBUG_FLR_IMAGE_TIMESTAMP: 5488ac17 FAILURE_BUCKET_ID: INVALID_POINTER_READ_c0000005_python27.dll!stringlib_find BUCKET_ID: APPLICATION_FAULT_INVALID_POINTER_READ_python27!stringlib_find+169 ANALYSIS_SOURCE: UM FAILURE_ID_HASH_STRING: um:invalid_pointer_read_c0000005_python27.dll!stringlib_find FAILURE_ID_HASH: {e37593ba-d07f-07cf-b7e5-32630cfd6e24} Followup: MachineOwner --------- ---------- files: bytearray.find_Buffer_Over-read.py messages: 245436 nosy: JohnLeitch priority: normal severity: normal status: open title: bytearray.find Buffer Over-read type: security versions: Python 2.7 Added file: http://bugs.python.org/file39719/bytearray.find_Buffer_Over-read.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 16:27:39 2015 From: report at bugs.python.org (David Rueter) Date: Wed, 17 Jun 2015 14:27:39 +0000 Subject: [issue24460] urlencode() of dictionary not as expected In-Reply-To: <1434523722.13.0.839663684524.issue24460@psf.upfronthosting.co.za> Message-ID: <1434551259.8.0.384206646092.issue24460@psf.upfronthosting.co.za> David Rueter added the comment: Ah hah! Indeed, urlencode() does work on dictionaries as expected when doseq=True. Thank you for clarifying. FWIW I had read the documentation and the referenced examples multiple times. I would like to make a few documentation suggestions for clarity. 1 ) Update https://docs.python.org/3/library/urllib.parse.html#urllib.parse.urlencode Where documentation currently says: "When a sequence of two-element tuples is used as the query argument, the first element of each tuple is a key and the second is a value. The value element in itself can be a sequence and in that case, if the optional parameter doseq is evaluates to True, individual key=value pairs separated by '&' are generated for each element of the value sequence for the key. The order of parameters in the encoded string will match the order of parameter tuples in the sequence." Perhaps instead the following would be more clear: "The query argument may be a sequence of two-element tuples where the first element of each tuple is a key and the second is a value. However the optional parameter doseq must then be set to True in order to reliably generate individual key=value pairs separated by '&' for each element of the value sequence for the key, and to preserve the sequence of the elements in the query parameter." 2) Update https://docs.python.org/3/library/urllib.request.html#urllib-examples The examples are referenced from the documentation: "Refer to urllib examples to find out how urlencode method can be used for generating query string for a URL or data for POST." However the example page provides contradictory information and examples for this specific use case. Currently the examples page says: "The urllib.parse.urlencode() function takes a mapping or sequence of 2-tuples and returns a string in this format. It should be encoded to bytes before being used as the data parameter. The charset parameter in Content-Type header may be used to specify the encoding. If charset parameter is not sent with the Content-Type header, the server following the HTTP 1.1 recommendation may assume that the data is encoded in ISO-8859-1 encoding. It is advisable to use charset parameter with encoding used in Content-Type header with the Request." Perhaps instead the following would be more clear: "The urllib.parse.urlencode() query parameter can accept a mapping or sequence of 2-tuples and return a string in this format if the optional parameter doseq is set to True. It should be encoded to bytes before being used as the query parameter. The charset parameter in Content-Type header may be used to specify the encoding. If charset parameter is not sent with the Content-Type header, the server following the HTTP 1.1 recommendation may assume that the data is encoded in ISO-8859-1 encoding. It is advisable to use charset parameter with encoding used in Content-Type header with the Request." 3) Also on the example page, there are examples of urlencode operating on dictionaries where doseq is not provided. This is confusing. It would be better to show doseq = True: Here is an example session that uses the GET method to retrieve a URL containing parameters: ... >>> data = urllib.parse.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0}) ... The following example uses the POST method instead. Note that params output from urlencode is encoded to bytes before it is sent to urlopen as data: ... >>> data = urllib.parse.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0}) I suggest that these examples read: >>> data = urllib.parse.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0}, doseq=true) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 16:37:17 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 17 Jun 2015 14:37:17 +0000 Subject: [issue24461] os.environ.get treats Environt variant with double quotation marks wrong In-Reply-To: <1434534662.14.0.922780196773.issue24461@psf.upfronthosting.co.za> Message-ID: <1434551837.85.0.617360283763.issue24461@psf.upfronthosting.co.za> R. David Murray added the comment: This is working in pretty much the only way it can work. Python is correctly retrieving the string from the environment (it includes the quotation marks). It is correctly passing that string to os.path: os.path takes the exact string that represents the filename. In windows it would be equally valid to do this: set dir3="just "" a"" test" %dir3%\hello.bat Your "simple fix" would not address that case (and would break existing programs that rely on the current behavior). There is no way to handle all the possible variations here. The only thing that can be done is what python does do: return exactly the string stored in the environment variable, and expect exactly the filename as input to functions that expect filenames. In many contexts in Windows it works perfectly fine to have the filename without quotes around it stored in the environment variable and to use that: dir %dir1% works fine, for example. The Windows rules for quoting are non-obvious and not completely consistent, I'm afraid, and there's nothing python can do to paper over that fact. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 17:10:47 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 17 Jun 2015 15:10:47 +0000 Subject: [issue24380] Got warning when compiling _scproxy.c on Mac In-Reply-To: <1433427659.62.0.118183885403.issue24380@psf.upfronthosting.co.za> Message-ID: <1434553847.48.0.948662496257.issue24380@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The patch is not correct. You're probably building with a new enough version of OSX as the deployment target. _scproxy.c should recognise this and should only perform the != NULL test when the variable address might be NULL. #if MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_4 if (if (&kSCPropNetProxiesExcludeSimpleHostnames != NULL) { #end .... #if MAC_OS_X_VERSION_MIN_REQUIRED <= MAC_OS_X_VERSION_10_4 } else { ... } #endif And as the variable is available on OSX 10.4 we could just drop the test and assume it is available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 17:51:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 17 Jun 2015 15:51:13 +0000 Subject: [issue24462] bytearray.find Buffer Over-read In-Reply-To: <1434551199.93.0.25363766054.issue24462@psf.upfronthosting.co.za> Message-ID: <1434556273.04.0.00968914307886.issue24462@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 18:48:18 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 17 Jun 2015 16:48:18 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434559698.0.0.24899716058.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, Stefan, Martin, Please find an updated patch attached. All issues that you guys found (thanks a lot for the reviews btw!) should be resolved. ---------- Added file: http://bugs.python.org/file39720/corotype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 18:50:03 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 17 Jun 2015 16:50:03 +0000 Subject: [issue24450] Add gi_yieldfrom calculated property to generator object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1434559803.46.0.469922365616.issue24450@psf.upfronthosting.co.za> Yury Selivanov added the comment: I think we need some feedback from PyPy & Jython guys on this. I'm not sure that they can expose 'yieldfrom' slot without some performance penalties. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 18:52:45 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 17 Jun 2015 16:52:45 +0000 Subject: [issue24439] Feedback for awaitable coroutine documentation In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za> Message-ID: <1434559965.08.0.225666222717.issue24439@psf.upfronthosting.co.za> Yury Selivanov added the comment: Martin, thanks a lot for the feedback and patch! I'll review the patch when issue24400 lands. ---------- assignee: docs at python -> yselivanov nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 18:56:58 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 17 Jun 2015 16:56:58 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1434560218.57.0.578428140394.issue23996@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov resolution: fixed -> stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 19:04:33 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 17 Jun 2015 17:04:33 +0000 Subject: [issue7518] Some functions in pymath.c should be moved elsewhere. In-Reply-To: <1260904788.96.0.184476026521.issue7518@psf.upfronthosting.co.za> Message-ID: <1434560673.2.0.243525111501.issue7518@psf.upfronthosting.co.za> Mark Dickinson added the comment: Yes, there are almost certainly better ways to organize the build here. A hacky solution might be to simply #include _math.c in the two other files that need it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 19:06:11 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 17 Jun 2015 17:06:11 +0000 Subject: [issue24450] Add gi_yieldfrom calculated property to generator object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1434560771.85.0.355024641346.issue24450@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- assignee: -> yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 19:49:18 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Wed, 17 Jun 2015 17:49:18 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1434563358.58.0.8664271509.issue23883@psf.upfronthosting.co.za> Changes by Jacek Ko?odziej : Added file: http://bugs.python.org/file39721/Issue23883_csv_all.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 21:47:24 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 17 Jun 2015 19:47:24 +0000 Subject: [issue24450] Add gi_yieldfrom calculated property to generator object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1434570444.87.0.32716734085.issue24450@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 21:47:39 2015 From: report at bugs.python.org (Ent) Date: Wed, 17 Jun 2015 19:47:39 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1434570459.6.0.990382248537.issue23255@psf.upfronthosting.co.za> Ent added the comment: Hello, Since this patch is in acceptable state, should the Status or Resolution be changed so that it is flagged to be merged into Python 3.5? Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 22:15:59 2015 From: report at bugs.python.org (Cyd Haselton) Date: Wed, 17 Jun 2015 20:15:59 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1434572159.34.0.492271324049.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Update: Now that I;ve finished porting a much-needed gdb to my device, I should have time to tackle patch and testing this weekend. Will post results when I have them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 22:37:12 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 17 Jun 2015 20:37:12 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1434573432.67.0.225100065862.issue23255@psf.upfronthosting.co.za> Ned Deily added the comment: Ent, thanks for all your work on this, and thanks to Demian and Martin for their reviews. In the meantime, the Python 3.5 release cycle has reached feature code cutoff so, at this point, generally only bug fixes are being accepted into 3.5, which means this refactoring will likely land in 3.6. The next step is for a core developer to do a final review and then decide whether to commit it. Berker has been commenting on this issue so perhaps he will have time to handle it as 3.6 gets underway. (http is one of the modules/packages in the standard library where currently no core developer has volunteered to be its "expert" so we all share responsibility for it as time and interest permits. https://docs.python.org/devguide/experts.html) ---------- keywords: +needs review nosy: +ned.deily versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 22:39:17 2015 From: report at bugs.python.org (Armin Rigo) Date: Wed, 17 Jun 2015 20:39:17 +0000 Subject: [issue24450] Add gi_yieldfrom calculated property to generator object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1434573557.59.0.945368504267.issue24450@psf.upfronthosting.co.za> Armin Rigo added the comment: No problem from PyPy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 17 22:47:52 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 17 Jun 2015 20:47:52 +0000 Subject: [issue24450] Add gi_yieldfrom calculated property to generator object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1434574072.82.0.635855292623.issue24450@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +fwierzbicki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 00:09:30 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 17 Jun 2015 22:09:30 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434578970.37.0.0645094642498.issue24400@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file39722/corotype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 01:01:02 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 17 Jun 2015 23:01:02 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434582062.86.0.409123480931.issue24400@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file39723/corotype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 03:07:22 2015 From: report at bugs.python.org (paul j3) Date: Thu, 18 Jun 2015 01:07:22 +0000 Subject: [issue24444] In argparse empty choices cannot be printed in the help In-Reply-To: <1434178022.79.0.230343884775.issue24444@psf.upfronthosting.co.za> Message-ID: <1434589642.97.0.302820226073.issue24444@psf.upfronthosting.co.za> paul j3 added the comment: Does this work for help='choices: %(choices)s' Without setting up my own test case, I'm guessing that the problem is with an empty help string. `help=''` should be ok, but the test handle that probably occurs earlier. Choices, empty or not, are included earlier in the help line, as well as usage. So there isn't real need to include them in the user defined part of the help line. Still, there are other bug issues regarding the formatting of choices. That part needs refinement to handle very long lists of choices, as well as ones that don't fit the usual 'list' format. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 03:07:54 2015 From: report at bugs.python.org (paul j3) Date: Thu, 18 Jun 2015 01:07:54 +0000 Subject: [issue24441] In argparse add_argument() allows the empty choices argument In-Reply-To: <1434145271.17.0.0249492593034.issue24441@psf.upfronthosting.co.za> Message-ID: <1434589674.32.0.543492686839.issue24441@psf.upfronthosting.co.za> Changes by paul j3 : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 03:17:23 2015 From: report at bugs.python.org (paul j3) Date: Thu, 18 Jun 2015 01:17:23 +0000 Subject: [issue24419] In argparse action append_const doesn't work for positional arguments In-Reply-To: <1433891109.51.0.989129061245.issue24419@psf.upfronthosting.co.za> Message-ID: <1434590243.15.0.61939993545.issue24419@psf.upfronthosting.co.za> paul j3 added the comment: What are you trying to accomplish in the examples with a 'dest'? For a positional, 'dest' is derived from the 'foo' name. There is no need to supply 'dest', in fact produces the error you get. It has nothing to with this action type (as your last example demonstrates). Your case with 'foo' and 'bar' shows that 'append_const' works fine. But be ware that such an action does not make much sense for a positional. Such an action takes no arguments, i.e. 'nargs=0'. So such a positional is always present, since it does not consume any `argv` strings. You might even get an error if you supply a string. (same would be true of 'store_true' and related actions). ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 04:16:56 2015 From: report at bugs.python.org (py.user) Date: Thu, 18 Jun 2015 02:16:56 +0000 Subject: [issue24419] In argparse action append_const doesn't work for positional arguments In-Reply-To: <1433891109.51.0.989129061245.issue24419@psf.upfronthosting.co.za> Message-ID: <1434593816.72.0.829245175955.issue24419@psf.upfronthosting.co.za> py.user added the comment: paul j3 wrote: > What are you trying to accomplish in the examples with a 'dest'? To append all that constants to one list. >From this: Namespace(bar=[43], foo=[42]) To this: Namespace(x=[43, 42]) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 04:35:43 2015 From: report at bugs.python.org (paul j3) Date: Thu, 18 Jun 2015 02:35:43 +0000 Subject: [issue24419] In argparse action append_const doesn't work for positional arguments In-Reply-To: <1433891109.51.0.989129061245.issue24419@psf.upfronthosting.co.za> Message-ID: <1434594943.06.0.563211524034.issue24419@psf.upfronthosting.co.za> paul j3 added the comment: None of the `append` actions makes sense with positionals. The name (and hence the 'dest') must be unique. And positionals can't be repeated. There are other ways to put a pair of values in the Namespace. For example, after parsing args.x = [42, 43] or before ns = argparse.Namespace(x=[42,43]) parser.parse_args(namespace=ns) or the `const` (or better the default) could be `[42, 43]`. Plain `append` might let you put `[42,43]` in the dest via the default, and then append further values to that list (from the user). I'd have to test that. It might be instructive to look at the `test_argparse.py` file, and search for test cases that use `append` or `const`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 05:12:30 2015 From: report at bugs.python.org (py.user) Date: Thu, 18 Jun 2015 03:12:30 +0000 Subject: [issue24419] In argparse action append_const doesn't work for positional arguments In-Reply-To: <1433891109.51.0.989129061245.issue24419@psf.upfronthosting.co.za> Message-ID: <1434597150.94.0.608350444532.issue24419@psf.upfronthosting.co.za> py.user added the comment: paul j3 wrote: > The name (and hence the 'dest') must be unique. The problem is in the dest argument of add_argument(). Why user can't set a custom name for a positional? We can use this list not only for positionals but for optionals too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 07:30:30 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Jun 2015 05:30:30 +0000 Subject: [issue24421] Race condition compiling Modules/_math.c In-Reply-To: <1433923600.68.0.73894537311.issue24421@psf.upfronthosting.co.za> Message-ID: <1434605430.8.0.241421524251.issue24421@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a hacky patch that adds #include "_math.c" so that it is not compiled as a separate object file. This was suggested by Mark in Issue 7518. It is far from a perfect solution, but I cannot suggest anything better without knowing more about Python?s build system. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file39724/include-math.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 08:31:50 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Jun 2015 06:31:50 +0000 Subject: [issue18383] test_warnings modifies warnings.filters when running with "-W default" In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za> Message-ID: <1434609110.38.0.115701044116.issue18383@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW there is a new message currently being triggered by test___all__. The patch here also stops this message. $ hg update 4335d898be59 $ ./python -bWall -m test test___all__ [1/1] test___all__ Warning -- warnings.filters was modified by test___all__ 1 test altered the execution environment: test___all__ ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 09:01:52 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Jun 2015 07:01:52 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1434610912.49.0.383938147627.issue15745@psf.upfronthosting.co.za> Martin Panter added the comment: The commit causes test_os to emit DeprecationWarning warnings, which it didn?t before: [vadmium at localhost cpython]$ hg update 4335d898be59 0 files updated, 0 files merged, 0 files removed, 0 files unresolved [vadmium at localhost cpython]$ ./python -bWdefault -m test test_os [1/1] test_os /media/disk/home/proj/python/cpython/Lib/unittest/case.py:638: DeprecationWarning: stat_float_times() is deprecated function(*args, **kwargs) [? 11 . . .] ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 10:22:31 2015 From: report at bugs.python.org (DmitryJ) Date: Thu, 18 Jun 2015 08:22:31 +0000 Subject: [issue24462] bytearray.find Buffer Over-read In-Reply-To: <1434551199.93.0.25363766054.issue24462@psf.upfronthosting.co.za> Message-ID: <1434615751.61.0.720201349881.issue24462@psf.upfronthosting.co.za> DmitryJ added the comment: Quick analysis tells this can be attributed to the following code (in 2.7): https://hg.python.org/cpython/file/a8e24d776e99/Objects/stringlib/fastsearch.h#l110 https://hg.python.org/cpython/file/a8e24d776e99/Objects/stringlib/fastsearch.h#l116 Suppose i = 0, then s[i+m] causes OOB access when m=n. Note only one iteration is possible in case of m=n due to loop condition of i <= (w = n-m = 0). Theoretically, one can try disclosing one adjacent byte, but more likely results are nothing (or potentially invalid match result) or a potential crash in an unlucky case of s[m] hitting an unmapped page. The same code lives in 3.2 (and likely any prior 3.x release), and 3.3 seems to be affected as well. 3.4 code has a modified version, but has the same problem (ss = s + m - 1; if (!STRINGLIB_BLOOM(mask, ss[i+1])) ...). ---------- nosy: +dev_zzo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 10:41:43 2015 From: report at bugs.python.org (DmitryJ) Date: Thu, 18 Jun 2015 08:41:43 +0000 Subject: [issue24462] bytearray.find Buffer Over-read In-Reply-To: <1434551199.93.0.25363766054.issue24462@psf.upfronthosting.co.za> Message-ID: <1434616903.07.0.046706345216.issue24462@psf.upfronthosting.co.za> DmitryJ added the comment: >From the author's page at http://effbot.org/zone/stringlib.htm "Note that the above Python code may access s[n], which would result in an IndexError exception. For the CPython implementation, this is not really a problem, since CPython adds trailing NULL entries to both 8-bit and Unicode strings." Apparently, this flaw was known to the author, but was not documented in C code. A possible quick-and-dirty solution is to treat m=n as a special case and resort to memcmp() or somesuch as there is no actual need to perform multiple match tries. This should fix things for bytearray and str in case str's implementation changes from appending a trailing NUL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 11:26:40 2015 From: report at bugs.python.org (John Helour) Date: Thu, 18 Jun 2015 09:26:40 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1434619600.33.0.454152078614.issue24339@psf.upfronthosting.co.za> Changes by John Helour : Removed file: http://bugs.python.org/file39575/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 12:01:48 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 18 Jun 2015 10:01:48 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1434621708.04.0.878671814319.issue23255@psf.upfronthosting.co.za> Berker Peksag added the comment: Ned is correct. I started to review the patch, but couldn't find time to do a complete review. I'll take a look at it in a week or two. Thanks! ---------- assignee: -> berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 12:32:55 2015 From: report at bugs.python.org (Tal Einat) Date: Thu, 18 Jun 2015 10:32:55 +0000 Subject: [issue24421] Race condition compiling Modules/_math.c In-Reply-To: <1433923600.68.0.73894537311.issue24421@psf.upfronthosting.co.za> Message-ID: <1434623575.56.0.536795650557.issue24421@psf.upfronthosting.co.za> Tal Einat added the comment: Adding Thomas Wouters to the nosy list, since he's listed on the Experts Index under "autoconf/makefiles" as an interest area. Hopefully he can help move this forward. ---------- nosy: +twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 12:35:57 2015 From: report at bugs.python.org (Tal Einat) Date: Thu, 18 Jun 2015 10:35:57 +0000 Subject: [issue23020] New matmul operator crashes modules compiled with CPython3.4 In-Reply-To: <1418128303.35.0.105853053103.issue23020@psf.upfronthosting.co.za> Message-ID: <1434623757.66.8.02631106059e-05.issue23020@psf.upfronthosting.co.za> Changes by Tal Einat : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 13:01:13 2015 From: report at bugs.python.org (vasya yugov) Date: Thu, 18 Jun 2015 11:01:13 +0000 Subject: [issue24463] Python 3.4 bugs Message-ID: <1434625273.11.0.800818633314.issue24463@psf.upfronthosting.co.za> New submission from vasya yugov: This code: w = [[0] * 2] * 2 w[1][1] = 1 print(w) prints [[0, 1], [0, 1]] Is it a bug? ---------- components: Macintosh messages: 245460 nosy: ned.deily, ronaldoussoren, vasya yugov priority: normal severity: normal status: open title: Python 3.4 bugs type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 13:15:13 2015 From: report at bugs.python.org (Benno Leslie) Date: Thu, 18 Jun 2015 11:15:13 +0000 Subject: [issue24450] Add gi_yieldfrom calculated property to generator object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1434626113.34.0.577032595003.issue24450@psf.upfronthosting.co.za> Benno Leslie added the comment: I've tried to address all the issues raised in the review of the first patch. ---------- Added file: http://bugs.python.org/file39725/gi_yieldfrom.v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 13:29:20 2015 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 18 Jun 2015 11:29:20 +0000 Subject: [issue24463] Python 3.4 bugs In-Reply-To: <1434625273.11.0.800818633314.issue24463@psf.upfronthosting.co.za> Message-ID: <1434626960.26.0.34315463221.issue24463@psf.upfronthosting.co.za> Skip Montanaro added the comment: Not a bug. The two elements of w are references to the same list: >>> w = [[0] * 2] * 2 >>> w [[0, 0], [0, 0]] >>> [id(elt) for elt in w] [21743952, 21743952] ---------- nosy: +skip.montanaro resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 13:31:43 2015 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 18 Jun 2015 11:31:43 +0000 Subject: [issue24464] Got warning when compiling sqlite3 module on Mac OSX Message-ID: <1434627103.24.0.34027869681.issue24464@psf.upfronthosting.co.za> New submission from Vajrasky Kok: I got this warning when compiling sqlite3 module. gcc -Wno-unused-result -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -DMODULE_NAME="sqlite3" -DSQLITE_OMIT_LOAD_EXTENSION=1 -IModules/_sqlite -I/usr/include -I./Include -I. -IInclude -I/usr/local/include -I/Users/sky/Code/python/cpython/Include -I/Users/sky/Code/python/cpython -c /Users/sky/Code/python/cpython/Modules/_sqlite/module.c -o build/temp.macosx-10.10-x86_64-3.6-pydebug/Users/sky/Code/python/cpython/Modules/_sqlite/module.o /Users/sky/Code/python/cpython/Modules/_sqlite/module.c:136:10: warning: 'sqlite3_enable_shared_cache' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations] rc = sqlite3_enable_shared_cache(do_enable); ^ /usr/include/sqlite3.h:5006:16: note: 'sqlite3_enable_shared_cache' has been explicitly marked deprecated here SQLITE_API int sqlite3_enable_shared_cache(int) __OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_0, __MAC_10_7, __I... ^ 1 warning generated. The enable_shared_cache method will fail if it is used afterwards. "Changing the shared_cache flag failed" Here is the patch to remove the warning. ---------- components: Macintosh files: remove_warning_compile__sqlite.patch keywords: patch messages: 245463 nosy: ned.deily, ronaldoussoren, vajrasky priority: normal severity: normal status: open title: Got warning when compiling sqlite3 module on Mac OSX versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39726/remove_warning_compile__sqlite.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 14:14:12 2015 From: report at bugs.python.org (Sam Thursfield) Date: Thu, 18 Jun 2015 12:14:12 +0000 Subject: [issue24465] Make tar files created by shutil.make_archive() have deterministic sorting Message-ID: <1434629652.82.0.994275977892.issue24465@psf.upfronthosting.co.za> New submission from Sam Thursfield: I want shutil.make_archive() to produce deterministic output when given identical data as inputs. Right now there are two holes in this. One is that mtimes might not match. This can be fixed by the caller. The second is that the order that files in a subdirectory get added to the tarfile is not deterministic. This can't be fixed by the caller. Attached is a trivial patch to sort the results of os.listdir() to ensure the output tarfile is stable. This only applies to the 'tar' format. I've attached my testcase for this, which creates 3 tarfiles in /tmp. When this patch is applied, the 3 tarfiles it creates are identical according to `sha1sum`. Without this patch, they are all different. ---------- components: Library (Lib) files: tar-reproducible-testcase.py messages: 245464 nosy: samthursfield priority: normal severity: normal status: open title: Make tar files created by shutil.make_archive() have deterministic sorting type: enhancement Added file: http://bugs.python.org/file39727/tar-reproducible-testcase.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 14:21:45 2015 From: report at bugs.python.org (Sam Thursfield) Date: Thu, 18 Jun 2015 12:21:45 +0000 Subject: [issue24465] Make tar files created by shutil.make_archive() have deterministic sorting In-Reply-To: <1434629652.82.0.994275977892.issue24465@psf.upfronthosting.co.za> Message-ID: <1434630105.14.0.803784822993.issue24465@psf.upfronthosting.co.za> Changes by Sam Thursfield : ---------- keywords: +patch Added file: http://bugs.python.org/file39728/tarfile-stable-ordering.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 14:35:05 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 18 Jun 2015 12:35:05 +0000 Subject: [issue24465] Make tarfile have deterministic sorting In-Reply-To: <1434629652.82.0.994275977892.issue24465@psf.upfronthosting.co.za> Message-ID: <1434630905.51.0.180304235577.issue24465@psf.upfronthosting.co.za> R. David Murray added the comment: This would go beyond what the tar command itself does. I'm not sure we want to do that, as we are pretty much modeling our behavior on tar. However, that doesn't automatically mean we can't do it. We'll see what other people think. Personally I'm -0. I've changed the issue title since your proposed patch is to tarfile, not shutil. ---------- nosy: +r.david.murray title: Make tar files created by shutil.make_archive() have deterministic sorting -> Make tarfile have deterministic sorting versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 15:04:11 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Thu, 18 Jun 2015 13:04:11 +0000 Subject: [issue24465] Make tarfile have deterministic sorting In-Reply-To: <1434629652.82.0.994275977892.issue24465@psf.upfronthosting.co.za> Message-ID: <1434632651.23.0.0297172731202.issue24465@psf.upfronthosting.co.za> Lars Gust?bel added the comment: You don't need to patch the tarfile module. You could use os.walk() in shutil._make_tarball() and add each file with TarFile.add(recursive=False). ---------- nosy: +lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 16:25:14 2015 From: report at bugs.python.org (Sam Thursfield) Date: Thu, 18 Jun 2015 14:25:14 +0000 Subject: [issue24465] Make tarfile have deterministic sorting In-Reply-To: <1434629652.82.0.994275977892.issue24465@psf.upfronthosting.co.za> Message-ID: <1434637514.37.0.239719928203.issue24465@psf.upfronthosting.co.za> Sam Thursfield added the comment: Thanks for the comments! Would you be happy for the patch to be merged if it was implemented by modifying shutil.make_archive() instead? I will rework it if so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 16:33:16 2015 From: report at bugs.python.org (alanf) Date: Thu, 18 Jun 2015 14:33:16 +0000 Subject: [issue24466] extend_path explanation in documentation is ambiguous Message-ID: <1434637996.53.0.698059319376.issue24466@psf.upfronthosting.co.za> New submission from alanf: The description of pkgutil.extend_path in the doc (e.g., https://docs.python.org/2/library/pkgutil.html , https://docs.python.org/3/library/pkgutil.html ) is so ambiguous that I had to run a test to understand its behavior. The doc says: This will add to the package?s __path__ all subdirectories of directories on sys.path named after the package. It wasn't clear to me how this should be parsed. Using parentheses to group the clauses, there's this possibility : (1) This will add to the package?s __path__ all (subdirectories of directories on sys.path) named after the package. That is, given all subdirectories of directories on sys.path, find the ones that are named after the package, and add them to the package's __path__. or: (2) This will add to the package?s __path__ all subdirectories of (directories on sys.path named after the package). That is, given all directories on sys.path that are named after the package, add all their subdirectories to the package's __path__. or: (3) This will add to the package?s __path__ all subdirectories of ((directories on sys.path) named after the package). That is, given all directories on sys.path that are named after the package, add all their subdirectories to the package's __path__. or: (4) This will add to the package?s __path__ all (subdirectories of (directories on sys.path)) named after the package. That is, given all directories on sys.path, add any of their subdirectories that are named after the package to the package's __path__. It was also unclear to me whether the subdirectories were meant to be traversed recursively. My testing indicates that (4) is the correct parse, and that the subdirectories are not meant to be traversed recursively. I suggest this wording: For each directory on sys.path that has a subdirectory that matches the package name, add the subdirectory to the package's __path__. ---------- assignee: docs at python components: Documentation messages: 245468 nosy: alanf, docs at python priority: normal severity: normal status: open title: extend_path explanation in documentation is ambiguous type: enhancement versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 17:13:15 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 18 Jun 2015 15:13:15 +0000 Subject: [issue24465] Make tarfile have deterministic sorting In-Reply-To: <1434629652.82.0.994275977892.issue24465@psf.upfronthosting.co.za> Message-ID: <1434640395.38.0.284440825418.issue24465@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't see any downside for this simple patch and think there is some merit for wanting a reproducible archive. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 17:23:11 2015 From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=) Date: Thu, 18 Jun 2015 15:23:11 +0000 Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop() In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za> Message-ID: <1434640991.22.0.738858798424.issue19542@psf.upfronthosting.co.za> Tin Tvrtkovi? added the comment: We're actually getting bitten by this in production through the Riak Python client, so this isn't a strictly theoretical problem. ---------- nosy: +tinchester _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 17:24:27 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Jun 2015 15:24:27 +0000 Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop() In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za> Message-ID: <1434641067.22.0.444525295385.issue19542@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, we need to fix this. Sorry for being a bit slow. ---------- versions: +Python 3.5, Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 18:19:16 2015 From: report at bugs.python.org (Ent) Date: Thu, 18 Jun 2015 16:19:16 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1434644356.59.0.861112767838.issue23255@psf.upfronthosting.co.za> Ent added the comment: Thanks Ned & Berker, I can only imagine the amount of work the core devs have to deal with. Hope my patch makes it through in next version. Regards, Ent ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 19:01:51 2015 From: report at bugs.python.org (paul j3) Date: Thu, 18 Jun 2015 17:01:51 +0000 Subject: [issue24419] In argparse action append_const doesn't work for positional arguments In-Reply-To: <1433891109.51.0.989129061245.issue24419@psf.upfronthosting.co.za> Message-ID: <1434646911.84.0.0718676183668.issue24419@psf.upfronthosting.co.za> paul j3 added the comment: You can give the positional any custom name (the first parameter). You just can't reuse it (by giving 2 positionals the same name). And if you don't like what the 'help' shows, you can set the 'metavar'. That way only you see the positional's name. The name of a positional can be the 'dest' of an optional. But wouldn't that be confusing? Setting the same attribute with a required postional and one or more optional optionals? 'nargs' is another way of assigning more than one value to a Namespace attribute. You just can't put an optional between two such values. `argparse` is a parser, a way of identifying what the user gives you. It is better to err on the side of preserving information. Different argument dests does that. You can always combine values after parsing. args.foo.append(args.bar) # or .extend() args.x = [args.foo, args.bar] Don't try to force argparse to do something special when you can just as easily do that later with normal Python expressions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 19:08:03 2015 From: report at bugs.python.org (Elazar Gershuni) Date: Thu, 18 Jun 2015 17:08:03 +0000 Subject: [issue19235] Add a dedicated subclass for recursion errors In-Reply-To: <1381596107.9.0.320701037292.issue19235@psf.upfronthosting.co.za> Message-ID: <1434647283.48.0.405777952053.issue19235@psf.upfronthosting.co.za> Elazar Gershuni added the comment: So what holds it back now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 20:05:49 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 18 Jun 2015 18:05:49 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434650749.16.0.741935917176.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: Another iteration of the patch is attached. Nick, I think it's ready for your review. ---------- stage: needs patch -> patch review type: -> enhancement Added file: http://bugs.python.org/file39729/corotype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 20:29:18 2015 From: report at bugs.python.org (eryksun) Date: Thu, 18 Jun 2015 18:29:18 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434652158.8.0.939038976161.issue24429@psf.upfronthosting.co.za> eryksun added the comment: > shapely's installation instructions from windows are to use > chris gohlke's prebuilt binaries from here: > http://www.lfd.uci.edu/~gohlke/pythonlibs/ Christoph Gohlke's Shapely?1.5.9?cp27?none?win_amd64.whl includes a version of geos_c.dll that has the VC90 manifest embedded as resource 2, just like python27.dll. The DLL also exports a GEOSFree function, which is what shapely actually uses. That said, the geos.py module still defines a global free() using cdll.msvcrt.free. As far as I can see, it never actually calls it. Otherwise it would surely crash the process due to a heap mismatch. Steve, since you haven't closed this issue, have you considered my suggestion to export _Py_ActivateActCtx and _Py_DeactivateActCtx for use by C extensions such as _ctypes.pyd? These functions are better than manually creating a context from the manifest that's embedded in python27.dll because they use the context that was active when python27.dll was initially loaded. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 21:29:00 2015 From: report at bugs.python.org (py.user) Date: Thu, 18 Jun 2015 19:29:00 +0000 Subject: [issue24419] In argparse action append_const doesn't work for positional arguments In-Reply-To: <1433891109.51.0.989129061245.issue24419@psf.upfronthosting.co.za> Message-ID: <1434655740.39.0.634291507673.issue24419@psf.upfronthosting.co.za> py.user added the comment: paul j3 wrote: > You can give the positional any custom name (the first parameter). The dest argument is not required for giving name for an optional. You can either make it automatically or set by dest, it's handy and clear. >>> import argparse >>> >>> parser = argparse.ArgumentParser() >>> _ = parser.add_argument('-a', '--aa') >>> _ = parser.add_argument('-b', '--bb', dest='x') >>> args = parser.parse_args([]) >>> print(args) Namespace(aa=None, x=None) >>> But if you do the same thing with a positional, it throws an exception. Why? (I'm a UNIX user and waiting predictable behaviour.) And the situation with another action (not only append_const, but future extensions) shows that dest may be required. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 21:32:18 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 18 Jun 2015 19:32:18 +0000 Subject: [issue19235] Add a dedicated subclass for recursion errors In-Reply-To: <1381596107.9.0.320701037292.issue19235@psf.upfronthosting.co.za> Message-ID: <1434655937.99.0.226058012789.issue19235@psf.upfronthosting.co.za> Yury Selivanov added the comment: +1. This, unfortunately, can't go in 3.5 (too late), but I can commit this in 3.6. ---------- assignee: -> yselivanov nosy: +yselivanov versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 21:54:41 2015 From: report at bugs.python.org (Elazar Gershuni) Date: Thu, 18 Jun 2015 19:54:41 +0000 Subject: [issue19235] Add a dedicated subclass for recursion errors In-Reply-To: <1381596107.9.0.320701037292.issue19235@psf.upfronthosting.co.za> Message-ID: <1434657281.85.0.171502125018.issue19235@psf.upfronthosting.co.za> Elazar Gershuni added the comment: Well that's a d?j? vu. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 21:59:54 2015 From: report at bugs.python.org (Sean Goodwin) Date: Thu, 18 Jun 2015 19:59:54 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1434657594.59.0.738362092305.issue6839@psf.upfronthosting.co.za> Changes by Sean Goodwin : ---------- nosy: +Sean Goodwin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 22:07:16 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 18 Jun 2015 20:07:16 +0000 Subject: [issue19235] Add a dedicated subclass for recursion errors In-Reply-To: <1381596107.9.0.320701037292.issue19235@psf.upfronthosting.co.za> Message-ID: <1434658036.8.0.573089829064.issue19235@psf.upfronthosting.co.za> Yury Selivanov added the comment: Larry, is there any chance this can be committed in 3.5 (the change is fully backwards compatible)? ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 22:37:08 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 18 Jun 2015 20:37:08 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1434659828.94.0.261279553355.issue24429@psf.upfronthosting.co.za> Steve Dower added the comment: > Steve, since you haven't closed this issue, have you considered my suggestion to export _Py_ActivateActCtx and _Py_DeactivateActCtx for use by C extensions such as _ctypes.pyd? These functions are better than manually creating a context from the manifest that's embedded in python27.dll because they use the context that was active when python27.dll was initially loaded. I'm always fairly slow to close issues - don't read too much into that :) I don't see any value in exporting them for other C extensions, since they can also capture the initial context when they are loaded. They really need exports for Python. windll.python27._Py_ActivateActCtx would suffice and I wouldn't want to go any further than that - this is *very* advanced functionality that I would expect most people to get wrong. Someone prepare a patch. I'm not -1 yet (and of course, I'm not the sole gatekeeper here, so one of the core devs who's still working on 2.7 can fix it too). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 22:49:43 2015 From: report at bugs.python.org (paul j3) Date: Thu, 18 Jun 2015 20:49:43 +0000 Subject: [issue24419] In argparse action append_const doesn't work for positional arguments In-Reply-To: <1433891109.51.0.989129061245.issue24419@psf.upfronthosting.co.za> Message-ID: <1434660582.99.0.834783842303.issue24419@psf.upfronthosting.co.za> paul j3 added the comment: (Important correction at the end of this post) The test that you are complaining about occurs at the start of the 'add_argument' method: def add_argument(self, *args, **kwargs): """ add_argument(dest, ..., name=value, ...) add_argument(option_string, option_string, ..., name=value, ...) """ # if no positional args are supplied or only one is supplied and # it doesn't look like an option string, parse a positional # argument chars = self.prefix_chars if not args or len(args) == 1 and args[0][0] not in chars: if args and 'dest' in kwargs: raise ValueError('dest supplied twice for positional argument') kwargs = self._get_positional_kwargs(*args, **kwargs) # otherwise, we're adding an optional argument else: kwargs = self._get_optional_kwargs(*args, **kwargs) ... and the 2 methods it calls: def _get_positional_kwargs(self, dest, **kwargs): # code to deduce the 'required' parameter ... # return the keyword arguments with no option strings return dict(kwargs, dest=dest, option_strings=[]) def _get_optional_kwargs(self, *args, **kwargs): # determine short and long option strings .... # infer destination, '--foo-bar' -> 'foo_bar' and '-x' -> 'x' dest = kwargs.pop('dest', None) if dest is None: if long_option_strings: dest_option_string = long_option_strings[0] else: dest_option_string = option_strings[0] dest = dest_option_string.lstrip(self.prefix_chars) if not dest: msg = _('dest= is required for options like %r') raise ValueError(msg % option_string) dest = dest.replace('-', '_') # return the updated keyword arguments return dict(kwargs, dest=dest, option_strings=option_strings) At the 'add_argument' stage, a big difference between positionals and optionals is in how 'dest' is deduced. Note the doc string. During parsing, positionals are distinguished from optionals by the 'option_strings' attribute (empty or not). 'dest' is not used during parsing, except by the Action '__call__'. ------------------------- I just thought of another way around this constraint - set 'dest' after the action is created: p=argparse.ArgumentParser() a1=p.add_argument('foo',action='append') a2=p.add_argument('bar',action='append') a1.dest='x' a2.dest='x' args=p.parse_args(['one','two']) produces Namespace(x=['one', 'two']) This works because after the action has been created, no one checks whether the 'dest' value is duplicated or even looks pretty (except when trying to format it for the help. You could also write a custom Action class, one that mangles the 'dest' to your heart's delight. The primary use of 'self.dest' is in the expression: setattr(namespace, self.dest, items) you could replace this line in the Action '__call__' with setattr(namespace, 'secret#dest', items) ----------------- I was mistaken on one thing - you can reuse positional 'names': a1=p.add_argument('foo',action='append') a2=p.add_argument('foo',action='append',type=int) p.parse_args(['a','3']) produces: Namespace(foo=['a', 3]) There is a 'name' conflict handler, but it only pays attention to the option strings (flags for optionals). You can't have two arguments using '-f' or '--foo'. But you can have 2 or more positionals with the same 'dest'. You just have to set the dest the right way. This last point renders the whole issue moot. But I'll leave it at the end to reflect my train of thought. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 22:51:10 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 18 Jun 2015 20:51:10 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434660670.13.0.666446458481.issue24400@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file39730/corotype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 18 23:04:35 2015 From: report at bugs.python.org (JohnLeitch) Date: Thu, 18 Jun 2015 21:04:35 +0000 Subject: [issue24467] bytearray pop and remove Buffer Over-read Message-ID: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za> New submission from JohnLeitch: The bytearray pop and remove methods suffer from buffer over-reads caused by memmove use under the assumption that PyByteArrayObject ob_size is less than ob_alloc, leading to a single byte over-read. This condition can be triggered by creating a bytearray from a range of length 0x10, then calling pop with a valid index: bytearray(range(0x10)).pop(0) The result is a memmove that reads off the end of src: 0:000> r eax=071aeff0 ebx=00000000 ecx=071aeff1 edx=00000010 esi=06ff80c8 edi=00000010 eip=6234b315 esp=0027fc98 ebp=0027fca0 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202 MSVCR90!memmove+0x5: 6234b315 8b750c mov esi,dword ptr [ebp+0Ch] ss:002b:0027fcac=071aeff1 0:000> dV dst = 0x071aeff0 "" src = 0x071aeff1 "???" count = 0x10 0:000> db poi(dst) 071aeff0 00 01 02 03 04 05 06 07-08 09 0a 0b 0c 0d 0e 0f ................ 071af000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071af010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071af020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071af030 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071af040 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071af050 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071af060 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 0:000> db poi(src) 071aeff1 01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f ?? ...............? 071af001 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071af011 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071af021 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071af031 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071af041 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071af051 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 071af061 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 0:000> g (1968.1a88): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=0c0b0a09 ebx=00000000 ecx=00000004 edx=00000000 esi=071aeff1 edi=071aeff0 eip=6234b468 esp=0027fc98 ebp=0027fca0 iopl=0 nv up ei ng nz ac pe cy cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010297 MSVCR90!UnwindUpVec+0x50: 6234b468 8b448efc mov eax,dword ptr [esi+ecx*4-4] ds:002b:071aeffd=???????? 0:000> k ChildEBP RetAddr 0027fca0 1e0856aa MSVCR90!UnwindUpVec+0x50 [f:\dd\vctools\crt_bld\SELF_X86\crt\src\Intel\MEMCPY.ASM @ 322] 0027fcc0 1e0aafd7 python27!bytearray_pop+0x8a [c:\build27\cpython\objects\bytearrayobject.c @ 2378] 0027fcd8 1e0edd10 python27!PyCFunction_Call+0x47 [c:\build27\cpython\objects\methodobject.c @ 81] 0027fd04 1e0f017a python27!call_function+0x2b0 [c:\build27\cpython\python\ceval.c @ 4033] 0027fd74 1e0f1150 python27!PyEval_EvalFrameEx+0x239a [c:\build27\cpython\python\ceval.c @ 2682] 0027fda8 1e0f11b2 python27!PyEval_EvalCodeEx+0x690 [c:\build27\cpython\python\ceval.c @ 3265] 0027fdd4 1e11707a python27!PyEval_EvalCode+0x22 [c:\build27\cpython\python\ceval.c @ 672] 0027fdec 1e1181c5 python27!run_mod+0x2a [c:\build27\cpython\python\pythonrun.c @ 1371] 0027fe0c 1e118760 python27!PyRun_FileExFlags+0x75 [c:\build27\cpython\python\pythonrun.c @ 1358] 0027fe4c 1e1190d9 python27!PyRun_SimpleFileExFlags+0x190 [c:\build27\cpython\python\pythonrun.c @ 950] 0027fe68 1e038d35 python27!PyRun_AnyFileExFlags+0x59 [c:\build27\cpython\python\pythonrun.c @ 753] 0027fee4 1d001017 python27!Py_Main+0x965 [c:\build27\cpython\modules\main.c @ 643] 0027fef0 1d0011b6 pythonw!WinMain+0x17 [c:\build27\cpython\pc\winmain.c @ 15] 0027ff80 76477c04 pythonw!__tmainCRTStartup+0x140 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 578] 0027ff94 7799ad1f KERNEL32!BaseThreadInitThunk+0x24 0027ffdc 7799acea ntdll!__RtlUserThreadStart+0x2f 0027ffec 00000000 ntdll!_RtlUserThreadStart+0x1b If the over-read is allowed to succeed, a byte adjacent to the buffer is copied: 0:000> r eax=01d8e978 ebx=00000000 ecx=00000000 edx=0000003a esi=01dc80c8 edi=00000010 eip=1e08569a esp=0027fd0c ebp=01d5aa10 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206 python27!bytearray_pop+0x7a: 1e08569a 8bd7 mov edx,edi 0:000> dt self Local var @ 0x27fd20 Type PyByteArrayObject* 0x01dc80c8 +0x000 ob_refcnt : 0n2 +0x004 ob_type : 0x1e21a6d0 _typeobject +0x008 ob_size : 0n16 +0x00c ob_exports : 0n0 +0x010 ob_alloc : 0n16 +0x014 ob_bytes : 0x01d8e978 "" 0:000> db 0x01d8e978 01d8e978 00 01 02 03 04 05 06 07-08 09 0a 0b 0c 0d 0e 0f ................ 01d8e988 ab ab ab ab ab ab ab ab-00 00 00 00 00 00 00 00 ................ 01d8e998 da 49 7a 0e b6 ac 10 00-b0 af d8 01 78 1c ce 01 .Iz.........x... 01d8e9a8 ee fe ee fe ee fe ee fe-ee fe ee fe ee fe ee fe ................ 01d8e9b8 5f 49 79 88 b7 ac 10 1d-02 00 00 00 f8 8b 22 1e _Iy...........". 01d8e9c8 d6 03 00 00 ff ff ff ff-00 00 00 00 20 54 72 69 ............ Tri 01d8e9d8 65 73 20 74 6f 20 64 65-74 65 72 6d 69 6e 65 20 es to determine 01d8e9e8 74 68 65 20 64 65 66 61-75 6c 74 20 6c 6f 63 61 the default loca 0:000> p eax=01d8e978 ebx=00000000 ecx=00000004 edx=00000000 esi=01dc80c8 edi=00000010 eip=1e0856aa esp=0027fd00 ebp=01d5aa10 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206 python27!bytearray_pop+0x8a: 1e0856aa 4f dec edi 0:000> db 0x01d8e978 01d8e978 01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f ab ................ 01d8e988 ab ab ab ab ab ab ab ab-00 00 00 00 00 00 00 00 ................ 01d8e998 da 49 7a 0e b6 ac 10 00-b0 af d8 01 78 1c ce 01 .Iz.........x... 01d8e9a8 ee fe ee fe ee fe ee fe-ee fe ee fe ee fe ee fe ................ 01d8e9b8 5f 49 79 88 b7 ac 10 1d-02 00 00 00 f8 8b 22 1e _Iy...........". 01d8e9c8 d6 03 00 00 ff ff ff ff-00 00 00 00 20 54 72 69 ............ Tri 01d8e9d8 65 73 20 74 6f 20 64 65-74 65 72 6d 69 6e 65 20 es to determine 01d8e9e8 74 68 65 20 64 65 66 61-75 6c 74 20 6c 6f 63 61 the default loca However, a subsequent call to PyByteArray_Resize overwrites the copied byte with a null terminator: 0:000> p eax=00000000 ebx=00000000 ecx=00000004 edx=00000000 esi=01dc80c8 edi=0000000f eip=1e0856c0 esp=0027fd0c ebp=01d5aa10 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 python27!bytearray_pop+0xa0: 1e0856c0 0fb6d3 movzx edx,bl 0:000> db 0x01d8e978 01d8e978 01 02 03 04 05 06 07 08-09 0a 0b 0c 0d 0e 0f 00 ................ 01d8e988 ab ab ab ab ab ab ab ab-00 00 00 00 00 00 00 00 ................ 01d8e998 da 49 7a 0e b6 ac 10 00-b0 af d8 01 78 1c ce 01 .Iz.........x... 01d8e9a8 ee fe ee fe ee fe ee fe-ee fe ee fe ee fe ee fe ................ 01d8e9b8 5f 49 79 88 b7 ac 10 1d-02 00 00 00 f8 8b 22 1e _Iy...........". 01d8e9c8 d6 03 00 00 ff ff ff ff-00 00 00 00 20 54 72 69 ............ Tri 01d8e9d8 65 73 20 74 6f 20 64 65-74 65 72 6d 69 6e 65 20 es to determine 01d8e9e8 74 68 65 20 64 65 66 61-75 6c 74 20 6c 6f 63 61 the default loca Because of this, these vulnerabilities should be classified as defense-in-depth. If PyByteArray_Resize could be forced to fail, or its behavior changes at a future date, it may become possible to exploit these issues to read adjacent memory. ---------- files: bytearray.pop_Buffer_Over-read.py messages: 245483 nosy: JohnLeitch priority: normal severity: normal status: open title: bytearray pop and remove Buffer Over-read type: security versions: Python 2.7 Added file: http://bugs.python.org/file39731/bytearray.pop_Buffer_Over-read.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 00:24:47 2015 From: report at bugs.python.org (Brandon Milam) Date: Thu, 18 Jun 2015 22:24:47 +0000 Subject: [issue21297] csv.skipinitialspace only skips spaces, not "whitespace" in general In-Reply-To: <1397821941.61.0.706896478348.issue21297@psf.upfronthosting.co.za> Message-ID: <1434666287.8.0.482260618167.issue21297@psf.upfronthosting.co.za> Brandon Milam added the comment: This is my first attempt at working with the test suite but I believe this is what you were asking for. Due to this being my first attempt at writing tests I have included it as a separate patch file. Any further changes just let me know. ---------- Added file: http://bugs.python.org/file39732/skipinitialspace_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 03:01:58 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Fri, 19 Jun 2015 01:01:58 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1434675718.36.0.704108978476.issue23883@psf.upfronthosting.co.za> Changes by Jacek Ko?odziej : Added file: http://bugs.python.org/file39733/Issue23883_support_check__all__.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 03:02:59 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Fri, 19 Jun 2015 01:02:59 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1434675779.24.0.00716386447873.issue23883@psf.upfronthosting.co.za> Changes by Jacek Ko?odziej : Added file: http://bugs.python.org/file39734/Issue23883_test_gettext.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 03:06:35 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Fri, 19 Jun 2015 01:06:35 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1434675995.33.0.261155553015.issue23883@psf.upfronthosting.co.za> Jacek Ko?odziej added the comment: Thank you for feedback, Martin. I've amended the the patch. Next, I've prepared some initial test.support.check__all__ helper, based on generalization of all previous patches. Its name/params' descriptions may be a bit rough - amendments/suggestions for such will be strongly appreciated: Issue23883_support_check__all__.patch I've added missing test.test_gettext.MiscTestCase, based on aforementioned check__all__ helper: Issue23883_test_gettext.patch I've also took the liberty of working on some more modules. These are: csv (using new helper), enum, ftplib, logging, optparse, pickletools, threading and wave: Issue23883_all.patch ftplib and threading have more functions (missing in their __all__ variables) that appear to be documented than mentioned in msg240217 - namely: * ftplib.error_temp https://docs.python.org/3/library/ftplib.html#ftplib.error_temp * ftplib.error_proto https://docs.python.org/3/library/ftplib.html#ftplib.error_proto * threading.main_thread https://docs.python.org/3/library/threading.html#threading.main_thread so I've added them as well. ---------- Added file: http://bugs.python.org/file39735/Issue23883_all.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 03:10:03 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Fri, 19 Jun 2015 01:10:03 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1434676202.99.0.144520494735.issue23883@psf.upfronthosting.co.za> Jacek Ko?odziej added the comment: > ftplib and threading have more functions I've meant function and exceptions, of course. Sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 06:47:33 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 19 Jun 2015 04:47:33 +0000 Subject: [issue24468] Expose compiler flag constants as code object attributes Message-ID: <1434689253.89.0.431597909643.issue24468@psf.upfronthosting.co.za> New submission from Nick Coghlan: As part of the PEP 492 implementation, Yury has needed to hardcode compile flag contants in various places, with adjacent comments explaining what the magic numbers mean. It occurred to me that there's a way we could make those constants readily available to any code manipulating code objects: expose them as read-only attributes via the code object type. Does this seem like a reasonable idea? If yes, would it be reasonable to classify it as part of the PEP 492 implementation process and include it during the 3.5 beta cycle? ---------- messages: 245487 nosy: gvanrossum, larry, ncoghlan, yselivanov priority: normal severity: normal stage: needs patch status: open title: Expose compiler flag constants as code object attributes type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 06:47:42 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 19 Jun 2015 04:47:42 +0000 Subject: [issue24468] Expose compiler flag constants as code object attributes In-Reply-To: <1434689253.89.0.431597909643.issue24468@psf.upfronthosting.co.za> Message-ID: <1434689262.6.0.0399412074095.issue24468@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- dependencies: +Awaitable ABC incompatible with functools.singledispatch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 06:48:19 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 19 Jun 2015 04:48:19 +0000 Subject: [issue24468] Expose compiler flag constants as code object attributes In-Reply-To: <1434689253.89.0.431597909643.issue24468@psf.upfronthosting.co.za> Message-ID: <1434689299.58.0.373144057323.issue24468@psf.upfronthosting.co.za> Larry Hastings added the comment: Probably, though I want to see a sample implementation before I agree to anything. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 07:06:39 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 19 Jun 2015 05:06:39 +0000 Subject: [issue24468] Expose compiler flag constants as code object attributes In-Reply-To: <1434689253.89.0.431597909643.issue24468@psf.upfronthosting.co.za> Message-ID: <1434690399.52.0.913399277616.issue24468@psf.upfronthosting.co.za> Nick Coghlan added the comment: In my last set of review comments on issue 24400 I suggested changing the Python level attributes for coroutine objects to cr_frame, cr_code, and cr_running. It's possible that may provide a different way to eliminate some of the current compiler flag checks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 07:09:09 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 19 Jun 2015 05:09:09 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434690549.63.0.326403832191.issue24400@psf.upfronthosting.co.za> Nick Coghlan added the comment: In my last set of review comments, I suggested changing the Python level attributes for coroutine objects to cr_frame, cr_code, and cr_running. That reminded me that now that coroutines are their own type, we should also give them their own state introspection API, matching the API for generators: https://docs.python.org/3/library/inspect.html#current-state-of-a-generator ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 07:17:46 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 19 Jun 2015 05:17:46 +0000 Subject: [issue24450] Add gi_yieldfrom calculated property to generator object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1434691066.48.0.389745339285.issue24450@psf.upfronthosting.co.za> Nick Coghlan added the comment: Marking this as dependent on issue 24400, as that refactors the PEP 492 implementation to make coroutines their own type (albeit one that shares a memory layout and some attribute names with generators at the C layer). I'd suggest cr_await as the calculated property for coroutines that corresponds to gi_yieldfrom for generators. ---------- dependencies: +Awaitable ABC incompatible with functools.singledispatch nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 08:31:18 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 19 Jun 2015 06:31:18 +0000 Subject: [issue24469] Py2.x int free list can grow without bounds Message-ID: <1434695478.8.0.352869011826.issue24469@psf.upfronthosting.co.za> New submission from Stefan Behnel: A Cython user noticed a memory leak when C-inheriting from "int". http://thread.gmane.org/gmane.comp.python.cython.devel/15689 The Cython code to reproduce this is simply this: cdef class ExtendedInt(int): pass for j in xrange(10000000): ExtendedInt(j) The problem is due to the free-list of the int type. It uses this code for deallocation: """ static void int_dealloc(PyIntObject *v) { if (PyInt_CheckExact(v)) { Py_TYPE(v) = (struct _typeobject *)free_list; free_list = v; } else Py_TYPE(v)->tp_free((PyObject *)v); } static void int_free(PyIntObject *v) { Py_TYPE(v) = (struct _typeobject *)free_list; free_list = v; } """ Now, when C-inheriting from PyInt_Type without providing an own tp_free implementation, PyType_Ready() will inherit the supertype's tp_free slot, which means that int_dealloc() above will end up calling int_free() in all cases, not only for the exact-int case. Thus, whether or not it's exactly "int" or a subtype, the object will always be added to the free-list on deallocation. However, in the subtype case, the free-list is actually ignored by int_new() and int_subtype_new(), so that as long as the user code only creates tons of int subtype instances and not plain int instances, the freelist will keep growing without bounds by pushing dead subtype objects onto it that are never reused. There are two problems here: 1) int subtypes should not be added to the freelist, or at least not unless they have exactly the same struct size as PyIntObject (which the ExtendedInt type above does but other subtypes may not) 2) if a free-list is used, it should be used in all instantiation cases, not just in PyInt_FromLong(). Fixing 1) by adding a type check to int_free() would be enough to fix the overall problem. Here's a quickly hacked up change that seems to work for me: """ static void int_free(PyIntObject *v) { if (PyInt_CheckExact(v)) { Py_TYPE(v) = (struct _typeobject *)free_list; free_list = v; } else if (Py_TYPE(v)->tp_flags & Py_TPFLAGS_HAVE_GC) PyObject_GC_Del(v); // untested by probably necessary else PyObject_Del(v); } """ ---------- components: Interpreter Core messages: 245492 nosy: scoder priority: normal severity: normal status: open title: Py2.x int free list can grow without bounds type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 09:15:23 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Fri, 19 Jun 2015 07:15:23 +0000 Subject: [issue24465] Make tarfile have deterministic sorting In-Reply-To: <1434629652.82.0.994275977892.issue24465@psf.upfronthosting.co.za> Message-ID: <1434698123.38.0.952185775239.issue24465@psf.upfronthosting.co.za> Lars Gust?bel added the comment: The patch would change behaviour for all tarfile users by the back door, that's why I am a little reluctant. And if the same can be achieved by a reasonably simple change to shutil I think it's just as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 10:35:41 2015 From: report at bugs.python.org (Marco Clemencic) Date: Fri, 19 Jun 2015 08:35:41 +0000 Subject: [issue24470] ctypes incorrect handling of long int on 64bits Linux Message-ID: <1434702940.98.0.688877329391.issue24470@psf.upfronthosting.co.za> New submission from Marco Clemencic: When passing a Python int to a C function expecting long int (or void*) via ctypes, the number gets truncated to 32 bits, even if the args types are correctly declared. The workaround is to wrap the argument in c_long (or c_void_p), but the automatic unwrapping of c_long (or c_void_p) in the return type lead to undefined behaviour in code like: myClib.getNumber.restype = c_long myClib.doSomething.args = [c_long] l = myClib.getnumber() myClib.doSomething(l) ---------- components: ctypes files: test_py.tar.bz2 messages: 245494 nosy: Marco Clemencic priority: normal severity: normal status: open title: ctypes incorrect handling of long int on 64bits Linux type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file39736/test_py.tar.bz2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 11:08:10 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 19 Jun 2015 09:08:10 +0000 Subject: [issue24450] Add gi_yieldfrom calculated property to generator object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1434704890.59.0.0481756888001.issue24450@psf.upfronthosting.co.za> Changes by Stefan Behnel : ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 11:15:52 2015 From: report at bugs.python.org (eryksun) Date: Fri, 19 Jun 2015 09:15:52 +0000 Subject: [issue24470] ctypes incorrect handling of long int on 64bits Linux In-Reply-To: <1434702940.98.0.688877329391.issue24470@psf.upfronthosting.co.za> Message-ID: <1434705352.66.0.0253883076445.issue24470@psf.upfronthosting.co.za> eryksun added the comment: It works for me: >>> open('test.c', 'w').write('long test(long x) {return x;}') >>> os.system('gcc -shared -fPIC -o test.so test.c') 0 >>> test = CDLL('./test.so').test >>> test.restype = c_long >>> test.argtypes = (c_long,) >>> test(2**63-1) == 2**63-1 True However, I used the correct attribute name, "argtypes". ctypes objects have dicts to allow setting arbitrary attribute names, so you won't get an AttributeError when setting "args" on a function pointer. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 11:15:57 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 19 Jun 2015 09:15:57 +0000 Subject: [issue24450] Add gi_yieldfrom calculated property to generator object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1434705357.18.0.767952184718.issue24450@psf.upfronthosting.co.za> Stefan Behnel added the comment: No problem for Cython either. The change in issue 24400 that makes coroutines real Awaitables also removes surprises for a "cr_await" return value being a coroutine and previously *not* an Awaitable. The contract for "gi_yieldfrom" is only that the returned value is an Iterator, IIUC? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 11:42:18 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 19 Jun 2015 09:42:18 +0000 Subject: [issue24469] Py2.x int free list can grow without bounds In-Reply-To: <1434695478.8.0.352869011826.issue24469@psf.upfronthosting.co.za> Message-ID: <1434706938.94.0.378925981782.issue24469@psf.upfronthosting.co.za> Changes by Stefan Behnel : ---------- nosy: +pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 12:21:52 2015 From: report at bugs.python.org (Sam Thursfield) Date: Fri, 19 Jun 2015 10:21:52 +0000 Subject: [issue24465] Make tarfile have deterministic sorting In-Reply-To: <1434629652.82.0.994275977892.issue24465@psf.upfronthosting.co.za> Message-ID: <1434709312.07.0.247401882292.issue24465@psf.upfronthosting.co.za> Sam Thursfield added the comment: I've discovered that this patch introduces a nasty failure case! If you have a relative symlink pointing to a directory that's alphabetically sorted after the symlink, and files inside the symlink, 'tar -x' won't be able to create those files because the symlink target won't exist yet. I'll rework this to only affect shutil.make_archive(), and to avoid hitting this bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 12:24:50 2015 From: report at bugs.python.org (Sam Thursfield) Date: Fri, 19 Jun 2015 10:24:50 +0000 Subject: [issue24465] Make tarfile have deterministic sorting In-Reply-To: <1434629652.82.0.994275977892.issue24465@psf.upfronthosting.co.za> Message-ID: <1434709490.2.0.959868228059.issue24465@psf.upfronthosting.co.za> Sam Thursfield added the comment: Having tested, the problem I described above doesn't happen with this patch. It's a mistake in some other code I wrote which is following symlinks when it should not do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 13:59:48 2015 From: report at bugs.python.org (Ismail Donmez) Date: Fri, 19 Jun 2015 11:59:48 +0000 Subject: [issue13501] Make libedit support more generic; port readline / libedit to FreeBSD In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za> Message-ID: <1434715188.1.0.184298757256.issue13501@psf.upfronthosting.co.za> Changes by Ismail Donmez : ---------- nosy: +cartman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 14:01:04 2015 From: report at bugs.python.org (=?utf-8?b?6ZmI5a+M?=) Date: Fri, 19 Jun 2015 12:01:04 +0000 Subject: =?utf-8?b?W2lzc3VlMjQ0NzFdIOWMl+S6rOWwj+WnkOaJvuS4iumXqOWFqOWll+acjQ==?= =?utf-8?b?5Yqh?= Message-ID: <1434715264.3.0.140511117983.issue24471@psf.upfronthosting.co.za> New submission from ??: ? ? ? ? ? ? ? ? ?188.0207.9509? ? ?188.0207.9509?? ? 10?20 ? ? ? ? 2 4 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?,? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?188.0207.9509? ? ? ?(? ?),(? ?) ? ? ? ? ? ? ? 1 ? ? ? ?`? ? ? ? 1 ? ? ? `? ? `? ? ? ? ?! ? ? ? 1 ? ? ?:188.0207.9509 ? ? MM ? ? ? ? ? ? ? ?! ?? ? ? ?? ?1?? ? ? ? 3 ? ? ? ? ? ? ? ? ? ?? ? ? ? ?? ? ? ? 3 ? ? ? ?? ? ? ? ? ? ?! ?2? ? ? ? ? ? ? ? ? ? ? ? ? ??? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ! ?3? ? ? ? ?:188.0207.9509? ?ewgreth1111111 ---------- components: Benchmarks files: 69f0d6e0ecbcee6fbb52097c52a7ee76.jpg messages: 245499 nosy: ddssaa123123 priority: normal severity: normal status: open title: ??????????? type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file39737/69f0d6e0ecbcee6fbb52097c52a7ee76.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 14:04:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 19 Jun 2015 12:04:39 +0000 Subject: =?utf-8?b?W2lzc3VlMjQ0NzFdIOWMl+S6rOWwj+WnkOaJvuS4iumXqOWFqOWll+acjQ==?= =?utf-8?b?5Yqh?= In-Reply-To: <1434715264.3.0.140511117983.issue24471@psf.upfronthosting.co.za> Message-ID: <1434715479.74.0.157710326947.issue24471@psf.upfronthosting.co.za> STINNER Victor added the comment: spam ---------- nosy: +haypo resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 14:24:07 2015 From: report at bugs.python.org (=?utf-8?b?6ZmI5a+M?=) Date: Fri, 19 Jun 2015 12:24:07 +0000 Subject: =?utf-8?b?W2lzc3VlMjQ0NzJdIOefs+WutuW6hOWwj+WnkOaJvuS4iumXqOWFqOWllw==?= =?utf-8?b?5pyN5Yqh?= Message-ID: <1434716647.75.0.323634381134.issue24472@psf.upfronthosting.co.za> New submission from ??: ? ? ? ? ? ? ? ? ? ? ?188.0207.9509? ? ?188.0207.9509?? ? 10?20 ? ? ? ? 2 4 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?,? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?188.0207.9509? ? ? ?(? ?),(? ?) ? ? ? ? ? ? ? 1 ? ? ? ?`? ? ? ? 1 ? ? ? `? ? `? ? ? ? ?! ? ? ? 1 ? ? ?:188.0207.9509 ? ? MM ? ? ? ? ? ? ? ?! ?? ? ? ?? ?1?? ? ? ? 3 ? ? ? ? ? ? ? ? ? ?? ? ? ? ?? ? ? ? 3 ? ? ? ?? ? ? ? ? ? ?! ?2? ? ? ? ? ? ? ? ? ? ? ? ? ??? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ! ?3? ? ? ? ?:188.0207.9509? ?ewgreth1111111 ---------- components: Benchmarks files: 9F059BE32A3FC19A52978B2901172641.jpg messages: 245501 nosy: ddssaa123123 priority: normal severity: normal status: open title: ???????????? type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file39738/9F059BE32A3FC19A52978B2901172641.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 14:29:56 2015 From: report at bugs.python.org (=?utf-8?b?6ZmI5a+M?=) Date: Fri, 19 Jun 2015 12:29:56 +0000 Subject: =?utf-8?b?W2lzc3VlMjQ0NzNdIOWNl+S6rOWwj+WnkOaJvuS4iumXqOWFqOWll+acjQ==?= =?utf-8?b?5Yqh?= Message-ID: <1434716996.22.0.597253490197.issue24473@psf.upfronthosting.co.za> New submission from ??: ? ? ? ? ? ? ? ? ?188.0207.9509? ? ?188.0207.9509?? ? 10?20 ? ? ? ? 2 4 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?,? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?188.0207.9509? ? ? ?(? ?),(? ?) ? ? ? ? ? ? ? 1 ? ? ? ?`? ? ? ? 1 ? ? ? `? ? `? ? ? ? ?! ? ? ? 1 ? ? ?:188.0207.9509 ? ? MM ? ? ? ? ? ? ? ?! ?? ? ? ?? ?1?? ? ? ? 3 ? ? ? ? ? ? ? ? ? ?? ? ? ? ?? ? ? ? 3 ? ? ? ?? ? ? ? ? ? ?! ?2? ? ? ? ? ? ? ? ? ? ? ? ? ??? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ! ?3? ? ? ? ?:188.0207.9509? ?ewgreth1111111 ---------- components: Benchmarks files: 12493721761041772378.jpg messages: 245502 nosy: ddssaa123123 priority: normal severity: normal status: open title: ??????????? type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file39739/12493721761041772378.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 14:32:45 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 19 Jun 2015 12:32:45 +0000 Subject: =?utf-8?b?W2lzc3VlMjQ0NzNdIOWNl+S6rOWwj+WnkOaJvuS4iumXqOWFqOWll+acjQ==?= =?utf-8?b?5Yqh?= In-Reply-To: <1434716996.22.0.597253490197.issue24473@psf.upfronthosting.co.za> Message-ID: <1434717165.86.0.382970802776.issue24473@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 14:33:00 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 19 Jun 2015 12:33:00 +0000 Subject: =?utf-8?b?W2lzc3VlMjQ0NzJdIOefs+WutuW6hOWwj+WnkOaJvuS4iumXqOWFqOWllw==?= =?utf-8?b?5pyN5Yqh?= In-Reply-To: <1434716647.75.0.323634381134.issue24472@psf.upfronthosting.co.za> Message-ID: <1434717180.0.0.630764709189.issue24472@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 14:56:25 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 19 Jun 2015 12:56:25 +0000 Subject: =?utf-8?b?W2lzc3VlMjQ0NzJdIOefs+WutuW6hOWwj+WnkOaJvuS4iumXqOWFqOWllw==?= =?utf-8?b?5pyN5Yqh?= In-Reply-To: <1434716647.75.0.323634381134.issue24472@psf.upfronthosting.co.za> Message-ID: <1434718585.45.0.33245955531.issue24472@psf.upfronthosting.co.za> Changes by Berker Peksag : Removed file: http://bugs.python.org/file39738/9F059BE32A3FC19A52978B2901172641.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 14:56:33 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 19 Jun 2015 12:56:33 +0000 Subject: =?utf-8?b?W2lzc3VlMjQ0NzJdIOefs+WutuW6hOWwj+WnkOaJvuS4iumXqOWFqOWllw==?= =?utf-8?b?5pyN5Yqh?= Message-ID: <1434718593.81.0.0708135955546.issue24472@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- Removed message: http://bugs.python.org/msg245501 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 14:56:46 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 19 Jun 2015 12:56:46 +0000 Subject: [issue24472] Spam Message-ID: <1434718606.85.0.252918740378.issue24472@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- title: ???????????? -> Spam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 14:57:00 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 19 Jun 2015 12:57:00 +0000 Subject: [issue24473] Spam In-Reply-To: <1434716996.22.0.597253490197.issue24473@psf.upfronthosting.co.za> Message-ID: <1434718620.71.0.608282131335.issue24473@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- title: ??????????? -> Spam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 14:57:06 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 19 Jun 2015 12:57:06 +0000 Subject: [issue24473] Spam Message-ID: <1434718626.11.0.271942898007.issue24473@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- Removed message: http://bugs.python.org/msg245502 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 14:57:11 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 19 Jun 2015 12:57:11 +0000 Subject: [issue24473] Spam Message-ID: <1434718631.41.0.0315475323913.issue24473@psf.upfronthosting.co.za> Changes by Berker Peksag : Removed file: http://bugs.python.org/file39739/12493721761041772378.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 15:11:58 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 19 Jun 2015 13:11:58 +0000 Subject: =?utf-8?b?W2lzc3VlMjQ0NzFdIOWMl+S6rOWwj+WnkOaJvuS4iumXqOWFqOWll+acjQ==?= =?utf-8?b?5Yqh?= In-Reply-To: <1434715264.3.0.140511117983.issue24471@psf.upfronthosting.co.za> Message-ID: <1434719518.17.0.459210434718.issue24471@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file39737/69f0d6e0ecbcee6fbb52097c52a7ee76.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 15:12:42 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 19 Jun 2015 13:12:42 +0000 Subject: =?utf-8?b?W2lzc3VlMjQ0NzFdIOWMl+S6rOWwj+WnkOaJvuS4iumXqOWFqOWll+acjQ==?= =?utf-8?b?5Yqh?= In-Reply-To: <1434715479.74.0.157710326947.issue24471@psf.upfronthosting.co.za> Message-ID: <1434719562.43.0.0413524401679.issue24471@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- Removed message: http://bugs.python.org/msg245499 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 15:13:47 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 19 Jun 2015 13:13:47 +0000 Subject: [issue24471] Spam In-Reply-To: <1434715479.74.0.157710326947.issue24471@psf.upfronthosting.co.za> Message-ID: <1434719627.27.0.0129328976414.issue24471@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: -Benchmarks nosy: -ddssaa123123, haypo stage: -> resolved title: ??????????? -> Spam type: behavior -> versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 15:16:09 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 19 Jun 2015 13:16:09 +0000 Subject: [issue24472] Spam Message-ID: <1434719769.64.0.440284772931.issue24472@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: -ddssaa123123 type: behavior -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 15:16:44 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 19 Jun 2015 13:16:44 +0000 Subject: [issue24472] Spam Message-ID: <1434719804.39.0.428373425925.issue24472@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: -Benchmarks resolution: -> not a bug stage: -> resolved versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 15:18:39 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 19 Jun 2015 13:18:39 +0000 Subject: [issue24473] Spam Message-ID: <1434719919.48.0.0937396735481.issue24473@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: -Benchmarks nosy: -ddssaa123123 resolution: -> not a bug stage: -> resolved type: behavior -> versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 15:38:26 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 19 Jun 2015 13:38:26 +0000 Subject: [issue24469] Py2.x int free list can grow without bounds In-Reply-To: <1434695478.8.0.352869011826.issue24469@psf.upfronthosting.co.za> Message-ID: <1434721106.53.0.828096538261.issue24469@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Now that's weird. Why is the current int_free() doing the same as int_dealloc()? Because some people call tp_free directly? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 15:42:49 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 19 Jun 2015 13:42:49 +0000 Subject: [issue24469] Py2.x int free list can grow without bounds In-Reply-To: <1434695478.8.0.352869011826.issue24469@psf.upfronthosting.co.za> Message-ID: <1434721369.39.0.401305661758.issue24469@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Apparently, this is because of 200559fcc664. The fix is weird, though: why duplicate code instead of moving it into tp_free? I'd rather let Guido and Barry discuss this, I'm not willing to touch the 2.x int type anymore. ---------- nosy: +barry, gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 15:42:53 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 19 Jun 2015 13:42:53 +0000 Subject: [issue24469] Py2.x int free list can grow without bounds In-Reply-To: <1434695478.8.0.352869011826.issue24469@psf.upfronthosting.co.za> Message-ID: <1434721373.06.0.363285641978.issue24469@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 16:16:37 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 19 Jun 2015 14:16:37 +0000 Subject: [issue24469] Py2.x int free list can grow without bounds In-Reply-To: <1434695478.8.0.352869011826.issue24469@psf.upfronthosting.co.za> Message-ID: <1434723397.81.0.530058377904.issue24469@psf.upfronthosting.co.za> Guido van Rossum added the comment: 1) The intended solution is to require that int subclasses override tp_free. 2) I don't see any constructors that don't call PyInt_FromLong() -- what am I missing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 18:16:29 2015 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Fri, 19 Jun 2015 16:16:29 +0000 Subject: [issue24474] Accidental exception chaining in inspect.Signature.bind() Message-ID: <1434730589.67.0.681224722356.issue24474@psf.upfronthosting.co.za> New submission from Walter D?rwald: When an exception is raised by inspect.Signature.bind() in some cases the exception has a StopIteration as its __context__: import inspect try: inspect.signature(lambda x:None).bind() except Exception as exc: print(repr(exc)) print(repr(exc.__context__)) This prints: TypeError("missing a required argument: 'x'",) StopIteration() I would have expected it to print: TypeError("missing a required argument: 'x'",) None This reason for this is that the code in bind() has nested exception handlers. The innermost handler does raise TypeError(...) from None to drop the exception context, but another context exception gets added by the outermost exception handler. ---------- messages: 245506 nosy: doerwalter priority: normal severity: normal status: open title: Accidental exception chaining in inspect.Signature.bind() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 18:20:44 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 19 Jun 2015 16:20:44 +0000 Subject: [issue24474] Accidental exception chaining in inspect.Signature.bind() In-Reply-To: <1434730589.67.0.681224722356.issue24474@psf.upfronthosting.co.za> Message-ID: <1434730844.41.0.229936848393.issue24474@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- assignee: -> yselivanov components: +Library (Lib) nosy: +yselivanov versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 18:27:50 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 19 Jun 2015 16:27:50 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434731270.02.0.735524854474.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: New patch is attached. Updates: 1. Coroutine type now has 'cr_*' slots *both* in Python *and* in C. 2. set_coroutine_wrapper now works *only* on coroutines created by 'async def' functions (generators wrapped with types.coroutine won't be intercepted). 3. RuntimeWarning that coroutine wasn't ever awaited will be raised *only* for 'async def' coroutines. 4. Coroutine objects no longer have 'CO_GENERATOR' flag. ---------- Added file: http://bugs.python.org/file39740/corotype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 18:56:33 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 19 Jun 2015 16:56:33 +0000 Subject: [issue24469] Py2.x int free list can grow without bounds In-Reply-To: <1434723397.81.0.530058377904.issue24469@psf.upfronthosting.co.za> Message-ID: <558449BF.8000607@behnel.de> Stefan Behnel added the comment: > 1) The intended solution is to require that int subclasses override tp_free. In the way I showed? By calling either PyObject_GC_Del() or PyObject_Del() directly? I'll happily do that (Py2.7 and Py2 "int" being dead ends makes that pretty future proof), but it's neither obvious nor very clean. > 2) I don't see any constructors that don't call PyInt_FromLong() -- what am I missing? Not sure what you mean. int_new() immediately calls int_subtype_new(), which then calls type->tp_alloc(). No call to PyInt_FromLong() involved. """ static PyObject * int_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { PyObject *x = NULL; int base = -909; static char *kwlist[] = {"x", "base", 0}; if (type != &PyInt_Type) return int_subtype_new(type, args, kwds); /* Wimp out */ ... static PyObject * int_subtype_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { ... tmp = int_new(&PyInt_Type, args, kwds); if (tmp == NULL) return NULL; if (!PyInt_Check(tmp)) { ival = PyLong_AsLong(tmp); if (ival == -1 && PyErr_Occurred()) { Py_DECREF(tmp); return NULL; } } else { ival = ((PyIntObject *)tmp)->ob_ival; } newobj = type->tp_alloc(type, 0); if (newobj == NULL) { Py_DECREF(tmp); return NULL; } ((PyIntObject *)newobj)->ob_ival = ival; Py_DECREF(tmp); return newobj; } """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 19:05:37 2015 From: report at bugs.python.org (Zahari Dim) Date: Fri, 19 Jun 2015 17:05:37 +0000 Subject: [issue24475] The docs never define what a pool "task" is Message-ID: <1434733537.74.0.146405679971.issue24475@psf.upfronthosting.co.za> New submission from Zahari Dim: See: http://stackoverflow.com/questions/30943161/multiprocessing-pool-with-maxtasksperchild-produces-equal-pids The documentation never makes clear what a "task" in the context of Pool.map. At best, it says: "This method chops the iterable into a number of chunks which it submits to the process pool as separate tasks. The (approximate) size of these chunks can be specified by setting chunksize to a positive integer." in the map documentation. However it does not say how this chunks are calculated by default, making the maxtasksperchild argument not very useful. The fact that a function evaluated by map is not a "task" should be much clearer in the documentation. Also, in the examples, such as: with multiprocessing.Pool(PROCESSES) as pool: # # Tests # TASKS = [(mul, (i, 7)) for i in range(10)] + \ [(plus, (i, 8)) for i in range(10)] results = [pool.apply_async(calculate, t) for t in TASKS] imap_it = pool.imap(calculatestar, TASKS) imap_unordered_it = pool.imap_unordered(calculatestar, TASKS) TASKS are not actually "tasks" but rather "task groups". ---------- assignee: docs at python components: Documentation messages: 245509 nosy: Zahari.Dim, docs at python priority: normal severity: normal status: open title: The docs never define what a pool "task" is versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 19:22:36 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 19 Jun 2015 17:22:36 +0000 Subject: [issue24468] Expose compiler flag constants as code object attributes In-Reply-To: <1434689253.89.0.431597909643.issue24468@psf.upfronthosting.co.za> Message-ID: <1434734556.83.0.429896627922.issue24468@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, Larry, please take a look at the attached patch. ---------- keywords: +patch Added file: http://bugs.python.org/file39741/code.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 19:48:25 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 19 Jun 2015 17:48:25 +0000 Subject: [issue24476] Statically link vcruntime140.dll Message-ID: <1434736105.85.0.548679802097.issue24476@psf.upfronthosting.co.za> New submission from Steve Dower: It's possible to statically link the vcruntime140.dll dependency without statically linking the entire CRT, which will save us from having to redistribute the file (meaning the entire CRT dependency is now system components). Patch to follow, and I'm very +1 on this, but didn't want to skip the chance for people to raise concerns or questions. ---------- assignee: steve.dower components: Windows messages: 245511 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: patch review status: open title: Statically link vcruntime140.dll type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 19:49:40 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 19 Jun 2015 17:49:40 +0000 Subject: [issue24476] Statically link vcruntime140.dll In-Reply-To: <1434736105.85.0.548679802097.issue24476@psf.upfronthosting.co.za> Message-ID: <1434736180.11.0.489227621692.issue24476@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- keywords: +patch Added file: http://bugs.python.org/file39742/24476_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 19:57:41 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 19 Jun 2015 17:57:41 +0000 Subject: [issue24474] Accidental exception chaining in inspect.Signature.bind() In-Reply-To: <1434730589.67.0.681224722356.issue24474@psf.upfronthosting.co.za> Message-ID: <1434736661.5.0.683286797637.issue24474@psf.upfronthosting.co.za> Yury Selivanov added the comment: Hi Walter, Thanks for reporting this. A patch is attached. ---------- keywords: +needs review, patch nosy: +larry, ncoghlan stage: -> patch review Added file: http://bugs.python.org/file39743/sig.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 21:12:52 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 19 Jun 2015 19:12:52 +0000 Subject: [issue24469] Py2.x int free list can grow without bounds In-Reply-To: <1434695478.8.0.352869011826.issue24469@psf.upfronthosting.co.za> Message-ID: <1434741172.2.0.761053868062.issue24469@psf.upfronthosting.co.za> Guido van Rossum added the comment: (1) Just look at the examples of other builtin types with a similar structure but no free_list. (2) I guess the intention is for classes that subclass int to also override tp_alloc. Note that much of this code is written pretty much assuming that subclasses are created using class statements (in a regular Python module, not Cython) which take care of all these details. That doesn't mean Cython is wrong to try this, but it does mean there isn't a lot of documentation, and it also means I don't think the thing you reported qualifies as a bug in CPython. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 21:22:08 2015 From: report at bugs.python.org (levkivskyi) Date: Fri, 19 Jun 2015 19:22:08 +0000 Subject: [issue24129] Incorrect (misleading) statement in the execution model documentation In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za> Message-ID: <1434741728.83.0.147732201218.issue24129@psf.upfronthosting.co.za> levkivskyi added the comment: Should I invite someone to review the patch or just wait? How the things are organized here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 21:32:43 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Jun 2015 19:32:43 +0000 Subject: [issue24447] tab indentation breaks in tokenize.untokenize In-Reply-To: <1434252794.24.0.0112893923697.issue24447@psf.upfronthosting.co.za> Message-ID: <1434742363.9.0.391716503606.issue24447@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> tokenize/untokenize roundtrip fails with tabs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 21:33:18 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Jun 2015 19:33:18 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <1434742398.54.0.917080272053.issue20387@psf.upfronthosting.co.za> Terry J. Reedy added the comment: #24447, closed as duplicate, has another example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 21:44:09 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Jun 2015 19:44:09 +0000 Subject: [issue24448] Syntax highlighting marks multiline comments as strings In-Reply-To: <1434262576.97.0.123947261736.issue24448@psf.upfronthosting.co.za> Message-ID: <1434743049.85.0.908905591897.issue24448@psf.upfronthosting.co.za> Terry J. Reedy added the comment: It is impossible for Idle to know the purpose of a multiline string. ---------- nosy: +terry.reedy resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 21:47:00 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 19 Jun 2015 19:47:00 +0000 Subject: [issue24129] Incorrect (misleading) statement in the execution model documentation In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za> Message-ID: <1434743220.26.0.736367463071.issue24129@psf.upfronthosting.co.za> R. David Murray added the comment: In this particular case, just wait (now that you have pinged the issue). Raymond is the most likely person to figure out how to phrase this better, but it isn't obvious what the best way to explain this is. I don't think your explanation is exactly correct, but I don't know enough about how class name resolution is implemented to explain what's wrong with it, I just know it doesn't feel quite right :) (Of course, I might be wrong.) Ping the issue again in a few weeks if there is no action. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 21:47:41 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 19 Jun 2015 19:47:41 +0000 Subject: [issue24476] Statically link vcruntime140.dll In-Reply-To: <1434736105.85.0.548679802097.issue24476@psf.upfronthosting.co.za> Message-ID: <1434743261.56.0.936537451943.issue24476@psf.upfronthosting.co.za> Paul Moore added the comment: +1 from me on this. Are there any specific technical implications (in terms of ease of interoperability, ability to use a different compiler to build Python, or whatever)? Whether there are or not, I'm still in favour - I think it's a good thing anyway on general principles. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 21:49:09 2015 From: report at bugs.python.org (Paul Anton Letnes) Date: Fri, 19 Jun 2015 19:49:09 +0000 Subject: [issue20741] Documentation archives should be available also in tar.xz format In-Reply-To: <1393142720.31.0.255845110134.issue20741@psf.upfronthosting.co.za> Message-ID: <1434743349.25.0.637539173801.issue20741@psf.upfronthosting.co.za> Paul Anton Letnes added the comment: The format (xz vs bzip2) might not matter much, but I'd say consistency does. I'd make the formats identical just for the sake of standardization. Where is this decided? In some (post)build script? ---------- nosy: +pletnes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 21:53:47 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Jun 2015 19:53:47 +0000 Subject: [issue15348] IDLE - shell becomes unresponsive if debugger windows is closed while active. In-Reply-To: <1342208290.25.0.778184843655.issue15348@psf.upfronthosting.co.za> Message-ID: <1434743627.04.0.512910011576.issue15348@psf.upfronthosting.co.za> Terry J. Reedy added the comment: #24455 is probably related. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 21:54:06 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 19 Jun 2015 19:54:06 +0000 Subject: [issue24476] Statically link vcruntime140.dll In-Reply-To: <1434736105.85.0.548679802097.issue24476@psf.upfronthosting.co.za> Message-ID: <1434743646.97.0.839906240841.issue24476@psf.upfronthosting.co.za> Steve Dower added the comment: There may be some potential issues when hosting Python in a C++ app built with a later version of MSVC, since vcruntime140.dll is predominantly initialization and exceptions for C++. I can't think of anything specific here though, and it seems likely that the host's initialization code would apply for the host. The C Runtime doesn't rely on anything initialized here as far as I know - it's only the C++ libraries. Shouldn't be any other implications other than slightly easier distribution and slightly larger file sizes. (Haven't actually checked how much larger, but it is no more than 10s of KB which I consider acceptable.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 21:54:21 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Jun 2015 19:54:21 +0000 Subject: [issue24455] IDLE debugger causes crash if not quitted properly before next run In-Reply-To: <1434383850.99.0.136251358232.issue24455@psf.upfronthosting.co.za> Message-ID: <1434743661.4.0.015186396066.issue24455@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This seems like an extension of #15348, but I will leave it open for now. The additional details may be useful. ---------- nosy: +terry.reedy versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 21:58:44 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 19 Jun 2015 19:58:44 +0000 Subject: [issue24476] Statically link vcruntime140.dll In-Reply-To: <1434736105.85.0.548679802097.issue24476@psf.upfronthosting.co.za> Message-ID: <1434743924.67.0.161077074392.issue24476@psf.upfronthosting.co.za> Zachary Ware added the comment: As long as a clean (updated) install of Vista, 7, 8, or 10 can download the installer, run it, and run Python without having to do anything else, I'm good with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 21:58:54 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 19 Jun 2015 19:58:54 +0000 Subject: [issue24129] Incorrect (misleading) statement in the execution model documentation In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za> Message-ID: <1434743934.37.0.259004408532.issue24129@psf.upfronthosting.co.za> Eric Snow added the comment: I've left a review. That said, we need to be sure this behavior is intentional. The fact that it skips the "nonlocal" scope(s) smells like a bug to me. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 22:01:12 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Jun 2015 20:01:12 +0000 Subject: [issue24470] ctypes incorrect handling of long int on 64bits Linux In-Reply-To: <1434702940.98.0.688877329391.issue24470@psf.upfronthosting.co.za> Message-ID: <1434744072.87.0.568038021605.issue24470@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Should this then be closed as not a bug? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 22:04:26 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 19 Jun 2015 20:04:26 +0000 Subject: [issue24476] Statically link vcruntime140.dll In-Reply-To: <1434736105.85.0.548679802097.issue24476@psf.upfronthosting.co.za> Message-ID: <1434744266.53.0.151107106459.issue24476@psf.upfronthosting.co.za> Paul Moore added the comment: Cool. Easier distribution is good. Better compatibility with GPL requirements (depending only on "system facilities") is probably helpful for the general community, too. Embedding in C++ built with a different version of the compiler is always going to be a fun exercise - I can't see this change as making things worse, even if it doesn't end up helping either. I'm guessing that this specific change won't make much difference to embedding in general - it's the move to the universal CRT that mitigates the worst of the "don't mix C runtimes" issues, rather than this specific change? Anyway, it's all steps in a positive direction, so that's good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 22:08:06 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 19 Jun 2015 20:08:06 +0000 Subject: [issue24476] Statically link vcruntime140.dll In-Reply-To: <1434736105.85.0.548679802097.issue24476@psf.upfronthosting.co.za> Message-ID: <1434744486.94.0.76961322904.issue24476@psf.upfronthosting.co.za> Steve Dower added the comment: > it's the move to the universal CRT that mitigates the worst of the "don't mix C runtimes" issues, rather than this specific change? Correct ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 22:09:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 19 Jun 2015 20:09:28 +0000 Subject: [issue24476] Statically link vcruntime140.dll In-Reply-To: <1434736105.85.0.548679802097.issue24476@psf.upfronthosting.co.za> Message-ID: <20150619200925.13777.8225@psf.io> Roundup Robot added the comment: New changeset 56ea535a8047 by Steve Dower in branch '3.5': Issue 24476: Statically links vcruntime140.dll and removes it from the installer https://hg.python.org/cpython/rev/56ea535a8047 New changeset c0827842102e by Steve Dower in branch 'default': Issue 24476: Statically links vcruntime140.dll and removes it from the installer https://hg.python.org/cpython/rev/c0827842102e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 22:09:50 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 19 Jun 2015 20:09:50 +0000 Subject: [issue24476] Statically link vcruntime140.dll In-Reply-To: <1434736105.85.0.548679802097.issue24476@psf.upfronthosting.co.za> Message-ID: <1434744590.02.0.804045043222.issue24476@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 22:10:20 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 19 Jun 2015 20:10:20 +0000 Subject: [issue24467] bytearray pop and remove Buffer Over-read In-Reply-To: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za> Message-ID: <1434744620.38.0.884986756971.issue24467@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 19 22:15:39 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 19 Jun 2015 20:15:39 +0000 Subject: [issue24475] The docs never define what a pool "task" is In-Reply-To: <1434733537.74.0.146405679971.issue24475@psf.upfronthosting.co.za> Message-ID: <1434744939.56.0.954225557258.issue24475@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +davin, sbt versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 00:04:06 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 19 Jun 2015 22:04:06 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434751446.19.0.0401880166153.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: Actually, I'm not sure that we should use 'cr_*' prefix instead of 'gi_*' for coroutines. Coroutines reusing generators machinery is a two-fold thing: on the one hand it makes the implementation simpler; on the other -- __await__ must return an *iterator*. If you want to push values into __await__, it must return a *generator*. Essentially, as Guido said in one of his emails, we should see PEP 492 as a refinement of 'yield from' and existing generator-based coroutines. I love the idea of separating types for coroutines and generators, but I'm not so sure about 'cr_*' prefix. Nick, Guido, what do you think about this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 00:16:50 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 19 Jun 2015 22:16:50 +0000 Subject: [issue24412] setUpClass equivalent for addCleanup In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za> Message-ID: <1434752210.08.0.760533296837.issue24412@psf.upfronthosting.co.za> R. David Murray added the comment: As further motivation, I actually tried to implement this using try/except. First I wrote a loop in tearDownClass that ran each of the cleanups inside a try/except and printed the exception if there was one. But of course that doesn't run if setUpClass fails. So I started to add a similar try/except loop in setUpClass...and then realized that in order to have the cleanups run correctly, I needed to add each cleanup to a list on the class if and only if the corresponding setup succeeded, and then run only those cleanups in the tearDownClass. So, I ended up implementing addClassCleanup. However, in order to make it generic (I have two classes where I need it currently, and will probably be adding more), I have a base class with setUpClass that calls a safeSetUpClass inside a try/except, my safeSetUpClass on the actual test class does the setup and calls to addClassCleanUp, and my tearDownClass does the loop over the accumulated cleanups. So, yeah, it would be really handy to have this as an actual feature :) ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 00:33:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 19 Jun 2015 22:33:02 +0000 Subject: [issue24412] setUpClass equivalent for addCleanup In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za> Message-ID: <1434753182.43.0.699628635151.issue24412@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: contextlib.ExitStack could help you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 00:48:31 2015 From: report at bugs.python.org (Elizabeth Myers) Date: Fri, 19 Jun 2015 22:48:31 +0000 Subject: [issue23749] asyncio missing wrap_socket In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1434754111.08.0.55335784021.issue23749@psf.upfronthosting.co.za> Elizabeth Myers added the comment: After giving this a look over, I think this is over my head. Sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 00:50:16 2015 From: report at bugs.python.org (levkivskyi) Date: Fri, 19 Jun 2015 22:50:16 +0000 Subject: [issue24129] Incorrect (misleading) statement in the execution model documentation In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za> Message-ID: <1434754216.06.0.776422121577.issue24129@psf.upfronthosting.co.za> levkivskyi added the comment: Eric, thank you for the review. I have incorporated proposed changes in second version of the patch. Concerning the question whether it is a bug, it also smells like a bug to me, but Guido said 13 years ago that this should not be changed: https://mail.python.org/pipermail/python-dev/2002-April/023428.html and it stayed like this since then. However, things changed a bit in Python 3.4 with the introduction of the LOAD_CLASSDEREF opcode. Perhaps, we should ask Guido again :) What do you think? ---------- Added file: http://bugs.python.org/file39744/classdoc_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 00:51:12 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 19 Jun 2015 22:51:12 +0000 Subject: [issue24412] setUpClass equivalent for addCleanup In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za> Message-ID: <1434754272.95.0.44139150654.issue24412@psf.upfronthosting.co.za> R. David Murray added the comment: That would not make it simpler. In fact it would make the test code more complex. I'd still need the safeSetUpClass dodge (or repeat the try/except/log in every setUpClass method), and I'd have to have a wrapper function that I passed each cleanup to as an argument to wrap it in a try/except/log, since close would just propagate the exceptions. I think implementing this parallel to addCleanUp is much cleaner, even if the feature isn't (yet :) in the stdlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 01:18:56 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 19 Jun 2015 23:18:56 +0000 Subject: [issue24129] Incorrect (misleading) statement in the execution model documentation In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za> Message-ID: <1434755936.93.0.501794140707.issue24129@psf.upfronthosting.co.za> Eric Snow added the comment: I expect you'll get the same response, especially given potential (though slight) chance for backward-compatibility issues. What I find curious is Guido's reference to "the rule that class bodies don't play the nested scopes game" (and his subsequent explanation). Is there something about that in the language reference? If so, the patch should be updated to link to that section. If not then it should be added to the language reference. That said, it wouldn't hurt to ask on python-dev, particularly in light of that new opcode. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 02:52:43 2015 From: report at bugs.python.org (py.user) Date: Sat, 20 Jun 2015 00:52:43 +0000 Subject: [issue24477] In argparse subparser's option goes to parent parser Message-ID: <1434761563.1.0.609201116133.issue24477@psf.upfronthosting.co.za> New submission from py.user: Some misleading behaviour found with option belonging. It's possible to put one option twicely, so it can set different parameters accoding to context. A source of argt.py for test: #!/usr/bin/env python3 import argparse parser = argparse.ArgumentParser() parser.add_argument('-f', dest='tf', action='store_true') subs = parser.add_subparsers() sub = subs.add_parser('cmd') sub.add_argument('-f', dest='cf', action='store_true') parser.add_argument('arg') args = parser.parse_args() print(args) Running it: [guest at localhost debug]$ ./argt.py cmd 1 Namespace(arg='1', cf=False, tf=False) [guest at localhost debug]$ ./argt.py cmd -f 1 Namespace(arg='1', cf=True, tf=False) [guest at localhost debug]$ ./argt.py cmd 1 -f Namespace(arg='1', cf=False, tf=True) [guest at localhost debug]$ ISTM, options for the top parser should be placed between program name and subcommand name in any order, and options for the subcommand should follow subcommand in any order. The argument of top parser should be moved to the end and parsed after all options were placed correctly. ---------- components: Library (Lib) messages: 245536 nosy: py.user priority: normal severity: normal status: open title: In argparse subparser's option goes to parent parser type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 03:29:19 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 20 Jun 2015 01:29:19 +0000 Subject: [issue24460] urlencode() of dictionary not as expected In-Reply-To: <1434523722.13.0.839663684524.issue24460@psf.upfronthosting.co.za> Message-ID: <1434763759.4.0.0553450565888.issue24460@psf.upfronthosting.co.za> Martin Panter added the comment: 1. urlencode(): I agree the documentation is unclear. But David Rueter?s suggestion does not help much. I think doseq=True is meant to also work for a mapping query (as in original post), and is not required in the sequence-of-tuples mode if each tuple has a single parameter value. Perhaps something like this could work instead: ?When a sequence of two-element tuples is used as *query*, the first element of each tuple is a key and the second specifies one or more values. If *doseq* is true, each *query* (mapping or sequence) item can specify a sequence of values; if *doseq* is false (the default), each item specifies a single value. The order of parameters in the encoded string will match the order of items in *query* and the order of values in an item.? 2. urlopen(data=...) and Request(data=...): I don?t see the contradiction. It looks like David Rueter?s suggestion only changes the first sentence, to say doseq=True is required to get the urlencoded format, but this is not required. See also Issue 23360 about my own problems with this bit of the documentation. 3. Examples: Again, I do not see why doseq=True should be shown when it is simpler without. But an example of when it is useful would be good, as R David Murray suggested. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 03:44:28 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 20 Jun 2015 01:44:28 +0000 Subject: [issue19613] test_nntplib: sporadic failures, test_article_head_body() In-Reply-To: <1384536645.9.0.862907413915.issue19613@psf.upfronthosting.co.za> Message-ID: <1434764668.27.0.21497688388.issue19613@psf.upfronthosting.co.za> Martin Panter added the comment: The timed out case seems to be similar to Issue 19756. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 03:58:59 2015 From: report at bugs.python.org (Rose Ames) Date: Sat, 20 Jun 2015 01:58:59 +0000 Subject: [issue24370] OrderedDict behavior is unclear with misbehaving keys. In-Reply-To: <1433300480.06.0.538096094872.issue24370@psf.upfronthosting.co.za> Message-ID: <1434765539.04.0.880577700079.issue24370@psf.upfronthosting.co.za> Changes by Rose Ames : ---------- nosy: +superluser _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 04:06:13 2015 From: report at bugs.python.org (Rose Ames) Date: Sat, 20 Jun 2015 02:06:13 +0000 Subject: [issue24468] Expose compiler flag constants as code object attributes In-Reply-To: <1434689253.89.0.431597909643.issue24468@psf.upfronthosting.co.za> Message-ID: <1434765973.12.0.612649111562.issue24468@psf.upfronthosting.co.za> Changes by Rose Ames : ---------- nosy: +superluser _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 04:24:34 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 20 Jun 2015 02:24:34 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434767074.28.0.866818745201.issue24400@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file39745/corotype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 05:54:58 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 20 Jun 2015 03:54:58 +0000 Subject: [issue24408] tkinter.font.Font.measure() broken in 3.5 In-Reply-To: <1433769737.94.0.512429608997.issue24408@psf.upfronthosting.co.za> Message-ID: <1434772498.28.0.0879293726596.issue24408@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch to decouple the families() and Font.actual("family") tests as I suggested. Ned, can you confirm if this works on the failing OS X setup? I expect it should be fine. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file39746/families.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 07:24:11 2015 From: report at bugs.python.org (Tal Einat) Date: Sat, 20 Jun 2015 05:24:11 +0000 Subject: [issue24412] setUpClass equivalent for addCleanup In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za> Message-ID: <1434777851.97.0.250422689469.issue24412@psf.upfronthosting.co.za> Tal Einat added the comment: I'm convinced. +1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 07:32:06 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 20 Jun 2015 05:32:06 +0000 Subject: [issue24468] Expose C level compiler flag constants to Python code In-Reply-To: <1434689253.89.0.431597909643.issue24468@psf.upfronthosting.co.za> Message-ID: <1434778326.38.0.894211219238.issue24468@psf.upfronthosting.co.za> Nick Coghlan added the comment: Bringing a design discussion back from the code review, since I didn't explain the problem to be solved very well, and instead jumped straight to recommending a specific solution. Currently, dis has a dictionary mapping from hardcoded compiler flag values (in decimal, no less!) to flag names. The inspect module then iterates over this dictionary at import time to publish the CO_* constants as module level attributes in inspect. Neither dis.COMPILER_FLAG_NAMES nor the inspect.CO_* constants are documented, and the *C* level flag values aren't published to the Python layer anywhere (hence the hardcoding of the magic numbers in dis). For the kind of code that needs to interrogate the flags in the issue 24400 patch, inspect and dis are also not appropriate things to adopt as dependencies. However, I like Larry's suggestion of adopting the _opcode module as our standard vector for passing this information up from the C layer to the Python layer better than my original idea of using code objects themselves. The opcode values themselves could potentially also be exposed that way (they're currently duplicated by hand in Lib/opcode.py). ---------- title: Expose compiler flag constants as code object attributes -> Expose C level compiler flag constants to Python code _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 08:25:51 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 20 Jun 2015 06:25:51 +0000 Subject: [issue20344] subprocess.check_output() docs misrepresent what shell=True does In-Reply-To: <1390400705.04.0.503333173013.issue20344@psf.upfronthosting.co.za> Message-ID: <1434781551.42.0.507283620628.issue20344@psf.upfronthosting.co.za> Martin Panter added the comment: I think it might be better to leave the platform-specific details in the full Popen description, not under Frequently Used Arguments. I suggest to use 20344_4.patch: * Move existing pointer to Popen constructor details up to top of section * Explain the escaping and quoting of a sequence only applies to Windows * Remove claim that a string simply names a program without arguments; appears to be only half true under Windows * Clarify shell=True command is normally a string, not a sequence * Drop new description of Unix shell argument sequence in favour of existing description under Popen * Move warning about Windows shell argument sequence under Popen ---------- stage: needs patch -> patch review versions: +Python 3.5, Python 3.6 -Python 3.3 Added file: http://bugs.python.org/file39747/20344_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 08:28:35 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 20 Jun 2015 06:28:35 +0000 Subject: [issue24474] Accidental exception chaining in inspect.Signature.bind() In-Reply-To: <1434730589.67.0.681224722356.issue24474@psf.upfronthosting.co.za> Message-ID: <1434781715.44.0.885055665732.issue24474@psf.upfronthosting.co.za> Nick Coghlan added the comment: This isn't a bug, as "raise exc from None" only hides *display* of the context, it doesn't lose the record of the context entirely. This means Walter's display code is incorrect, as it isn't checking for __suppress_context__: >>> import inspect >>> try: ... inspect.signature(lambda x:None).bind() ... except Exception as e: ... exc = e ... >>> exc.__suppress_context__ True Interestingly, neither PEP 409 *nor* PEP 415 capture the rationale for that design: retaining the full context data even when it's hidden by the default exception display routines means that you can still debug code that uses "raise X from None" inappropriately. (I thought there was an open RFE to make it easy to force the traceback module to ignore __suppress_context__ but if there is one, I can't find it) ---------- resolution: -> not a bug stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 08:53:13 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 20 Jun 2015 06:53:13 +0000 Subject: [issue24370] OrderedDict behavior is unclear with misbehaving keys. In-Reply-To: <1433300480.06.0.538096094872.issue24370@psf.upfronthosting.co.za> Message-ID: <1434783193.45.0.0031757963394.issue24370@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I would expect the behavior to be undefined (though non-crashing). That is all you should expect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 09:02:57 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 20 Jun 2015 07:02:57 +0000 Subject: [issue24129] Incorrect (misleading) statement in the execution model documentation In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za> Message-ID: <1434783777.11.0.762876377533.issue24129@psf.upfronthosting.co.za> Nick Coghlan added the comment: The "normal rules for name resolution" reference here is referring to the name lookup rules as they existed prior to the introduction of lexical scoping for functions. It's a dated way of describing it, as the current behaviour of functions has now been around long enough that a lot of folks will consider *that* normal, and the module, class and exec scoping rules to be the unusual case (as levkivskyi has here). However, I've spent far too many hours staring at CPython compiler internals to be able to suggest a helpful rewording that will make sense to folks that *haven't* done that, so I'll instead provide the relevant background info to see if others can come up with a concise rewording of the reference docs :) Prior to Python 2.1, Python didn't have closure support, and hence nested functions and classes couldn't see variables in outer scopes at all - they could see their local scope, the module globals, and the builtins. That changed with the introduction of nested scopes as a __future__ import in Python 2.1 and the default behaviour in 2.2: https://www.python.org/dev/peps/pep-0227/ As a result of that change, the compiler now keeps track of "function locals" at compile time, and *emits different code for references to them*. Where early versions of CPython only had LOAD_NAME and LOAD_GLOBAL in the bytecode, these days we now also have LOAD_FAST (function local), LOAD_CLOSURE (function local referenced as a nonlocal), LOAD_DEREF (function nonlocal) and LOAD_CLASSDEREF (class nonlocal). The latter four opcodes will *only* be emitted in a function body - they'll never be emitted for module level code (include the bodies of module level class definitions). If you attempt to reference a function local before a value has been assigned, you'll get UnboundLocalError rather than NameError. The name lookup rules used for execution of class bodies are thus the same ones used for the exec() builtin with two namespace arguments: there is a local namespace where name assignments happen, and name lookups check the local, global and builtin namespaces in that order. The code is executed line by line, so if a name is referenced before it has been assigned locally, then it may find a global or builtin of that name. Classes that are defined inside a function may refer to lexically scoped local variables from the class body, but class variables are not themselves visible to function definitions nested inside a class scope (i.e. method definitions). These rules are also used for module level execution and exec() with a single namespace argument, except that the local namespace and the global namespace refer to the same namespace. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 09:10:26 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 20 Jun 2015 07:10:26 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1434784226.54.0.961387288542.issue21279@psf.upfronthosting.co.za> Martin Panter added the comment: Patch v6 looks okay, so I think it is ready to commit. ---------- stage: patch review -> commit review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 09:13:46 2015 From: report at bugs.python.org (Dingyuan Wang) Date: Sat, 20 Jun 2015 07:13:46 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <1434784426.71.0.297913391897.issue20387@psf.upfronthosting.co.za> Dingyuan Wang added the comment: Sorry for the inconvenience. I failed to find this old bug. I think there is another problem. The docs of `untokenize` said "The iterable must return sequences with **at least** two elements, the token type and the token string. Any additional sequence elements are ignored.", so if I feed in, say, a 3-tuple, the untokenize should accept it as tok[:2]. The attached patch should have addressed the problems above. When trying to make a patch, a tokenize bug was found. Consider the new attached tab.py, the tabs between comments and code, and the tabs between expressions are lost, so when untokenizing, position information is used to produce equivalent spaces, instead of tabs. Despite the tokenization problem, the patch can produce syntactically correct code as accurately as it can. The PEP 8 recommends spaces for indentation, but the usage of tabs should not be ignored. new tab.py (in Python string): '#!/usr/bin/env python\n# -*- coding: utf-8 -*-\n\ndef foo():\n\t"""\n\tTests tabs in tokenization\n\t\tfoo\n\t"""\n\tpass\n\tpass\n\tif 1:\n\t\t# not indent correctly\n\t\tpass\n\t\t# correct\ttab\n\t\tpass\n\tpass\n\tbaaz = {\'a\ttab\':\t1,\n\t\t\t\'b\': 2}\t\t# also fails\n\npass\n#if 2:\n\t#pass\n#pass\n' ---------- keywords: +patch nosy: +gumblex Added file: http://bugs.python.org/file39748/tokenize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 09:14:09 2015 From: report at bugs.python.org (levkivskyi) Date: Sat, 20 Jun 2015 07:14:09 +0000 Subject: [issue24129] Incorrect (misleading) statement in the execution model documentation In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za> Message-ID: <1434784449.21.0.645004703882.issue24129@psf.upfronthosting.co.za> levkivskyi added the comment: Eric, the "rule" that classes don't play the nested scopes game is explained at beginning of the same section, but the explanation is "one sided" it only explains that names defined in classes are not visible inside functions. Nick, thank you for the thorough explanation. I will try to improve the wording. It looks like a bit more substantial changes are needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 09:31:58 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 20 Jun 2015 07:31:58 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434785518.05.0.881076261015.issue24400@psf.upfronthosting.co.za> Nick Coghlan added the comment: My view is that the "gi_*" prefixed attributes are the ducktyped representation of whether an object is a generator-iterator or a coroutine. With the change, it means "hasattr(obj, 'cr_running')" is to "hasattr(obj, 'gi_running') as "isinstance(obj, collections.abc.Coroutine)" is to "isinstance(obj, collections.abc.Generator)". The main lesson I personally learned from our experience with PEP 342 is that generator-as-iterator and generator-as-coroutine are fundamentally different concepts, and that having them *look* similar on the surface turned out to be inherently confusing. I see PEP 492 as the natural consequence of that perspective: from an eval loop perspective, native coroutines and generators-as-coroutines remain essentially interchangeable, but on the surface, they'll now look *completely* different. That allows folks to learn them as two distinct concepts (generator-iterator and coroutine), and defer (perhaps indefinitely) the realisation that they share a common underlying foundation. Originally we were happy to let that distinction be purely syntactic, and still let the underlying implementation details leak through in the object model. This issue helped highlight that that approach was likely to prove to be a recipe for hard to debug problems as we tried to figure out where we were dealing with generator-iterator objects, native coroutine objects and generator-as-coroutine objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 09:34:41 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 20 Jun 2015 07:34:41 +0000 Subject: [issue24474] Accidental exception chaining in inspect.Signature.bind() In-Reply-To: <1434730589.67.0.681224722356.issue24474@psf.upfronthosting.co.za> Message-ID: <1434785681.43.0.107211761788.issue24474@psf.upfronthosting.co.za> Yury Selivanov added the comment: > This isn't a bug, as "raise exc from None" only hides *display* of the context, it doesn't lose the record of the context entirely. Agree. My patch, though, is still valid. I think removing try..except blocks actually simplifies the code, and removes the need of using 'raise .. from None' completely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 09:38:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 20 Jun 2015 07:38:54 +0000 Subject: [issue24478] asyncio: segfault in test_env_var_debug() on non-debug Windows buildbot Message-ID: <1434785934.32.0.696273570884.issue24478@psf.upfronthosting.co.za> New submission from STINNER Victor: It looks like buildbot slave crashs since: http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/23 or http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/22 Changes: changeset a1b76c1c3be8409565af71b02b84685233276120 ====================================================================== FAIL: test_env_var_debug (test.test_asyncio.test_base_events.BaseEventLoopTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "B:\buildarea\3.x.ware-win81-release\build\lib\test\test_asyncio\test_base_events.py", line 680, in test_env_var_debug PYTHONASYNCIODEBUG='') File "B:\buildarea\3.x.ware-win81-release\build\lib\test\support\script_helper.py", line 135, in assert_python_ok return _assert_python(True, *args, **env_vars) File "B:\buildarea\3.x.ware-win81-release\build\lib\test\support\script_helper.py", line 121, in _assert_python err)) AssertionError: Process return code is 3221225477 command line: ['B:\\buildarea\\3.x.ware-win81-release\\build\\PCbuild\\amd64\\python.exe', '-X', 'faulthandler', '-c', 'import asyncio\nloop = asyncio.get_event_loop()\nprint(loop.get_debug())'] stdout: --- --- stderr: --- Fatal Python error: Segmentation fault Current thread 0x00000390 (most recent call first): File "B:\buildarea\3.x.ware-win81-release\build\lib\functools.py", line 423 in decorating_function File "B:\buildarea\3.x.ware-win81-release\build\lib\ipaddress.py", line 1963 in IPv6Address File "B:\buildarea\3.x.ware-win81-release\build\lib\ipaddress.py", line 1869 in File "", line 222 in _call_with_frames_removed File "", line 661 in exec_module File "", line 673 in _load_unlocked File "", line 958 in _find_and_load_unlocked File "", line 969 in _find_and_load File "B:\buildarea\3.x.ware-win81-release\build\lib\ssl.py", line 90 in File "", line 222 in _call_with_frames_removed File "", line 661 in exec_module File "", line 673 in _load_unlocked File "", line 958 in _find_and_load_unlocked File "", line 969 in _find_and_load File "B:\buildarea\3.x.ware-win81-release\build\lib\asyncio\sslproto.py", line 5 in File "", line 222 in _call_with_frames_removed File "", line 661 in exec_module File "", line 673 in _load_unlocked File "", line 958 in _find_and_load_unlocked File "", line 969 in _find_and_load File "", line 222 in _call_with_frames_removed File "", line 1016 in _handle_fromlist File "B:\buildarea\3.x.ware-win81-release\build\lib\asyncio\proactor_events.py", line 16 in File "", line 222 in _call_with_frames_removed File "", line 661 in exec_module File "", line 673 in _load_unlocked File "", line 958 in _find_and_load_unlocked File "", line 969 in _find_and_load File "", line 222 in _call_with_frames_removed File "", line 1016 in _handle_fromlist File "B:\buildarea\3.x.ware-win81-release\build\lib\asyncio\windows_events.py", line 13 in File "", line 222 in _call_with_frames_removed File "", line 661 in exec_module File "", line 673 in _load_unlocked File "", line 958 in _find_and_load_unlocked File "", line 969 in _find_and_load File "B:\buildarea\3.x.ware-win81-release\build\lib\asyncio\__init__.py", line 46 in File "", line 222 in _call_with_frames_removed File "", line 661 in exec_module File "", line 673 in _load_unlocked File "", line 958 in _find_and_load_unlocked File "", line 969 in _find_and_load File "", line 1 in --- ---------- components: Windows, asyncio messages: 245551 nosy: gvanrossum, haypo, paul.moore, steve.dower, tim.golden, yselivanov, zach.ware priority: normal severity: normal status: open title: asyncio: segfault in test_env_var_debug() on non-debug Windows buildbot versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 10:03:29 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 20 Jun 2015 08:03:29 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434787409.59.0.0563805960118.issue24400@psf.upfronthosting.co.za> Nick Coghlan added the comment: Based on that last comment, I realised there's something else @types.coroutine should now do: delegate both the existing gi_* attributes *and* the new cr_* attributes to the underlying generator. That should allow all of the poking around in code object flags to be encapsulated entirely in the types module, as the 3 kinds of object would subsequently be distinguishable by their attributes: gi_running: generator-iterator or generator-as-coroutine cr_running: native coroutine or generator-as-coroutine both: generator-as-coroutine ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 10:17:40 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 20 Jun 2015 08:17:40 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434788260.5.0.959920692201.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: OK, let's go with cr_* prefix for coroutine type's slots. Nick, there is one more thing I'd be glad to receive your input on. Currently, inspect.iscoroutine(o) uses isinstance(o, abc.Coroutine) to do the check. Ben and Stefan reasonably ask to refactor isgenerator() to use abc.Generator. However, after giving this some thought, I think that inspect.iscoroutine() should actually use isinstance(types.CoroutineType). Lots of existing code assumes, that if isgenerator() returns True, then the object has gi_code etc, so the function returns True when the passed object is a pure Python generator. Same logic should work for iscoroutine(), right? isawaitable(), however, should continue using abc.Awaitable, since it only checks for __await__ presence on the type (or should we just drop it?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 10:24:30 2015 From: report at bugs.python.org (Armin Rigo) Date: Sat, 20 Jun 2015 08:24:30 +0000 Subject: [issue24129] Incorrect (misleading) statement in the execution model documentation In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za> Message-ID: <1434788670.41.0.786904910717.issue24129@psf.upfronthosting.co.za> Armin Rigo added the comment: Related to http://bugs.python.org/issue19979 and others mentioned there. ---------- nosy: +arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 10:50:59 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 20 Jun 2015 08:50:59 +0000 Subject: [issue24474] Accidental exception chaining in inspect.Signature.bind() In-Reply-To: <1434730589.67.0.681224722356.issue24474@psf.upfronthosting.co.za> Message-ID: <1434790259.54.0.895102285811.issue24474@psf.upfronthosting.co.za> Nick Coghlan added the comment: The sentinel form of next() is nice when there's a natural sentinel value, but needing to *create* a sentinel is generally a sign that the out-of-band exception is a better fit. The function could likely do with some refactoring (e.g. breaking out some helper functions to make the logic easier to follow), but shifting from idiomatic code to non-idiomatic code isn't a good way of tackling that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 12:18:22 2015 From: report at bugs.python.org (Andreas Nilsson) Date: Sat, 20 Jun 2015 10:18:22 +0000 Subject: [issue24479] Support LMMS project files in mimetypes.guess_type Message-ID: <1434795502.53.0.948243693094.issue24479@psf.upfronthosting.co.za> New submission from Andreas Nilsson: There is no support for recognizing LMMS project files (.mmpz / .mmp). Could this be added for strict=False? ---------- components: Library (Lib) messages: 245556 nosy: Andreas Nilsson priority: normal severity: normal status: open title: Support LMMS project files in mimetypes.guess_type type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 12:46:01 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 20 Jun 2015 10:46:01 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434797161.37.0.690255062917.issue24400@psf.upfronthosting.co.za> Nick Coghlan added the comment: I believe the key issue of concern for Cython is being able to emulate the native CPython types in a way that things like asyncio "just work", rather than specifically needing to have inspect report them as native generators and coroutines. As such, having inspect.isgenerator() and inspect.iscoroutine() be consistent in checking specifically for the *native* types makes sense to me, but it should be made clear that they're stricter checks than "isinstance(obj, collections.abc.Generator)" and "isinstance(obj, collections.abc.Coroutine)". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 13:01:47 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 20 Jun 2015 11:01:47 +0000 Subject: [issue19979] Missing nested scope vars in class scope (bis) In-Reply-To: <1386970277.4.0.799872209267.issue19979@psf.upfronthosting.co.za> Message-ID: <1434798107.27.0.0357174570272.issue19979@psf.upfronthosting.co.za> Nick Coghlan added the comment: With the fact that the existence of "Python without closures" predates Python 2.2, this now reads like a straight up compiler bug to me. Compare the behaviour with no local assignment in the class body: >>> def f(): ... n = 1 ... class C: ... print(n) ... >>> f() 1 To the behaviour once the local is assigned: >>> def f(): ... n = 1 ... class C: ... n = n ... print(n) ... >>> f() Traceback (most recent call last): File "", line 1, in File "", line 3, in f File "", line 4, in C NameError: name 'n' is not defined The issue is that the latter will still emit a LOAD_NAME/STORE_NAME pair, while the former emits LOAD_CLASSDEREF (and has emitted LOAD_DEREF for as long as I can recall hacking on the compiler). Off the top of my head, I'm not sure our current symbol table analysis pass can actually cope with this idea though - it would require separating "just a class body local, which may or may not first be retrieved as a global or builtin" from "a class body local which is first retrieved from a closure reference". ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 14:00:48 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 20 Jun 2015 12:00:48 +0000 Subject: [issue14911] generator.throw() documentation inaccurate In-Reply-To: <1337943736.85.0.146138312281.issue14911@psf.upfronthosting.co.za> Message-ID: <1434801648.68.0.699010370724.issue14911@psf.upfronthosting.co.za> Martin Panter added the comment: See Issue 13213 for some analysis of the behaviour of different combinations of arguments. The docstring should be changed if necessary, but in this case I don?t see what needs changing. The argument names perhaps, just for consistency?s sake? ---------- nosy: +vadmium versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 14:02:41 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 20 Jun 2015 12:02:41 +0000 Subject: [issue13213] generator.throw() behavior In-Reply-To: <1318961803.9.0.966531589594.issue13213@psf.upfronthosting.co.za> Message-ID: <1434801761.05.0.611611182476.issue13213@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> generator.throw() documentation inaccurate _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 14:50:44 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 20 Jun 2015 12:50:44 +0000 Subject: [issue10482] subprocess and deadlock avoidance In-Reply-To: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za> Message-ID: <1434804644.09.0.120718464045.issue10482@psf.upfronthosting.co.za> Martin Panter added the comment: Related: Issue 1260171, essentially proposing streaming readers and writers for communicate() instead of fixed buffers, but without using OS threads. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 15:34:54 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 20 Jun 2015 13:34:54 +0000 Subject: [issue24478] asyncio: segfault in test_env_var_debug() on non-debug Windows buildbot In-Reply-To: <1434785934.32.0.696273570884.issue24478@psf.upfronthosting.co.za> Message-ID: <1434807294.66.0.097199378456.issue24478@psf.upfronthosting.co.za> Zachary Ware added the comment: Note that it's not necessarily that changeset; I think build 22 is around when the buildbot started actually doing non-debug builds (the buildmaster and buildslave scripts in Tools/buildbot had no support for a non-debug build before then). I'll try to run the tests a little further back soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 15:37:44 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 20 Jun 2015 13:37:44 +0000 Subject: [issue4322] function with modified __name__ uses original name when there's an arg error In-Reply-To: <1226645058.7.0.820357853432.issue4322@psf.upfronthosting.co.za> Message-ID: <1434807464.44.0.329152521157.issue4322@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 15:55:42 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sat, 20 Jun 2015 13:55:42 +0000 Subject: [issue24129] Incorrect (misleading) statement in the execution model documentation In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za> Message-ID: <1434808542.24.0.0130776914893.issue24129@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Eric, I have submitted a new version of the patch. Could you please make a review? Nick, it will be interesting to hear your opinion too. I tried to follow such rules: 1. Explanation should be succinct yet clear 2. It should tell as less as possible about implementation details 3. Minimize necessary changes It turns out that these goals could be achieved by a) simply reshuffling and structuring the existing text to separate the exceptions (classes, etc.) from the general case; and b) adding some minor clarifications. Armin, thank you for the link. It looks like this is a really old discussion. PS: Unfortunately, the diff after reshuffling of the text looks big and cumbersome, in fact the changes are minimal. ---------- Added file: http://bugs.python.org/file39749/classdoc-v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 17:14:02 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 20 Jun 2015 15:14:02 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <1434813242.52.0.789223543845.issue20387@psf.upfronthosting.co.za> Jason R. Coombs added the comment: @gumblex: This is a good start. It certainly provides a candidate implementation. First, can I suggest that you remove the changes pertinent to the "at least two elements" and address that in a separate ticket/discussion? Second, any patch will necessarily need to include a test that fails before the patch and passes after the test. Third, and least important, the proposed implementation adds a lot of branching and cognitive complexity to an already complicated function. I'd like to work on the implementation to see if we can make it easier to comprehend. That said, practicality beats purity, so if it passes the test, then it's surely acceptable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 18:11:46 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 20 Jun 2015 16:11:46 +0000 Subject: [issue24306] Backport py.exe to 3.4 In-Reply-To: <1432771856.97.0.606443218974.issue24306@psf.upfronthosting.co.za> Message-ID: <1434816706.79.0.639603025759.issue24306@psf.upfronthosting.co.za> Steve Dower added the comment: Attached a patch to set the component IDs in the 3.4 installer to match the ones we're using for 3.5 and later. This should prevent downgrading of the launcher in future releases, though it's not strictly the "right" way to do this. (Nosied Martin in case he wants to weigh in on this.) (The right way is to have a separate MSI with a matching upgrade code, which is not feasible for 3.4.) Unfortunately, it won't help when 3.5 is installed per-user (the default), but there's nothing we can do there short of backporting the launcher changes, probably selectively to avoid the fixes for the VC10->14 change. (Nosied Larry to see if he wants to approve this.) ---------- keywords: +patch nosy: +larry, loewis Added file: http://bugs.python.org/file39750/24306_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 18:16:38 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 20 Jun 2015 16:16:38 +0000 Subject: [issue24478] asyncio: segfault in test_env_var_debug() on non-debug Windows buildbot In-Reply-To: <1434785934.32.0.696273570884.issue24478@psf.upfronthosting.co.za> Message-ID: <1434816998.57.0.37361983508.issue24478@psf.upfronthosting.co.za> Steve Dower added the comment: Presumably it's from the C implementation of lru cache ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 18:27:45 2015 From: report at bugs.python.org (Yunlong Liu) Date: Sat, 20 Jun 2015 16:27:45 +0000 Subject: [issue24480] Python 2.7.10 Message-ID: <1434817665.64.0.647960324638.issue24480@psf.upfronthosting.co.za> New submission from Yunlong Liu: Hi, I detected an inconsistency in the Modules stack of Python 2.7.10. In Module/_ssl.c, I see all _ssl._SSLContext are changed to ssl.SSLContext but it is inconsistent with the lib file in Lib/ssl.py. In ssl.py, it is still importing _SSLContext, which doesn't exist in the C file. ---------- components: Library (Lib) messages: 245566 nosy: yliu120 priority: normal severity: normal status: open title: Python 2.7.10 type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 18:36:22 2015 From: report at bugs.python.org (Yunlong Liu) Date: Sat, 20 Jun 2015 16:36:22 +0000 Subject: [issue24480] Python 2.7.10 In-Reply-To: <1434817665.64.0.647960324638.issue24480@psf.upfronthosting.co.za> Message-ID: <1434818182.47.0.736719325185.issue24480@psf.upfronthosting.co.za> Yunlong Liu added the comment: I have seen this has been corrected in the svn python chunk. But I doubt it is still there in the public download tar ball. Please make a change to the tar ball. Thanks ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 20:52:19 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 20 Jun 2015 18:52:19 +0000 Subject: [issue24306] Backport py.exe to 3.4 In-Reply-To: <1432771856.97.0.606443218974.issue24306@psf.upfronthosting.co.za> Message-ID: <1434826339.41.0.704024191444.issue24306@psf.upfronthosting.co.za> Larry Hastings added the comment: "Last installed wins" isn't perfect, but at least it's predictable. Is it possible to make the 3.4 installer detect that 3.5+ is installed and not install the launcher? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 21:32:00 2015 From: report at bugs.python.org (JohnLeitch) Date: Sat, 20 Jun 2015 19:32:00 +0000 Subject: [issue24462] bytearray.find Buffer Over-read In-Reply-To: <1434551199.93.0.25363766054.issue24462@psf.upfronthosting.co.za> Message-ID: <1434828720.62.0.578002103746.issue24462@psf.upfronthosting.co.za> JohnLeitch added the comment: Given my understanding of the issue, the memcmp approach seems like a viable fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 21:39:02 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 20 Jun 2015 19:39:02 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434829142.04.0.504563293708.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, Martin, here's an updated patch with all your comments addressed. ---------- Added file: http://bugs.python.org/file39751/corotype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 21:39:53 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 20 Jun 2015 19:39:53 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1434829193.8.0.254333962082.issue24017@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- dependencies: +Awaitable ABC incompatible with functools.singledispatch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 21:42:03 2015 From: report at bugs.python.org (=?utf-8?q?Crist=C3=B3bal_Ganter?=) Date: Sat, 20 Jun 2015 19:42:03 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1434829323.14.0.761241828506.issue15753@psf.upfronthosting.co.za> Crist?bal Ganter added the comment: I have the same question as Josh Rosenberg. Also, do you know any workarounds for this problem? ---------- nosy: +Crist?bal Ganter versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 22:11:15 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 20 Jun 2015 20:11:15 +0000 Subject: [issue24306] Backport py.exe to 3.4 In-Reply-To: <1432771856.97.0.606443218974.issue24306@psf.upfronthosting.co.za> Message-ID: <1434831075.88.0.523262479361.issue24306@psf.upfronthosting.co.za> Steve Dower added the comment: The current patch should do that for all-user installs of 3.5, but those aren't the default. There's no sensible way to detect per-user installs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 22:37:25 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 20 Jun 2015 20:37:25 +0000 Subject: [issue24468] Expose C level compiler flag constants to Python code In-Reply-To: <1434689253.89.0.431597909643.issue24468@psf.upfronthosting.co.za> Message-ID: <1434832645.74.0.900331709361.issue24468@psf.upfronthosting.co.za> Yury Selivanov added the comment: Larry, Nick, Attached patch exposes CO* constants in the '_opcode' module. There is one slight complication though: importing '_opcode' in 'types' (required for issue24400) breaks Python compilation, as 'types' module is used by many tools at the point where '_opcode' module isn't yet compiled. We should either make '_opcode' compiled earlier or move constants to the 'sys' module. ---------- Added file: http://bugs.python.org/file39752/opcode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 22:40:47 2015 From: report at bugs.python.org (JohnLeitch) Date: Sat, 20 Jun 2015 20:40:47 +0000 Subject: [issue24481] hotspot pack_string Heap Buffer Overflow Message-ID: <1434832847.29.0.0777461609837.issue24481@psf.upfronthosting.co.za> New submission from JohnLeitch: The hotspot module suffer from a heap buffer overflow due to a memcpy in the pack_string function at line 633: static int pack_string(ProfilerObject *self, const char *s, Py_ssize_t len) { if (len + PISIZE + self->index >= BUFFERSIZE) { if (flush_data(self) < 0) return -1; } assert(len < INT_MAX); if (pack_packed_int(self, (int)len) < 0) return -1; memcpy(self->buffer + self->index, s, len); self->index += len; return 0; } The problem arises because const char *s is variable length, while ProfilerObject.buffer is fixed-length: typedef struct { PyObject_HEAD PyObject *filemap; PyObject *logfilename; Py_ssize_t index; unsigned char buffer[BUFFERSIZE]; FILE *logfp; int lineevents; int linetimings; int frametimings; /* size_t filled; */ int active; int next_fileno; hs_time prev_timeofday; } ProfilerObject; An overflow can be triggered by passing a large string to the Profile.addinfo method via the value parameter: from hotshot.stats import * x = hotshot.Profile("A", "A") x.addinfo("A", "A" * 0xfceb) Which produces the following exception: 0:000> r eax=00000041 ebx=0000fceb ecx=00003532 edx=00000002 esi=075dcb35 edi=075d9000 eip=6c29af1c esp=0027fc78 ebp=0027fc80 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202 MSVCR90!LeadUpVec+0x70: 6c29af1c f3a5 rep movs dword ptr es:[edi],dword ptr [esi] 0:000> db edi-0x10 075d8ff0 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 075d9000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 075d9010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 075d9020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 075d9030 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 075d9040 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 075d9050 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 075d9060 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 0:000> db esi 075dcb35 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 075dcb45 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 075dcb55 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 075dcb65 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 075dcb75 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 075dcb85 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 075dcb95 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 075dcba5 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0:000> !heap -p -a edi address 075d9000 found in _DPH_HEAP_ROOT @ 6ca1000 in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize) 722809c: 75d67c8 2838 - 75d6000 4000 6c3194ec verifier!AVrfDebugPageHeapAllocate+0x0000023c 77a257b7 ntdll!RtlDebugAllocateHeap+0x0000003c 779c77ce ntdll!RtlpAllocateHeap+0x0004665a 77981134 ntdll!RtlAllocateHeap+0x0000014d 6c2c3db8 MSVCR90!malloc+0x00000079 [f:\dd\vctools\crt_bld\self_x86\crt\src\malloc.c @ 163] 1e0ae6d1 python27!PyObject_Malloc+0x00000161 [c:\build27\cpython\objects\obmalloc.c @ 968] 0:000> !heap -p -a esi address 075dcb35 found in _DPH_HEAP_ROOT @ 6ca1000 in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize) 7228068: 75da300 fd00 - 75da000 11000 6c3194ec verifier!AVrfDebugPageHeapAllocate+0x0000023c 77a257b7 ntdll!RtlDebugAllocateHeap+0x0000003c 779c77ce ntdll!RtlpAllocateHeap+0x0004665a 77981134 ntdll!RtlAllocateHeap+0x0000014d 6c2c3db8 MSVCR90!malloc+0x00000079 [f:\dd\vctools\crt_bld\self_x86\crt\src\malloc.c @ 163] 1e0ae6d1 python27!PyObject_Malloc+0x00000161 [c:\build27\cpython\objects\obmalloc.c @ 968] 0:000> k4 ChildEBP RetAddr 0027fc80 1e008380 MSVCR90!LeadUpVec+0x70 [f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm @ 289] 0027fc90 1e008407 python27!pack_string+0x40 [c:\build27\cpython\modules\_hotshot.c @ 634] 0027fca8 1e0089bb python27!pack_add_info+0x77 [c:\build27\cpython\modules\_hotshot.c @ 652] 0027fcc0 1e0aafd7 python27!profiler_addinfo+0x5b [c:\build27\cpython\modules\_hotshot.c @ 1020] 0:000> .frame 1 01 0027fc90 1e008407 python27!pack_string+0x40 [c:\build27\cpython\modules\_hotshot.c @ 634] 0:000> dV self = 0x075dcb35 s = 0x075da314 "AAAAAAAAAAAAAAAAAAA[...]AA..." len = 0n123572224 0:000> dt self Local var @ esi Type ProfilerObject* +0x000 ob_refcnt : 0n1094795585 +0x004 ob_type : 0x41414141 _typeobject +0x008 filemap : 0x41414141 _object +0x00c logfilename : 0x41414141 _object +0x010 index : 0n1094795585 +0x014 buffer : [10240] "AAAAAAAAAAAAAAAAAAA[...]AA..." +0x2814 logfp : 0x41414141 _iobuf +0x2818 lineevents : 0n1094795585 +0x281c linetimings : 0n1094795585 +0x2820 frametimings : 0n1094795585 +0x2824 active : 0n1094795585 +0x2828 next_fileno : 0n1094795585 +0x2830 prev_timeofday : 0n4702111234474983745 0:000> !analyze -v -nodb ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* FAULTING_IP: MSVCR90!LeadUpVec+70 [f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm @ 289] 6c29af1c f3a5 rep movs dword ptr es:[edi],dword ptr [esi] EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 6c29af1c (MSVCR90!LeadUpVec+0x00000070) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000001 Parameter[1]: 075d9000 Attempt to write to address 075d9000 CONTEXT: 00000000 -- (.cxr 0x0;r) eax=00000041 ebx=0000fceb ecx=00003532 edx=00000002 esi=075dcb35 edi=075d9000 eip=6c29af1c esp=0027fc78 ebp=0027fc80 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202 MSVCR90!LeadUpVec+0x70: 6c29af1c f3a5 rep movs dword ptr es:[edi],dword ptr [esi] FAULTING_THREAD: 000013b0 PROCESS_NAME: pythonw.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: 00000001 EXCEPTION_PARAMETER2: 075d9000 WRITE_ADDRESS: 075d9000 FOLLOWUP_IP: MSVCR90!LeadUpVec+70 [f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm @ 289] 6c29af1c f3a5 rep movs dword ptr es:[edi],dword ptr [esi] NTGLOBALFLAG: 2000000 APPLICATION_VERIFIER_FLAGS: 0 APP: pythonw.exe ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre BUGCHECK_STR: APPLICATION_FAULT_STRING_DEREFERENCE_INVALID_POINTER_WRITE_EXPLOITABLE_FILL_PATTERN_NXCODE PRIMARY_PROBLEM_CLASS: STRING_DEREFERENCE_EXPLOITABLE_FILL_PATTERN_NXCODE DEFAULT_BUCKET_ID: STRING_DEREFERENCE_EXPLOITABLE_FILL_PATTERN_NXCODE LAST_CONTROL_TRANSFER: from 1e008380 to 6c29af1c STACK_TEXT: 0027fc80 1e008380 075d67df 075da314 0000fceb MSVCR90!LeadUpVec+0x70 0027fc90 1e008407 075da314 1e008960 00000000 python27!pack_string+0x40 0027fca8 1e0089bb 072e67b4 075da314 0769e788 python27!pack_add_info+0x77 0027fcc0 1e0aafd7 075d67c8 071aabc0 0769e788 python27!profiler_addinfo+0x5b 0027fcd8 1e0edd10 0769e788 071aabc0 00000000 python27!PyCFunction_Call+0x47 0027fd04 1e0f017a 0027fd5c 06d57b18 06d57b18 python27!call_function+0x2b0 0027fd74 1e0f1150 071a9870 00000000 06d57b18 python27!PyEval_EvalFrameEx+0x239a 0027fda8 1e0f11b2 06d57b18 071a9870 06d5ba50 python27!PyEval_EvalCodeEx+0x690 0027fdd4 1e11707a 06d57b18 06d5ba50 06d5ba50 python27!PyEval_EvalCode+0x22 0027fdec 1e1181c5 0722e260 06d5ba50 06d5ba50 python27!run_mod+0x2a 0027fe0c 1e118760 6c2f7408 06d17fac 00000101 python27!PyRun_FileExFlags+0x75 0027fe4c 1e1190d9 6c2f7408 06d17fac 00000001 python27!PyRun_SimpleFileExFlags+0x190 0027fe68 1e038d35 6c2f7408 06d17fac 00000001 python27!PyRun_AnyFileExFlags+0x59 0027fee4 1d001017 00000002 06d17f88 1d0011b6 python27!Py_Main+0x965 0027fef0 1d0011b6 1d000000 00000000 04d3ffa8 pythonw!WinMain+0x17 0027ff80 76477c04 7ffde000 76477be0 63080f16 pythonw!__tmainCRTStartup+0x140 0027ff94 7799ad1f 7ffde000 62fa2f53 00000000 KERNEL32!BaseThreadInitThunk+0x24 0027ffdc 7799acea ffffffff 77980228 00000000 ntdll!__RtlUserThreadStart+0x2f 0027ffec 00000000 1d001395 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b STACK_COMMAND: .cxr 0x0 ; kb FAULTING_SOURCE_LINE: f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm FAULTING_SOURCE_FILE: f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm FAULTING_SOURCE_LINE_NUMBER: 289 FAULTING_SOURCE_CODE: No source found for 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm' SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: msvcr90!LeadUpVec+70 FOLLOWUP_NAME: MachineOwner MODULE_NAME: MSVCR90 IMAGE_NAME: MSVCR90.dll DEBUG_FLR_IMAGE_TIMESTAMP: 51ea24a5 FAILURE_BUCKET_ID: STRING_DEREFERENCE_EXPLOITABLE_FILL_PATTERN_NXCODE_c0000005_MSVCR90.dll!LeadUpVec BUCKET_ID: APPLICATION_FAULT_STRING_DEREFERENCE_INVALID_POINTER_WRITE_EXPLOITABLE_FILL_PATTERN_NXCODE_msvcr90!LeadUpVec+70 ANALYSIS_SOURCE: UM FAILURE_ID_HASH_STRING: um:string_dereference_exploitable_fill_pattern_nxcode_c0000005_msvcr90.dll!leadupvec FAILURE_ID_HASH: {006f2a1a-db5d-7798-544b-da0c2e0bcf19} Followup: MachineOwner --------- To fix the issue, pack_string should confirm that the fixed-length buffer is of sufficient size prior to performing the memcpy. ---------- files: hotspot_pack_string_Buffer_Overflow.py messages: 245574 nosy: JohnLeitch priority: normal severity: normal status: open title: hotspot pack_string Heap Buffer Overflow type: security versions: Python 2.7 Added file: http://bugs.python.org/file39753/hotspot_pack_string_Buffer_Overflow.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 20 23:37:51 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 20 Jun 2015 21:37:51 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1434836271.09.0.0319994923682.issue24325@psf.upfronthosting.co.za> Yury Selivanov added the comment: Larry, Nick, Looking at how issue24400 progresses, I think it would be really great if we can merge this one in 3.5.0. It also makes it unnecessary to merge issue24468 in 3.5. ---------- dependencies: +Awaitable ABC incompatible with functools.singledispatch Added file: http://bugs.python.org/file39754/types_coroutine_speedup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 00:53:41 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 20 Jun 2015 22:53:41 +0000 Subject: [issue24479] Support LMMS project files in mimetypes.guess_type In-Reply-To: <1434795502.53.0.948243693094.issue24479@psf.upfronthosting.co.za> Message-ID: <1434840821.63.0.499464173472.issue24479@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- keywords: +easy stage: -> needs patch versions: +Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 01:05:16 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 20 Jun 2015 23:05:16 +0000 Subject: [issue24481] hotshot pack_string Heap Buffer Overflow In-Reply-To: <1434832847.29.0.0777461609837.issue24481@psf.upfronthosting.co.za> Message-ID: <1434841516.76.0.247964307174.issue24481@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +benjamin.peterson stage: -> needs patch title: hotspot pack_string Heap Buffer Overflow -> hotshot pack_string Heap Buffer Overflow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 01:58:18 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 20 Jun 2015 23:58:18 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <1434844698.52.0.445288310483.issue20387@psf.upfronthosting.co.za> Jason R. Coombs added the comment: I've created a repo clone and have added a version of Terry's test to it and will now test Dingyuan's patch. ---------- assignee: -> jason.coombs hgrepos: +313 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 02:14:44 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 21 Jun 2015 00:14:44 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <1434845684.29.0.156440000424.issue20387@psf.upfronthosting.co.za> Jason R. Coombs added the comment: I've committed the patch without the change for "at least two elements" as https://bitbucket.org/jaraco/cpython-issue20387/commits/b7fe3c865b8dbdb33d26f4bc5cbb6096f5445fb2. The patch corrects the new test, demonstrating its effectiveness, but yields two new test failures (apparent regressions): $ ./python.exe Lib/test/test_tokenize.py ********************************************************************** File "/public/cpython-issue20387/Lib/test/test_tokenize.py", line ?, in test.test_tokenize.__test__.doctests Failed example: roundtrip("try: import somemodule\n" "except ImportError: # comment\n" " print('Can not import' # comment2\n)" "else: print('Loaded')\n") Exception raised: Traceback (most recent call last): File "/public/cpython-issue20387/Lib/doctest.py", line 1318, in __run compileflags, 1), test.globs) File "", line 1, in roundtrip("try: import somemodule\n" File "/public/cpython-issue20387/Lib/test/test_tokenize.py", line 698, in roundtrip bytes_from5 = untokenize(tokens5) File "/public/cpython-issue20387/Lib/tokenize.py", line 339, in untokenize out = ut.untokenize(iterable) File "/public/cpython-issue20387/Lib/tokenize.py", line 273, in untokenize self.add_whitespace(start) File "/public/cpython-issue20387/Lib/tokenize.py", line 236, in add_whitespace .format(row, col, self.prev_row, self.prev_col)) ValueError: start (4,1) precedes previous end (4,4) ********************************************************************** File "/public/cpython-issue20387/Lib/test/test_tokenize.py", line ?, in test.test_tokenize.__test__.doctests Failed example: for testfile in testfiles: if not roundtrip(open(testfile, 'rb')): print("Roundtrip failed for file %s" % testfile) break else: True Exception raised: Traceback (most recent call last): File "/public/cpython-issue20387/Lib/doctest.py", line 1318, in __run compileflags, 1), test.globs) File "", line 2, in if not roundtrip(open(testfile, 'rb')): File "/public/cpython-issue20387/Lib/test/test_tokenize.py", line 698, in roundtrip bytes_from5 = untokenize(tokens5) File "/public/cpython-issue20387/Lib/tokenize.py", line 339, in untokenize out = ut.untokenize(iterable) File "/public/cpython-issue20387/Lib/tokenize.py", line 273, in untokenize self.add_whitespace(start) File "/public/cpython-issue20387/Lib/tokenize.py", line 236, in add_whitespace .format(row, col, self.prev_row, self.prev_col)) ValueError: start (73,8) precedes previous end (73,12) ********************************************************************** 1 items had failures: 2 of 74 in test.test_tokenize.__test__.doctests ***Test Failed*** 2 failures. Traceback (most recent call last): File "Lib/test/test_tokenize.py", line 1261, in test_main() File "Lib/test/test_tokenize.py", line 1252, in test_main support.run_doctest(test_tokenize, True) File "/public/cpython-issue20387/Lib/test/support/__init__.py", line 1854, in run_doctest raise TestFailed("%d of %d doctests failed" % (f, t)) test.support.TestFailed: 2 of 79 doctests failed @gumblex, Can you review the failures and address them? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 02:15:42 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Jun 2015 00:15:42 +0000 Subject: [issue15753] No-argument super in method with variable arguments raises SystemError In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za> Message-ID: <1434845742.7.0.0197668922113.issue15753@psf.upfronthosting.co.za> Martin Panter added the comment: The obvious workaround is to include an explicit ?self? parameter (name shouldn?t matter): def f(arbitrary, *positional, **most_keywords): all_positional = (arbitrary,) + positional ... If you need to reserve all keyword parameter names, you could try the manual version of super(): class A: def f(*all_positional, **all_keywords): print(super(A, all_positional[0]).__repr__()) ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 03:46:41 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 21 Jun 2015 01:46:41 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434851201.68.0.278317273106.issue24400@psf.upfronthosting.co.za> Nick Coghlan added the comment: Latest version looks good to me - I'd suggest we merge this, and file any remaining problems as separate issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 03:53:17 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 21 Jun 2015 01:53:17 +0000 Subject: [issue24468] Expose C level compiler flag constants to Python code In-Reply-To: <1434689253.89.0.431597909643.issue24468@psf.upfronthosting.co.za> Message-ID: <1434851597.94.0.594004329894.issue24468@psf.upfronthosting.co.za> Nick Coghlan added the comment: Making _opcode a builtin module rather than an extension module makes more sense to me than adding more random stuff to the sys module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 03:59:05 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 21 Jun 2015 01:59:05 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1434851945.31.0.958124923186.issue24325@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 from me for merging this for 3.5.0 and deferring issue 24468 (which now proposes making _opcode a builtin module to allow compiler constants to be easily shared between C code and Python code) to 3.6 instead. The design changes to address issue 24400 cleaned up various aspect of both the internal architecture and the public data model of PEP 492, and the latest draft of this patch benefits accordingly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 09:40:24 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Jun 2015 07:40:24 +0000 Subject: [issue16095] urllib2 failing with squid proxy and digest authentication In-Reply-To: <1349023291.71.0.297566179231.issue16095@psf.upfronthosting.co.za> Message-ID: <1434872424.08.0.509563591039.issue16095@psf.upfronthosting.co.za> Martin Panter added the comment: There are two problems with the test case, and one bug in Python: 1. HTTPPasswordMgr doesn?t handle realm=None; it has to be a string. You can use HTTPPasswordMgrWithDefaultRealm though. 2. The password managers won?t match a proxy with a non-standard port number against a hostname without a port. So you have to include the port in the add_password() call. 3. AbstractDigestAuthHandler.get_authorization() is using the wrong URL, as Alexander already discovered. I made proxy-digest.patch which should fix this. The wrong URL (final URL rather than proxy) was actually tested for in test_urllib2_localnet.ProxyAuthTests. So I fixed those tests. ---------- keywords: +patch nosy: +vadmium stage: -> patch review versions: +Python 3.6 Added file: http://bugs.python.org/file39755/proxy-digest.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 09:47:23 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Jun 2015 07:47:23 +0000 Subject: [issue16095] urllib2 failing with squid proxy and digest authentication In-Reply-To: <1349023291.71.0.297566179231.issue16095@psf.upfronthosting.co.za> Message-ID: <1434872843.8.0.383262382685.issue16095@psf.upfronthosting.co.za> Martin Panter added the comment: I should point out my patch also adds add_password() methods for the authentication handlers to the documentation. These were only documented by example, but everyone seems to prefer using them rather than the equivalent password manager method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 10:55:37 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Jun 2015 08:55:37 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1434876937.08.0.824254976223.issue24259@psf.upfronthosting.co.za> Martin Panter added the comment: >From the current documentation and limited experience with the module, ReadError (or a subclass) sounds best. I would only expect OSError only for OS-level things, like file not found, disk error, etc. The patches look good. One last suggestion is to use assertRaisesRegex, to be sure that you are getting exactly the exception you expect. Too many times I have found tests in the test suite that were completely broken, but happened to pass because the error happened to match the exception being tested. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 10:56:59 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 21 Jun 2015 08:56:59 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434877019.32.0.535709533349.issue24400@psf.upfronthosting.co.za> Stefan Behnel added the comment: I added three more comments to the review. The rest looks good to me, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 11:44:30 2015 From: report at bugs.python.org (Akira Li) Date: Sun, 21 Jun 2015 09:44:30 +0000 Subject: [issue22442] Deprecate PIPE with subprocess.check_call() and call() In-Reply-To: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za> Message-ID: <1434879870.57.0.148029913999.issue22442@psf.upfronthosting.co.za> Akira Li added the comment: Martin, thank you for the review. As Matthias mentioned, the introduction of subprocess.run() perhaps deprecates this issue: old api should be left alone to avoid breaking old code, new code should use new api, those who need old api (e.g., to write 2/3 compatible code) are expected to read the docs that already contain necessary warnings). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 11:47:32 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 21 Jun 2015 09:47:32 +0000 Subject: [issue22442] Deprecate PIPE with subprocess.check_call() and call() In-Reply-To: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za> Message-ID: <1434880052.33.0.890519096034.issue22442@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 12:28:37 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Jun 2015 10:28:37 +0000 Subject: [issue19756] test_nntplib: sporadic failures, network isses? server down? In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za> Message-ID: <1434882517.8.0.341550781034.issue19756@psf.upfronthosting.co.za> Martin Panter added the comment: See Issue 1186900 about the NNTP client raising EOFError. As for the ?cannot read from timed out object? errors (also reported in Issue 19613), I think the test classes are bad. The test logs don?t seem to be available, but I reckon that the previous test to the failing test would have been skipped due to the transient Internet handler. The test classes are essentially coded like this: class NetworkedNNTP_SSLTests(TestCase): @classmethod def setUpClass(cls): with support.transient_internet(cls.NNTP_HOST): cls.server = NNTP_SSL(cls.NNTP_HOST, timeout=TIMEOUT) def test_that_triggered_the_failure(self): with support.transient_internet(self.NNTP_HOST): ... # Suppose this timed out and the test was skipped def test_capabilities(self): # Now this is reusing the existing connection, left in a broken state by # the previous test self.server.capabilities() Either the server connection should be freshly made for each individual test case (not once per class), or all the test cases grouped by setUpClass() should be skipped if the transient Internet handler kicks in. I?m not sure if it is practical to do the second option with the standard unittest module. Perhaps the method wrapping stage could add some extra checks to see if the test should be skipped. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 12:46:00 2015 From: report at bugs.python.org (Dmitry Odzerikho) Date: Sun, 21 Jun 2015 10:46:00 +0000 Subject: [issue24482] itertools.tee causes segfault in a multithreading environment, while the equivalent implementation does'nt Message-ID: <1434883560.45.0.736397732879.issue24482@psf.upfronthosting.co.za> Changes by Dmitry Odzerikho : ---------- components: Library (Lib) nosy: Dmitry Odzerikho priority: normal severity: normal status: open title: itertools.tee causes segfault in a multithreading environment, while the equivalent implementation does'nt type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 12:59:20 2015 From: report at bugs.python.org (Dmitry Odzerikho) Date: Sun, 21 Jun 2015 10:59:20 +0000 Subject: [issue24482] itertools.tee causes segfault in a multithreading environment, while the equivalent implementation doesn't Message-ID: <1434884360.87.0.819783838298.issue24482@psf.upfronthosting.co.za> New submission from Dmitry Odzerikho: Hi, I'm using iterators returned by itertools.tee in different threads. The original iterator passed to itertools.tee is thread-safe, however, it doesn't guarantees that the cloned iterators are thread safe too. However the equivalent implementation of itertools.tee in pure Python seems to work fine in this case. Is it expected or I'm doing something wrong? I'm attaching a simple example that shows the behaviour. ---------- title: itertools.tee causes segfault in a multithreading environment, while the equivalent implementation does'nt -> itertools.tee causes segfault in a multithreading environment, while the equivalent implementation doesn't Added file: http://bugs.python.org/file39756/test_segfault.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 13:02:43 2015 From: report at bugs.python.org (Dmitry Odzerikho) Date: Sun, 21 Jun 2015 11:02:43 +0000 Subject: [issue24482] itertools.tee causes segfault in a multithreading environment, while the equivalent implementation doesn't In-Reply-To: <1434884360.87.0.819783838298.issue24482@psf.upfronthosting.co.za> Message-ID: <1434884563.54.0.692733602783.issue24482@psf.upfronthosting.co.za> Changes by Dmitry Odzerikho : Added file: http://bugs.python.org/file39757/test_segfault.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 13:02:50 2015 From: report at bugs.python.org (Dmitry Odzerikho) Date: Sun, 21 Jun 2015 11:02:50 +0000 Subject: [issue24482] itertools.tee causes segfault in a multithreading environment, while the equivalent implementation doesn't In-Reply-To: <1434884360.87.0.819783838298.issue24482@psf.upfronthosting.co.za> Message-ID: <1434884570.06.0.80821833301.issue24482@psf.upfronthosting.co.za> Changes by Dmitry Odzerikho : Removed file: http://bugs.python.org/file39756/test_segfault.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 13:07:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 21 Jun 2015 11:07:22 +0000 Subject: [issue24426] re.split performance degraded significantly by capturing group In-Reply-To: <1433962389.05.0.538082969488.issue24426@psf.upfronthosting.co.za> Message-ID: <20150621110718.116075.24957@psf.io> Roundup Robot added the comment: New changeset 7e46a503dd16 by Serhiy Storchaka in branch 'default': Issue #24426: Fast searching optimization in regular expressions now works https://hg.python.org/cpython/rev/7e46a503dd16 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 13:07:43 2015 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 21 Jun 2015 11:07:43 +0000 Subject: [issue24482] itertools.tee causes segfault in a multithreading environment, while the equivalent implementation doesn't In-Reply-To: <1434884360.87.0.819783838298.issue24482@psf.upfronthosting.co.za> Message-ID: <1434884863.81.0.670878198934.issue24482@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +rhettinger stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 13:10:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Jun 2015 11:10:26 +0000 Subject: [issue24426] re.split performance degraded significantly by capturing group In-Reply-To: <1433962389.05.0.538082969488.issue24426@psf.upfronthosting.co.za> Message-ID: <1434885026.45.0.350857859907.issue24426@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 13:44:21 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 21 Jun 2015 11:44:21 +0000 Subject: [issue24408] tkinter.font.Font.measure() broken in 3.5 In-Reply-To: <1433769737.94.0.512429608997.issue24408@psf.upfronthosting.co.za> Message-ID: <20150621114418.20082.20645@psf.io> Roundup Robot added the comment: New changeset 8e90f3ffa784 by Serhiy Storchaka in branch '2.7': Issue #24408: Fixed test for tkinter.Font on OS X. https://hg.python.org/cpython/rev/8e90f3ffa784 New changeset 014ee2df443a by Serhiy Storchaka in branch '3.4': Issue #24408: Fixed test for tkinter.Font on OS X. https://hg.python.org/cpython/rev/014ee2df443a New changeset 5b037f934e40 by Serhiy Storchaka in branch '3.5': Issue #24408: Fixed test for tkinter.Font on OS X. https://hg.python.org/cpython/rev/5b037f934e40 New changeset 2d072d07dfe2 by Serhiy Storchaka in branch 'default': Issue #24408: Fixed test for tkinter.Font on OS X. https://hg.python.org/cpython/rev/2d072d07dfe2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 13:45:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Jun 2015 11:45:34 +0000 Subject: [issue24408] tkinter.font.Font.measure() broken in 3.5 In-Reply-To: <1433769737.94.0.512429608997.issue24408@psf.upfronthosting.co.za> Message-ID: <1434887133.99.0.611151270557.issue24408@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Ned and Martin. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 13:47:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Jun 2015 11:47:05 +0000 Subject: [issue24482] itertools.tee causes segfault in a multithreading environment, while the equivalent implementation doesn't In-Reply-To: <1434884360.87.0.819783838298.issue24482@psf.upfronthosting.co.za> Message-ID: <1434887225.89.0.033885689067.issue24482@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 14:19:56 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 21 Jun 2015 12:19:56 +0000 Subject: [issue24464] Got warning when compiling sqlite3 module on Mac OSX In-Reply-To: <1434627103.24.0.34027869681.issue24464@psf.upfronthosting.co.za> Message-ID: <1434889196.7.0.798037391292.issue24464@psf.upfronthosting.co.za> Ronald Oussoren added the comment: appears to indicate that the function is deprecated on OSX 10.7 and iOS 5.0, but looking at the latest sources on sqlite.org that's not the case, the warning in the documentation appears to be for the version of SQLite that Apple ships with their systems. Because of this I'm against merging this patch as is because it also affects anyone building using the upstream version of SQLite instead of the version shipped with OSX. I'm -0 on suppressing the warning other ways, either by detecting that the build uses Apple's build of SQLite or by using pragma's to disable deprecation warnings for this functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 14:34:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Jun 2015 12:34:02 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() Message-ID: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: There is a difference between Python and C implementations of functools.lru_cache(). Python implementation caches the hash of the key, C implementation doesn't. May be this is not too important (at least I have no an example that shows the benefit of caching the hash), but there is a place for possible optimization. Proposed patch uses private functions _PyDict_GetItem_KnownHash() and _PyDict_SetItem_KnownHash() to avoid the second calculating of the hash for new keys. The hash is still calculated second time when the key is deleted from full cache. To avoid this _PyDict_DelItem_KnownHash() is needed. ---------- components: Library (Lib) files: clru_cache_known_hash.patch keywords: patch messages: 245593 nosy: ncoghlan, rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Avoid repeated hash calculation in C implementation of functools.lru_cache() type: performance versions: Python 3.6 Added file: http://bugs.python.org/file39758/clru_cache_known_hash.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 14:43:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Jun 2015 12:43:15 +0000 Subject: [issue24436] _PyTraceback_Add has no const qualifier for its char * arguments In-Reply-To: <1434054292.35.0.944686887599.issue24436@psf.upfronthosting.co.za> Message-ID: <1434890595.49.0.629101686483.issue24436@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 14:48:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Jun 2015 12:48:52 +0000 Subject: [issue24436] _PyTraceback_Add has no const qualifier for its char * arguments In-Reply-To: <1434054292.35.0.944686887599.issue24436@psf.upfronthosting.co.za> Message-ID: <1434890932.18.0.518034420688.issue24436@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 15:01:24 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 21 Jun 2015 13:01:24 +0000 Subject: [issue24436] _PyTraceback_Add has no const qualifier for its char * arguments In-Reply-To: <1434054292.35.0.944686887599.issue24436@psf.upfronthosting.co.za> Message-ID: <20150621130121.21966.39715@psf.io> Roundup Robot added the comment: New changeset 6f659b9f7fbc by Serhiy Storchaka in branch '3.4': Issue #24436: Added const qualifiers for char* arguments of _PyTraceback_Add. https://hg.python.org/cpython/rev/6f659b9f7fbc New changeset 9602b8313dd5 by Serhiy Storchaka in branch '3.5': Issue #24436: Added const qualifiers for char* arguments of _PyTraceback_Add. https://hg.python.org/cpython/rev/9602b8313dd5 New changeset 4cd00e6fa2ee by Serhiy Storchaka in branch 'default': Issue #24436: Added const qualifiers for char* arguments of _PyTraceback_Add. https://hg.python.org/cpython/rev/4cd00e6fa2ee ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 15:22:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Jun 2015 13:22:21 +0000 Subject: [issue24436] _PyTraceback_Add has no const qualifier for its char * arguments In-Reply-To: <1434054292.35.0.944686887599.issue24436@psf.upfronthosting.co.za> Message-ID: <1434892941.11.0.241935177733.issue24436@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Michael. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 15:57:11 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sun, 21 Jun 2015 13:57:11 +0000 Subject: [issue24129] Incorrect (misleading) statement in the execution model documentation In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za> Message-ID: <1434895031.28.0.617519115266.issue24129@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Nick, thank you for a review, I have made a new patch with all the previous comments taken into account. ---------- Added file: http://bugs.python.org/file39759/classdoc-v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 17:08:27 2015 From: report at bugs.python.org (Jorge Herskovic) Date: Sun, 21 Jun 2015 15:08:27 +0000 Subject: [issue24484] multiprocessing cleanup occasionally throws exception Message-ID: <1434899306.98.0.122661278895.issue24484@psf.upfronthosting.co.za> New submission from Jorge Herskovic: I'm writing a library on top of multiprocessing. As part of the test suite, I create and destroy dozens of processes repeatedly. About once in 50 runs, the tests complete successfully but the program crashes with: Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/util.py", line 286, in _exit_function _run_finalizers(0) File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/util.py", line 246, in _run_finalizers items = [x for x in list(_finalizer_registry.items()) if f(x)] RuntimeError: dictionary changed size during iteration (this is on OS X 10.10.3, Python 3.4.3; I've been unable to replicate the behavior on Python 2.7.9, 3.5.0b2, or pypy despite hundreds of runs) The problematic code is available at https://github.com/jherskovic/mpetl and the tests should be run with nosetests ---------- components: Library (Lib) messages: 245597 nosy: Jorge Herskovic priority: normal severity: normal status: open title: multiprocessing cleanup occasionally throws exception type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 18:05:36 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Sun, 21 Jun 2015 16:05:36 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1434902736.97.0.27387210361.issue23883@psf.upfronthosting.co.za> Jacek Ko?odziej added the comment: I've added previously missing test and docs for test.support.check__all__ in Issue23883_support_check__all__.v2.patch . Awaiting review. :) ---------- Added file: http://bugs.python.org/file39760/Issue23883_support_check__all__.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 18:40:25 2015 From: report at bugs.python.org (George Jenkins) Date: Sun, 21 Jun 2015 16:40:25 +0000 Subject: [issue1182143] making builtin exceptions more informative Message-ID: <1434904825.02.0.0318105351013.issue1182143@psf.upfronthosting.co.za> George Jenkins added the comment: Reviewer please :) (or, advice on how I can get this to proceed, thx) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 18:50:02 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 21 Jun 2015 16:50:02 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1434905402.5.0.963662388629.issue24483@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This is important. ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 18:53:13 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 21 Jun 2015 16:53:13 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1434905593.34.0.864317310329.issue24483@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I would like the full functionality of the Python version to be implemented. Guaranteeing that the hash is only calculated once prevents a reentrancy hole and provides a speed benefit as well. Please implement exactly what the pure python version does (no more than one call to hash ever). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 18:53:20 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 21 Jun 2015 16:53:20 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1434905600.84.0.304431389211.issue24483@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg245600 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 18:56:41 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 21 Jun 2015 16:56:41 +0000 Subject: [issue24482] itertools.tee causes segfault in a multithreading environment, while the equivalent implementation doesn't In-Reply-To: <1434884360.87.0.819783838298.issue24482@psf.upfronthosting.co.za> Message-ID: <1434905801.81.0.309243491893.issue24482@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Is it expected? No, it is a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 19:00:23 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 21 Jun 2015 17:00:23 +0000 Subject: [issue1182143] making builtin exceptions more informative Message-ID: <1434906023.32.0.158578996551.issue1182143@psf.upfronthosting.co.za> R. David Murray added the comment: What does your patch implement? It's not clear from the issue discussion that an API was decided on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 19:15:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Jun 2015 17:15:59 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1434906959.46.0.0868729536959.issue24483@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New patch adds _PyDict_DelItem_KnownHash() and uses it to guarantee that the hash is only calculated once. ---------- Added file: http://bugs.python.org/file39761/clru_cache_known_hash_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 19:28:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Jun 2015 17:28:03 +0000 Subject: [issue24482] itertools.tee causes segfault in a multithreading environment, while the equivalent implementation doesn't In-Reply-To: <1434884360.87.0.819783838298.issue24482@psf.upfronthosting.co.za> Message-ID: <1434907683.34.0.583140799275.issue24482@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I can't reproduce the crash in 3.3+ (this doesn't matter the bug is gone), but can reproduce in 2.7 and 3.2. Here is a reproducer that compatible with 2.7 and 3.x. ---------- Added file: http://bugs.python.org/file39762/test_segfault.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 19:37:09 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 21 Jun 2015 17:37:09 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1434908229.26.0.222734971183.issue14373@psf.upfronthosting.co.za> Raymond Hettinger added the comment: If the C version is to remain in Python3.5, please make sure it provides all of the carefully designed features of the pure python version: * The hash function is called no more than once per element * The key is constructed to be flat as possible * Thread-safe where needed: - make_key called outside locks - within a reentrant lock (either a real lock or the GIL), check to see if the key is in the cache and if so, update the stats and return the value + outside of locks, call the user function (allowing for recursive functions) + within a reentrant lock (either a real lock or the GIL) handle cache misses by 1) verifying there was not an intervening cache update by the user function, 2) updating links, 3) updating stats. During the updates, make only one potentially reentrant cache[key] assignment after all invariants have been restored. Save all decrefs until all other state updates have been completed. A number of features of the lru_cache were designed for space savings over speed (lru is all about eviction to make space for a new entry), for thread safety and to not fall apart during reentrancy. It also provides a guarantee that the hash function is not called more than once per element and is called *before* any of the lru structure updates or lookups (this makes reasoning about correctness *much* easier). In these capabilities can't be reliably reproduced for 3.5, I think the whole thing should be reverted and deferred to 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 19:37:55 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Sun, 21 Jun 2015 17:37:55 +0000 Subject: [issue24309] string.Template should be using str.format and/or deprecated In-Reply-To: <1432787130.33.0.724179416311.issue24309@psf.upfronthosting.co.za> Message-ID: <1434908275.28.0.244495683942.issue24309@psf.upfronthosting.co.za> Changes by Dmitry Kazakov : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 20:13:16 2015 From: report at bugs.python.org (johnkw) Date: Sun, 21 Jun 2015 18:13:16 +0000 Subject: [issue23531] SSL operations cause entire process to hang In-Reply-To: <1424980715.38.0.880892658959.issue23531@psf.upfronthosting.co.za> Message-ID: <1434910396.89.0.798423912158.issue23531@psf.upfronthosting.co.za> johnkw added the comment: This bug is not present on Python 2.7.10 on 64-bit Linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 21:08:56 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 21 Jun 2015 19:08:56 +0000 Subject: [issue24464] Got warning when compiling sqlite3 module on Mac OS X In-Reply-To: <1434627103.24.0.34027869681.issue24464@psf.upfronthosting.co.za> Message-ID: <1434913736.09.0.828940250862.issue24464@psf.upfronthosting.co.za> Ned Deily added the comment: I agree with Ronald that the proposed patch should not be applied as is. For example, the Pythons installed by the current python.org OS X installers build and link with a newer version of libsqlite3. This is one of several examples of third-party libraries for which the Apple-supplied version in OS X is old and users are better served by providing a newer version for use with Python. I think a better approach would be to make it easier for people building from source on OS X to also build and include these newer versions, like the installer build does. ---------- priority: normal -> low title: Got warning when compiling sqlite3 module on Mac OSX -> Got warning when compiling sqlite3 module on Mac OS X versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 22:57:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 21 Jun 2015 20:57:58 +0000 Subject: [issue24408] tkinter.font.Font.measure() broken in 3.5 In-Reply-To: <1433769737.94.0.512429608997.issue24408@psf.upfronthosting.co.za> Message-ID: <20150621205754.20059.14727@psf.io> Roundup Robot added the comment: New changeset 20c9290a5de4 by Ned Deily in branch '2.7': Issue #24408: Prevent test_font failures with non-ascii font names. https://hg.python.org/cpython/rev/20c9290a5de4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 21 23:04:26 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 21 Jun 2015 21:04:26 +0000 Subject: [issue24408] tkinter.font.Font.measure() broken in 3.5 In-Reply-To: <1433769737.94.0.512429608997.issue24408@psf.upfronthosting.co.za> Message-ID: <1434920666.94.0.247118733787.issue24408@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the fix, Martin and Serhiy. With Tk 8.4 on OS X, at least, it is possible to have non-ascii font names. I extended the 2.7 test to account for that. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 00:02:30 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 21 Jun 2015 22:02:30 +0000 Subject: [issue23684] urlparse() documentation does not account for default scheme In-Reply-To: <1426556382.03.0.776976224321.issue23684@psf.upfronthosting.co.za> Message-ID: <1434924150.59.0.87222781342.issue23684@psf.upfronthosting.co.za> Berker Peksag added the comment: LGTM. Added a minor question on Rietveld. ---------- assignee: docs at python -> berker.peksag nosy: +berker.peksag stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 00:08:37 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 21 Jun 2015 22:08:37 +0000 Subject: [issue24484] multiprocessing cleanup occasionally throws exception In-Reply-To: <1434899306.98.0.122661278895.issue24484@psf.upfronthosting.co.za> Message-ID: <1434924517.31.0.664909579657.issue24484@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +davin, sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 04:19:38 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 22 Jun 2015 02:19:38 +0000 Subject: [issue1186900] nntplib shouldn't raise generic EOFError Message-ID: <1434939578.84.0.138464238535.issue1186900@psf.upfronthosting.co.za> Martin Panter added the comment: Quick survey of other communication protocol modules: ftplib: uses EOFError; not documented http.client: custom IncompleteRead exception imaplib: custom IMAP4.abort exception poplib: custom error_proto exception smtplib: SMTPServerDisconnected exception, subclassing OSError telnetlib: EOFError is documented ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 04:33:13 2015 From: report at bugs.python.org (Dingyuan Wang) Date: Mon, 22 Jun 2015 02:33:13 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <1434940393.68.0.733290402414.issue20387@psf.upfronthosting.co.za> Dingyuan Wang added the comment: The new patch should now pass all tests correctly. The main idea is: * if the token is INDENT, push it on the `indents` stack and continue * if a new line starts, AND the position of the first token >= the length of the last indent level, we assume the indent is contained in the leading whitespaces. The new test_tokenize.py fails: https://bitbucket.org/jaraco/cpython-issue20387/src/b7fe3c865b8dbdb33d26f4bc5cbb6096f5445fb2/Lib/test/test_tokenize.py?at=3.4#cl-1244 Line 1244 should be: codelines = self.roundtrip(code).split(b'\n') It seems that the tokens generated by tokenize.tokenize don't contain enough information to restore the original file. * Tabs between tokens are not preserved. * Space before backslash as line continuation are not preserved. (From test/tokenize_tests.txt) # Backslash means line continuation: -x = 1 \ +x = 1\ + 1 My roundtrip test code copied here from #24447: python2 -c 'import sys, tokenize; sys.stdout.write(tokenize.untokenize(tokenize.generate_tokens(sys.stdin.readline)))' python3 -c 'import sys, tokenize; sys.stdout.buffer.write(tokenize.untokenize(tokenize.tokenize(sys.stdin.buffer.readline)))' ---------- Added file: http://bugs.python.org/file39763/tokenize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 04:33:51 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 22 Jun 2015 02:33:51 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1434940431.09.0.370588487972.issue23883@psf.upfronthosting.co.za> Martin Panter added the comment: To avoid the list of patches here getting out of control, I suggest opening a fresh issue for any new patches that aren?t a new version of the patches here. We can mark the new issue as a dependency of this one to keep track of it. Nice work with the check__all__() function. I left some comments on Reitveld. Also, it currently ignores items satisfying either of these checks: * isinstance(module_object, types.ModuleType) * getattr(module_object, '__module__', None) not in name_of_module The first is largely redundant with the second, because module objects don?t have a __module__ attribute. However I wonder if it would be better to drop the second check and just rely on the ModuleType check, making the test stricter. Or would this be too annoying in some cases (requiring a huge blacklist)? If so, maybe make the name_of_module checking optional. === Serhiy: ftplib.Error does not actually appear to be documented. Perhaps it should not be added to __all__ after all? (excuse the pun) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 05:34:44 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 22 Jun 2015 03:34:44 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434944084.05.0.819051777699.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: An updated patch is attached. I'll commit it tomorrow morning. ---------- Added file: http://bugs.python.org/file39764/corotype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 05:43:18 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 22 Jun 2015 03:43:18 +0000 Subject: [issue24439] Feedback for awaitable coroutine documentation In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za> Message-ID: <1434944598.24.0.440643196484.issue24439@psf.upfronthosting.co.za> Yury Selivanov added the comment: Martin, if you want to help with the documentation, it would be great if you can help me with updating asyncio coroutines section: https://docs.python.org/3.5/library/asyncio-task.html#coroutines ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 05:47:56 2015 From: report at bugs.python.org (Andreas Nilsson) Date: Mon, 22 Jun 2015 03:47:56 +0000 Subject: [issue24479] Support LMMS project files in mimetypes.guess_type In-Reply-To: <1434795502.53.0.948243693094.issue24479@psf.upfronthosting.co.za> Message-ID: <1434944876.38.0.395299817405.issue24479@psf.upfronthosting.co.za> Andreas Nilsson added the comment: Here is a decompressed example (use lmms -d to decompress). Shouldn't this be parsed as XML? Here's a log of my experiment with it: Python 2.7.9 (default, Apr 2 2015, 15:33:21) [GCC 4.9.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mimetypes >>> mimetypes.init() >>> mimetypes.guess_type("seaman.mmp") (None, None) >>> mimetypes.guess_type("seaman.mmp", False) (None, None) By default LMMS saves as .mmpz which is the compressed type, I do not know the encryption method they use though but I can ask them if you want so! ---------- Added file: http://bugs.python.org/file39765/seaman.mmp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 06:10:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 22 Jun 2015 04:10:51 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1434908229.26.0.222734971183.issue14373@psf.upfronthosting.co.za> Message-ID: <1441431.bRtOMGd49G@raxxla> Serhiy Storchaka added the comment: > If the C version is to remain in Python3.5, please make sure it provides all > of the carefully designed features of the pure python version: > > * The hash function is called no more than once per element Will be satisfied by issue24483. I think all other capabilities are satisfied. The GIL is used to satisfy thread-safe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 06:18:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 22 Jun 2015 04:18:27 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1434946706.99.0.0876457834863.issue24483@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New patch touches also unbounded cache version. Larry, do you allow to commit such patch in 3.5? ---------- nosy: +larry versions: +Python 3.5 Added file: http://bugs.python.org/file39766/clru_cache_known_hash_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 08:32:54 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 22 Jun 2015 06:32:54 +0000 Subject: [issue23750] Clarify difference between os.system/subprocess.call in section "Replacing os.system()" In-Reply-To: <1427120891.65.0.0570880238086.issue23750@psf.upfronthosting.co.za> Message-ID: <1434954774.38.0.147192927321.issue23750@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch: * Use different return value variable names and point out that they are encoded differently * Add another bullet point about signal handling * Fix os.system() documentation of the return value. My understanding is it is the C standard that does not define the return value, and Posix essentially means Unix. ---------- keywords: +patch stage: -> patch review versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39767/system-subprocess.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 08:39:33 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 22 Jun 2015 06:39:33 +0000 Subject: [issue24420] Documentation regressions from adding subprocess.run() In-Reply-To: <1433909056.73.0.964707918197.issue24420@psf.upfronthosting.co.za> Message-ID: <1434955173.61.0.590926995335.issue24420@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 11:41:28 2015 From: report at bugs.python.org (Malthe Borch) Date: Mon, 22 Jun 2015 09:41:28 +0000 Subject: [issue24485] Function source inspection fails on closures Message-ID: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za> New submission from Malthe Borch: Very simple to reproduce (see attachment). ---------- components: Library (Lib) files: test.py messages: 245621 nosy: malthe priority: normal severity: normal status: open title: Function source inspection fails on closures type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39768/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 12:06:16 2015 From: report at bugs.python.org (DmitryJ) Date: Mon, 22 Jun 2015 10:06:16 +0000 Subject: [issue24462] bytearray.find Buffer Over-read In-Reply-To: <1434551199.93.0.25363766054.issue24462@psf.upfronthosting.co.za> Message-ID: <1434967576.17.0.356926585236.issue24462@psf.upfronthosting.co.za> DmitryJ added the comment: I am preparing a patch for this issue, then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 12:23:49 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 22 Jun 2015 10:23:49 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1434968629.36.0.668082203451.issue24483@psf.upfronthosting.co.za> Larry Hastings added the comment: I can accept this change, but I don't like that code. Is it really considered acceptable to have that much copy-and-paste code in the dict implementation for KnownHash calls? Could the common code be split off into a Py_LOCAL_INLINE function? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 12:57:15 2015 From: report at bugs.python.org (DmitryJ) Date: Mon, 22 Jun 2015 10:57:15 +0000 Subject: [issue24481] hotshot pack_string Heap Buffer Overflow In-Reply-To: <1434832847.29.0.0777461609837.issue24481@psf.upfronthosting.co.za> Message-ID: <1434970635.9.0.176310072849.issue24481@psf.upfronthosting.co.za> Changes by DmitryJ : ---------- nosy: +dev_zzo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 14:00:36 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 22 Jun 2015 12:00:36 +0000 Subject: [issue24439] Feedback for awaitable coroutine documentation In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za> Message-ID: <1434974436.12.0.0473100135758.issue24439@psf.upfronthosting.co.za> Martin Panter added the comment: When I update my patch I can try updating the asyncio section. However I have only had limited experience with asyncio, so feel free to suggest things to add. Here is a list of things I think may need changing: * ?async def? routines are allowed in addition to generators in asyncio (e.g. in Task constructor) * Other awaitables are also accepted as asyncio coroutines * List of ?yield from? actions could be augmented with ?await?, ?async for?, etc * The coroutines provided by asyncio are both iterable and awaitable, so they may be used with both ?yield from? and ?await? * Change references of asyncio.async() to ensure_future() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 14:44:07 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 22 Jun 2015 12:44:07 +0000 Subject: [issue23377] HTTPResponse may drop buffer holding next response In-Reply-To: <1422881776.12.0.998068930599.issue23377@psf.upfronthosting.co.za> Message-ID: <1434977047.92.0.522773074079.issue23377@psf.upfronthosting.co.za> Martin Panter added the comment: Minor update based on Demian?s review ---------- Added file: http://bugs.python.org/file39769/http-buffer.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 15:15:11 2015 From: report at bugs.python.org (Julien Palard) Date: Mon, 22 Jun 2015 13:15:11 +0000 Subject: [issue24486] http/client.py block indefinitely on line 308 in _read_status Message-ID: <1434978911.11.0.520674356543.issue24486@psf.upfronthosting.co.za> New submission from Julien Palard: Requesting HTTP using `requests`, which uses `http.client` which use `socket`, sometimes, my program get stuck like this: ``` File "/usr/lib/python3.2/socket.py", line 287 in readinto File "/usr/lib/python3.2/http/client.py", line 308 in _read_status File "/usr/lib/python3.2/http/client.py", line 346 in begin File "/usr/lib/python3.2/http/client.py", line 1052 in getresponse ... in python requests ... ``` The line is the first of _read_status:: ``` line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1") ``` At a lower level, the program is stuck in a `recvfrom()` syscall. So obviously, an error at the network level caused the server to not reply, but the client recvfrom() the network in a blocking socket without checking first if data is available, so it get stuck indefinitely :-( ---------- components: Library (Lib) messages: 245626 nosy: Julien.Palard priority: normal severity: normal status: open title: http/client.py block indefinitely on line 308 in _read_status versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 15:17:14 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 22 Jun 2015 13:17:14 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1434979034.16.0.450678112497.issue24483@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Serhiy's code looks like the cleanest way to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 15:19:37 2015 From: report at bugs.python.org (Sam Thursfield) Date: Mon, 22 Jun 2015 13:19:37 +0000 Subject: [issue24465] Make tarfile have deterministic sorting In-Reply-To: <1434629652.82.0.994275977892.issue24465@psf.upfronthosting.co.za> Message-ID: <1434979177.42.0.662948223667.issue24465@psf.upfronthosting.co.za> Sam Thursfield added the comment: Here's a patch which does the same thing but only for shutil.make_archive(). Note that the final output will still be non-deterministic if you use format=gztar because time.time() and the base_name argument get added to the gzip header. Might be nice to add an option to make that deterministic too, as a separate thing. This patch is useful to me as-is though. ---------- Added file: http://bugs.python.org/file39770/make_archive-stable-ordering.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 15:47:57 2015 From: report at bugs.python.org (Jorge Herskovic) Date: Mon, 22 Jun 2015 13:47:57 +0000 Subject: [issue24484] multiprocessing cleanup occasionally throws exception In-Reply-To: <1434899306.98.0.122661278895.issue24484@psf.upfronthosting.co.za> Message-ID: <1434980877.99.0.3378948879.issue24484@psf.upfronthosting.co.za> Jorge Herskovic added the comment: This happens reliably between 1-5% of the time on my home Mac (a 4.0 GHz i7). My work Mac Pro, a lot slower, doesn't exhibit this behavior on the same 3.4.3 interpreter. Could it be related to a concurrency issue in the interpreter? We're attempting to replicate on other systems. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 16:23:02 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 22 Jun 2015 14:23:02 +0000 Subject: [issue10399] AST Optimization: inlining of function calls In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za> Message-ID: <1434982982.51.0.915667316204.issue10399@psf.upfronthosting.co.za> Mark Lawrence added the comment: I get the impression that there's a lot to be gained here, especially when compared to some of the micro-optimizations that are committed. Can we resurrect this, perhaps by taking it up on python-dev? Also msg121082 refers to a Globals cache patch posted on issue10401. ---------- nosy: +BreamoreBoy versions: +Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 16:24:29 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 22 Jun 2015 14:24:29 +0000 Subject: =?utf-8?q?=5Bissue24487=5D_Change_asyncio=2Easync=28=29_=E2=86=92_ensure?= =?utf-8?b?X2Z1dHVyZSgp?= Message-ID: <1434983069.7.0.469854953168.issue24487@psf.upfronthosting.co.za> New submission from Martin Panter: The async() function is marked as deprecated in 3.4.4. This patch replaces most references to it with references to ensure_future(). The exception is , which suggests using it in Python < 3.4.2. ---------- assignee: docs at python components: Documentation, asyncio files: ensure_future.patch keywords: patch messages: 245631 nosy: docs at python, gvanrossum, haypo, vadmium, yselivanov priority: normal severity: normal stage: patch review status: open title: Change asyncio.async() ? ensure_future() versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39771/ensure_future.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 16:39:29 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 22 Jun 2015 14:39:29 +0000 Subject: [issue24486] http/client.py block indefinitely on line 308 in _read_status In-Reply-To: <1434978911.11.0.520674356543.issue24486@psf.upfronthosting.co.za> Message-ID: <1434983969.29.0.174349566551.issue24486@psf.upfronthosting.co.za> Martin Panter added the comment: You did not mention if the HTTP connection has a timeout set. If no timeout is set, it will block until the server sends or closes the connection. The timeout sets how long the socket spends ?checking if data is available? before giving up. ---------- nosy: +vadmium type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 16:40:43 2015 From: report at bugs.python.org (bkcsfi sfi) Date: Mon, 22 Jun 2015 14:40:43 +0000 Subject: [issue24485] Function source inspection fails on closures In-Reply-To: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za> Message-ID: <1434984043.4.0.397253963856.issue24485@psf.upfronthosting.co.za> Changes by bkcsfi sfi : ---------- nosy: +bkcsfi sfi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 16:56:22 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 22 Jun 2015 14:56:22 +0000 Subject: =?utf-8?q?=5Bissue24487=5D_Change_asyncio=2Easync=28=29_=E2=86=92_ensure?= =?utf-8?b?X2Z1dHVyZSgp?= In-Reply-To: <1434983069.7.0.469854953168.issue24487@psf.upfronthosting.co.za> Message-ID: <1434984982.87.0.172580090102.issue24487@psf.upfronthosting.co.za> Yury Selivanov added the comment: Martin, I believe this was done as part of issue24180, see this commit https://hg.python.org/cpython/rev/9d9e445d25dc ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 17:01:27 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 22 Jun 2015 15:01:27 +0000 Subject: =?utf-8?q?=5Bissue24487=5D_Change_asyncio=2Easync=28=29_=E2=86=92_ensure?= =?utf-8?b?X2Z1dHVyZSgp?= In-Reply-To: <1434983069.7.0.469854953168.issue24487@psf.upfronthosting.co.za> Message-ID: <1434985287.55.0.60830596872.issue24487@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- resolution: not a bug -> out of date stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 17:08:42 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 22 Jun 2015 15:08:42 +0000 Subject: [issue24485] Function source inspection fails on closures In-Reply-To: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za> Message-ID: <1434985722.93.0.0975608455122.issue24485@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 17:11:05 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 22 Jun 2015 15:11:05 +0000 Subject: [issue24485] Function source inspection fails on closures In-Reply-To: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za> Message-ID: <1434985865.2.0.45114600149.issue24485@psf.upfronthosting.co.za> Yury Selivanov added the comment: Looks like this is a regression in 3.5. ---------- priority: normal -> release blocker stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 17:23:42 2015 From: report at bugs.python.org (DmitryJ) Date: Mon, 22 Jun 2015 15:23:42 +0000 Subject: [issue24462] bytearray.find Buffer Over-read In-Reply-To: <1434551199.93.0.25363766054.issue24462@psf.upfronthosting.co.za> Message-ID: <1434986622.1.0.689619572502.issue24462@psf.upfronthosting.co.za> DmitryJ added the comment: Attached please find a patch against the 2.7 branch. CPython built with the patch passes the tests from the test suite. Unfortunately, as there is not much control over memory allocation, there is no 100% reliable test case that would allow for reproducing the reported issue. Some notes on the patch. I have studied possible ways of fixing the issue narrowing them to two options; the approaches considered were: a. Patch bytearray methods so they use stringlib's functions with respect to the corner case of out-of-bounds access on m = n. b. Patch fastsearch() avoiding the out-of-bounds access on m = n completely. Of these two, approach a is less "invasive" as changes, in theory, would be contained in bytearray() code only and should not affect any other code. Approach b fixes all possible cases, but affects other code not related to bytearray. Upon closer studying of both bytearray and stringlib code, I discovered that it might be impossible to patch bytearray code only as stringlib contains a few methods that make use of the affected fastsearch() function, see e.g. stringlib_partition() as used in bytearray_partition(). If the approach of fixing bytearray specific code only would be chosen, I have to incorporate at least some of code following the fastsearch() call in stringlib_partition(). Similar considerations apply to other bytearray methods that make use of stringlib; the amount of code duplication varies. The end result is, I chose to patch fastsearch() instead. Performance wise, the change incurs a small penalty due to one extra branch when m != n and brings considerable gain in (potentially rare) case when m = n. I would appreciate if someone could test and review the patch. NB. I stand corrected for the comment in msg245457 -- there is a note I missed in the C code. My sincere apologies to the author. ---------- keywords: +patch Added file: http://bugs.python.org/file39772/issue24462-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 18:31:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 22 Jun 2015 16:31:35 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <20150622163132.21213.78524@psf.io> Roundup Robot added the comment: New changeset 7a0a1a4ac639 by Yury Selivanov in branch '3.5': Issue #24400: Introduce a distinct type for 'async def' coroutines. https://hg.python.org/cpython/rev/7a0a1a4ac639 New changeset 44253ce374fc by Yury Selivanov in branch 'default': Issue #24400: Merge 3.5 https://hg.python.org/cpython/rev/44253ce374fc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 18:33:59 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 22 Jun 2015 16:33:59 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1434990839.5.0.518511158902.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, Martin, Stefan, thanks to all of you for the code review! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 18:45:17 2015 From: report at bugs.python.org (Andreas Hilboll) Date: Mon, 22 Jun 2015 16:45:17 +0000 Subject: [issue24488] ConfigParser.getboolean fails on boolean options Message-ID: <1434991517.36.0.491167534114.issue24488@psf.upfronthosting.co.za> New submission from Andreas Hilboll: Not sure if this is by design (or if I'm doing something utterly stupid), but I often create a ConfigParser object for my application and then pass this around (or make it global). So when I do something like cfg.set("input_filter", "include_filtered", True) and then cfg.getboolean("input_filter", "include_filtered") I receive an error (AttributeError: 'bool' object has no attribute 'lower'). Wouldn't it be more sensible if getboolean would return the raw value in case the raw value is already a boolean? If not, which would be the best way forward for me? ---------- components: Library (Lib) messages: 245638 nosy: andreas-h priority: normal severity: normal status: open title: ConfigParser.getboolean fails on boolean options versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 19:05:33 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 22 Jun 2015 17:05:33 +0000 Subject: [issue24488] ConfigParser.getboolean fails on boolean options In-Reply-To: <1434991517.36.0.491167534114.issue24488@psf.upfronthosting.co.za> Message-ID: <1434992733.04.0.906919997808.issue24488@psf.upfronthosting.co.za> R. David Murray added the comment: In python3 you will get an error: "TypeError: option values must be strings". So, this is an infelicity in the configparser API. Or, rather, I presume it is a design decision (ie: python shouldn't guess what string format you want the value to have in the file). I'll leave it up to Lukaz to decide if this should be closed, or if there is an acceptable feature request here. But your solution is to call str on your boolean values when you store them. ---------- assignee: -> lukasz.langa nosy: +lukasz.langa, r.david.murray versions: +Python 3.6 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 19:13:33 2015 From: report at bugs.python.org (Boris) Date: Mon, 22 Jun 2015 17:13:33 +0000 Subject: [issue3905] subprocess failing in GUI applications on Windows In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za> Message-ID: <1434993213.6.0.714775716174.issue3905@psf.upfronthosting.co.za> Boris added the comment: Probably the same issue: everything works when called from command line, but when called via a desktop shortcut I get ... _winapi.DUPLICATE_SAME_ACCESS) OSError: [WinError 6] The handle is invalid Changing pythonw to python solved the problem. ...this could be expected behavior. If anyone is interested I can attach my test files. ---------- nosy: +borisompol versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 19:36:05 2015 From: report at bugs.python.org (paul j3) Date: Mon, 22 Jun 2015 17:36:05 +0000 Subject: [issue24419] In argparse action append_const doesn't work for positional arguments In-Reply-To: <1433891109.51.0.989129061245.issue24419@psf.upfronthosting.co.za> Message-ID: <1434994565.62.0.404657490798.issue24419@psf.upfronthosting.co.za> paul j3 added the comment: To wrap this up, the correct way to specify that 2 or more positionals share a 'dest' is to supply that dest as the first parameter. If the help should have something else, use the `metavar`. import argparse parser = argparse.ArgumentParser() parser.add_argument('x', action='append_const', const=42, metavar='foo') parser.add_argument('x', action='append_const', const=43, metavar='bar') parser.print_help() args=parser.parse_args([]) print(args) produces usage: issue24419.py [-h] positional arguments: foo bar optional arguments: -h, --help show this help message and exit Namespace(x=[42, 43]) (I think this issue can be closed). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 20:34:53 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 22 Jun 2015 18:34:53 +0000 Subject: [issue24439] Feedback for awaitable coroutine documentation In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za> Message-ID: <1434998093.88.0.137107827783.issue24439@psf.upfronthosting.co.za> Yury Selivanov added the comment: Hi Martin, I've left you some feedback in the code review. > * ?async def? routines are allowed in addition to generators in asyncio (e.g. in Task constructor) Right. I think we need to add some code samples too. > * Other awaitables are also accepted as asyncio coroutines Depending on where, I guess. asyncio.Task should only accept when asyncio.iscoroutine is true -- abc.Coroutine, types.GeneratorType. > * List of ?yield from? actions could be augmented with ?await?, ?async for?, etc Not sure what you mean here. > * The coroutines provided by asyncio are both iterable and awaitable, so they may be used with both ?yield from? and ?await? Right. We also need to make sure that it's documented that in order to have "yield from native_coro()", you have to decorate the gen function with 'asyncio.coroutine'. And we should mention that if you're targeting Python 3.5+ you should use the new syntax. > * Change references of asyncio.async() to ensure_future() This is already done ;) Thanks! ---------- nosy: +asvetlov, gvanrossum, haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 20:56:26 2015 From: report at bugs.python.org (Evgeny Kapun) Date: Mon, 22 Jun 2015 18:56:26 +0000 Subject: [issue24129] Incorrect (misleading) statement in the execution model documentation In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za> Message-ID: <1434999386.45.0.662132681528.issue24129@psf.upfronthosting.co.za> Changes by Evgeny Kapun : ---------- nosy: +abacabadabacaba _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 21:42:54 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 22 Jun 2015 19:42:54 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1435002174.1.0.392817705111.issue19995@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Found my first 3.5 breakage which I think is due to this. >>> from uuid import uuid4 >>> '%.32x' % uuid4() ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 21:46:27 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 22 Jun 2015 19:46:27 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1435002387.69.0.228308896657.issue19995@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Fix: >>> '%.32x' % uuid4().int ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 22:11:32 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 22 Jun 2015 20:11:32 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1435003892.01.0.421430439363.issue24483@psf.upfronthosting.co.za> Larry Hastings added the comment: Patch doesn't build for me against current trunk: gcc -pthread -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I. -IInclude -I./Include -DPy_BUILD_CORE -c ./Modules/_functoolsmodule.c -o Modules/_functoolsmodule.o ./Modules/_functoolsmodule.c: In function ?infinite_lru_cache_wrapper?: ./Modules/_functoolsmodule.c:769:14: error: too few arguments to function ?_PyDict_GetItem_KnownHash? result = _PyDict_GetItem_KnownHash(self->cache, key); ^ In file included from Include/Python.h:87:0, from ./Modules/_functoolsmodule.c:2: Include/dictobject.h:59:24: note: declared here PyAPI_FUNC(PyObject *) _PyDict_GetItem_KnownHash(PyObject *mp, PyObject *key, ^ ./Modules/_functoolsmodule.c:785:9: error: too few arguments to function ?_PyDict_SetItem_KnownHash? if (_PyDict_SetItem_KnownHash(self->cache, key, result) < 0) { ^ In file included from Include/Python.h:87:0, from ./Modules/_functoolsmodule.c:2: Include/dictobject.h:71:17: note: declared here PyAPI_FUNC(int) _PyDict_SetItem_KnownHash(PyObject *mp, PyObject *key, ^ Makefile:1695: recipe for target 'Modules/_functoolsmodule.o' failed make: *** [Modules/_functoolsmodule.o] Error 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 22:30:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 22 Jun 2015 20:30:09 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1435005009.26.0.22554241862.issue24483@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: My bad. I submitted the last patch without checking (rebuilding Python takes too much time on my slow netbook). Here is fixed and tested patch. ---------- Added file: http://bugs.python.org/file39773/clru_cache_known_hash_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 22:39:18 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 22 Jun 2015 20:39:18 +0000 Subject: [issue24478] asyncio: segfault in test_env_var_debug() on non-debug Windows buildbot In-Reply-To: <1434785934.32.0.696273570884.issue24478@psf.upfronthosting.co.za> Message-ID: <1435005558.9.0.175228524552.issue24478@psf.upfronthosting.co.za> Zachary Ware added the comment: Actually, it looks like it's due to PEP 492: C:\Users\Zachary\code\hg.python.org\3.5>hg bisect -b The first bad revision is: changeset: 96411:d1959cafc68c branch: 3.5 parent: 96407:e59966bb6de5 parent: 96410:b7b73029c825 user: Yury Selivanov date: Sat May 30 21:02:34 2015 -0400 summary: Issue 24004: Support Awaitables (pep 492) in @asyncio.coroutine decorator Not all ancestors of this changeset have been checked. Use bisect --extend to continue the bisection from the common ancestor, 943fa0e8b6a4. ---------- stage: -> needs patch type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 22:39:38 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 22 Jun 2015 20:39:38 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1435005578.23.0.281667811094.issue15014@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I believe this change broke RFC 4954's AUTH command when the optional initial-response is expected. $4 "The AUTH Command" says: AUTH mechanism [initial-response] ... initial-response: An optional initial client response. If present, this response MUST be encoded as described in Section 4 of [BASE64] or contain a single character "=" It's possible that some SMTP servers only look for a string like AUTH PLAIN and won't issue a challenge if it's missing. Such an example is found in the lazr.smtptest and used by the testing SMTPd in GNU Mailman. It's possible that the servers are not standards compliant (I haven't completely groked RFC 4422), but still, since this is a backward incompatible change and breaks existing code, there should be some way of making smtplib.login() provide the initial-response, and it probably ought to be the default for backward compatibility. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 23:14:32 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 22 Jun 2015 21:14:32 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1435007672.95.0.82828932857.issue15014@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Here's a rough thought for a fix. Some auth_*() methods require a challenge, but some don't, e.g. auth_plain(). Let's allow authobject() to be called with challenge=None. If they allow an initial-response, then they can just return the response bytes. If they return None, then they don't allow an initial-response and so must wait for the challenge (i.e. 334 response code). I think that would at least restore backward compatibility for AUTH PLAIN. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 23:47:00 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 22 Jun 2015 21:47:00 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1435009620.16.0.642839721127.issue15014@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Also, smtpd is not compatible with auth challenges because found_terminator() doesn't know that the response its getting isn't a command but instead a challenge response. So really we need another bug to track fixes to smtpd.py to handle challenge responses. It makes no sense for smtpd and smtplib not to be compatible. (Who wants to reimplement smtpd in asyncio? :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 22 23:50:09 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 22 Jun 2015 21:50:09 +0000 Subject: [issue24478] asyncio: segfault in test_env_var_debug() on non-debug Windows buildbot In-Reply-To: <1434785934.32.0.696273570884.issue24478@psf.upfronthosting.co.za> Message-ID: <1435009809.8.0.664330275779.issue24478@psf.upfronthosting.co.za> Yury Selivanov added the comment: Hi Zachary, This is extremely strange. The test doesn't even start the loop, it only creates it, and prints out what 'get_debug' says. It can't be 'sys.set_coroutine_wrapper' either, as it's only called when a loop is running, or when it's about to start/stop running. The change in "96411:d1959cafc68c" can only affect running coroutines, but I don't think the tests invokes any. asyncio itself does not even have any 'async def' functions (only in test_pep492.py)... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 00:00:28 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 22 Jun 2015 22:00:28 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1435010428.05.0.000926948967956.issue15014@psf.upfronthosting.co.za> R. David Murray added the comment: Sounds reasonable. I'll suggest a slight variation. We change the authobj signature to challenge=None, then the first thing we do in auth is 'initial_response = authobj()'. The return value can be the empty string or a real initial value, and we send the auth command with ' '.join(mechanism, initial_response).strip(). Then we do the challenge part only if we get the 334. There's already an open issue for smtpd auth, with at least a preliminary patch, but it got blocked a bit by Martin quoting an RFC... ---------- priority: normal -> release blocker stage: resolved -> needs patch versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 00:04:25 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 22 Jun 2015 22:04:25 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1435010665.42.0.06518734662.issue15014@psf.upfronthosting.co.za> R. David Murray added the comment: The smtpd issue is issue 21935. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 00:05:55 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 22 Jun 2015 22:05:55 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1435010428.05.0.000926948967956.issue15014@psf.upfronthosting.co.za> Message-ID: <20150622180549.343b50d5@anarchist.wooz.org> Barry A. Warsaw added the comment: On Jun 22, 2015, at 10:00 PM, R. David Murray wrote: >We change the authobj signature to challenge=None, then the first thing we do >in auth is 'initial_response = authobj()'. The return value can be the empty >string or a real initial value, and we send the auth command with ' >'.join(mechanism, initial_response).strip(). Then we do the challenge part >only if we get the 334. Sounds good to me. I'll see if I can work up a patch. I have a hack in my testing code to work around the lack of auth in smtpd. It's not pretty but it works. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 00:09:36 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 22 Jun 2015 22:09:36 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1435010976.45.0.214954699156.issue24325@psf.upfronthosting.co.za> Yury Selivanov added the comment: A rebased version of the patch is attached (now a "review" link should appear). Nick, Stefan, please take a look. Larry, can we merge this in 3.5.0? I've invested a lot of time to have 100% test coverage; the test suite is very elaborate now. There seems to be no refleaks too. I think this change is a very natural continuation of what we've done in issue24400. ---------- Added file: http://bugs.python.org/file39774/types_coroutine_speedup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 00:10:38 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 22 Jun 2015 22:10:38 +0000 Subject: [issue21935] Implement AUTH command in smtpd. In-Reply-To: <1404766823.82.0.391401675174.issue21935@psf.upfronthosting.co.za> Message-ID: <1435011038.72.0.395725827765.issue21935@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Martin says: "I cannot see any particular circumstances where unencrypted passwords for smtpd would be acceptable, given that there are perfectly established technologies. So I remain -1 on this patch." Here's a use case: a testing SMTP server, such as lazr.smtptest which is built on top of smtpd. In some testing scenarios, you really don't care about STARTTLS complications, and everything's connecting over localhost anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 00:12:52 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 22 Jun 2015 22:12:52 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1435011172.69.0.91629444702.issue24325@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +asvetlov, haypo, vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 00:16:50 2015 From: report at bugs.python.org (Akshit Khurana) Date: Mon, 22 Jun 2015 22:16:50 +0000 Subject: [issue24412] setUpClass equivalent for addCleanup In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za> Message-ID: <1435011410.44.0.0801715084201.issue24412@psf.upfronthosting.co.za> Changes by Akshit Khurana : ---------- nosy: +axitkhurana _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 00:18:45 2015 From: report at bugs.python.org (Joe Jevnik) Date: Mon, 22 Jun 2015 22:18:45 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1435011525.01.0.0670903192849.issue24379@psf.upfronthosting.co.za> Joe Jevnik added the comment: Based on some discussion on python-ideas, this is being renamed to operator.subscript. Here is the patch that makes the correct the changes to move this object into the operator module. ---------- components: +Extension Modules -Interpreter Core title: slice.literal notation -> operator.subscript Added file: http://bugs.python.org/file39775/operator_subscript.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 00:26:14 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 22 Jun 2015 22:26:14 +0000 Subject: [issue24450] Add gi_yieldfrom calculated property to generator object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1435011974.22.0.596743283522.issue24450@psf.upfronthosting.co.za> Yury Selivanov added the comment: Please find attached a new patch that exposes 'cr_await' attribute on coroutine objects. I don't think we can merge 'gi_yieldfrom' in 3.5, but 'cr_await' should probably be fine. ---------- Added file: http://bugs.python.org/file39776/cr_await.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 00:40:05 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 22 Jun 2015 22:40:05 +0000 Subject: [issue24450] Add cr_await calculated property to coroutine object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1435012805.13.0.534322799892.issue24450@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- title: Add gi_yieldfrom calculated property to generator object -> Add cr_await calculated property to coroutine object _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 01:14:56 2015 From: report at bugs.python.org (py.user) Date: Mon, 22 Jun 2015 23:14:56 +0000 Subject: [issue24419] In argparse action append_const doesn't work for positional arguments In-Reply-To: <1433891109.51.0.989129061245.issue24419@psf.upfronthosting.co.za> Message-ID: <1435014896.45.0.313921723311.issue24419@psf.upfronthosting.co.za> py.user added the comment: Tested on argdest.py: #!/usr/bin/env python3 import argparse parser = argparse.ArgumentParser() parser.add_argument('x', action='append') parser.add_argument('x', action='append_const', const=42, metavar='foo') parser.add_argument('x', action='append_const', const=43, metavar='bar') parser.add_argument('-x', action='append_const', const=44) args = parser.parse_args() print(args) Run: [guest at localhost debug]$ ./argdest.py -h usage: argdest.py [-h] [-x] x positional arguments: x foo bar optional arguments: -h, --help show this help message and exit -x [guest at localhost debug]$ ./argdest.py -x 1 -x Namespace(x=[44, '1', 42, 43, 44]) [guest at localhost debug]$ LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 01:26:44 2015 From: report at bugs.python.org (koobs) Date: Mon, 22 Jun 2015 23:26:44 +0000 Subject: [issue12210] test_smtplib: intermittent failures on FreeBSD In-Reply-To: <1306700978.51.0.107374125859.issue12210@psf.upfronthosting.co.za> Message-ID: <1435015604.16.0.635683746528.issue12210@psf.upfronthosting.co.za> koobs added the comment: Observed the following test_smtplib failure on koobs-freebsd10, noting that the timeout parameter is still 3 test test_smtplib failed -- Traceback (most recent call last): File "/usr/home/buildbot/python/2.7.koobs-freebsd10/build/Lib/test/test_smtplib.py", line 222, in testHELP smtp = smtplib.SMTP(HOST, self.port, local_hostname='localhost', timeout=3) File "/usr/home/buildbot/python/2.7.koobs-freebsd10/build/Lib/smtplib.py", line 256, in __init__ (code, msg) = self.connect(host, port) File "/usr/home/buildbot/python/2.7.koobs-freebsd10/build/Lib/smtplib.py", line 317, in connect (code, msg) = self.getreply() File "/usr/home/buildbot/python/2.7.koobs-freebsd10/build/Lib/smtplib.py", line 365, in getreply + str(e)) SMTPServerDisconnected: Connection unexpectedly closed: timed out[283/401] test_abstract_numbers Complete log attached. ---------- nosy: +koobs resolution: wont fix -> stage: resolved -> needs patch status: closed -> open Added file: http://bugs.python.org/file39777/koobs-freebsd10.python.27.build978.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 04:46:51 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 23 Jun 2015 02:46:51 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1435027611.69.0.363930999923.issue24379@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 04:58:20 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 23 Jun 2015 02:58:20 +0000 Subject: =?utf-8?q?=5Bissue24487=5D_Change_asyncio=2Easync=28=29_=E2=86=92_ensure?= =?utf-8?b?X2Z1dHVyZSgp?= In-Reply-To: <1434983069.7.0.469854953168.issue24487@psf.upfronthosting.co.za> Message-ID: <1435028300.97.0.230813325912.issue24487@psf.upfronthosting.co.za> Martin Panter added the comment: There are a few references left in that revision. For instance still suggests scheduling a coroutine by calling async(). But depending on the context this may cause a syntax error in 3.5, so I think it should suggest calling ensure_future() instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 05:50:51 2015 From: report at bugs.python.org (sih4sing5hong5) Date: Tue, 23 Jun 2015 03:50:51 +0000 Subject: [issue24263] unittest cannot load module whose name starts with Unicode Message-ID: <1435031451.77.0.239152930978.issue24263@psf.upfronthosting.co.za> New submission from sih4sing5hong5: Because VALID_MODULE_NAME is r'[_a-z]\w*\.py$' in unittest/loader.py. Using r'[^\W\d]\w*\.py$' insteaded. ---------- keywords: +patch title: Why VALID_MODULE_NAME in unittest/loader.py is r'[_a-z]\w*\.py$' not r'\w+\.py$' ? -> unittest cannot load module whose name starts with Unicode Added file: http://bugs.python.org/file39778/VALID_MODULE_NAME.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 06:04:53 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 23 Jun 2015 04:04:53 +0000 Subject: [issue24263] unittest cannot load module whose name starts with Unicode In-Reply-To: <1435031451.77.0.239152930978.issue24263@psf.upfronthosting.co.za> Message-ID: <1435032293.23.0.900743276436.issue24263@psf.upfronthosting.co.za> Robert Collins added the comment: Are the module names valid in import statements? it would help if you could perhaps attach a little tar/zip file with an example failure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 06:12:29 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 23 Jun 2015 04:12:29 +0000 Subject: [issue24450] Add cr_await calculated property to coroutine object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1435032749.45.0.137271412886.issue24450@psf.upfronthosting.co.za> Nick Coghlan added the comment: Guido indicated on python-dev that he considered it reasonable to view adding gi_yieldfrom as part of the PEP 492 implementation: https://mail.python.org/pipermail/python-dev/2015-June/140498.html That perspective makes sense to me as well, since it preserves the functional equivalence of native coroutines (cr_await) and generator based coroutines (gi_yieldfrom) from a state introspection perspective. I've added Larry to the nosy list here to give him the option of veto'ing as release manager, but I think we want both in order to get full debuggability benefits. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 06:15:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Jun 2015 04:15:13 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1435032913.07.0.409591845501.issue24379@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is C implementation needed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 06:20:14 2015 From: report at bugs.python.org (Joe Jevnik) Date: Tue, 23 Jun 2015 04:20:14 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1435033214.69.0.956224228552.issue24379@psf.upfronthosting.co.za> Joe Jevnik added the comment: I just moved it over since I implemented it for slice originally, I can drop the C implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 06:46:53 2015 From: report at bugs.python.org (sih4sing5hong5) Date: Tue, 23 Jun 2015 04:46:53 +0000 Subject: [issue24263] unittest cannot load module whose name starts with Unicode In-Reply-To: <1435031451.77.0.239152930978.issue24263@psf.upfronthosting.co.za> Message-ID: <1435034813.61.0.961061171949.issue24263@psf.upfronthosting.co.za> sih4sing5hong5 added the comment: There is an attached file for examples. I ran {{{ cd test_dir python -m unittest -v }}} and got "Ran 1 test in 0.000s" ---------- Added file: http://bugs.python.org/file39779/test_dir.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 07:36:52 2015 From: report at bugs.python.org (sih4sing5hong5) Date: Tue, 23 Jun 2015 05:36:52 +0000 Subject: [issue24263] unittest cannot load module whose name starts with Unicode In-Reply-To: <1435031451.77.0.239152930978.issue24263@psf.upfronthosting.co.za> Message-ID: <1435037812.79.0.745321775504.issue24263@psf.upfronthosting.co.za> sih4sing5hong5 added the comment: By the way, I ran with Python 3.4.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 09:43:54 2015 From: report at bugs.python.org (Julien Palard) Date: Tue, 23 Jun 2015 07:43:54 +0000 Subject: [issue24486] http/client.py block indefinitely on line 308 in _read_status In-Reply-To: <1434978911.11.0.520674356543.issue24486@psf.upfronthosting.co.za> Message-ID: <1435045434.95.0.147041966419.issue24486@psf.upfronthosting.co.za> Julien Palard added the comment: I only have a `socket.setdefaulttimeout(10)` just after my imports... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 09:46:33 2015 From: report at bugs.python.org (DmitryJ) Date: Tue, 23 Jun 2015 07:46:33 +0000 Subject: [issue24467] bytearray pop and remove Buffer Over-read In-Reply-To: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za> Message-ID: <1435045593.94.0.692563591611.issue24467@psf.upfronthosting.co.za> DmitryJ added the comment: Offending code in 2.7: https://hg.python.org/cpython/file/20c9290a5de4/Objects/bytearrayobject.c#l2381 https://hg.python.org/cpython/file/20c9290a5de4/Objects/bytearrayobject.c#l2412 Let n = 16, where = 0; memmove() then attempts to copy (n - where) = 16 bytes where it should have copied 15, since we drop one. This appears to be a typical case of off-by-one. Changing (n - where) to (n - where - 1) should fix the issue. This underfows when (where + 1) > n, but this case is guarded against in bytearray_pop() and cannot occur in bytearray_remove(). The exact same memmove() invocation code is found in all 3.x branches as well. ---------- nosy: +dev_zzo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 09:52:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Jun 2015 07:52:31 +0000 Subject: [issue24467] bytearray pop and remove Buffer Over-read In-Reply-To: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za> Message-ID: <1435045951.22.0.229198726397.issue24467@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 10:16:21 2015 From: report at bugs.python.org (DmitryJ) Date: Tue, 23 Jun 2015 08:16:21 +0000 Subject: [issue24467] bytearray pop and remove Buffer Over-read In-Reply-To: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za> Message-ID: <1435047381.38.0.122917664575.issue24467@psf.upfronthosting.co.za> DmitryJ added the comment: Attached is a patch that fixes the reported issue. Since there are no visible side effects in Python, I could not write a test for this. ---------- keywords: +patch Added file: http://bugs.python.org/file39780/issue24467-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 10:16:43 2015 From: report at bugs.python.org (DmitryJ) Date: Tue, 23 Jun 2015 08:16:43 +0000 Subject: [issue24467] bytearray pop and remove Buffer Over-read In-Reply-To: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za> Message-ID: <1435047403.09.0.409631837578.issue24467@psf.upfronthosting.co.za> Changes by DmitryJ : Added file: http://bugs.python.org/file39781/issue24467-3.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 10:16:48 2015 From: report at bugs.python.org (DmitryJ) Date: Tue, 23 Jun 2015 08:16:48 +0000 Subject: [issue24467] bytearray pop and remove Buffer Over-read In-Reply-To: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za> Message-ID: <1435047408.55.0.0407164974299.issue24467@psf.upfronthosting.co.za> Changes by DmitryJ : Added file: http://bugs.python.org/file39782/issue24467-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 10:16:52 2015 From: report at bugs.python.org (DmitryJ) Date: Tue, 23 Jun 2015 08:16:52 +0000 Subject: [issue24467] bytearray pop and remove Buffer Over-read In-Reply-To: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za> Message-ID: <1435047412.19.0.0694571688913.issue24467@psf.upfronthosting.co.za> Changes by DmitryJ : Added file: http://bugs.python.org/file39783/issue24467-3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 10:16:56 2015 From: report at bugs.python.org (DmitryJ) Date: Tue, 23 Jun 2015 08:16:56 +0000 Subject: [issue24467] bytearray pop and remove Buffer Over-read In-Reply-To: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za> Message-ID: <1435047416.13.0.380373093689.issue24467@psf.upfronthosting.co.za> Changes by DmitryJ : Added file: http://bugs.python.org/file39784/issue24467-3.5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 10:24:17 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 23 Jun 2015 08:24:17 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1435047857.05.0.742936674096.issue24483@psf.upfronthosting.co.za> Larry Hastings added the comment: I suggest that 20 lines of identical code copy-and-pasted between two functions is not the cleanest way to do it. Find attached my version of the patch, which splits this common code out into a static function. ---------- Added file: http://bugs.python.org/file39785/clru_cache_known_hash_5.larry.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 10:30:05 2015 From: report at bugs.python.org (Paul Anton Letnes) Date: Tue, 23 Jun 2015 08:30:05 +0000 Subject: [issue10708] Misc/porting should be folded into the development FAQ or the devguide In-Reply-To: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za> Message-ID: <1435048205.11.0.474999639041.issue10708@psf.upfronthosting.co.za> Paul Anton Letnes added the comment: I created a patch to the devguide with some rewording as necessary. As I am not an expert on porting Python, it would be great if someone could point out any mistakes I made. The new FAQ is at the very bottom of the file, as I didn't find any other category to place it in. If people port Python to new platforms on a regular basis, I suggest adding a hint to discuss it on some mailing list, or that this FAQ is expanded into a more substantial piece of documentation. But then, I guess few people have an issue with Python not building on their system these days? Branch on bitbucket: issue10708-move-porting-to-devguide ---------- hgrepos: +314 keywords: +patch nosy: +pletnes Added file: http://bugs.python.org/file39786/issue10708-move-porting-to-devguide.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 11:50:34 2015 From: report at bugs.python.org (Cyd Haselton) Date: Tue, 23 Jun 2015 09:50:34 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1435053034.92.0.255728582486.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: UPDATE: Spent this past weekend fixing the broken on-device compiler. Will get to tests this weekend ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 12:00:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Jun 2015 10:00:04 +0000 Subject: [issue24263] unittest cannot load module whose name starts with Unicode In-Reply-To: <1435031451.77.0.239152930978.issue24263@psf.upfronthosting.co.za> Message-ID: <1435053604.84.0.122550773488.issue24263@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: r'[^\W\d]\w*' doesn't match all valid Python identifiers. It would be more correct to write the check as: root, ext = os.path.splitext(basename) if not (ext == '.py' and root.isidentifier()): # valid Python identifiers only return None, False ---------- nosy: +serhiy.storchaka versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 12:53:38 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 23 Jun 2015 10:53:38 +0000 Subject: [issue12210] test_smtplib: intermittent failures on FreeBSD In-Reply-To: <1306700978.51.0.107374125859.issue12210@psf.upfronthosting.co.za> Message-ID: <1435056818.24.0.848137866361.issue12210@psf.upfronthosting.co.za> R. David Murray added the comment: Those are in the second (or rather the first, in the file) group of tests, which have a timeout of 3 on python3. The comment in the test case says that DNS lookup delays can cause timeouts. Is there any chance that that machine sometimes has problems looking up 'localhost'? There is no record in this issue of any change being applied to the tests, and I don't see any changes by Stefan in the file. I suppose there's no real reason not to make all the timeouts 15 on both 2.7 and python3. It is weird that those tests should take so long to run, but more likely to be an environment problem than a python code problem. On the other hand, you might want to look in to why this is happening on FreeBSD, it might reveal something interesting. The problem with this theory, of course, is that we haven't apparently seen the timeouts on python3. But I'm not sure what to look at to try to diagnose a difference...the smtplib code isn't that different between the two, so presumably if there is a real difference it is at the level of the socket code. Since this is as far as we know only a test problem, we should probably just go ahead and increase the timeouts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 12:57:35 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 23 Jun 2015 10:57:35 +0000 Subject: [issue24263] unittest cannot load module whose name starts with Unicode In-Reply-To: <1435031451.77.0.239152930978.issue24263@psf.upfronthosting.co.za> Message-ID: <1435057055.04.0.114056899039.issue24263@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, I bet that regex is left over from python2, where we didn't have isidentifier. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 14:15:08 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 23 Jun 2015 12:15:08 +0000 Subject: [issue24489] cmath.polar() can raise due to pre-existing errno Message-ID: <1435061708.83.0.683406714861.issue24489@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Here is a patch, with additional tests. ---------- components: Library (Lib) files: polar_errno.patch keywords: patch messages: 245678 nosy: mark.dickinson, pitrou priority: normal severity: normal stage: patch review status: open title: cmath.polar() can raise due to pre-existing errno type: behavior versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39787/polar_errno.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 14:26:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 23 Jun 2015 12:26:04 +0000 Subject: [issue24489] cmath.polar() can raise due to pre-existing errno In-Reply-To: <1435061708.83.0.683406714861.issue24489@psf.upfronthosting.co.za> Message-ID: <1435062364.33.0.54187782108.issue24489@psf.upfronthosting.co.za> STINNER Victor added the comment: polar_errno.patch doesn't apply cleanly on the default branch, I get that you wrote your patch for Python 3.4. + @cpython_only + def test_polar_errno(self): + # Check a previously set C errno doesn't disturb polar() Please add the number of this issue in the comment. + inf = float('inf') + ... + nan = float('nan') On Python 3.5 and 3.6, You can use math.inf and math.nan. Except of that, the patch looks good to me. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 14:26:33 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 23 Jun 2015 12:26:33 +0000 Subject: [issue24439] Feedback for awaitable coroutine documentation In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za> Message-ID: <1435062393.55.0.520607608788.issue24439@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch with more improvements to the coroutine documentation, including: * Remove expansion of ?coroutine? glossary to include generators; it was not my original intention of this bug. Perhaps this can be dealt with separately in Issue 24087 if other people agree there is a problem. * Add Native Coroutine Objects section to /Doc/reference/datamodel.rst describing each method * Tweak coroutine and wrapper object doc strings to avoid generator terms * Mention native coroutines and ?await? in the asyncio Coroutines section, where the existing text only mentions generators and ?yield from? * Also recommend native coroutines, @asyncio.coroutine for calling native coroutines, etc I changed two of the asyncio coroutine examples to use ?async def? rather than generators. There is a third example that still uses generators which I did not change, because I would also have to update the sequence diagram. ---------- Added file: http://bugs.python.org/file39788/async-doc.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 14:27:04 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 23 Jun 2015 12:27:04 +0000 Subject: [issue24489] cmath.polar() can raise due to pre-existing errno In-Reply-To: <1435061708.83.0.683406714861.issue24489@psf.upfronthosting.co.za> Message-ID: <1435062424.84.0.858459824381.issue24489@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > On Python 3.5 and 3.6, You can use math.inf and math.nan. The patch is for 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 14:28:55 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 23 Jun 2015 12:28:55 +0000 Subject: [issue24489] cmath.polar() can raise due to pre-existing errno In-Reply-To: <1435061708.83.0.683406714861.issue24489@psf.upfronthosting.co.za> Message-ID: <1435062535.06.0.145654306031.issue24489@psf.upfronthosting.co.za> STINNER Victor added the comment: >> On Python 3.5 and 3.6, You can use math.inf and math.nan. > > The patch is for 3.4. Ok, it confirms my guess. But when you merge your change into 3.5, you may replace nan and inf with math.nan and math.inf. As you want. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 14:40:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 23 Jun 2015 12:40:14 +0000 Subject: [issue24489] cmath.polar() can raise due to pre-existing errno In-Reply-To: <1435061708.83.0.683406714861.issue24489@psf.upfronthosting.co.za> Message-ID: <20150623124004.1512.15887@psf.io> Roundup Robot added the comment: New changeset 70e3230c2872 by Antoine Pitrou in branch '3.4': Issue #24489: ensure a previously set C errno doesn't disturb cmath.polar(). https://hg.python.org/cpython/rev/70e3230c2872 New changeset d165712b2dee by Antoine Pitrou in branch '3.5': Issue #24489: ensure a previously set C errno doesn't disturb cmath.polar(). https://hg.python.org/cpython/rev/d165712b2dee New changeset b1fac7685947 by Antoine Pitrou in branch 'default': Issue #24489: ensure a previously set C errno doesn't disturb cmath.polar(). https://hg.python.org/cpython/rev/b1fac7685947 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 14:44:27 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 23 Jun 2015 12:44:27 +0000 Subject: [issue24489] cmath.polar() can raise due to pre-existing errno In-Reply-To: <1435061708.83.0.683406714861.issue24489@psf.upfronthosting.co.za> Message-ID: <20150623124423.46589.25693@psf.io> Roundup Robot added the comment: New changeset 9f4b066754c3 by Antoine Pitrou in branch '2.7': Issue #24489: ensure a previously set C errno doesn't disturb cmath.polar(). https://hg.python.org/cpython/rev/9f4b066754c3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 14:44:49 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 23 Jun 2015 12:44:49 +0000 Subject: [issue24489] cmath.polar() can raise due to pre-existing errno In-Reply-To: <1435061708.83.0.683406714861.issue24489@psf.upfronthosting.co.za> Message-ID: <1435063489.33.0.510827896091.issue24489@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, pushed it! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 14:49:50 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 23 Jun 2015 12:49:50 +0000 Subject: [issue24486] http/client.py block indefinitely on line 308 in _read_status In-Reply-To: <1434978911.11.0.520674356543.issue24486@psf.upfronthosting.co.za> Message-ID: <1435063790.19.0.387658556769.issue24486@psf.upfronthosting.co.za> Martin Panter added the comment: The closest I have is Python 3.3, but this times out properly for me: >>> from http.client import HTTPConnection >>> import socket >>> socket.setdefaulttimeout(10) >>> h = HTTPConnection("192.168.1.84") >>> h.request("GET", "/") >>> h.getresponse() Traceback (most recent call last): File "", line 1, in File "C:\Python33\lib\http\client.py", line 1147, in getresponse response.begin() File "C:\Python33\lib\http\client.py", line 358, in begin version, status, reason = self._read_status() File "C:\Python33\lib\http\client.py", line 320, in _read_status line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1") File "C:\Python33\lib\socket.py", line 297, in readinto return self._sock.recv_into(b) socket.timeout: timed out I suggest you either try to come up with a recipe to reproduce this with plain http.client, or look into whether the Requests package supports using the default socket timeout setting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 15:01:52 2015 From: report at bugs.python.org (Jorge Herskovic) Date: Tue, 23 Jun 2015 13:01:52 +0000 Subject: [issue24484] multiprocessing cleanup occasionally throws exception In-Reply-To: <1434899306.98.0.122661278895.issue24484@psf.upfronthosting.co.za> Message-ID: <1435064512.85.0.75375934038.issue24484@psf.upfronthosting.co.za> Jorge Herskovic added the comment: More data: I've been unable to replicate this behavior on Ubuntu 15.04 on Python 3.4.3 over ~20 thousand test runs. (Same machine, running in a VM) An overnight repeated run on the original machine on OS X, 3.4.3, official distribution gave an actual frequency of 0.1% (7 crashes in 6980 runs). Approximately 3,300 runs on Python 2.7.9 on the same machine have not resulted in any crashes. I now built 3.4.3 from source using the latest clang and am trying it again, on the same machine, instead of using the official distribution. So far, 0 crashes in approximately 3,300 runs so far. At the moment, then, the problem seems localized to the official 3.4.3 binaries for OS X. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 15:23:45 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 23 Jun 2015 13:23:45 +0000 Subject: [issue24458] Documentation for PEP 489 In-Reply-To: <1434452866.14.0.181014085851.issue24458@psf.upfronthosting.co.za> Message-ID: <1435065825.23.0.477138284052.issue24458@psf.upfronthosting.co.za> Nick Coghlan added the comment: Leaving the tutorial alone until the callback problem is resolved makes sense to me. The patch overall looks good, I sent a few more detailed comments via Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 15:51:48 2015 From: report at bugs.python.org (Nathan Jensen) Date: Tue, 23 Jun 2015 13:51:48 +0000 Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za> Message-ID: <1435067508.91.0.440299338846.issue23246@psf.upfronthosting.co.za> Nathan Jensen added the comment: Is it possible to get the license issues resolved and get this fixed in 2.7.11 since that's the last 2.7 release that is currently scheduled? ---------- nosy: +Nathan Jensen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 15:57:02 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 23 Jun 2015 13:57:02 +0000 Subject: [issue22032] Use __qualname__ together with __module__ In-Reply-To: <1406019756.34.0.140996851672.issue22032@psf.upfronthosting.co.za> Message-ID: <1435067822.03.0.475536607281.issue22032@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: FWIW, this broke the zope.testing doctests: https://bugs.launchpad.net/zope.testing/+bug/1467644 I submitted a patch, which was reasonable given the normalization that zope.testing does for doctest output, but people should be aware that this can break doctests. Unfortunately, short of the normalizing tricks that zope.testing does, there's no way to write such tests that are compatible with both 3.4 and 3.5. OTOH, I agree that raising nested exceptions the way zope.testing does is probably rare. ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 16:12:09 2015 From: report at bugs.python.org (Jakub Mateusz Kowalski) Date: Tue, 23 Jun 2015 14:12:09 +0000 Subject: [issue24490] DeprecationWarning hidden even after warnings.filterwarnings('always') called Message-ID: <1435068729.87.0.403412824944.issue24490@psf.upfronthosting.co.za> New submission from Jakub Mateusz Kowalski: The error occurs when there was a warning before the call to filterwarnings(): $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import warnings >>> warnings.warn('aa', DeprecationWarning) >>> warnings.filterwarnings('always') >>> warnings.warn('aa', DeprecationWarning) >>> When filterwarnings() is called before warnings, everything is working as expected: $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import warnings >>> warnings.filterwarnings('always') >>> warnings.warn('aa', DeprecationWarning) __main__:1: DeprecationWarning: aa >>> warnings.warn('aa', DeprecationWarning) __main__:1: DeprecationWarning: aa >>> ---------- components: Interpreter Core messages: 245691 nosy: Jakub.Mateusz.Kowalski priority: normal severity: normal status: open title: DeprecationWarning hidden even after warnings.filterwarnings('always') called type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 16:26:04 2015 From: report at bugs.python.org (sih4sing5hong5) Date: Tue, 23 Jun 2015 14:26:04 +0000 Subject: [issue24263] unittest cannot load module whose name starts with Unicode In-Reply-To: <1435031451.77.0.239152930978.issue24263@psf.upfronthosting.co.za> Message-ID: <1435069564.5.0.379534146459.issue24263@psf.upfronthosting.co.za> Changes by sih4sing5hong5 : Removed file: http://bugs.python.org/file39778/VALID_MODULE_NAME.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 16:27:43 2015 From: report at bugs.python.org (sih4sing5hong5) Date: Tue, 23 Jun 2015 14:27:43 +0000 Subject: [issue24263] unittest cannot load module whose name starts with Unicode In-Reply-To: <1435031451.77.0.239152930978.issue24263@psf.upfronthosting.co.za> Message-ID: <1435069663.01.0.363695840313.issue24263@psf.upfronthosting.co.za> sih4sing5hong5 added the comment: Thank you. I updated my patch in `VALID_MODULE_NAME.patch`. ---------- Added file: http://bugs.python.org/file39789/VALID_MODULE_NAME.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 16:57:21 2015 From: report at bugs.python.org (=?utf-8?b?SmFrdWIgS2FkbMSNw61r?=) Date: Tue, 23 Jun 2015 14:57:21 +0000 Subject: [issue2406] Improvement suggestions for the gzip module documentation In-Reply-To: <1205872183.57.0.209526870399.issue2406@psf.upfronthosting.co.za> Message-ID: <1435071441.64.0.279156448272.issue2406@psf.upfronthosting.co.za> Jakub Kadl??k added the comment: Hello, I think the example code snippets are awesome and no doubts, they helped me a lot. The only problem is that they are not idiomatic. They look like C more than Python. I suggest following patch ---------- nosy: +FrostyX Added file: http://bugs.python.org/file39790/idiomatic-gzip.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 18:46:56 2015 From: report at bugs.python.org (Zorceta) Date: Tue, 23 Jun 2015 16:46:56 +0000 Subject: [issue24491] inspect.getsource can't get source code if provided function isn't from a file Message-ID: <1435078016.43.0.770185123709.issue24491@psf.upfronthosting.co.za> New submission from Zorceta: Both python.exe and IDLE can't. IPython is able to, as it inserts REPL input into linecache. ---------- messages: 245694 nosy: zorceta priority: normal severity: normal status: open title: inspect.getsource can't get source code if provided function isn't from a file type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 19:31:19 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 23 Jun 2015 17:31:19 +0000 Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za> Message-ID: <1435080679.35.0.954451947925.issue23246@psf.upfronthosting.co.za> Steve Dower added the comment: That's two separate questions: > Is it possible to get the license issues resolved AFAICT they are resolved. Go ahead and copy the relevant code from setuptools. > get this fixed in 2.7.11 Why do you need/want to build without setuptools? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 19:40:13 2015 From: report at bugs.python.org (Armin Rigo) Date: Tue, 23 Jun 2015 17:40:13 +0000 Subject: [issue24492] using custom objects as modules: AttributeErrors new in 3.5 Message-ID: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za> New submission from Armin Rigo: A regression in 3.5: if we use custom objects as modules (like some projects do), then these custom objects may not have an attribute called "__name__". There is new code in 3.5 added for issue #17636 which tries sometimes to read the "__name__" of a module when executing an import statement, and if this leads to an AttributeError, it will get propagated. I imagine this could break real code using "try: except ImportError:". It _does_ break the tests of the "cffi" project, which try to check that some import of a nonexisting name correctly gives ImportError. Now it gives AttributeError("__name__") instead. ---------- components: Interpreter Core keywords: 3.4regression messages: 245696 nosy: arigo, larry priority: normal severity: normal status: open title: using custom objects as modules: AttributeErrors new in 3.5 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 19:43:59 2015 From: report at bugs.python.org (Ethan Furman) Date: Tue, 23 Jun 2015 17:43:59 +0000 Subject: [issue24492] using custom objects as modules: AttributeErrors new in 3.5 In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za> Message-ID: <1435081439.06.0.68990264674.issue24492@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +brett.cannon, eric.snow, ethan.furman, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 19:45:30 2015 From: report at bugs.python.org (Armin Rigo) Date: Tue, 23 Jun 2015 17:45:30 +0000 Subject: [issue24492] using custom objects as modules: AttributeErrors new in 3.5 In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za> Message-ID: <1435081530.2.0.067423496701.issue24492@psf.upfronthosting.co.za> Changes by Armin Rigo : Added file: http://bugs.python.org/file39791/test_case.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 20:16:29 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 23 Jun 2015 18:16:29 +0000 Subject: [issue24492] using custom objects as modules: AttributeErrors new in 3.5 In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za> Message-ID: <1435083389.24.0.763604706254.issue24492@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 21:09:32 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 23 Jun 2015 19:09:32 +0000 Subject: [issue24129] Incorrect (misleading) statement in the execution model documentation In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za> Message-ID: <1435086572.87.0.425668457641.issue24129@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: It looks like on python-dev (http://www.mail-archive.com/python-dev at python.org/msg88256.html) there is an agreement that this behavior should not be changed (at least not in the nearest future). If there are no more comments/suggestions, then maybe one could accept the latest patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 21:30:12 2015 From: report at bugs.python.org (Nathan Jensen) Date: Tue, 23 Jun 2015 19:30:12 +0000 Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za> Message-ID: <1435087812.74.0.997166075216.issue23246@psf.upfronthosting.co.za> Nathan Jensen added the comment: Ok, I was confused since the ticket was still marked as Open. We are trying to make an open source CPython extension available for download and building and we don't want to add a dependency on setuptools. We will patch our build commands based on the setuptools link provided in the message above. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 21:41:47 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 23 Jun 2015 19:41:47 +0000 Subject: [issue19235] Add a dedicated subclass for recursion errors In-Reply-To: <1381596107.9.0.320701037292.issue19235@psf.upfronthosting.co.za> Message-ID: <1435088507.27.0.989334970773.issue19235@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 21:52:50 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 23 Jun 2015 19:52:50 +0000 Subject: [issue24492] using custom objects as modules: AttributeErrors new in 3.5 In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za> Message-ID: <1435089170.73.0.444078304071.issue24492@psf.upfronthosting.co.za> Larry Hastings added the comment: What's a sensible approach to ameliorate the problem? Gracefully muddle through without a __name__ on the imported object? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 22:06:11 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 23 Jun 2015 20:06:11 +0000 Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za> Message-ID: <1435089971.18.0.175236802103.issue23246@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 22:37:07 2015 From: report at bugs.python.org (Florian Bruhin) Date: Tue, 23 Jun 2015 20:37:07 +0000 Subject: [issue24493] subprocess with env=os.environ fails with "fatal python error" when calling 32-bit python from 64-bit one on Windows Message-ID: <1435091827.68.0.4316449172.issue24493@psf.upfronthosting.co.za> New submission from Florian Bruhin: Trying to call a 32bit Python via subprocess from a 64bit one works as expected: Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:16:31) [MSC v.1600 64 bit (AMD64)] on win32 [...] >>> subprocess.check_call([r'C:\Python34_x32\python.exe', '-c', 'print("Hello World")']) Hello World However, when passing the `env` parameter, even just as `env=os.environ`, things break: >>> subprocess.check_call([r'C:\Python34_x32\python.exe', '-c', 'print("Hello World")'], env=os.environ) Fatal Python error: Failed to initialize Windows random API (CryptoGen) Starting a 64bit Python from the 64bit one works fine: >>> subprocess.check_call([r'C:\Python34\python.exe', '-c', 'print("Hello World")'], env=os.environ) Hello World According to issue20614 the "Fatal Python error" happens when SYSTEMROOT is not set, but that's definitely set in the original environment. Looking at the code, it just passes env to Windows' CreateProcess[1] - I guess this does *something* different in this scenario when None/NULL is given as compared to the os.environ dict? This breaks virtualenv with --python for me: C:\Users\florian\tmp>C:\Python34\python.exe -m virtualenv --python=C:\Python34_x32\python.exe venv3 Running virtualenv with interpreter C:\Python34_x32\python.exe Fatal Python error: Failed to initialize Windows random API (CryptoGen) [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx ---------- components: Library (Lib), Windows messages: 245700 nosy: The Compiler, astrand, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: subprocess with env=os.environ fails with "fatal python error" when calling 32-bit python from 64-bit one on Windows versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 23:13:47 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 23 Jun 2015 21:13:47 +0000 Subject: [issue23749] asyncio missing wrap_socket (starttls) In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1435094027.14.0.49047963958.issue23749@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: asyncio missing wrap_socket -> asyncio missing wrap_socket (starttls) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 23 23:17:02 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 23 Jun 2015 21:17:02 +0000 Subject: [issue22508] Remove __version__ string from email In-Reply-To: <1411851922.47.0.151418243457.issue22508@psf.upfronthosting.co.za> Message-ID: <1435094222.62.0.366028726793.issue22508@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: When I ported Mailman 3 to Python 3.5 I had to remove the check on email.__version__ :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 00:09:07 2015 From: report at bugs.python.org (Joe Jevnik) Date: Tue, 23 Jun 2015 22:09:07 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1435097347.97.0.577395463271.issue24379@psf.upfronthosting.co.za> Joe Jevnik added the comment: I removed the C implementation. ---------- Added file: http://bugs.python.org/file39792/operator_subscript_pyonly.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 01:47:06 2015 From: report at bugs.python.org (irdb) Date: Tue, 23 Jun 2015 23:47:06 +0000 Subject: [issue15348] IDLE - shell becomes unresponsive if debugger windows is closed while active. In-Reply-To: <1342208290.25.0.778184843655.issue15348@psf.upfronthosting.co.za> Message-ID: <1435103226.93.0.938295318066.issue15348@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 04:08:46 2015 From: report at bugs.python.org (eryksun) Date: Wed, 24 Jun 2015 02:08:46 +0000 Subject: [issue24493] subprocess with env=os.environ fails with "fatal python error" when calling 32-bit python from 64-bit one on Windows In-Reply-To: <1435091827.68.0.4316449172.issue24493@psf.upfronthosting.co.za> Message-ID: <1435111726.24.0.379183939247.issue24493@psf.upfronthosting.co.za> eryksun added the comment: I can't reproduce this in Windows 7 or 10 using Python 3.4. What gets printed for the following? import os import subprocess cmd32 = os.path.join(os.environ['SYSTEMROOT'], 'SysWOW64', 'cmd.exe') subprocess.call('{} /c set SYSTEMROOT'.format(cmd32), env=os.environ) ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 04:14:05 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 24 Jun 2015 02:14:05 +0000 Subject: [issue24484] multiprocessing cleanup occasionally throws exception In-Reply-To: <1434899306.98.0.122661278895.issue24484@psf.upfronthosting.co.za> Message-ID: <1435112045.87.0.29751643356.issue24484@psf.upfronthosting.co.za> Ned Deily added the comment: Can you show the version info from the Python 3.4 where you see the failures? /usr/local/bin/python3.4 -c 'import sys;print(sys.version)' ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 04:54:33 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 24 Jun 2015 02:54:33 +0000 Subject: [issue24484] multiprocessing cleanup occasionally throws exception In-Reply-To: <1434899306.98.0.122661278895.issue24484@psf.upfronthosting.co.za> Message-ID: <1435114473.59.0.106883577826.issue24484@psf.upfronthosting.co.za> Ned Deily added the comment: Exactly how are you building the Python 3.4 that does not fail for you? FWIW, I am able to reproduce the failure easily on a 10.10.3 system using python.org 64-bit/32-bit 3.4.3, using a current MacPorts source-built 3.4.3 (which is built with clang), and repeatedly using the current head of the 3.4 branch (post-3.4.3) built with clang, both with and without pydebug enabled. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 05:27:11 2015 From: report at bugs.python.org (Florian Bruhin) Date: Wed, 24 Jun 2015 03:27:11 +0000 Subject: [issue24493] subprocess with env=os.environ fails with "fatal python error" when calling 32-bit python from 64-bit one on Windows In-Reply-To: <1435091827.68.0.4316449172.issue24493@psf.upfronthosting.co.za> Message-ID: <1435116431.6.0.167691109805.issue24493@psf.upfronthosting.co.za> Florian Bruhin added the comment: That gives me "Environment variable SYSTEMROOT not defined" which would explain the "Fatal Python error" I'm seeing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 05:27:28 2015 From: report at bugs.python.org (Jorge Herskovic) Date: Wed, 24 Jun 2015 03:27:28 +0000 Subject: [issue24484] multiprocessing cleanup occasionally throws exception In-Reply-To: <1434899306.98.0.122661278895.issue24484@psf.upfronthosting.co.za> Message-ID: <1435116448.18.0.0898754394422.issue24484@psf.upfronthosting.co.za> Jorge Herskovic added the comment: The failing Python: 3.4.3 (v3.4.3:9b73f1c3e601, Feb 23 2015, 02:52:03) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] The non-failing Python: 3.4.3 (default, Jun 23 2015, 06:33:02) [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] The non-failing python, I just downloaded the tarball and ran ./configure --prefix=/opt/python343, make, sudo make install, and then created a virtualenv using that binary. Given what you're telling me, I'll run some more loops with the "non-failing" python. I'm grateful you've been able to reproduce the problem, FWIW. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 05:32:35 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 24 Jun 2015 03:32:35 +0000 Subject: [issue24490] DeprecationWarning hidden even after warnings.filterwarnings('always') called In-Reply-To: <1435068729.87.0.403412824944.issue24490@psf.upfronthosting.co.za> Message-ID: <1435116755.76.0.688890448003.issue24490@psf.upfronthosting.co.za> Ned Deily added the comment: The problem you describe was covered by Issue4180 and fixed in Python 3.4.2. From the discussion there, you can see that it was decided to not change the behavior of Python 2.7. ---------- nosy: +ned.deily resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> warnings.simplefilter("always") does not make warnings always show up _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 05:42:11 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 24 Jun 2015 03:42:11 +0000 Subject: [issue2406] Improvement suggestions for the gzip module documentation In-Reply-To: <1205872183.57.0.209526870399.issue2406@psf.upfronthosting.co.za> Message-ID: <1435117331.29.0.795035264129.issue2406@psf.upfronthosting.co.za> Ned Deily added the comment: Jakub, thanks for your suggested changes. But this issue was closed and the documentation updated many years ago. Please open a new issue with your suggested changes, otherwise they will likely be forgotten and ignored. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 05:44:12 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 24 Jun 2015 03:44:12 +0000 Subject: [issue24244] Python exception on strftime with %f on Python 3 and Python 2 on windows In-Reply-To: <1432096666.93.0.307433086156.issue24244@psf.upfronthosting.co.za> Message-ID: <1435117452.27.0.462320571567.issue24244@psf.upfronthosting.co.za> Steve Dower added the comment: Finally got back to looking at this, and since %f works against MSVC 14.0 I'm just going to remove the part of the test that is currently failing and close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 05:47:29 2015 From: report at bugs.python.org (lilydjwg) Date: Wed, 24 Jun 2015 03:47:29 +0000 Subject: [issue24494] Can't specify encoding with fileinput and inplace=True Message-ID: <1435117649.09.0.218021607576.issue24494@psf.upfronthosting.co.za> New submission from lilydjwg: I want to use fileinput to modify files, but find no way to specify the file encoding. I tried to use "hook_encoded", but it says "FileInput cannot use an opening hook in inplace mode". ---------- components: Library (Lib) messages: 245711 nosy: lilydjwg priority: normal severity: normal status: open title: Can't specify encoding with fileinput and inplace=True versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 05:49:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Jun 2015 03:49:09 +0000 Subject: [issue24244] Python exception on strftime with %f on Python 3 and Python 2 on windows In-Reply-To: <1432096666.93.0.307433086156.issue24244@psf.upfronthosting.co.za> Message-ID: <20150624034906.29322.96257@psf.io> Roundup Robot added the comment: New changeset 2c10e9f62613 by Steve Dower in branch '3.5': Closes #24244: Removes invalid test from test_time https://hg.python.org/cpython/rev/2c10e9f62613 New changeset f0ca1fabb41f by Steve Dower in branch 'default': Closes #24244: Removes invalid test from test_time https://hg.python.org/cpython/rev/f0ca1fabb41f ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 05:52:42 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 24 Jun 2015 03:52:42 +0000 Subject: [issue24484] multiprocessing cleanup occasionally throws exception In-Reply-To: <1434899306.98.0.122661278895.issue24484@psf.upfronthosting.co.za> Message-ID: <1435117962.81.0.322240812898.issue24484@psf.upfronthosting.co.za> Ned Deily added the comment: FWIW, building 3.4.3 from source as you described results in failures about 30% of the time. With some of the earlier tests, it failed even more frequently. This is running on a 2.2GHz I7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 06:04:29 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 24 Jun 2015 04:04:29 +0000 Subject: [issue12920] Document that inspect.getsource only works for objects loaded from files, not interactive session In-Reply-To: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za> Message-ID: <1435118669.12.0.525930121865.issue12920@psf.upfronthosting.co.za> Ned Deily added the comment: In duplicate Issue24491, zorceta notes: "Both python.exe and IDLE can't. IPython is able to, as it inserts REPL input into linecache." ---------- nosy: +ned.deily, zorceta versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 06:04:41 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 24 Jun 2015 04:04:41 +0000 Subject: [issue24491] inspect.getsource can't get source code if provided function isn't from a file In-Reply-To: <1435078016.43.0.770185123709.issue24491@psf.upfronthosting.co.za> Message-ID: <1435118681.58.0.806858433291.issue24491@psf.upfronthosting.co.za> Ned Deily added the comment: Issue12920 is currently open with a suggestion to change the documentation for inspect.getsource. ---------- nosy: +ned.deily resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Document that inspect.getsource only works for objects loaded from files, not interactive session _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 06:14:44 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 24 Jun 2015 04:14:44 +0000 Subject: [issue23639] Not documented special names In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za> Message-ID: <1435119284.82.0.473852871504.issue23639@psf.upfronthosting.co.za> Martin Panter added the comment: index-special.patch is a patch that adds index entries to the existing documentation that I found above. ---------- keywords: +patch versions: +Python 3.6 Added file: http://bugs.python.org/file39793/index-special.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 06:14:47 2015 From: report at bugs.python.org (Florian Bruhin) Date: Wed, 24 Jun 2015 04:14:47 +0000 Subject: [issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1 In-Reply-To: <1435091827.68.0.4316449172.issue24493@psf.upfronthosting.co.za> Message-ID: <1435119287.97.0.114509637529.issue24493@psf.upfronthosting.co.za> Florian Bruhin added the comment: Sorry I missed this - I can reproduce this on Windows 8.1, but not on Windows 7. I hope I'll be able to try another Windows 8.1 machine today. SYSTEMROOT is definitely set in the original environment: >>> os.environ['SYSTEMROOT'] 'C:\\Windows' >>> subprocess.call('{} /c set SYSTEMROOT'.format(cmd32), env=os.environ) Environment variable SYSTEMROOT not defined 1 >>> subprocess.call('{} /c set SYSTEMROOT'.format(cmd32)) SystemRoot=C:\Windows 0 It seems only a minimal set of environment variables are set in the spawned process: >>> subprocess.call('{} /c set'.format(cmd32), env=os.environ) COMSPEC=C:\Windows\SysWOW64\cmd.exe PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS;.MSC PROMPT=$P$G ---------- title: subprocess with env=os.environ fails with "fatal python error" when calling 32-bit python from 64-bit one on Windows -> subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 06:29:34 2015 From: report at bugs.python.org (sih4sing5hong5) Date: Wed, 24 Jun 2015 04:29:34 +0000 Subject: [issue24263] unittest cannot load module whose name starts with Unicode In-Reply-To: <1435031451.77.0.239152930978.issue24263@psf.upfronthosting.co.za> Message-ID: <1435120174.34.0.131143050366.issue24263@psf.upfronthosting.co.za> sih4sing5hong5 added the comment: update by adding `except AttributeError:` ---------- Added file: http://bugs.python.org/file39794/VALID_MODULE_NAME2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 07:28:04 2015 From: report at bugs.python.org (Milan Oberkirch) Date: Wed, 24 Jun 2015 05:28:04 +0000 Subject: [issue19111] 2to3 should remove from future_builtins import * In-Reply-To: <1380379953.79.0.934483665034.issue19111@psf.upfronthosting.co.za> Message-ID: <1435123684.6.0.900556277019.issue19111@psf.upfronthosting.co.za> Milan Oberkirch added the comment: Here is a simple patch that would solve this issue. The new fixer 'future_builtins' removes `from future_builtins import foo` statements if they aren't nested in other constructs (try-except, classes, ...) and replaces them with `pass` otherwise. ---------- keywords: +patch nosy: +zvyn versions: +Python 2.7, Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file39795/2to3_fix_future_builtins.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 07:43:49 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 24 Jun 2015 05:43:49 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1435124629.3.0.230962288073.issue24483@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry Larry, but I prefer Serhiy's version. The known_hash variants need to have their own function intact version and gum up the rest of the code. See the current known_hash function for comparison (Serhiy modeled on what we had already decided to do much earlier on a separate issue). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 07:45:05 2015 From: report at bugs.python.org (Zorceta) Date: Wed, 24 Jun 2015 05:45:05 +0000 Subject: [issue12920] inspect.getsource only works for objects loaded from files, not interactive session In-Reply-To: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za> Message-ID: <1435124705.17.0.300544785906.issue12920@psf.upfronthosting.co.za> Zorceta added the comment: When provided object is not from a file, like input in interactive shell, `inspect` internals will check for it in `linecache`, which official Python shell and IDLE won't put interactive shell input into, yet. This can be simply solved. Whether interactive shell input can be put into `linecache` may be a problem, but it'll make life easier, as interactive shell saves time from edit-save-run 'loop'. btw, I changed the title, since I don't think, what original author thought need to be documented, is absolutely right. ---------- title: Document that inspect.getsource only works for objects loaded from files, not interactive session -> inspect.getsource only works for objects loaded from files, not interactive session _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 07:46:39 2015 From: report at bugs.python.org (Zorceta) Date: Wed, 24 Jun 2015 05:46:39 +0000 Subject: [issue12920] inspect.getsource only works for objects loaded from files, not interactive session In-Reply-To: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za> Message-ID: <1435124798.99.0.00168299034264.issue12920@psf.upfronthosting.co.za> Changes by Zorceta : ---------- components: +IDLE, Interpreter Core -Documentation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 07:46:58 2015 From: report at bugs.python.org (Zorceta) Date: Wed, 24 Jun 2015 05:46:58 +0000 Subject: [issue12920] inspect.getsource only works for objects loaded from files, not interactive session In-Reply-To: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za> Message-ID: <1435124818.75.0.111963319657.issue12920@psf.upfronthosting.co.za> Changes by Zorceta : ---------- nosy: -docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 07:51:58 2015 From: report at bugs.python.org (eryksun) Date: Wed, 24 Jun 2015 05:51:58 +0000 Subject: [issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1 In-Reply-To: <1435091827.68.0.4316449172.issue24493@psf.upfronthosting.co.za> Message-ID: <1435125118.16.0.681358956258.issue24493@psf.upfronthosting.co.za> eryksun added the comment: > It seems only a minimal set of environment variables are set Apparently the initial environment is empty. The values you see are defaults set by cmd.exe when it starts. It also sets the 'hidden' variable "=C:" to the current directory on the C: drive, which you can see via set "". As a workaround, try running the command using shell=True (i.e. cmd /c). This should let you modify the environment passed to 64-bit cmd.exe, which will be inherited by the grandchild process that it creates. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 08:05:03 2015 From: report at bugs.python.org (Zorceta) Date: Wed, 24 Jun 2015 06:05:03 +0000 Subject: [issue12920] inspect.getsource only works for objects loaded from files, not interactive session In-Reply-To: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za> Message-ID: <1435125903.85.0.20624860234.issue12920@psf.upfronthosting.co.za> Zorceta added the comment: > When provided object is not from a file should be 'When `inspect` can't find the source file of provided object'. My mistake. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 09:09:45 2015 From: report at bugs.python.org (Florian Bruhin) Date: Wed, 24 Jun 2015 07:09:45 +0000 Subject: [issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1 In-Reply-To: <1435091827.68.0.4316449172.issue24493@psf.upfronthosting.co.za> Message-ID: <1435129785.32.0.277890722626.issue24493@psf.upfronthosting.co.za> Florian Bruhin added the comment: I've now updated to Python 3.4.3 and it's broken there as well. I tried on two other Windows 8.1 machines (with Python 3.4.3 and 3.4.1 respectively), and I can't reproduce there either... It works with shell=True indeed. I wonder why this is only broken on that one machine... It's a virtual machine which only has Firefox, Python, PyQt and a few Python packages installed - otherwise it's vanilla. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 10:29:24 2015 From: report at bugs.python.org (Armin Rigo) Date: Wed, 24 Jun 2015 08:29:24 +0000 Subject: [issue24492] using custom objects as modules: AttributeErrors new in 3.5 In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za> Message-ID: <1435134564.41.0.654218479466.issue24492@psf.upfronthosting.co.za> Armin Rigo added the comment: I'd guess so: if the PyObject_GetAttrId() fails, then ignore the rest of the code that was added in https://hg.python.org/cpython/rev/fded07a2d616 and jump straight to ``PyErr_Format(PyExc_ImportError, ...)``. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 10:35:18 2015 From: report at bugs.python.org (Armin Rigo) Date: Wed, 24 Jun 2015 08:35:18 +0000 Subject: [issue24492] using custom objects as modules: AttributeErrors new in 3.5 In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za> Message-ID: <1435134918.0.0.287820936223.issue24492@psf.upfronthosting.co.za> Armin Rigo added the comment: Also, if we want to be paranoid, the _PyObject_GetAttrId() can return anything, not necessarily a string object. This would make the following PyUnicode_FromFormat() fail. So maybe you also want to overwrite failures in PyUnicode_FromFormat() with the final ImportError. (It actually looks like a good--if convoluted--use case for exception chaining at the C level...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 10:35:28 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 24 Jun 2015 08:35:28 +0000 Subject: =?utf-8?q?=5Bissue24495=5D_asyncio=2Eensure=5Ffuture=28=29_AttributeError?= =?utf-8?q?_with_=E2=80=9Casync_def=E2=80=9D_coroutines?= Message-ID: <1435134928.01.0.885019628037.issue24495@psf.upfronthosting.co.za> New submission from Martin Panter: While trying to port the example at to use ?async def?, I discovered the ensure_future() function does not like the coroutine field name changes introduced in Issue 24400: >>> asyncio.ensure_future(slow_operation(future)) Traceback (most recent call last): File "", line 1, in File "/home/proj/python/cpython/Lib/asyncio/futures.py", line 196, in __repr__ info = self._repr_info() File "/home/proj/python/cpython/Lib/asyncio/tasks.py", line 105, in _repr_info coro = coroutines._format_coroutine(self._coro) File "/home/proj/python/cpython/Lib/asyncio/coroutines.py", line 242, in _format_coroutine filename = coro.gi_code.co_filename AttributeError: 'coroutine' object has no attribute 'gi_code' I understand the gi_ names all changed to cr_, so I guess this code has to adjust as well. ---------- components: asyncio messages: 245727 nosy: gvanrossum, haypo, vadmium, yselivanov priority: normal severity: normal stage: needs patch status: open title: asyncio.ensure_future() AttributeError with ?async def? coroutines type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 10:47:29 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Jun 2015 08:47:29 +0000 Subject: =?utf-8?q?=5Bissue24495=5D_asyncio=2Eensure=5Ffuture=28=29_AttributeError?= =?utf-8?q?_with_=E2=80=9Casync_def=E2=80=9D_coroutines?= In-Reply-To: <1435134928.01.0.885019628037.issue24495@psf.upfronthosting.co.za> Message-ID: <1435135649.3.0.222625541165.issue24495@psf.upfronthosting.co.za> STINNER Victor added the comment: It's not the first time that a bug in found in _format_coroutine(). We need more unit tests! Previous bug: https://github.com/python/asyncio/issues/222 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 12:17:13 2015 From: report at bugs.python.org (=?utf-8?b?SmFrdWIgS2FkbMSNw61r?=) Date: Wed, 24 Jun 2015 10:17:13 +0000 Subject: [issue24496] Non-idiomatic examples in gzip docs Message-ID: <1435141033.01.0.69017919729.issue24496@psf.upfronthosting.co.za> New submission from Jakub Kadl??k: Hello, I think there are awesome example code snippets in gzip documentation. No doubt, they helped me a lot. The only problem is that they are not idiomatic. They look like C more than Python. I suggest following patch ---------- assignee: docs at python components: Documentation files: idiomatic-gzip.diff keywords: patch messages: 245729 nosy: FrostyX, docs at python priority: normal severity: normal status: open title: Non-idiomatic examples in gzip docs type: enhancement Added file: http://bugs.python.org/file39796/idiomatic-gzip.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 13:04:23 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 24 Jun 2015 11:04:23 +0000 Subject: [issue24496] Non-idiomatic examples in gzip docs In-Reply-To: <1435141033.01.0.69017919729.issue24496@psf.upfronthosting.co.za> Message-ID: <1435143863.01.0.185734309698.issue24496@psf.upfronthosting.co.za> Martin Panter added the comment: It looks like this is for Python 2. I agree with the change, but I suggest back-porting revisions 35c53e7e2280, a01992e219c0 and ae1528beae67 (Issue 21146) instead, to match the Python 3 documentation. ---------- nosy: +vadmium versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 13:45:46 2015 From: report at bugs.python.org (Jorge Herskovic) Date: Wed, 24 Jun 2015 11:45:46 +0000 Subject: [issue24484] multiprocessing cleanup occasionally throws exception In-Reply-To: <1434899306.98.0.122661278895.issue24484@psf.upfronthosting.co.za> Message-ID: <1435146346.2.0.504761336634.issue24484@psf.upfronthosting.co.za> Jorge Herskovic added the comment: 20,000+ iterations of the test suite with my homebuilt 3.4.3 throw no exceptions. Weirder and weirder. Any suggestions? Without any actual knowledge ("unencumbered by the thought process"), a concurrency issue in the interpreter itself is my guess. Especially since I can't reproduce it at all on other versions. I'll see if I can come up with a shorter, self-contained test that can illustrate the issue too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 14:04:23 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 24 Jun 2015 12:04:23 +0000 Subject: [issue24450] Add cr_await calculated property to coroutine object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1435147463.23.0.845839719738.issue24450@psf.upfronthosting.co.za> Martin Panter added the comment: For Benno?s original gi_yieldfrom property, I guess the asyncio.coroutines.CoroWrapper class would need updating. The GeneratorWrapper class for @types.coroutine probably should be updated too, since it already supports other internal generator properties. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 14:09:50 2015 From: report at bugs.python.org (Armin Rigo) Date: Wed, 24 Jun 2015 12:09:50 +0000 Subject: [issue24450] Add cr_await calculated property to coroutine object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1435147790.66.0.789921547645.issue24450@psf.upfronthosting.co.za> Changes by Armin Rigo : ---------- nosy: -arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 14:16:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 24 Jun 2015 12:16:19 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1435148179.31.0.597129639307.issue24483@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I would prefer do not repeat the code, but I afraid this can affect the performance, and the performance of PyDict_GetItem is critical for Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 14:36:04 2015 From: report at bugs.python.org (mattyw) Date: Wed, 24 Jun 2015 12:36:04 +0000 Subject: [issue24497] test_decimal.py contains a dead link Message-ID: <1435149364.96.0.261968389532.issue24497@psf.upfronthosting.co.za> New submission from mattyw: The comments in test_decimal contain a url for downloading tests written by Mike Cowlishaw: Cowlishaw's tests can be downloaded from: www2.hursley.ibm.com/decimal/dectest.zip Python 3.4.3 contains an updated url: http://speleotrove.com/decimal/dectest.zip It seems like the url should be updated in 2.7 as well ---------- assignee: docs at python components: Documentation messages: 245734 nosy: docs at python, mattyw priority: normal severity: normal status: open title: test_decimal.py contains a dead link versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 14:42:06 2015 From: report at bugs.python.org (mattyw) Date: Wed, 24 Jun 2015 12:42:06 +0000 Subject: [issue24497] test_decimal.py contains a dead link In-Reply-To: <1435149364.96.0.261968389532.issue24497@psf.upfronthosting.co.za> Message-ID: <1435149726.39.0.729294397419.issue24497@psf.upfronthosting.co.za> Changes by mattyw : ---------- keywords: +patch Added file: http://bugs.python.org/file39797/24497.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 14:46:20 2015 From: report at bugs.python.org (Julien Palard) Date: Wed, 24 Jun 2015 12:46:20 +0000 Subject: [issue24486] http/client.py block indefinitely on line 308 in _read_status In-Reply-To: <1434978911.11.0.520674356543.issue24486@psf.upfronthosting.co.za> Message-ID: <1435149980.39.0.821865546571.issue24486@psf.upfronthosting.co.za> Julien Palard added the comment: OK, so, requests have a `timeout` and take it into account, and it solves my problem. Yet I don't understand one little thing: With both requests `timeout` parameter set or unset, the exact same http.client.py:_read_status call the same socket.readinto. With a `request` `timeout`, the socket.readinto uses the recvfrom syscall, but with a `request` `timeout`, readinto uses a `poll` syscall with the given timeout. The root of the problem is that urllib3 ignores the `socket` `defaulttimeout`, I opened a ticket on this: https://github.com/shazow/urllib3/issues/655#issuecomment-114835279 So this ticket can be considered closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 14:46:28 2015 From: report at bugs.python.org (Julien Palard) Date: Wed, 24 Jun 2015 12:46:28 +0000 Subject: [issue24486] http/client.py block indefinitely on line 308 in _read_status In-Reply-To: <1434978911.11.0.520674356543.issue24486@psf.upfronthosting.co.za> Message-ID: <1435149988.24.0.891816323281.issue24486@psf.upfronthosting.co.za> Changes by Julien Palard : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 14:55:59 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 24 Jun 2015 12:55:59 +0000 Subject: [issue24486] http/client.py block indefinitely on line 308 in _read_status In-Reply-To: <1434978911.11.0.520674356543.issue24486@psf.upfronthosting.co.za> Message-ID: <1435150559.0.0.652619180925.issue24486@psf.upfronthosting.co.za> Martin Panter added the comment: I assume you meant _without_ an explicit timeout setting in Requests, you see a recvfrom() system call, and _with_ an explicit timeout you see poll(). I guess that would be because Requests is using a blocking socket in the first case, and in the second case the timeout is implemented by waiting for data to be available before reading it. ---------- resolution: -> third party stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 15:11:50 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 24 Jun 2015 13:11:50 +0000 Subject: [issue24439] Feedback for awaitable coroutine documentation In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za> Message-ID: <1435151510.45.0.508296018377.issue24439@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for reviewing this Yury. Here is a new patch: * Drop the ?native? term; distinguish by referring to ?async def? where necessary * Add generator version of display_date() coroutine example * Change chained coroutine example over to ?async def? and updated sequence diagram * Change one other example over (then I ran into Issue 24495) * Include Yury?s new documentation for @types.coroutine from Issue 24325 ---------- Added file: http://bugs.python.org/file39798/async-doc.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 15:13:43 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 24 Jun 2015 13:13:43 +0000 Subject: [issue24439] Feedback for awaitable coroutine documentation In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za> Message-ID: <1435151623.38.0.902448823676.issue24439@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file39799/tulip_coro.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 15:17:03 2015 From: report at bugs.python.org (Jorge Herskovic) Date: Wed, 24 Jun 2015 13:17:03 +0000 Subject: [issue24484] multiprocessing cleanup occasionally throws exception In-Reply-To: <1434899306.98.0.122661278895.issue24484@psf.upfronthosting.co.za> Message-ID: <1435151823.78.0.737548763381.issue24484@psf.upfronthosting.co.za> Jorge Herskovic added the comment: Finally able to repro on my old Mac Pro at work (Universal 64/32bit 3.4.3 from python.org, OS X 10.10.3). For some reason I can't quite fathom, there were two exceptions this time. Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/util.py", line 286, in _exit_function _run_finalizers(0) File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/util.py", line 246, in _run_finalizers items = [x for x in list(_finalizer_registry.items()) if f(x)] RuntimeError: dictionary changed size during iteration Exception ignored in: Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/util.py", line 185, in __call__ File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/multiprocessing/queues.py", line 207, in _finalize_close File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threading.py", line 342, in notify TypeError: 'NoneType' object is not callable ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 15:28:58 2015 From: report at bugs.python.org (Jorge Herskovic) Date: Wed, 24 Jun 2015 13:28:58 +0000 Subject: [issue24484] multiprocessing cleanup occasionally throws exception In-Reply-To: <1434899306.98.0.122661278895.issue24484@psf.upfronthosting.co.za> Message-ID: <1435152538.05.0.668452574811.issue24484@psf.upfronthosting.co.za> Jorge Herskovic added the comment: Ok, sorry, one more important thing I omitted in the previous comment. ^^^ The second exception above seems to be related to a new test I added, one that includes a daemonic process which itself relies on daemonic threads. The cleanup of that seems to be FUBARed, and it makes the original exception much more likely to pop up as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 15:38:34 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 24 Jun 2015 13:38:34 +0000 Subject: [issue24494] Can't specify encoding with fileinput and inplace=True In-Reply-To: <1435117649.09.0.218021607576.issue24494@psf.upfronthosting.co.za> Message-ID: <1435153114.45.0.958227984779.issue24494@psf.upfronthosting.co.za> R. David Murray added the comment: I presume this is because openhook could be anything, including something where the inplace code couldn't even find the file to rename. On the other hand, Python is a "consenting adults" language, so we can assume you know what you are doing if you specify both. I think this restriction could be relaxed, and am willing to review a patch proposal to so, if it comes with tests :). ---------- nosy: +r.david.murray stage: -> needs patch type: -> enhancement versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 15:38:52 2015 From: report at bugs.python.org (Stefan Krah) Date: Wed, 24 Jun 2015 13:38:52 +0000 Subject: [issue12210] test_smtplib: intermittent failures on FreeBSD In-Reply-To: <1306700978.51.0.107374125859.issue12210@psf.upfronthosting.co.za> Message-ID: <1435153132.04.0.444016655199.issue12210@psf.upfronthosting.co.za> Stefan Krah added the comment: If it is a DNS failure, the timeout of 3s indeed looks too low for me. On a misconfigured machine I'm easily getting timeouts of 20s, (not for this particular test, just in general, e.g. when using ssh). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 15:42:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Jun 2015 13:42:25 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <20150624134222.66908.53206@psf.io> Roundup Robot added the comment: New changeset f4b702672beb by Yury Selivanov in branch '3.4': asyncio: Merge changes from issue #24400. https://hg.python.org/cpython/rev/f4b702672beb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 16:05:12 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 24 Jun 2015 14:05:12 +0000 Subject: [issue12210] test_smtplib: intermittent failures on FreeBSD In-Reply-To: <1306700978.51.0.107374125859.issue12210@psf.upfronthosting.co.za> Message-ID: <1435154712.31.0.467877616773.issue12210@psf.upfronthosting.co.za> R. David Murray added the comment: It would have to be a misconfigured machine that doesn't have 'localhost' in /etc/hosts (so that a lookup of localhost goes through DNS). Or, I suppose, one that prioritizes the resolver over /etc/hosts (is that even possible?) I would think other tests would fail if DNS has a 20 second latency. I think having localhost configured in /etc/hosts is a requirement for other tests, so if that really is the problem I'm not sure we should be fixing the test suite here. On the third hand, it doesn't really matter in this case and we're already using 15 for other tests, so I have no objection to making the test consistent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 16:26:30 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 24 Jun 2015 14:26:30 +0000 Subject: [issue24498] Shoudl ptags and eptags be removed from repo? Message-ID: <1435155990.35.0.688744790399.issue24498@psf.upfronthosting.co.za> New submission from R. David Murray: ctags directly supports python. Is there any reason to keep the ptags and eptags scripts in Tools/scripts? ---------- messages: 245744 nosy: r.david.murray priority: normal severity: normal status: open title: Shoudl ptags and eptags be removed from repo? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 16:43:48 2015 From: report at bugs.python.org (Stefan Krah) Date: Wed, 24 Jun 2015 14:43:48 +0000 Subject: [issue12210] test_smtplib: intermittent failures on FreeBSD In-Reply-To: <1306700978.51.0.107374125859.issue12210@psf.upfronthosting.co.za> Message-ID: <1435157028.44.0.381009962297.issue12210@psf.upfronthosting.co.za> Stefan Krah added the comment: I think it's also possible to misconfigure /etc/nsswitch.conf. When I opened this issue, my buildbot had the FreeBSD default configuration. I no longer have any FreeBSD machines, so I cannot check this now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 16:48:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Jun 2015 14:48:37 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <20150624144833.49106.34117@psf.io> Roundup Robot added the comment: New changeset 3a78be4bcbde by Yury Selivanov in branch '3.4': Issue #24400: Fix CoroWrapper for 'async def' coroutines https://hg.python.org/cpython/rev/3a78be4bcbde New changeset 338597d2e93b by Yury Selivanov in branch '3.5': Issue #24400: Fix CoroWrapper for 'async def' coroutines https://hg.python.org/cpython/rev/338597d2e93b New changeset 2e4d604c449d by Yury Selivanov in branch 'default': Issue #24400: Fix CoroWrapper for 'async def' coroutines https://hg.python.org/cpython/rev/2e4d604c449d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 16:50:02 2015 From: report at bugs.python.org (Jens Diemer) Date: Wed, 24 Jun 2015 14:50:02 +0000 Subject: [issue21417] Compression level for zipfile In-Reply-To: <1399053616.42.0.124840881006.issue21417@psf.upfronthosting.co.za> Message-ID: <1435157402.53.0.42101935675.issue21417@psf.upfronthosting.co.za> Changes by Jens Diemer : ---------- nosy: +jens _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 16:52:32 2015 From: report at bugs.python.org (Jens Diemer) Date: Wed, 24 Jun 2015 14:52:32 +0000 Subject: [issue19894] zipfile ignores deflate level settings in zipinfo object In-Reply-To: <1386235609.47.0.431866049959.issue19894@psf.upfronthosting.co.za> Message-ID: <1435157552.89.0.411587704802.issue19894@psf.upfronthosting.co.za> Jens Diemer added the comment: IMHO it should be possible to set compression level not only for DEFLATE. And it should be similar with the tarfile API. Seems that http://bugs.python.org/issue21417 will cover this. ---------- nosy: +jens _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 16:55:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Jun 2015 14:55:48 +0000 Subject: =?utf-8?q?=5Bissue24495=5D_asyncio=2Eensure=5Ffuture=28=29_AttributeError?= =?utf-8?q?_with_=E2=80=9Casync_def=E2=80=9D_coroutines?= In-Reply-To: <1435134928.01.0.885019628037.issue24495@psf.upfronthosting.co.za> Message-ID: <20150624145543.108389.11944@psf.io> Roundup Robot added the comment: New changeset 8f4e738cb07f by Yury Selivanov in branch '3.5': Issue #24495, #24400: Test asyncio.Task.repr in debug mode https://hg.python.org/cpython/rev/8f4e738cb07f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 16:55:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Jun 2015 14:55:48 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <20150624145543.108389.73736@psf.io> Roundup Robot added the comment: New changeset 8f4e738cb07f by Yury Selivanov in branch '3.5': Issue #24495, #24400: Test asyncio.Task.repr in debug mode https://hg.python.org/cpython/rev/8f4e738cb07f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 16:57:31 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 24 Jun 2015 14:57:31 +0000 Subject: =?utf-8?q?=5Bissue24495=5D_asyncio=2Eensure=5Ffuture=28=29_AttributeError?= =?utf-8?q?_with_=E2=80=9Casync_def=E2=80=9D_coroutines?= In-Reply-To: <1435134928.01.0.885019628037.issue24495@psf.upfronthosting.co.za> Message-ID: <1435157851.26.0.410969856648.issue24495@psf.upfronthosting.co.za> Yury Selivanov added the comment: Should be fixed now. Thanks for discovering this, Martin! Victor, I'll make a PR on github/asyncio with some refactoring or CoroWrapper etc. The code became too cumbersome, and has to be properly refactored. At least we should have one wrapper class for generator based coroutines, and another one for 'async def' ones. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 17:04:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Jun 2015 15:04:57 +0000 Subject: [issue24439] Feedback for awaitable coroutine documentation In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za> Message-ID: <20150624150454.29618.46250@psf.io> Roundup Robot added the comment: New changeset e31aad001fdb by Yury Selivanov in branch '3.5': Issue #24439: Improve PEP 492 related docs. https://hg.python.org/cpython/rev/e31aad001fdb New changeset d99770da3b2a by Yury Selivanov in branch 'default': Merge 3.5 (issue #24439) https://hg.python.org/cpython/rev/d99770da3b2a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 17:06:25 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 24 Jun 2015 15:06:25 +0000 Subject: [issue24439] Feedback for awaitable coroutine documentation In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za> Message-ID: <1435158385.16.0.978857893167.issue24439@psf.upfronthosting.co.za> Yury Selivanov added the comment: Committed. Thanks a lot, Martin! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 17:10:54 2015 From: report at bugs.python.org (Jens Diemer) Date: Wed, 24 Jun 2015 15:10:54 +0000 Subject: [issue21417] Compression level for zipfile In-Reply-To: <1399053616.42.0.124840881006.issue21417@psf.upfronthosting.co.za> Message-ID: <1435158654.33.0.162447457566.issue21417@psf.upfronthosting.co.za> Jens Diemer added the comment: btw. hacked work-a-round is: zlib.Z_DEFAULT_COMPRESSION = 9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 17:14:47 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 24 Jun 2015 15:14:47 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1435158887.32.0.040599490548.issue24483@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I would prefer do not repeat the code, but I afraid this can affect the performance, and the performance of PyDict_GetItem is critical for Python. Static function calls like that one will most likely be inlined by the compiler... But if you don't want to rely on that, maybe we can use a macro to avoid code duplication? ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 17:44:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 24 Jun 2015 15:44:57 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1435158887.32.0.040599490548.issue24483@psf.upfronthosting.co.za> Message-ID: <1595810.ElYSPzWV63@raxxla> Serhiy Storchaka added the comment: > But if you don't want to rely on that, maybe we can use a macro > to avoid code duplication? This will not make the code cleaner. In any case this is other issue. ---------- title: Avoid repeated hash calculation in C implementation of functools.lru_cache() -> Avoid repeated hash calculation in C implementation of functools.lru_cache() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 17:45:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Jun 2015 15:45:33 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <20150624154527.53102.82965@psf.io> Roundup Robot added the comment: New changeset eb6fb8e2f995 by Yury Selivanov in branch '3.5': Issue #24325, #24400: Add more unittests for types.coroutine; tweak wrapper implementation. https://hg.python.org/cpython/rev/eb6fb8e2f995 New changeset 7a2a79362bbe by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24325, #24400) https://hg.python.org/cpython/rev/7a2a79362bbe ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 17:45:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Jun 2015 15:45:33 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <20150624154527.53102.15273@psf.io> Roundup Robot added the comment: New changeset eb6fb8e2f995 by Yury Selivanov in branch '3.5': Issue #24325, #24400: Add more unittests for types.coroutine; tweak wrapper implementation. https://hg.python.org/cpython/rev/eb6fb8e2f995 New changeset 7a2a79362bbe by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24325, #24400) https://hg.python.org/cpython/rev/7a2a79362bbe ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 17:48:05 2015 From: report at bugs.python.org (Matthieu Gautier) Date: Wed, 24 Jun 2015 15:48:05 +0000 Subject: =?utf-8?q?=5Bissue23319=5D_Missing_SWAP=5FINT=C2=A0in_I=5Fset=5Fsw?= In-Reply-To: <1422212017.26.0.671058309435.issue23319@psf.upfronthosting.co.za> Message-ID: <1435160885.74.0.897392367346.issue23319@psf.upfronthosting.co.za> Matthieu Gautier added the comment: A little ping. With a new patch integrating the unit test. ---------- Added file: http://bugs.python.org/file39800/ctypes_swap_uint_unittest.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 17:59:31 2015 From: report at bugs.python.org (=?utf-8?b?WmFjaCDigJxUaGUgUXVhbnR1bSBNZWNoYW5pY+KAnSBX?=) Date: Wed, 24 Jun 2015 15:59:31 +0000 Subject: [issue24499] Python Installer text piles up during installation process Message-ID: <1435161571.8.0.161419365704.issue24499@psf.upfronthosting.co.za> New submission from Zach ?The Quantum Mechanic? W: A minor visual bug that causes text to "pile up" in the installer window. Installation finished, python seems to run fine. Operating System: Windows 8.1 64x Installer: Python 3.5.0b2 ---------- components: Installation files: python_installer_visual_error.png messages: 245759 nosy: Zach ?The Quantum Mechanic? W priority: normal severity: normal status: open title: Python Installer text piles up during installation process type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39801/python_installer_visual_error.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 18:03:02 2015 From: report at bugs.python.org (Zahari Dim) Date: Wed, 24 Jun 2015 16:03:02 +0000 Subject: [issue24500] xontextlib.redirect_stdout should redirect C output Message-ID: <1435161782.93.0.989546707262.issue24500@psf.upfronthosting.co.za> New submission from Zahari Dim: It is common to have an inflexible C wrapper with lots of undesired output. However it is not so trivial to supress (or redirect) that output from Python in a selective way. contextlib.redirect_stdout doesn't help, since it only changes sys.sdout, without touching the actual file descriptor. The following worked for my use case, which I adapted from here http://eli.thegreenplace.net/2015/redirecting-all-kinds-of-stdout-in-python/: import sys import os from contextlib import contextmanager, redirect_stdout @contextmanager def supress_stdout(): devnull = open(os.devnull, 'wb') try: stdout_flieno = sys.stdout.fileno() except ValueError: redirect = False else: redirect = True sys.stdout.flush() #sys.stdout.close() devnull_fileno = devnull.fileno() saved_stdout_fd = os.dup(stdout_flieno) os.dup2(devnull_fileno, stdout_flieno) with redirect_stdout(devnull): yield if redirect: os.dup2(stdout_flieno, saved_stdout_fd) ---------- components: Extension Modules, Library (Lib) messages: 245760 nosy: Zahari.Dim priority: normal severity: normal status: open title: xontextlib.redirect_stdout should redirect C output type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 18:09:46 2015 From: report at bugs.python.org (Zahari Dim) Date: Wed, 24 Jun 2015 16:09:46 +0000 Subject: [issue24500] contextlib.redirect_stdout should redirect C output In-Reply-To: <1435161782.93.0.989546707262.issue24500@psf.upfronthosting.co.za> Message-ID: <1435162186.33.0.201726409485.issue24500@psf.upfronthosting.co.za> Changes by Zahari Dim : ---------- title: xontextlib.redirect_stdout should redirect C output -> contextlib.redirect_stdout should redirect C output _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 18:19:02 2015 From: report at bugs.python.org (Pete Lancashire) Date: Wed, 24 Jun 2015 16:19:02 +0000 Subject: [issue24501] configure does not find (n)curses in /usr/local/libs Message-ID: <1435162742.72.0.811828390011.issue24501@psf.upfronthosting.co.za> Changes by Pete Lancashire : ---------- components: Build nosy: petepdx priority: normal severity: normal status: open title: configure does not find (n)curses in /usr/local/libs type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 18:52:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Jun 2015 16:52:04 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <20150624165200.38096.22476@psf.io> Roundup Robot added the comment: New changeset 9aee273bf8b7 by Yury Selivanov in branch '3.5': Issue #24400, #24325: More tests for types._GeneratorWrapper https://hg.python.org/cpython/rev/9aee273bf8b7 New changeset fa097a336079 by Yury Selivanov in branch 'default': Merge 3.5 (issue #24325 & #24400) https://hg.python.org/cpython/rev/fa097a336079 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 18:52:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Jun 2015 16:52:04 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <20150624165200.38096.93552@psf.io> Roundup Robot added the comment: New changeset 9aee273bf8b7 by Yury Selivanov in branch '3.5': Issue #24400, #24325: More tests for types._GeneratorWrapper https://hg.python.org/cpython/rev/9aee273bf8b7 New changeset fa097a336079 by Yury Selivanov in branch 'default': Merge 3.5 (issue #24325 & #24400) https://hg.python.org/cpython/rev/fa097a336079 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 18:55:04 2015 From: report at bugs.python.org (Pete Lancashire) Date: Wed, 24 Jun 2015 16:55:04 +0000 Subject: [issue24501] configure does not find (n)curses in /usr/local/libs Message-ID: <1435164904.34.0.98182021259.issue24501@psf.upfronthosting.co.za> New submission from Pete Lancashire: ./configure does not find ncurses in /usr/local/lib, an older version of (one I don't want to use) copy exists in /usr/lib checking curses.h usability... yes checking curses.h presence... yes checking for curses.h... yes checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no AIX O/S Version 7100-03-05-1524 IBM AIX C lslpp -h vac.C Fileset Level Action Status Date Time ---------------------------------------------------------------------------- Path: /usr/lib/objrepos vac.C 12.1.0.0 COMMIT COMPLETE 06/18/15 14:35:28 Path: /etc/objrepos vac.C 12.1.0.0 COMMIT COMPLETE 06/18/15 14:35:33 lslpp -h xlC.rte Fileset Level Action Status Date Time ---------------------------------------------------------------------------- Path: /usr/lib/objrepos xlC.rte 12.1.0.1 COMMIT COMPLETE 06/18/15 10:56:34 12.1.0.3 COMMIT COMPLETE 06/18/15 14:26:15 Environment Variables OBJECT_MODE 64 PATH /usr/local/bin:/usr/bin:/etc:/usr/sbin:/usr/ucb:/home/buildsw/bin:/usr/bin/X11:/sbin:.:/usr/vac/bin:/usr/vacpp/bin CC xlc_r CFLAGS -qmaxmem=-1 -DSYSV -D_AIX -D_AIX71 -D_ALL_SOURCE -DFUNCPROTO=15 -O -I/usr/local/include LDFLAGS -L/usr/local/lib64 -L/usr/local/lib -bmaxdata:0x80000000 -brtl LIBS CPPFLAGS CXX xlc++_r CXXFLAGS -qmaxmem=-1 -DSYSV -D_AIX -D_AIX71 -D_ALL_SOURCE -DFUNCPROTO=15 -O -I/usr/local/include CPP CXXCPP LDPATH /usr/local/lib ncurses version 5.9 ls /usr/local/lib/*curses* /usr/local/lib/libncurses++.a /usr/local/lib/libncurses.a /usr/local/lib/libncurses_g.a ./configure --with-tcltk-includes='-I/usr/include' --with-tcltk-libs='-L/usr/lib' | tee configure.out ---------- Added file: http://bugs.python.org/file39802/config.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 19:01:26 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 24 Jun 2015 17:01:26 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1435165286.18.0.980748334857.issue24325@psf.upfronthosting.co.za> Yury Selivanov added the comment: I've committed new unittests from this patch (as they are applicable to pure Python implementation of the wrapper too) The patch now contains only the C implementation of the wrapper and should be ready to be committed. Larry? ---------- Added file: http://bugs.python.org/file39803/types_coroutine_speedup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 19:06:11 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 24 Jun 2015 17:06:11 +0000 Subject: [issue24450] Add cr_await calculated property to coroutine object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1435165571.19.0.154288945243.issue24450@psf.upfronthosting.co.za> Yury Selivanov added the comment: Larry, what's your opinion on this? cr_await is a new thing (trivial on the C level) on a new type, it shouldn't break anything. gi_yieldfrom is identical to cr_await. Can we add this to 3.5? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 19:13:15 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 24 Jun 2015 17:13:15 +0000 Subject: [issue24500] provide context manager to redirect C output In-Reply-To: <1435161782.93.0.989546707262.issue24500@psf.upfronthosting.co.za> Message-ID: <1435165995.92.0.403206666596.issue24500@psf.upfronthosting.co.za> R. David Murray added the comment: This was discussed in the original redirect_stdout issue (issue 15805). It was suggested then that C level redirection was a separate issue, and should probably be something in the subprocess module. ---------- components: -Extension Modules nosy: +r.david.murray stage: -> needs patch title: contextlib.redirect_stdout should redirect C output -> provide context manager to redirect C output versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 19:31:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 24 Jun 2015 17:31:57 +0000 Subject: =?utf-8?q?=5Bissue23319=5D_Missing_SWAP=5FINT=C2=A0in_I=5Fset=5Fsw?= In-Reply-To: <1422212017.26.0.671058309435.issue23319@psf.upfronthosting.co.za> Message-ID: <1435167117.16.0.562326655715.issue23319@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +amaury.forgeotdarc, belopolsky, meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 20:20:30 2015 From: report at bugs.python.org (Frank Wierzbicki) Date: Wed, 24 Jun 2015 18:20:30 +0000 Subject: [issue24450] Add cr_await calculated property to coroutine object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1435170030.33.0.378300706518.issue24450@psf.upfronthosting.co.za> Frank Wierzbicki added the comment: This shouldn't be a problem for Jython. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 21:10:26 2015 From: report at bugs.python.org (Pete Lancashire) Date: Wed, 24 Jun 2015 19:10:26 +0000 Subject: [issue24501] configure does not find (n)curses in /usr/local/libs In-Reply-To: <1435164904.34.0.98182021259.issue24501@psf.upfronthosting.co.za> Message-ID: <1435173026.16.0.488002894443.issue24501@psf.upfronthosting.co.za> Pete Lancashire added the comment: added stdout of ./configure ---------- Added file: http://bugs.python.org/file39804/configure.out _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 21:12:01 2015 From: report at bugs.python.org (Jim Zajkowski) Date: Wed, 24 Jun 2015 19:12:01 +0000 Subject: [issue24502] OS X 2.7 package has zeros for version numbers in sub-packages Message-ID: <1435173121.58.0.153613185242.issue24502@psf.upfronthosting.co.za> New submission from Jim Zajkowski: The 2.7.0 download has zeros as version numbers on the .pkgs inside the metapackage, which leads to the package database showing an installed version of 0. e.g.: m-jamesez-darthpro:Downloads jamesez$ pkgutil --info org.python.Python.PythonApplications-2.7 package-id: org.python.Python.PythonApplications-2.7 version: 0 volume: / location: Applications install-time: 1435172997 This is from the Distribution file in your package: #Python_Framework.pkg #Python_Applications.pkg #Python_Command_Line_Tools.pkg #Python_Documentation.pkg #Python_Shell_Profile_Updater.pkg #Python_Install_Pip.pkg ---------- components: Installation, Macintosh messages: 245769 nosy: Jim Zajkowski, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: OS X 2.7 package has zeros for version numbers in sub-packages versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 21:16:44 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 24 Jun 2015 19:16:44 +0000 Subject: [issue24502] OS X 2.7 package has zeros for version numbers in sub-packages In-Reply-To: <1435173121.58.0.153613185242.issue24502@psf.upfronthosting.co.za> Message-ID: <1435173404.11.0.681656897151.issue24502@psf.upfronthosting.co.za> Ned Deily added the comment: I assume you are talking about current Python 2.7 .pkg installers, like for 2.7.10. If so, we can probably fix that, but I'm curious as to what problems this causes. ---------- assignee: -> ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 21:23:48 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 24 Jun 2015 19:23:48 +0000 Subject: [issue24478] asyncio: segfault in test_env_var_debug() on non-debug Windows buildbot In-Reply-To: <1434785934.32.0.696273570884.issue24478@psf.upfronthosting.co.za> Message-ID: <1435173828.68.0.376234104889.issue24478@psf.upfronthosting.co.za> Zachary Ware added the comment: Well, whatever it was, 44253ce374fc21402c15cbce9c2be0e184610882 seems to have fixed it. As of build 35 on 3.x and build 31 on 3.5, test_asyncio passes on the Non-Debug Windows bot. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 22:05:15 2015 From: report at bugs.python.org (Wolfgang E. Sanyer) Date: Wed, 24 Jun 2015 20:05:15 +0000 Subject: [issue24503] csv.writer fails when within csv.reader Message-ID: <1435176315.93.0.429947665214.issue24503@psf.upfronthosting.co.za> New submission from Wolfgang E. Sanyer: I have a use case where I am using a csv.reader to loop through one file and trying to use a csv.writer to output to another file. However, when I do this, the csv.writer instance does not write anything to the output file. ex: import csv with open("input.csv", "rb") as input, open("output.csv", "wb") as output: reader = csv.reader(input) writer = csv.writer(output) for row in reader: writer.writerow("data") # this writes out nothing writer.writerow("more data") # this writes out something ---------- components: Library (Lib) messages: 245772 nosy: ezzieyguywuf priority: normal severity: normal status: open title: csv.writer fails when within csv.reader type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 22:37:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Jun 2015 20:37:45 +0000 Subject: [issue24497] test_decimal.py contains a dead link In-Reply-To: <1435149364.96.0.261968389532.issue24497@psf.upfronthosting.co.za> Message-ID: <20150624203717.24638.1189@psf.io> Roundup Robot added the comment: New changeset 37c827d9dda4 by Ned Deily in branch '2.7': Issue #24497: update link in test_decimal comments https://hg.python.org/cpython/rev/37c827d9dda4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 22:38:29 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 24 Jun 2015 20:38:29 +0000 Subject: [issue24497] test_decimal.py contains a dead link In-Reply-To: <1435149364.96.0.261968389532.issue24497@psf.upfronthosting.co.za> Message-ID: <1435178309.27.0.332285530116.issue24497@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for noticing! ---------- nosy: +ned.deily resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 22:40:13 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 24 Jun 2015 20:40:13 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1435178413.6.0.556898504383.issue24483@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Please let this go forward as Serhiy has written it. That is the way I wrote the existing known hash function. You all should be focused on correctness, not on bike-shedding my and Serhiy's coding style. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 22:41:14 2015 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 24 Jun 2015 20:41:14 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <55786A90.10005@behnel.de> Message-ID: <558B15E1.4060609@behnel.de> Stefan Behnel added the comment: > I originally planned to make the next Cython release patch the Generator > and Coroutine ABCs into collections.abc, but I now think it would be worth > uploading an "abc_backports" package to PyPI instead that does that and on > which asyncio, tornado and other packages could simply depend with a > try-import. Done: https://pypi.python.org/pypi/backports_abc Feedback welcome. Stefan ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 23:44:37 2015 From: report at bugs.python.org (Denis Gordeev) Date: Wed, 24 Jun 2015 21:44:37 +0000 Subject: [issue24504] os.listdir() error if the last folder starts not with the capital letter Message-ID: <1435182277.25.0.0494331055897.issue24504@psf.upfronthosting.co.za> New submission from Denis Gordeev: My code is: mypath = 'Z:\Pr Files\norma' file_list = [ f for f in listdir(mypath) if isfile(join(mypath,f))] Error: Traceback (most recent call last): File "C:\Documents and Settings\Administrator\Desktop\uni\click zhenilo workshop\noise.py", line 13, in file_list = [ f for f in listdir(mypath) if isfile(join(mypath,f))] WindowsError: [Error 123] The filename, directory name, or volume label syntax is incorrect: 'Z:\\Pr Files\norma/*.*' It works all right, if the path is: mypath = 'Z:\Pr Files\Norma' ---------- components: Windows messages: 245777 nosy: Denis Gordeev, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: os.listdir() error if the last folder starts not with the capital letter versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 23:48:15 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 24 Jun 2015 21:48:15 +0000 Subject: [issue24504] os.listdir() error if the last folder starts not with the capital letter In-Reply-To: <1435182277.25.0.0494331055897.issue24504@psf.upfronthosting.co.za> Message-ID: <1435182495.74.0.758741737487.issue24504@psf.upfronthosting.co.za> STINNER Victor added the comment: 'Z:\Pr Files\norma' looks wrong '\n' is a single character, a new line. Try to write r'Z:\Pr Files\norma'. https://docs.python.org/dev/reference/lexical_analysis.html#string-and-bytes-literals ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 23:50:13 2015 From: report at bugs.python.org (Denis Gordeev) Date: Wed, 24 Jun 2015 21:50:13 +0000 Subject: [issue24504] os.listdir() error if the last folder starts not with the capital letter In-Reply-To: <1435182277.25.0.0494331055897.issue24504@psf.upfronthosting.co.za> Message-ID: <1435182613.42.0.212555110287.issue24504@psf.upfronthosting.co.za> Denis Gordeev added the comment: Oh, sorry. Forgot about it. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jun 24 23:51:01 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 24 Jun 2015 21:51:01 +0000 Subject: [issue24504] os.listdir() error if the last folder starts not with the capital letter In-Reply-To: <1435182277.25.0.0494331055897.issue24504@psf.upfronthosting.co.za> Message-ID: <1435182661.75.0.677482787841.issue24504@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 00:09:39 2015 From: report at bugs.python.org (Bob Alexander) Date: Wed, 24 Jun 2015 22:09:39 +0000 Subject: [issue24505] shutil.which wrong result on Windows Message-ID: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za> New submission from Bob Alexander: Python session with 3.5b2 Showing existing error: >>> from shutil import which Works OK >>> which("python") 'C:\\Python27\\python.EXE' Also works OK >>> which('C:\\Python27\\python.EXE') 'C:\\Python27\\python.EXE' Fails >>> which('C:\\Python27\\python') >>> Showing better results with my fix (attached): >>> from which2 import which >>> which("python") 'C:\\Python27\\python.exe' >>> which('C:\\Python27\\python.exe') 'C:\\Python27\\python.exe' >>> which('C:\\Python27\\python') 'C:\\Python27\\python.exe' Problem is with the short-circuiting code near the beginning of the function. It fails to check the extensions for Windows when short-circuited. My fix has a few other improvements -- efficiency and nicer output without those ugly upper-case extensions. ---------- components: Library (Lib) files: which2.py messages: 245780 nosy: bobjalex priority: normal severity: normal status: open title: shutil.which wrong result on Windows type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file39805/which2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 00:13:04 2015 From: report at bugs.python.org (Karl Richter) Date: Wed, 24 Jun 2015 22:13:04 +0000 Subject: [issue24506] make fails with gcc 4.9 due to fatal warning of unused variable and empty macro in Parser/pgen.c Message-ID: <1435183984.12.0.342400171116.issue24506@psf.upfronthosting.co.za> New submission from Karl Richter: `gcc` 4.9 is more restictive and recognizes that the empty definition of the `REQN` macro doesn't use some variables. It's more suitable to wrap the usage of the macro in the same preprocessor conditionals like the macro definition. experienced with 41fbc222af8c503e1659250a36f4e293d864a92b Patch attached. Tests pass (see https://semaphoreci.com/krichter/cpython/branches/empty_macro/builds/1 for details). ---------- components: Build files: 0001-removed-empty-definition-of-REQN-preprocessor-macro-.patch keywords: patch messages: 245781 nosy: krichter priority: normal severity: normal status: open title: make fails with gcc 4.9 due to fatal warning of unused variable and empty macro in Parser/pgen.c versions: Python 2.7 Added file: http://bugs.python.org/file39806/0001-removed-empty-definition-of-REQN-preprocessor-macro-.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 01:19:07 2015 From: report at bugs.python.org (Jim Zajkowski) Date: Wed, 24 Jun 2015 23:19:07 +0000 Subject: [issue24502] OS X 2.7 package has zeros for version numbers in sub-packages In-Reply-To: <1435173121.58.0.153613185242.issue24502@psf.upfronthosting.co.za> Message-ID: <1435187947.25.0.766676563992.issue24502@psf.upfronthosting.co.za> Jim Zajkowski added the comment: Among the problems this causes, we can't correctly track which version is present on our Macs (~6,000 systems) for upgrading. --Jim ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 01:19:39 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Wed, 24 Jun 2015 23:19:39 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1435187979.69.0.0611013828307.issue23883@psf.upfronthosting.co.za> Changes by Jacek Ko?odziej : Added file: http://bugs.python.org/file39807/Issue23883_support_check__all__.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 01:19:47 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Wed, 24 Jun 2015 23:19:47 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1435187987.23.0.752056697147.issue23883@psf.upfronthosting.co.za> Changes by Jacek Ko?odziej : Added file: http://bugs.python.org/file39808/Issue23883_test_gettext.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 01:21:18 2015 From: report at bugs.python.org (Meador Inge) Date: Wed, 24 Jun 2015 23:21:18 +0000 Subject: [issue24506] make fails with gcc 4.9 due to fatal warning of unused variable and empty macro in Parser/pgen.c In-Reply-To: <1435183984.12.0.342400171116.issue24506@psf.upfronthosting.co.za> Message-ID: <1435188078.59.0.317762408083.issue24506@psf.upfronthosting.co.za> Meador Inge added the comment: What is the exact GCC revision and what are the error messages? I just tried GCC 4.9.3 and GCC 4.10.0 and don't see the errors. Also, what configure and make parameters did you use to trigger the error? I did './configure --with-pydebug' and './configure' with 'make -j4'. ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 01:22:35 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Wed, 24 Jun 2015 23:22:35 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1435188155.36.0.0607888763833.issue23883@psf.upfronthosting.co.za> Jacek Ko?odziej added the comment: > Nice work with the check__all__() function. Thank you! :) > I left some comments on Reitveld. Also, it currently ignores items satisfying either of these checks: > > * isinstance(module_object, types.ModuleType) > * getattr(module_object, '__module__', None) not in name_of_module > > The first is largely redundant with the second, because module objects don?t have a __module__ attribute. However I wonder if it would be better to drop the second check and just rely on the ModuleType check, making the test stricter. Or would this be too annoying in some cases (requiring a huge blacklist)? If so, maybe make the name_of_module checking optional. Could you please elaborate on "making the test stricter"? I'd go with the first check + optional name_of_module. With second one alone, all freshly added test__all__ tests would need additional names in blacklists - not huge ones, but they would otherwise be unnecessary. I've amended the patches and I'm waiting for review. I've also thought of not only making name_of_module param optional, but to make it extra_names_of_module (so such param would be added to module.__name__ used in "getattr(module_object, '__module__', None) in name of module" check. It would account for less typing in general (module.__name__ occurs in almost all cases), but also less explicity. What do you think? ---------- Added file: http://bugs.python.org/file39809/Issue23883_all.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 01:22:52 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 24 Jun 2015 23:22:52 +0000 Subject: [issue24503] csv.writer fails when within csv.reader In-Reply-To: <1435176315.93.0.429947665214.issue24503@psf.upfronthosting.co.za> Message-ID: <1435188172.85.0.944601251348.issue24503@psf.upfronthosting.co.za> Martin Panter added the comment: It?s working properly for me in 2.7.10: $ cat -A input.csv a,b,c$ 1,2,3$ $ python2 testcase.py $ cat -A output.csv d,a,t,a^M$ d,a,t,a^M$ m,o,r,e, ,d,a,t,a^M$ ---------- nosy: +vadmium stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 01:25:28 2015 From: report at bugs.python.org (Karl Richter) Date: Wed, 24 Jun 2015 23:25:28 +0000 Subject: [issue24506] make fails with gcc 4.9 due to fatal warning of unused variable and empty macro in Parser/pgen.c In-Reply-To: <1435183984.12.0.342400171116.issue24506@psf.upfronthosting.co.za> Message-ID: <1435188328.74.0.405294025996.issue24506@psf.upfronthosting.co.za> Karl Richter added the comment: It's a fatal warning of `gcc 4.9.2`, not an error (my bad) for `int i;` in `Parser/pgen.c` line 227. It might be ignored as well, but I think my approach is more elegant and deals with issues sooner than later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 01:38:47 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 24 Jun 2015 23:38:47 +0000 Subject: [issue24439] Feedback for awaitable coroutine documentation In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za> Message-ID: <1435189127.61.0.50109414093.issue24439@psf.upfronthosting.co.za> Martin Panter added the comment: Hi Yury. It looks like you missed my updated /Doc/library/tulip_coro.dia file. Here it is separately, in case you are having trouble extracting it from the patch. ---------- Added file: http://bugs.python.org/file39810/tulip_coro.dia _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 03:32:59 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 25 Jun 2015 01:32:59 +0000 Subject: [issue24503] csv.writer fails when within csv.reader In-Reply-To: <1435176315.93.0.429947665214.issue24503@psf.upfronthosting.co.za> Message-ID: <1435195979.88.0.35556781974.issue24503@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Obvious possibility: input.csv is empty, so the loop never executes. You could always add prints within the loop as well, so you know it actually read something. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 03:46:57 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 25 Jun 2015 01:46:57 +0000 Subject: [issue19111] 2to3 should remove from future_builtins import * In-Reply-To: <1380379953.79.0.934483665034.issue19111@psf.upfronthosting.co.za> Message-ID: <1435196817.63.0.62597842987.issue19111@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Shouldn't it also disable the relevant fixers for map, filter, zip, etc. as appropriate? Otherwise a whole bunch of calls will be wrapper in list() or the like to mimic a behavior the code never had in Py2 in the first place. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 04:57:26 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 25 Jun 2015 02:57:26 +0000 Subject: [issue16830] Add skip_host and skip_accept_encoding to HTTPConnection.request() In-Reply-To: <1356998273.75.0.911756727263.issue16830@psf.upfronthosting.co.za> Message-ID: <1435201046.48.0.377537211339.issue16830@psf.upfronthosting.co.za> Martin Panter added the comment: I tend to think that this proposal should be rejected. If you need low-level control over the header fields, just use putrequest(), putheader() and endheaders() methods instead. And adding these flags to request() isn?t going to help with urlopen(), unless the Request class was extended in a similar way. ---------- title: Add skip_host and skip_accept_encoding to httplib/http.client -> Add skip_host and skip_accept_encoding to HTTPConnection.request() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 05:12:06 2015 From: report at bugs.python.org (Kevin Shweh) Date: Thu, 25 Jun 2015 03:12:06 +0000 Subject: [issue7406] int arithmetic relies on C signed overflow behaviour In-Reply-To: <1259495783.96.0.0738564373709.issue7406@psf.upfronthosting.co.za> Message-ID: <1435201926.01.0.173922509167.issue7406@psf.upfronthosting.co.za> Kevin Shweh added the comment: It looks like the fast paths for INPLACE_ADD and INPLACE_SUBTRACT in Python 2 don't have the cast-to-unsigned fix, so they're still relying on undefined behavior. For example, in INPLACE_ADD: /* INLINE: int + int */ register long a, b, i; a = PyInt_AS_LONG(v); b = PyInt_AS_LONG(w); i = a + b; if ((i^a) < 0 && (i^b) < 0) goto slow_iadd; ---------- nosy: +Kevin Shweh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 05:26:03 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 25 Jun 2015 03:26:03 +0000 Subject: [issue24505] shutil.which wrong result on Windows In-Reply-To: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za> Message-ID: <1435202763.03.0.678757712734.issue24505@psf.upfronthosting.co.za> R. David Murray added the comment: Could you please submit your proposal as a patch? (A diff -u against the existing version). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 05:26:22 2015 From: report at bugs.python.org (Rusi) Date: Thu, 25 Jun 2015 03:26:22 +0000 Subject: [issue24507] CRLF issues Message-ID: <1435202782.41.0.930107926701.issue24507@psf.upfronthosting.co.za> New submission from Rusi: While trying to freshly setup a CPython repo, encountered the following CRLF issues: Mixed file -- both LF and CRLF (line 29 LF rest CRLF) Lib/venv/scripts/nt/Activate.ps1 Lib/test/decimaltestdata is a directory with mixed up files -- ie some CRLF some LF files PCbuild/readme.txt: CRLF (explicit) This is fine. Many of the following should (ideally/IMHO) be likewise CRLF (not BIN) *.sln: CRLF but marked as BIN in hgeol PC/example_nt/example.vcproj Emacs shows as Dos file; But not picked up by file; maybe other such Missing BIN pattern from .hgeol *.pdf Note that Doc/library/turtle-star.pdf exists This is most likely a bug Existent file-types with non-existent files in hgeol; Probably harmless *.vsprops *.mk *.dsp *.dsw These seem straightforward CRLF files to me; why BIN in hgeol? Lib/test/test_email/data/msg_26.txt Lib/test/coding20731.py ---------- components: Build messages: 245793 nosy: RusiMody, zach.ware priority: normal severity: normal status: open title: CRLF issues versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 06:26:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 25 Jun 2015 04:26:32 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1435206392.58.0.442501360288.issue23883@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Serhiy: ftplib.Error does not actually appear to be documented. Perhaps it should not be added to __all__ after all? (excuse the pun) Agree. The list is only cursorily filtered result of some one-liners and can contain false names. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 06:26:49 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 25 Jun 2015 04:26:49 +0000 Subject: [issue24508] Backport 3.5's Windows build project files to 2.7 Message-ID: <1435206408.67.0.0166063443293.issue24508@psf.upfronthosting.co.za> New submission from Zachary Ware: Here's the (enormous) patch backporting 3.5's project files to 2.7. It also takes care of adjusting the old project files to their new home in PC/VS9.0, and makes a couple of small adjustments in distutils.command.build_ext, FixTk, regrtest, and the Tcl/Tk tests to keep the test suite running properly. I've run a couple of builds on the custom buildbots, and at this point there are no failures that I can see any reason to blame this patch for. I would greatly appreciate some review, or at least 'review by testing' to make sure this doesn't completely break anybody's workflow. Terry, I'm particularly interested in your feedback since I'm pretty sure you generally build from the VS GUI, which I usually avoid doing. PCbuild\pcbuild.sln *will not* work with the VS 2008 GUI, but it should work with any other VS, 2010 or newer. If you'd prefer to continue using the 2008 GUI, PC\VS9.0\pcbuild.sln should continue to work. When using the new project files, though, this should also take care of the headache of making Tcl/Tk play the game; you shouldn't have to do anything extra to be able to use Tkinter. Steve, I did not make any changes to Tools\msi, but I'd be happy to if it makes your job any easier. Looking forward to your feedback, Zach ---------- assignee: zach.ware components: Build, Windows files: 2.7_project_files_backport.diff keywords: patch messages: 245795 nosy: paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware priority: normal severity: normal stage: patch review status: open title: Backport 3.5's Windows build project files to 2.7 type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file39811/2.7_project_files_backport.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 06:39:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 25 Jun 2015 04:39:54 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1435207194.93.0.318502511777.issue23883@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Adding new names to __all__ can have undesired effect and break user code (by hiding builtins as for tarfile.open). Perhaps not all documented names should be imported with "import *". In any case it is too late for 3.5. ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 06:56:13 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 25 Jun 2015 04:56:13 +0000 Subject: [issue24508] Backport 3.5's Windows build project files to 2.7 In-Reply-To: <1435206408.67.0.0166063443293.issue24508@psf.upfronthosting.co.za> Message-ID: <1435208173.72.0.761851055026.issue24508@psf.upfronthosting.co.za> Steve Dower added the comment: Feel free to fix up msi.py as much as it needs. I don't particularly understand it - I just run it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 07:06:49 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 25 Jun 2015 05:06:49 +0000 Subject: [issue24508] Backport 3.5's Windows build project files to 2.7 In-Reply-To: <1435206408.67.0.0166063443293.issue24508@psf.upfronthosting.co.za> Message-ID: <1435208809.85.0.0975635850527.issue24508@psf.upfronthosting.co.za> Zachary Ware added the comment: Do you plan to use the old project files or the new? For the new, there should be no change in Tools/msi, which would make fixing it very easy for me ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 07:10:29 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 25 Jun 2015 05:10:29 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1435209029.0.0.109899256944.issue24483@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 to what Raymond says here. Concerns regarding code duplication need to be weighed against the likelihood of that code changing in the future, and the impact on the readability of each copy of the code in isolation. In this particular case, I think the likelihood of future change is low, and the likely negative impact of consolidation on readability is high, so it makes sense to me to defer consolidation until there's a clear benefit to sharing the implementations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 07:28:54 2015 From: report at bugs.python.org (Milan Oberkirch) Date: Thu, 25 Jun 2015 05:28:54 +0000 Subject: [issue19111] 2to3 should remove from future_builtins import * In-Reply-To: <1380379953.79.0.934483665034.issue19111@psf.upfronthosting.co.za> Message-ID: <1435210134.65.0.86222460691.issue19111@psf.upfronthosting.co.za> Milan Oberkirch added the comment: The other fixers you mentioned are deactivated independently of this patch if an import from future_builtins exists. I gave it the same run_order as in the fix for __future__ imports which prevents 2to3 from deleting the calls before other fixers check for their existence. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 07:37:54 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 25 Jun 2015 05:37:54 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1435210674.13.0.20598075138.issue23883@psf.upfronthosting.co.za> Martin Panter added the comment: I think names should be in __all__ even if they shadow builtins, at least in a new feature release. There is plenty of precedent, e.g. asyncio.TimeoutError; reprlib.repr(); threading.enumerate(). Modules with open() in __all__ include aifc, bz2, codecs, dbm, dbm.dumb, gzip, lzma, os, shelve, wave and webbrowser. Plus, pydoc ignores things excluded from __all__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 08:02:58 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 25 Jun 2015 06:02:58 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1435212178.76.0.250383041021.issue23883@psf.upfronthosting.co.za> Martin Panter added the comment: Jacek: If we used the ModuleType check, and somebody adds a module-level constant (like logging.CRITICAL = 50), the test will automatically detect if they forget to update __all__. That is what I meant by the test being stricter. But it looks like you went for the other option, which has its own relative advantages :) Will try to to a proper review later when I get a chance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 09:37:50 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 25 Jun 2015 07:37:50 +0000 Subject: [issue24509] Undocumented features of asyncio: call_at, call_later Message-ID: <1435217870.26.0.229926734137.issue24509@psf.upfronthosting.co.za> New submission from ???? ?????????: These function returns handle, so, registered callback can be cancelled. ---------- messages: 245803 nosy: mmarkk priority: normal severity: normal status: open title: Undocumented features of asyncio: call_at, call_later versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 09:38:21 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 25 Jun 2015 07:38:21 +0000 Subject: [issue24509] Undocumented features of asyncio: call_at, call_later In-Reply-To: <1435217870.26.0.229926734137.issue24509@psf.upfronthosting.co.za> Message-ID: <1435217901.54.0.958174118482.issue24509@psf.upfronthosting.co.za> Changes by ???? ????????? : ---------- assignee: -> docs at python components: +Documentation, asyncio nosy: +docs at python, gvanrossum, haypo, yselivanov type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 09:52:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 25 Jun 2015 07:52:10 +0000 Subject: [issue24509] Undocumented features of asyncio: call_at, call_later In-Reply-To: <1435217870.26.0.229926734137.issue24509@psf.upfronthosting.co.za> Message-ID: <1435218730.86.0.179996178006.issue24509@psf.upfronthosting.co.za> STINNER Victor added the comment: Documentatin of call_soon() and call_later() contain the sentence "An instance of asyncio.Handle is returned." with a link to Handle which shows the cancel() method: https://docs.python.org/dev/library/asyncio-eventloop.html#asyncio.BaseEventLoop.call_soon https://docs.python.org/dev/library/asyncio-eventloop.html#asyncio.BaseEventLoop.call_later Can you please suggest a new sentence to explain that a Handle can be cancelled? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 11:05:11 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Thu, 25 Jun 2015 09:05:11 +0000 Subject: [issue24294] DeprecationWarnings should be visible by default in the interactive REPL In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za> Message-ID: <1435223111.94.0.142670959866.issue24294@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Ping. I know this is pretty trivial and everyone's focused on 3.5-related stuff, but it would be nice to get this finalized soon b/c the sooner CPython commits to some standard behavior here, the sooner all the other (faster-moving) python REPLs will converge to match. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 11:35:08 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 25 Jun 2015 09:35:08 +0000 Subject: [issue24509] Undocumented features of asyncio: call_at, call_later In-Reply-To: <1435217870.26.0.229926734137.issue24509@psf.upfronthosting.co.za> Message-ID: <1435224908.21.0.364468086884.issue24509@psf.upfronthosting.co.za> ???? ????????? added the comment: For delayed execution methods: "Returned handle is actually timer object. That timer can be deactivated using asyncio.Handle.cancel() method, so registered callback won't be called". For other callback registration methods: "Returned handle may be used to unregister callback using asyncio.Handle.cancel(), so registered callback won't be called". Also: 1. Documentation of .cancel does not say if it is allowed to cancel cancelled handle. 2. Documentation does not say if it is allowed to cancel timer, that was already fired. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 12:14:59 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 25 Jun 2015 10:14:59 +0000 Subject: [issue19111] 2to3 should remove from future_builtins import * In-Reply-To: <1380379953.79.0.934483665034.issue19111@psf.upfronthosting.co.za> Message-ID: <1435227299.24.0.931775757674.issue19111@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Ah, my mistake. Apologies. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 14:48:45 2015 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 25 Jun 2015 12:48:45 +0000 Subject: [issue24503] csv.writer fails when within csv.reader In-Reply-To: <1435176315.93.0.429947665214.issue24503@psf.upfronthosting.co.za> Message-ID: <1435236525.75.0.547063309573.issue24503@psf.upfronthosting.co.za> Skip Montanaro added the comment: @ezzieyguywuf - Can you provide an example of a non-empty input.csv which fails for you? Otherwise, I'd have to agree with @josh.r and @vadmium that it's working as it should. ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 15:03:50 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 25 Jun 2015 13:03:50 +0000 Subject: [issue24508] Backport 3.5's Windows build project files to 2.7 In-Reply-To: <1435206408.67.0.0166063443293.issue24508@psf.upfronthosting.co.za> Message-ID: <1435237430.98.0.0248460142252.issue24508@psf.upfronthosting.co.za> Steve Dower added the comment: I'll try out the changes when I get a bit of time today or tomorrow and decide then what I'll do. msi.py doesn't actually build the projects AFAIK, so it's probably okay. It might try to read them to get paths though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 17:06:21 2015 From: report at bugs.python.org (Jorge Herskovic) Date: Thu, 25 Jun 2015 15:06:21 +0000 Subject: [issue24484] multiprocessing cleanup occasionally throws exception In-Reply-To: <1434899306.98.0.122661278895.issue24484@psf.upfronthosting.co.za> Message-ID: <1435244781.05.0.469228952005.issue24484@psf.upfronthosting.co.za> Jorge Herskovic added the comment: Ok, I *think* I tracked it down to Connections getting cleaned up in a non-orderly fashion, sometimes while _run_finalizers is executing. The following patch to lib/python3.4/multiprocessing/connection.py cures the problem on my machine. @@ -124,10 +124,10 @@ self._handle = handle self._readable = readable self._writable = writable - + self._shutdown = util.Finalize(self, self._finalizer) # XXX should we use util.Finalize instead of a __del__? - - def __del__(self): + + def _finalizer(self): if self._handle is not None: self._close() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 17:10:49 2015 From: report at bugs.python.org (Piotr Dobrogost) Date: Thu, 25 Jun 2015 15:10:49 +0000 Subject: [issue18857] urlencode of a None value uses the string 'None' In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za> Message-ID: <1435245049.05.0.979824933405.issue18857@psf.upfronthosting.co.za> Piotr Dobrogost added the comment: This problem came out in the bug "Cannot make URL query string with a parameter without a value (https://github.com/kennethreitz/requests/issues/2651) raised in urllib3 project (which itself is being used by Requests library mentioned in this bug). ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 17:35:58 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 25 Jun 2015 15:35:58 +0000 Subject: [issue24510] Make _PyCoro_GetAwaitableIter a public API Message-ID: <1435246558.17.0.296607565259.issue24510@psf.upfronthosting.co.za> New submission from Yury Selivanov: We should consider making _PyCoro_GetAwaitableIter(o) a public API. Its implementation isn't trivial because it's not around simply accessing 'tp_as_async->am_await'. You also need to check is 'o' is a generator with a CO_ITERABLE_COROUTINE or a CoroObject, etc. ---------- assignee: yselivanov components: Interpreter Core messages: 245812 nosy: gvanrossum, haypo, ncoghlan, scoder, yselivanov priority: normal severity: normal status: open title: Make _PyCoro_GetAwaitableIter a public API type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 17:36:18 2015 From: report at bugs.python.org (Meador Inge) Date: Thu, 25 Jun 2015 15:36:18 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1435246578.91.0.674488559113.issue24483@psf.upfronthosting.co.za> Meador Inge added the comment: I did some regression testing and reviewed the code; LGTM. As for the code structure issues, I agree that the duplication is undesirable (the readability argument is not that convincing), but Serhiy's patch is consistent with the existing design. As such, I think the structure issue is a separate one and definitely should not hold this patch up. ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 17:42:28 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 25 Jun 2015 15:42:28 +0000 Subject: [issue24511] Add methods for async protocols Message-ID: <1435246948.22.0.255546128718.issue24511@psf.upfronthosting.co.za> New submission from Yury Selivanov: Let's consider adding C API functions for working with new tp_as_async: PyAwait_Check for checking tp_as_async->am_await || PyCoro_Check || PyGen & CO_ITERABLE_COROUTINE PyAwait_AsyncIterCheck for checking tp_as_async->am_iter PyAwait_GetAsyncIter for calling tp_as_async->am_iter PyAwait_AsyncIterNext for calling tp_as_async->am_next Please also see issue24510 for opening up _PyCoro_GetAwaitableIter; we can call it PyAwait_Get ---------- assignee: yselivanov components: Interpreter Core messages: 245814 nosy: gvanrossum, haypo, ncoghlan, scoder, yselivanov priority: normal severity: normal status: open title: Add methods for async protocols versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 17:42:34 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 25 Jun 2015 15:42:34 +0000 Subject: [issue24511] Add methods for async protocols In-Reply-To: <1435246948.22.0.255546128718.issue24511@psf.upfronthosting.co.za> Message-ID: <1435246954.86.0.457446443285.issue24511@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 17:48:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 25 Jun 2015 15:48:59 +0000 Subject: [issue24439] Feedback for awaitable coroutine documentation In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za> Message-ID: <20150625154856.62221.93095@psf.io> Roundup Robot added the comment: New changeset e9c34e16f445 by Yury Selivanov in branch '3.5': Issue #24439: Update tulip_coro.dia https://hg.python.org/cpython/rev/e9c34e16f445 New changeset 15b8a62da6ff by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24439) https://hg.python.org/cpython/rev/15b8a62da6ff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 17:51:11 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 25 Jun 2015 15:51:11 +0000 Subject: [issue24439] Feedback for awaitable coroutine documentation In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za> Message-ID: <1435247471.97.0.607625516162.issue24439@psf.upfronthosting.co.za> Yury Selivanov added the comment: Martin, it's now updated. (As for why it wasn't applied in the first place, I guess standard MacOS `patch` command fails to apply git binary diffs) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 17:55:09 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 25 Jun 2015 15:55:09 +0000 Subject: [issue24510] Make _PyCoro_GetAwaitableIter a public API In-Reply-To: <1435246558.17.0.296607565259.issue24510@psf.upfronthosting.co.za> Message-ID: <1435247709.98.0.117636851222.issue24510@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like the code is currently moving fast. I suggest to wait until Python 3.6 to stabilize the Python C API for async/await. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 18:05:54 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 25 Jun 2015 16:05:54 +0000 Subject: [issue24510] Make _PyCoro_GetAwaitableIter a public API In-Reply-To: <1435246558.17.0.296607565259.issue24510@psf.upfronthosting.co.za> Message-ID: <1435248354.03.0.893414241954.issue24510@psf.upfronthosting.co.za> Yury Selivanov added the comment: > It looks like the code is currently moving fast. [..] Yeah, that's my feeling too, I don't want to rush things too much. Unless Guido, Nick and you are in complete agreement that we need this, we should postpone till 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 18:22:14 2015 From: report at bugs.python.org (Cal Leeming) Date: Thu, 25 Jun 2015 16:22:14 +0000 Subject: [issue16379] SQLite error code not exposed to python In-Reply-To: <1351764878.68.0.13361347428.issue16379@psf.upfronthosting.co.za> Message-ID: <1435249334.1.0.994658526473.issue16379@psf.upfronthosting.co.za> Cal Leeming added the comment: Any update on this? Still seems to be a problem as of 3.4.0. ---------- nosy: +sleepycal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 19:27:47 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 25 Jun 2015 17:27:47 +0000 Subject: [issue24507] CRLF issues In-Reply-To: <1435202782.41.0.930107926701.issue24507@psf.upfronthosting.co.za> Message-ID: <1435253267.34.0.48635088056.issue24507@psf.upfronthosting.co.za> Eric V. Smith added the comment: At least for the files in decimaltestdata, I'd be wary about changing them. My understanding is that these files are from the IBM decimal test library. I don't think we should stray from upstream here, even for something as simple as line endings. Unfortunately, the link http://www2.hursley.ibm.com/decimal from the file headers is no longer valid. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 19:38:44 2015 From: report at bugs.python.org (John Laurence Poole) Date: Thu, 25 Jun 2015 17:38:44 +0000 Subject: [issue24425] Installer Vender Issue In-Reply-To: <1433951061.45.0.0884040195007.issue24425@psf.upfronthosting.co.za> Message-ID: <1435253924.11.0.992867850596.issue24425@psf.upfronthosting.co.za> John Laurence Poole added the comment: I attempted to install on Windows Server 2008 R2 Service Pack 1 and had the same problems. I thought it might be proxy since I'm behind a firewall, but setting the usual values did not allow the program to overcome whatever it is that PIP is having problems with. here's the log at the failure point: MSI (s) (2C:BC) [11:10:26:806]: Executing op: CacheSizeFlush(,) MSI (s) (2C:BC) [11:10:26:806]: Executing op: ActionStart(Name=UpdatePip,,) Action 11:10:26: UpdatePip. MSI (s) (2C:BC) [11:10:26:809]: Executing op: CustomActionSchedule(Action=UpdatePip,ActionType=3090,Source=C:\Python27\python.exe,Target=-m ensurepip -U --default-pip,) MSI (s) (2C:BC) [11:10:26:812]: Note: 1: 1721 2: UpdatePip 3: C:\Python27\python.exe 4: -m ensurepip -U --default-pip MSI (s) (2C:BC) [11:10:26:812]: Note: 1: 2262 2: Error 3: -2147287038 Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: UpdatePip, location: C:\Python27\python.exe, command: -m ensurepip -U --default-pip MSI (s) (2C:BC) [11:10:30:520]: Note: 1: 2262 2: Error 3: -2147287038 MSI (s) (2C:BC) [11:10:30:520]: Product: Python 2.7.10 (64-bit) -- Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: UpdatePip, location: C:\Python27\python.exe, command: -m ensurepip -U --default-pip Action ended 11:10:30: InstallFinalize. Return value 3. To get this to install, during the installation, disengage entirely PIP, it's default is to install it. ---------- nosy: +John Laurence Poole _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 19:50:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 25 Jun 2015 17:50:52 +0000 Subject: [issue24509] Undocumented features of asyncio: call_at, call_later In-Reply-To: <1435217870.26.0.229926734137.issue24509@psf.upfronthosting.co.za> Message-ID: <20150625175049.28495.34877@psf.io> Roundup Robot added the comment: New changeset 3199ec504dbe by Yury Selivanov in branch '3.4': Issue #24509: Clarify Handle.cancel() and loop.call_* methods. https://hg.python.org/cpython/rev/3199ec504dbe New changeset fc69dd6aea55 by Yury Selivanov in branch '3.5': Merge 3.4 (issue #24509) https://hg.python.org/cpython/rev/fc69dd6aea55 New changeset 9aad116baee8 by Yury Selivanov in branch 'default': Merge 3.5 (issue #24509) https://hg.python.org/cpython/rev/9aad116baee8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 19:52:08 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 25 Jun 2015 17:52:08 +0000 Subject: [issue24509] Undocumented features of asyncio: call_at, call_later In-Reply-To: <1435217870.26.0.229926734137.issue24509@psf.upfronthosting.co.za> Message-ID: <1435254728.2.0.766202955204.issue24509@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks for reporting this Mark! ---------- resolution: -> fixed stage: -> commit review status: open -> closed versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 20:00:51 2015 From: report at bugs.python.org (Rusi) Date: Thu, 25 Jun 2015 18:00:51 +0000 Subject: [issue24507] CRLF issues In-Reply-To: <1435253267.34.0.48635088056.issue24507@psf.upfronthosting.co.za> Message-ID: Rusi added the comment: The newest (at least newer) version seems to be http://speleotrove.com/decimal/ Top of page says: Welcome to the General Decimal Arithmetic website, which is now hosted at speleotrove.com. The page and file names here have not been changed from the names used on the previous website, www2.hursley.ibm.com. File to download is dectest.zip All files are now CRLF More significantly the versions are bumped up from 2.59 in the python repo to 2.62 at this link Needless to say there are much larger differences between these than just CRLF :-) On Thu, Jun 25, 2015 at 10:57 PM, Eric V. Smith wrote: > > Eric V. Smith added the comment: > > At least for the files in decimaltestdata, I'd be wary about changing them. My understanding is that these files are from the IBM decimal test library. I don't think we should stray from upstream here, even for something as simple as line endings. > > Unfortunately, the link http://www2.hursley.ibm.com/decimal from the file headers is no longer valid. The newest (at least newer) version seems to be http://speleotrove.com/decimal/ Top of page says: Welcome to the General Decimal Arithmetic website, which is now hosted at speleotrove.com. The page and file names here have not been changed from the names used on the previous website, www2.hursley.ibm.com. File to download is dectest.zip All files are now CRLF More significantly the versions are bumped up from 2.59 in the python repo to 2.62 at this link Needless to say there are much larger differences between these versions than just CRLF :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 20:07:44 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 25 Jun 2015 18:07:44 +0000 Subject: [issue16379] SQLite error code not exposed to python In-Reply-To: <1351764878.68.0.13361347428.issue16379@psf.upfronthosting.co.za> Message-ID: <1435255664.32.0.0941303742476.issue16379@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 20:19:54 2015 From: report at bugs.python.org (Timothy Cardenas) Date: Thu, 25 Jun 2015 18:19:54 +0000 Subject: [issue24512] multiprocessing should log a warning when forking multithreaded process Message-ID: <1435256394.21.0.131332757316.issue24512@psf.upfronthosting.co.za> New submission from Timothy Cardenas: We were tracking down a bug the other day that was rather hard to find involving a forking a process that had both a primary thread and a logging thread. The docs clearly state that forking a multithreaded process is "problematic" https://docs.python.org/3.4/library/multiprocessing.html#contexts-and-start-methods However given that it is very simple to check if the process currently has multiple threads at the time of the forking operation and that its almost never safe to do so with multiple running threads I was wondering if it made sense to add a message that warned that a unsafe operation (forking a multithreaded process without the forkserver option) was occurring. ---------- components: Library (Lib) messages: 245825 nosy: trcarden priority: normal severity: normal status: open title: multiprocessing should log a warning when forking multithreaded process type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 22:28:14 2015 From: report at bugs.python.org (David Watson) Date: Thu, 25 Jun 2015 20:28:14 +0000 Subject: [issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names In-Reply-To: <1431777658.14.0.622939986647.issue9377@psf.upfronthosting.co.za> Message-ID: <20150625202807.GA19433@localhost.dbwats.plus.com> David Watson added the comment: I've updated the ASCII/surrogateescape patches in line with various changes to Python since I posted them. return-ascii-surrogateescape-2015-06-25.diff incorporates the ascii-surrogateescape and uname-surrogateescape patches, and accept-ascii-surrogateescape-2015-06-25.diff corresponds to the try-surrogateescape-first patch. Neither patch touches gethostname() on Windows. Python's existing code now has a fast path for ASCII-only strings which passes them through unchanged (Unicode -> ASCII), so in order not to slow down processing of valid IDNs, the latter patch now effectively tries encodings in the order ASCII/strict (existing code, fast path) IDNA/strict (existing code) ASCII/surrogateescape (added by patch) rather than the previous ASCII/surrogateescape IDNA/strict This doesn't change the behaviour of the patch, since IDNA always rejects strings containing surrogate codes, and either rejects ASCII-only strings (e.g. when a label is longer than 63 characters) or passes them through unchanged. These patches would at least allow getfqdn() to work in Almad's example, but in that case the host also appears to be addressable by the IDNA equivalent ("xn--didejo-noas-1ic") of its Unicode hostname (I haven't checked as I'm not a Windows user, but I presume the UnicodeDecodeError came from gethost_common() in socketmodule.c and hence the name lookup was successful), so it would certainly be more helpful to return Unicode for non-ASCII gethostbyaddr() results there, if they were guaranteed to map to real IDNA hostnames in Windows environments. (That isn't guaranteed in Unix environments of course, which is why I'm still suggesting ASCII/surrogateescape for the general case.) ---------- Added file: http://bugs.python.org/file39812/return-ascii-surrogateescape-2015-06-25.diff Added file: http://bugs.python.org/file39813/accept-ascii-surrogateescape-2015-06-25.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- # HG changeset patch # Parent a497e7faa09b9a836983635b96adbf216a39e4f5 Decode hostnames as ASCII/surrogateescape (except socket.gethostname() on Windows). diff --git a/Doc/library/os.rst b/Doc/library/os.rst --- a/Doc/library/os.rst +++ b/Doc/library/os.rst @@ -587,12 +587,21 @@ process and user. :func:`socket.gethostname` or even ``socket.gethostbyaddr(socket.gethostname())``. + The strings are converted using the file system encoding and + the ``'surrogateescape'`` error handler, except for + :attr:`nodename`, which is converted as ASCII with the + ``'surrogateescape'`` error handler (see the :mod:`socket` + module documentation for details). + Availability: recent flavors of Unix. .. versionchanged:: 3.3 Return type changed from a tuple to a tuple-like object with named attributes. + .. versionchanged:: XXX + The :attr:`nodename` attribute is now converted as + ASCII/``surrogateescape``. .. function:: unsetenv(key) diff --git a/Doc/library/socket.rst b/Doc/library/socket.rst --- a/Doc/library/socket.rst +++ b/Doc/library/socket.rst @@ -124,6 +124,14 @@ differently into an actual IPv4/v6 addre resolution and/or the host configuration. For deterministic behavior use a numeric address in *host* portion. +When a hostname is returned by a system interface (except +:func:`gethostname` on Windows), it is decoded into a string +using the ``'ascii'`` codec and the ``'surrogateescape'`` error +handler; this leaves ASCII bytes as ASCII, including IDNA +ASCII-compatible encodings (see :mod:`encodings.idna`), but +converts any non-ASCII bytes to the Unicode lone surrogate codes +U+DC80...U+DCFF. + All errors raise exceptions. The normal exceptions for invalid argument types and out-of-memory conditions can be raised; starting from Python 3.3, errors related to socket or address semantics raise :exc:`OSError` or one of its diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c --- a/Modules/posixmodule.c +++ b/Modules/posixmodule.c @@ -4464,6 +4464,7 @@ os_uname_impl(PyModuleDef *module) struct utsname u; int res; PyObject *value; + PyObject *o; Py_BEGIN_ALLOW_THREADS res = uname(&u); @@ -4486,7 +4487,13 @@ os_uname_impl(PyModuleDef *module) } \ SET(0, u.sysname); - SET(1, u.nodename); + o = PyUnicode_DecodeASCII(u.nodename, strlen(u.nodename), + "surrogateescape"); + if (!o) { + Py_DECREF(value); + return NULL; + } + PyStructSequence_SET_ITEM(value, 1, o); SET(2, u.release); SET(3, u.version); SET(4, u.machine); diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c --- a/Modules/socketmodule.c +++ b/Modules/socketmodule.c @@ -895,6 +895,15 @@ static PyThread_type_lock netdb_lock; #endif +/* Return the string representation for the given hostname. */ + +static PyObject * +decode_hostname(const char *name) +{ + return PyUnicode_DecodeASCII(name, strlen(name), "surrogateescape"); +} + + /* Convert a string specifying a host name or one of a few symbolic names to a numeric IP address. This usually calls gethostbyname() to do the work; the names "" and "" are special. @@ -4440,7 +4449,7 @@ socket_gethostname(PyObject *self, PyObj if (res < 0) return set_error(); buf[sizeof buf - 1] = '\0'; - return PyUnicode_DecodeFSDefault(buf); + return decode_hostname(buf); #endif } @@ -4562,7 +4571,7 @@ gethost_common(struct hostent *h, struct if (h->h_aliases) { for (pch = h->h_aliases; *pch != NULL; pch++) { int status; - tmp = PyUnicode_FromString(*pch); + tmp = decode_hostname(*pch); if (tmp == NULL) goto err; @@ -4630,7 +4639,8 @@ gethost_common(struct hostent *h, struct goto err; } - rtn_tuple = Py_BuildValue("sOO", h->h_name, name_list, addr_list); + rtn_tuple = Py_BuildValue("NOO", decode_hostname(h->h_name), + name_list, addr_list); err: Py_XDECREF(name_list); @@ -5573,9 +5583,9 @@ socket_getaddrinfo(PyObject *self, PyObj makesockaddr(-1, res->ai_addr, res->ai_addrlen, protocol); if (addr == NULL) goto err; - single = Py_BuildValue("iiisO", res->ai_family, + single = Py_BuildValue("iiiNO", res->ai_family, res->ai_socktype, res->ai_protocol, - res->ai_canonname ? res->ai_canonname : "", + decode_hostname(res->ai_canonname ? res->ai_canonname : ""), addr); Py_DECREF(addr); if (single == NULL) @@ -5681,7 +5691,7 @@ socket_getnameinfo(PyObject *self, PyObj set_gaierror(error); goto fail; } - ret = Py_BuildValue("ss", hbuf, pbuf); + ret = Py_BuildValue("Ns", decode_hostname(hbuf), pbuf); fail: if (res) -------------- next part -------------- # HG changeset patch # Parent 5c2d7aceb46865110857879702bed186f8aa1ad7 Accept ASCII/surrogateescape strings as hostname arguments. diff --git a/Doc/library/socket.rst b/Doc/library/socket.rst --- a/Doc/library/socket.rst +++ b/Doc/library/socket.rst @@ -132,6 +132,19 @@ ASCII-compatible encodings (see :mod:`en converts any non-ASCII bytes to the Unicode lone surrogate codes U+DC80...U+DCFF. +When a string is passed as a hostname argument, it will be +encoded as ASCII if it contains only ASCII characters; otherwise, +the :mod:`~encodings.idna` codec will be used, and if that fails +(for instance, because the string contains lone surrogate codes), +then the string will be encoded using the ``'ascii'`` codec and +the ``'surrogateescape'`` error handler. + + .. versionchanged:: XXX + Previously, hostnames were decoded as UTF-8 (except by + :func:`gethostname`, which on non-Windows platforms used the + file system encoding and the ``'surrogateescape'`` error + handler), and encoded as strict ASCII or IDNA. + All errors raise exceptions. The normal exceptions for invalid argument types and out-of-memory conditions can be raised; starting from Python 3.3, errors related to socket or address semantics raise :exc:`OSError` or one of its diff --git a/Lib/test/test_socket.py b/Lib/test/test_socket.py --- a/Lib/test/test_socket.py +++ b/Lib/test/test_socket.py @@ -1434,6 +1434,66 @@ class GeneralModuleTests(unittest.TestCa self.assertEqual(s.family, 42424) self.assertEqual(s.type, 13331) + +# This should produce the same results with or without network access, +# but can hang for some time if the upstream DNS servers are +# unreachable. + at unittest.skipUnless(support.is_resource_enabled('network'), + 'network is not enabled') +class TestHostnameRepresentations(unittest.TestCase): + + def tryHostnameArgs(self, function, notfounderror): + # Call the given one-argument function with various valid and + # invalid representations of nonexistent hostnames - it should + # raise notfounderror for valid representations. + + # An RFC 1123-compliant host name (".invalid" TLD is reserved + # under RFC 2606). + self.assertRaises(notfounderror, function, "host.domain.invalid.") + # Previous name as bytes and bytearray. + self.assertRaises(notfounderror, function, b"host.domain.invalid.") + self.assertRaises(notfounderror, function, + bytearray(b"host.domain.invalid.")) + # A domain name with a non-ASCII octet, as bytes and bytearray. + self.assertRaises(notfounderror, function, b"\xff.domain.invalid.") + self.assertRaises(notfounderror, function, + bytearray(b"\xff.domain.invalid.")) + # Previous domain name as ASCII/surrogateescape string representation. + self.assertRaises(notfounderror, function, "\udcff.domain.invalid.") + # A legal IDN. + self.assertRaises(notfounderror, function, "???.domain.invalid.") + # A combination of the previous two, which may make sense in + # theory, but is not accepted (the Euro sign means it must be + # interpreted as an IDN, but it is is not a legal IDN, because + # it contains a surrogate character). + self.assertRaises(TypeError, function, "\udcff.???.domain.invalid.") + + def testGethostbynameHostnames(self): + self.tryHostnameArgs(socket.gethostbyname, + (socket.herror, socket.gaierror)) + + def testGethostbyname_exHostnames(self): + self.tryHostnameArgs(socket.gethostbyname_ex, + (socket.herror, socket.gaierror)) + + def testGethostbyaddrHostnames(self): + self.tryHostnameArgs(socket.gethostbyaddr, + (socket.herror, socket.gaierror)) + + def testGetaddrinfoHostnames(self): + self.tryHostnameArgs(lambda host: socket.getaddrinfo(host, None), + socket.gaierror) + + def testSocketObjectHostnames(self): + def f(host): + s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) + try: + s.connect((host, 80)) + finally: + s.close() + self.tryHostnameArgs(f, socket.error) + + @unittest.skipUnless(HAVE_SOCKET_CAN, 'SocketCan required for this test.') class BasicCANTest(unittest.TestCase): @@ -5305,6 +5365,7 @@ def test_main(): tests.append(TestUnixDomain) tests.append(TestLinuxAbstractNamespace) tests.extend([TIPCTest, TIPCThreadableTest]) + tests.append(TestHostnameRepresentations) tests.extend([BasicCANTest, CANTest]) tests.extend([BasicRDSTest, RDSTest]) tests.extend([ diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c --- a/Modules/socketmodule.c +++ b/Modules/socketmodule.c @@ -1413,6 +1413,11 @@ idna_converter(PyObject *obj, struct may return 0; } obj3 = PyUnicode_AsEncodedString(obj2, "idna", NULL); + /* IDNA codec doesn't use UnicodeEncodeError. */ + if (!obj3 && PyErr_ExceptionMatches(PyExc_UnicodeError)) { + PyErr_Clear(); + obj3 = PyUnicode_AsEncodedString(obj2, "ascii", "surrogateescape"); + } Py_DECREF(obj2); if (!obj3) { PyErr_SetString(PyExc_TypeError, "encoding of hostname failed"); @@ -4501,17 +4506,17 @@ extern int sethostname(const char *, siz static PyObject * socket_gethostbyname(PyObject *self, PyObject *args) { - char *name; + struct maybe_idna host = {NULL, NULL}; sock_addr_t addrbuf; PyObject *ret = NULL; - if (!PyArg_ParseTuple(args, "et:gethostbyname", "idna", &name)) + if (!PyArg_ParseTuple(args, "O&:gethostbyname", idna_converter, &host)) return NULL; - if (setipaddr(name, SAS2SA(&addrbuf), sizeof(addrbuf), AF_INET) < 0) + if (setipaddr(host.buf, SAS2SA(&addrbuf), sizeof(addrbuf), AF_INET) < 0) goto finally; ret = makeipaddr(SAS2SA(&addrbuf), sizeof(struct sockaddr_in)); finally: - PyMem_Free(name); + idna_cleanup(&host); return ret; } @@ -4655,7 +4660,7 @@ gethost_common(struct hostent *h, struct static PyObject * socket_gethostbyname_ex(PyObject *self, PyObject *args) { - char *name; + struct maybe_idna host = {NULL, NULL}; struct hostent *h; sock_addr_t addr; struct sockaddr *sa; @@ -4674,27 +4679,27 @@ socket_gethostbyname_ex(PyObject *self, #endif #endif /* HAVE_GETHOSTBYNAME_R */ - if (!PyArg_ParseTuple(args, "et:gethostbyname_ex", "idna", &name)) + if (!PyArg_ParseTuple(args, "O&:gethostbyname_ex", idna_converter, &host)) return NULL; - if (setipaddr(name, SAS2SA(&addr), sizeof(addr), AF_INET) < 0) + if (setipaddr(host.buf, SAS2SA(&addr), sizeof(addr), AF_INET) < 0) goto finally; Py_BEGIN_ALLOW_THREADS #ifdef HAVE_GETHOSTBYNAME_R #if defined(HAVE_GETHOSTBYNAME_R_6_ARG) - gethostbyname_r(name, &hp_allocated, buf, buf_len, + gethostbyname_r(host.buf, &hp_allocated, buf, buf_len, &h, &errnop); #elif defined(HAVE_GETHOSTBYNAME_R_5_ARG) - h = gethostbyname_r(name, &hp_allocated, buf, buf_len, &errnop); + h = gethostbyname_r(host.buf, &hp_allocated, buf, buf_len, &errnop); #else /* HAVE_GETHOSTBYNAME_R_3_ARG */ memset((void *) &data, '\0', sizeof(data)); - result = gethostbyname_r(name, &hp_allocated, &data); + result = gethostbyname_r(host.buf, &hp_allocated, &data); h = (result != 0) ? NULL : &hp_allocated; #endif #else /* not HAVE_GETHOSTBYNAME_R */ #ifdef USE_GETHOSTBYNAME_LOCK PyThread_acquire_lock(netdb_lock, 1); #endif - h = gethostbyname(name); + h = gethostbyname(host.buf); #endif /* HAVE_GETHOSTBYNAME_R */ Py_END_ALLOW_THREADS /* Some C libraries would require addr.__ss_family instead of @@ -4708,7 +4713,7 @@ socket_gethostbyname_ex(PyObject *self, PyThread_release_lock(netdb_lock); #endif finally: - PyMem_Free(name); + idna_cleanup(&host); return ret; } @@ -4727,7 +4732,7 @@ socket_gethostbyaddr(PyObject *self, PyO { sock_addr_t addr; struct sockaddr *sa = SAS2SA(&addr); - char *ip_num; + struct maybe_idna ip_num = {NULL, NULL}; struct hostent *h; PyObject *ret = NULL; #ifdef HAVE_GETHOSTBYNAME_R @@ -4751,10 +4756,10 @@ socket_gethostbyaddr(PyObject *self, PyO int al; int af; - if (!PyArg_ParseTuple(args, "et:gethostbyaddr", "idna", &ip_num)) + if (!PyArg_ParseTuple(args, "O&:gethostbyaddr", idna_converter, &ip_num)) return NULL; af = AF_UNSPEC; - if (setipaddr(ip_num, sa, sizeof(addr), af) < 0) + if (setipaddr(ip_num.buf, sa, sizeof(addr), af) < 0) goto finally; af = sa->sa_family; ap = NULL; @@ -4800,7 +4805,7 @@ socket_gethostbyaddr(PyObject *self, PyO PyThread_release_lock(netdb_lock); #endif finally: - PyMem_Free(ip_num); + idna_cleanup(&ip_num); return ret; } @@ -5502,11 +5507,11 @@ socket_getaddrinfo(PyObject *self, PyObj PyObject *hobj = NULL; PyObject *pobj = (PyObject *)NULL; char pbuf[30]; - char *hptr, *pptr; + char *pptr; int family, socktype, protocol, flags; int error; PyObject *all = (PyObject *)NULL; - PyObject *idna = NULL; + struct maybe_idna host = {NULL, NULL}; socktype = protocol = flags = 0; family = AF_UNSPEC; @@ -5516,20 +5521,8 @@ socket_getaddrinfo(PyObject *self, PyObj return NULL; } if (hobj == Py_None) { - hptr = NULL; - } else if (PyUnicode_Check(hobj)) { - _Py_IDENTIFIER(encode); - - idna = _PyObject_CallMethodId(hobj, &PyId_encode, "s", "idna"); - if (!idna) - return NULL; - assert(PyBytes_Check(idna)); - hptr = PyBytes_AS_STRING(idna); - } else if (PyBytes_Check(hobj)) { - hptr = PyBytes_AsString(hobj); - } else { - PyErr_SetString(PyExc_TypeError, - "getaddrinfo() argument 1 must be string or None"); + host.buf = NULL; + } else if (!idna_converter(hobj, &host)) { return NULL; } if (PyLong_CheckExact(pobj)) { @@ -5566,7 +5559,7 @@ socket_getaddrinfo(PyObject *self, PyObj hints.ai_flags = flags; Py_BEGIN_ALLOW_THREADS ACQUIRE_GETADDRINFO_LOCK - error = getaddrinfo(hptr, pptr, &hints, &res0); + error = getaddrinfo(host.buf, pptr, &hints, &res0); Py_END_ALLOW_THREADS RELEASE_GETADDRINFO_LOCK /* see comment in setipaddr() */ if (error) { @@ -5595,13 +5588,13 @@ socket_getaddrinfo(PyObject *self, PyObj goto err; Py_XDECREF(single); } - Py_XDECREF(idna); + idna_cleanup(&host); if (res0) freeaddrinfo(res0); return all; err: Py_XDECREF(all); - Py_XDECREF(idna); + idna_cleanup(&host); if (res0) freeaddrinfo(res0); return (PyObject *)NULL; From report at bugs.python.org Thu Jun 25 22:28:44 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 25 Jun 2015 20:28:44 +0000 Subject: [issue18857] urlencode of a None value uses the string 'None' In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za> Message-ID: <1435264124.36.0.763069716178.issue18857@psf.upfronthosting.co.za> R. David Murray added the comment: I see no reason for this issue to be open. As suggested on the linked bug, the value should be passed as an empty string (which will produce, eg "&foo=&a='1'", which is the "correct" format for such a parameter. Unless someone can point to a "real" web server that does something different with "&foo" than with "&foo=", there is no reason to make a change to Python. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 22:39:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 25 Jun 2015 20:39:03 +0000 Subject: [issue23684] urlparse() documentation does not account for default scheme In-Reply-To: <1426556382.03.0.776976224321.issue23684@psf.upfronthosting.co.za> Message-ID: <20150625203900.14147.60424@psf.io> Roundup Robot added the comment: New changeset 368db4b1ced9 by Berker Peksag in branch '3.4': Issue #23684: Clarify the return value of the scheme attribute of ParseResult and SplitResult objects. https://hg.python.org/cpython/rev/368db4b1ced9 New changeset 68629ebe0fee by Berker Peksag in branch '3.5': Issue #23684: Clarify the return value of the scheme attribute of ParseResult and SplitResult objects. https://hg.python.org/cpython/rev/68629ebe0fee New changeset 7846aadbd4f5 by Berker Peksag in branch 'default': Issue #23684: Clarify the return value of the scheme attribute of ParseResult and SplitResult objects. https://hg.python.org/cpython/rev/7846aadbd4f5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 22:46:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 25 Jun 2015 20:46:51 +0000 Subject: [issue23684] urlparse() documentation does not account for default scheme In-Reply-To: <1426556382.03.0.776976224321.issue23684@psf.upfronthosting.co.za> Message-ID: <20150625204648.35967.93025@psf.io> Roundup Robot added the comment: New changeset 7bf9e10fc32f by Berker Peksag in branch '2.7': Issue #23684: Clarify the return value of the scheme attribute of ParseResult and SplitResult objects. https://hg.python.org/cpython/rev/7bf9e10fc32f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 22:48:05 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 25 Jun 2015 20:48:05 +0000 Subject: [issue23684] urlparse() documentation does not account for default scheme In-Reply-To: <1426556382.03.0.776976224321.issue23684@psf.upfronthosting.co.za> Message-ID: <1435265285.0.0.488702143286.issue23684@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks Martin. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 22:56:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 25 Jun 2015 20:56:50 +0000 Subject: [issue24496] Non-idiomatic examples in gzip docs In-Reply-To: <1435141033.01.0.69017919729.issue24496@psf.upfronthosting.co.za> Message-ID: <20150625205647.16794.84470@psf.io> Roundup Robot added the comment: New changeset 10eea15880db by Berker Peksag in branch '2.7': Issue #24496: Backport gzip examples to Python 2. https://hg.python.org/cpython/rev/10eea15880db ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 22:59:41 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 25 Jun 2015 20:59:41 +0000 Subject: [issue24496] Non-idiomatic examples in gzip docs In-Reply-To: <1435141033.01.0.69017919729.issue24496@psf.upfronthosting.co.za> Message-ID: <1435265981.81.0.298421895945.issue24496@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Jakub. I've updated the patch to match ae1528beae67 (thanks Martin) and commit it. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 23:05:30 2015 From: report at bugs.python.org (Arc Riley) Date: Thu, 25 Jun 2015 21:05:30 +0000 Subject: [issue24511] Add methods for async protocols In-Reply-To: <1435246948.22.0.255546128718.issue24511@psf.upfronthosting.co.za> Message-ID: <1435266330.2.0.170163835687.issue24511@psf.upfronthosting.co.za> Changes by Arc Riley : ---------- nosy: +ArcRiley _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jun 25 23:32:42 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 25 Jun 2015 21:32:42 +0000 Subject: [issue24420] Documentation regressions from adding subprocess.run() In-Reply-To: <1433909056.73.0.964707918197.issue24420@psf.upfronthosting.co.za> Message-ID: <1435267962.91.0.666043694374.issue24420@psf.upfronthosting.co.za> Berker Peksag added the comment: LGTM, too. I just left a comment on Rietveld. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 01:21:29 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 25 Jun 2015 23:21:29 +0000 Subject: [issue24508] Backport 3.5's Windows build project files to 2.7 In-Reply-To: <1435206408.67.0.0166063443293.issue24508@psf.upfronthosting.co.za> Message-ID: <1435274489.92.0.966016199669.issue24508@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 05:12:26 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Fri, 26 Jun 2015 03:12:26 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <1435288346.78.0.675692873015.issue20387@psf.upfronthosting.co.za> Jason R. Coombs added the comment: @gumblex, I've applied your updated patch (though I couldn't figure out why it wouldn't apply mechanically; I had to paste it). I also corrected the test. Thanks for the advice on that. I don't understand the second half of your message. Are you stating caveats for our edification? Do you have outstanding concerns? Can you confirm your original report is corrected by the latest tip in the patch repository? I believe what remains to be done is to add a NEWS entry and merge the changes with the 3.4, 3.5, and default branches. If a 2.7 backport is required, that could be done also. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 06:04:13 2015 From: report at bugs.python.org (Rusi) Date: Fri, 26 Jun 2015 04:04:13 +0000 Subject: [issue24513] decimal test version mismatch Message-ID: <1435291452.99.0.632352537758.issue24513@psf.upfronthosting.co.za> New submission from Rusi: In http://bugs.python.org/issue24507 there was an apprehension about changing the decimal test versions. Poking around I find that the versions in headers of files in Lib/test/decimaltestdata refer to version 2.59 and the IBM link http://www2.hursley.ibm.com/decimal which is dead Whereas help(decimal) points to http://speleotrove.com/decimal/decarith.html -- version 1.70 http://speleotrove.com/decimal/ contains dectest.zip which is at version 2.62 ---------- messages: 245835 nosy: RusiMody, eric.smith, zach.ware priority: normal severity: normal status: open title: decimal test version mismatch versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 07:29:52 2015 From: report at bugs.python.org (Jacques-D. Piguet) Date: Fri, 26 Jun 2015 05:29:52 +0000 Subject: [issue19065] sqlite3 timestamp adapter chokes on timezones In-Reply-To: <1379808201.46.0.645672081963.issue19065@psf.upfronthosting.co.za> Message-ID: <1435296592.46.0.950980085254.issue19065@psf.upfronthosting.co.za> Jacques-D. Piguet added the comment: I just hit the problem in Python 2.7. The patch given here is not applicable due to missing class "datetime.timezone" in Python before 3.2. Question 1: when will the patch be applied in Python 3? Question 2: any chance to get a solution in Python 2? ---------- nosy: +jacques-piguet type: enhancement -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 09:40:39 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 26 Jun 2015 07:40:39 +0000 Subject: [issue24510] Make _PyCoro_GetAwaitableIter a public API In-Reply-To: <1435246558.17.0.296607565259.issue24510@psf.upfronthosting.co.za> Message-ID: <1435304439.05.0.393560401247.issue24510@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 for deferring to 3.6 (version field adjusted accordingly) One nice aspect of marking private APIs by convention rather than having them enforced by the compiler is that the folks that *really* need them can ignore our recommendation and accept the fact they may need to adapt their code to account for backwards incompatible changes. ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 09:42:35 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 26 Jun 2015 07:42:35 +0000 Subject: [issue24511] Add methods for async protocols In-Reply-To: <1435246948.22.0.255546128718.issue24511@psf.upfronthosting.co.za> Message-ID: <1435304555.26.0.920112614232.issue24511@psf.upfronthosting.co.za> Nick Coghlan added the comment: As per the discussion on issue 24510, we can wait until 3.6 to decide the details of a public C level API for the PEP 492 machinery. ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 11:10:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Jun 2015 09:10:48 +0000 Subject: [issue24456] audioop.adpcm2lin Buffer Over-read In-Reply-To: <1434401846.51.0.0422696666136.issue24456@psf.upfronthosting.co.za> Message-ID: <1435309848.35.0.731825782235.issue24456@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> needs patch versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 11:11:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Jun 2015 09:11:05 +0000 Subject: [issue24457] audioop.lin2adpcm Buffer Over-read In-Reply-To: <1434401906.27.0.811918052895.issue24457@psf.upfronthosting.co.za> Message-ID: <1435309865.56.0.503643619116.issue24457@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> needs patch versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 11:18:57 2015 From: report at bugs.python.org (Philippe) Date: Fri, 26 Jun 2015 09:18:57 +0000 Subject: [issue24514] tarfile fails to extract archive (handled fine by gnu tar and bsdtar) Message-ID: <1435310337.24.0.0720447050888.issue24514@psf.upfronthosting.co.za> New submission from Philippe: The extraction fails when calling tarfile.open using this archive: http://archive.apache.org/dist/commons/logging/source/commons-logging-1.1.2-src.tar.gz After some investigation, the file can be extracted with gnu tar and bsdtar and the gzip compression is not the issue: if I gunzip the tar.gz to a tar and call tarfile on plain tar, the problem is the same. Also this archive was created most likely on Windows (based on the `file` command output) using some Java tools per http://commons.apache.org/proper/commons-logging/building.html from these original files: http://svn.apache.org/repos/asf/commons/proper/logging/tags/LOGGING_1_1_2/ ... that's all I could find out. The error trace is slightly different on 2.7 and 3.4 but similar. The problem has been verified on Linux 64 with Python 2.7 and 3.4 and on Windows with Python 2.7. On 2.7: >>> TarFile.taropen(name) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/tarfile.py", line 1705, in taropen return cls(name, mode, fileobj, **kwargs) File "/usr/lib/python2.7/tarfile.py", line 1574, in __init__ self.firstmember = self.next() File "/usr/lib/python2.7/tarfile.py", line 2335, in next raise ReadError(str(e)) tarfile.ReadError: invalid header On 3.4: >>> TarFile.taropen(name) Traceback (most recent call last): File "/usr/lib/python3.4/tarfile.py", line 180, in nti n = int(nts(s, "ascii", "strict") or "0", 8) ValueError: invalid literal for int() with base 8: ' ' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.4/tarfile.py", line 2248, in next tarinfo = self.tarinfo.fromtarfile(self) File "/usr/lib/python3.4/tarfile.py", line 1083, in fromtarfile obj = cls.frombuf(buf, tarfile.encoding, tarfile.errors) File "/usr/lib/python3.4/tarfile.py", line 1032, in frombuf obj.uid = nti(buf[108:116]) File "/usr/lib/python3.4/tarfile.py", line 182, in nti raise InvalidHeaderError("invalid header") tarfile.InvalidHeaderError: invalid header During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.4/tarfile.py", line 1595, in taropen return cls(name, mode, fileobj, **kwargs) File "/usr/lib/python3.4/tarfile.py", line 1469, in __init__ self.firstmember = self.next() File "/usr/lib/python3.4/tarfile.py", line 2260, in next raise ReadError(str(e)) tarfile.ReadError: invalid header ---------- components: Library (Lib) files: commons-logging-1.1.2-src.tar.gz messages: 245839 nosy: lars.gustaebel, pombreda priority: normal severity: normal status: open title: tarfile fails to extract archive (handled fine by gnu tar and bsdtar) versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file39814/commons-logging-1.1.2-src.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 11:21:27 2015 From: report at bugs.python.org (Philippe) Date: Fri, 26 Jun 2015 09:21:27 +0000 Subject: [issue24514] tarfile fails to extract archive (handled fine by gnu tar and bsdtar) In-Reply-To: <1435310337.24.0.0720447050888.issue24514@psf.upfronthosting.co.za> Message-ID: <1435310487.35.0.193514148925.issue24514@psf.upfronthosting.co.za> Philippe added the comment: Note: the traceback above are from calling taropen on the gunzipped tar.gz The error are similar but a tar less informative when using the tgz and open. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 11:49:10 2015 From: report at bugs.python.org (Luc Saffre) Date: Fri, 26 Jun 2015 09:49:10 +0000 Subject: [issue24515] docstring of isinstance Message-ID: <1435312150.5.0.444169583356.issue24515@psf.upfronthosting.co.za> New submission from Luc Saffre: The docstring of built-in function 'isinstance' should explain that if the classinfo is a tuple, the object must be instance of *any* (not *all*) of the class objects. ---------- assignee: docs at python components: Documentation messages: 245841 nosy: Luc Saffre, docs at python priority: normal severity: normal status: open title: docstring of isinstance type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 11:51:11 2015 From: report at bugs.python.org (Zahari Dim) Date: Fri, 26 Jun 2015 09:51:11 +0000 Subject: [issue24500] provide context manager to redirect C output In-Reply-To: <1435161782.93.0.989546707262.issue24500@psf.upfronthosting.co.za> Message-ID: <1435312271.41.0.594609441694.issue24500@psf.upfronthosting.co.za> Zahari Dim added the comment: Well, the simple minded example I posted has so many bugs (many of which I don't understand, for example why it destroys the stdout of an interpreter permanently) that I really think this feature is necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 11:58:18 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 26 Jun 2015 09:58:18 +0000 Subject: [issue24515] docstring of isinstance In-Reply-To: <1435312150.5.0.444169583356.issue24515@psf.upfronthosting.co.za> Message-ID: <1435312698.26.0.656282412319.issue24515@psf.upfronthosting.co.za> Steven D'Aprano added the comment: It already does: "The form using a tuple, isinstance(x, (A, B, ...)), is a shortcut for isinstance(x, A) or isinstance(x, B) or ... (etc.)." If it were "all", it would use "and", not "or". I don't think any change is needed. Do you have a suggestion for new wording? If not, I'm going to close this issue. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 12:00:10 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Fri, 26 Jun 2015 10:00:10 +0000 Subject: [issue24514] tarfile fails to extract archive (handled fine by gnu tar and bsdtar) In-Reply-To: <1435310337.24.0.0720447050888.issue24514@psf.upfronthosting.co.za> Message-ID: <1435312810.36.0.0249725217954.issue24514@psf.upfronthosting.co.za> Lars Gust?bel added the comment: The problem is that the tar archive has empty uid and gid fields, i.e. 7 spaces terminated with a null-byte. I attached a patch that solves the problem. ---------- keywords: +patch Added file: http://bugs.python.org/file39815/issue24514.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 12:03:13 2015 From: report at bugs.python.org (Philippe) Date: Fri, 26 Jun 2015 10:03:13 +0000 Subject: [issue24514] tarfile fails to extract archive (handled fine by gnu tar and bsdtar) In-Reply-To: <1435310337.24.0.0720447050888.issue24514@psf.upfronthosting.co.za> Message-ID: <1435312993.79.0.567309824021.issue24514@psf.upfronthosting.co.za> Philippe added the comment: lars: you are my hero! you rock. I picture you being able to read through tar binary headers while you sleep. I am in awe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 12:10:34 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Fri, 26 Jun 2015 10:10:34 +0000 Subject: [issue24514] tarfile fails to extract archive (handled fine by gnu tar and bsdtar) In-Reply-To: <1435310337.24.0.0720447050888.issue24514@psf.upfronthosting.co.za> Message-ID: <1435313434.85.0.433750253161.issue24514@psf.upfronthosting.co.za> Lars Gust?bel added the comment: You're welcome :-D ---------- assignee: -> lars.gustaebel priority: normal -> low stage: -> patch review type: -> behavior versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 12:17:17 2015 From: report at bugs.python.org (Philippe) Date: Fri, 26 Jun 2015 10:17:17 +0000 Subject: [issue24514] tarfile fails to extract archive (handled fine by gnu tar and bsdtar) In-Reply-To: <1435310337.24.0.0720447050888.issue24514@psf.upfronthosting.co.za> Message-ID: <1435313837.18.0.900771722059.issue24514@psf.upfronthosting.co.za> Philippe added the comment: I verified that the patch issue24514.diff (adding .rstrip() ) works also on Python 2.7. I verified it also works on Python 3.4 I ran it on 2.7 against a fairly large test suite of tar files without problems. This is a +1 for me. Lars: Do you think you could apply it to 2.7 too? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 12:35:47 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Fri, 26 Jun 2015 10:35:47 +0000 Subject: [issue24514] tarfile fails to extract archive (handled fine by gnu tar and bsdtar) In-Reply-To: <1435310337.24.0.0720447050888.issue24514@psf.upfronthosting.co.za> Message-ID: <1435314947.54.0.620330052422.issue24514@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Yes, Python 2.7 still gets bugfixes. However, there's still some work to do on the patch (maybe clean the code, write a test, add a NEWS entry). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 12:59:05 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 26 Jun 2015 10:59:05 +0000 Subject: [issue24513] decimal test version mismatch In-Reply-To: <1435291452.99.0.632352537758.issue24513@psf.upfronthosting.co.za> Message-ID: <1435316345.88.0.529360351588.issue24513@psf.upfronthosting.co.za> Stefan Krah added the comment: For libmpdec (and thus _decimal) I've always used the latest version of dectest.zip. Upgrading decimaltestdata/* will not make any difference. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 14:41:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Jun 2015 12:41:30 +0000 Subject: [issue24456] audioop.adpcm2lin Buffer Over-read In-Reply-To: <1434401846.51.0.0422696666136.issue24456@psf.upfronthosting.co.za> Message-ID: <1435322490.19.0.71796092173.issue24456@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that checks the state and raises ValueError if integer values out of range. ---------- keywords: +patch Added file: http://bugs.python.org/file39816/audioop_adpcm_range_check.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 14:56:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Jun 2015 12:56:36 +0000 Subject: [issue24457] audioop.lin2adpcm Buffer Over-read In-Reply-To: <1434401906.27.0.811918052895.issue24457@psf.upfronthosting.co.za> Message-ID: <1435323396.41.0.361609712864.issue24457@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch for issue24456 fixes this issue. ---------- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> audioop.adpcm2lin Buffer Over-read _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 15:05:40 2015 From: report at bugs.python.org (Petr Messner) Date: Fri, 26 Jun 2015 13:05:40 +0000 Subject: [issue24516] SSL create_default_socket purpose insufficiently documented Message-ID: <1435323940.35.0.0347196481189.issue24516@psf.upfronthosting.co.za> New submission from Petr Messner: Please, is it possible to put more information about the purpose parameter to the documentation of ssl.create_default_context()? It's not obvious that SERVER_AUTH should be used for client sockets and not server sockets. It took me a while to discover this, while all I was getting was only "SSLEOFError: EOF occurred in violation of protocol" (which is also not helpful). This is especially confusing, because OpenSSL uses serverAuth and clientAuth (for extendedKeyUsage configuration) in the exactly opposite meaning. ---------- assignee: docs at python components: Documentation messages: 245852 nosy: docs at python, messa priority: normal severity: normal status: open title: SSL create_default_socket purpose insufficiently documented type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 15:29:40 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 26 Jun 2015 13:29:40 +0000 Subject: [issue24516] SSL create_default_socket purpose insufficiently documented In-Reply-To: <1435323940.35.0.0347196481189.issue24516@psf.upfronthosting.co.za> Message-ID: <1435325380.68.0.467720873084.issue24516@psf.upfronthosting.co.za> Christian Heimes added the comment: Python uses serverAuth and clientAuth in the exact same meaning as EKU (extended key usage). In order to create X.509 cert for a web server, it should have EKU "SSL/TLS Web Server Authentication". On the other hand a client must validate the cert for a specific purpose, too. So the client creates a context with purpose SERVER_AUTH. This loads only trust anchors which are flagged with EKU "SSL/TLS Web Server Authentication". For TLS/SSL server it is the other way around. The server side uses a context with CLIENT_AUTH to load only root certs that can validate client certs. Other purposes aren't supported because Python's ssl does neither support S/MIME nor code signing. https://docs.python.org/2/library/ssl.html#ssl.SSLContext.load_default_certs explains the purpose flags, too. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 15:50:52 2015 From: report at bugs.python.org (Rusi) Date: Fri, 26 Jun 2015 13:50:52 +0000 Subject: [issue24513] decimal test version mismatch In-Reply-To: <1435316345.88.0.529360351588.issue24513@psf.upfronthosting.co.za> Message-ID: Rusi added the comment: On Fri, Jun 26, 2015 at 4:29 PM, Stefan Krah wrote: > > Stefan Krah added the comment: > > For libmpdec (and thus _decimal) I've always used the latest version > of dectest.zip. Upgrading decimaltestdata/* will not make any difference. > Not sure Stefan what you are saying. Under the assumption that you are addressing the apprehension of eric.smith in the earlier bug-report http://bugs.python.org/issue24507, Eric's comment is here reproduced: > At least for the files in decimaltestdata, I'd be wary about changing > them. My understanding is that these files are from the IBM decimal > test library. I don't think we should stray from upstream here, even > for something as simple as line endings. > Unfortunately, the link http://www2.hursley.ibm.com/decimal from the > file headers is no longer valid. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 16:38:45 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 26 Jun 2015 14:38:45 +0000 Subject: [issue24513] decimal test version mismatch In-Reply-To: <1435291452.99.0.632352537758.issue24513@psf.upfronthosting.co.za> Message-ID: <1435329525.19.0.398318127387.issue24513@psf.upfronthosting.co.za> Stefan Krah added the comment: I'm saying that decimal has already been tested against the most recent test cases. For (non-technical) reasons that I don't want to go into right now, I'd prefer to postpone the update though. ---------- resolution: -> later status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 17:18:34 2015 From: report at bugs.python.org (testbpo) Date: Fri, 26 Jun 2015 15:18:34 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1435331914.43.0.213874300128.issue2771@psf.upfronthosting.co.za> Changes by testbpo : Added file: http://bugs.python.org/file39817/testtestpatch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 17:21:44 2015 From: report at bugs.python.org (Dingyuan Wang) Date: Fri, 26 Jun 2015 15:21:44 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <1435332104.91.0.828467310171.issue20387@psf.upfronthosting.co.za> Dingyuan Wang added the comment: I mean the patch only restores tabs in indentation. The reports above should be corrected. Tabs between tokens and other race conditions can't be restored exactly providing the token stream. This won't affect the syntax. I wonder if it's also a bug or a wont-fix in tokenize/untokenize roundtrip because fixing it involves adding whitespace information in the token stream. (I can't pull down the whole hg repo, so the patch is manually created by just diffing two versions.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 17:38:51 2015 From: report at bugs.python.org (testbpo) Date: Fri, 26 Jun 2015 15:38:51 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1435333131.18.0.726529208303.issue2771@psf.upfronthosting.co.za> Changes by testbpo : Added file: http://bugs.python.org/file39819/issue18958-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 19:45:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Jun 2015 17:45:26 +0000 Subject: [issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za> Message-ID: <1435340726.09.0.743750638399.issue19176@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that also fixes other issues with doctype. 1) Direct call of doctype() issues a warning. 2) Parser's doctype() is not called if target's doctype() is called. ---------- Added file: http://bugs.python.org/file39820/inherit-doctype.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 19:46:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Jun 2015 17:46:37 +0000 Subject: [issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za> Message-ID: <1435340796.99.0.368570129872.issue19176@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 2.7, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 19:53:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Jun 2015 17:53:14 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <1435341194.22.0.280542943585.issue24336@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 19:59:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 26 Jun 2015 17:59:00 +0000 Subject: [issue22609] Constructors of some mapping classes don't accept `self` keyword argument In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za> Message-ID: <1435341540.46.0.641832432405.issue22609@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch addresses Martin's comments. ---------- versions: +Python 3.6 Added file: http://bugs.python.org/file39821/UserDict_self_and_dict_keywords_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 21:13:45 2015 From: report at bugs.python.org (dendory) Date: Fri, 26 Jun 2015 19:13:45 +0000 Subject: [issue24517] %z does not work in time.strftime() Message-ID: <1435346025.05.0.415032825862.issue24517@psf.upfronthosting.co.za> New submission from dendory: Using `%z` gives the same result as using `%Z` in `time.strftime()`: Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:43:06) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.strftime("%z") 'Eastern Daylight Time' >>> time.strftime("%Z") 'Eastern Daylight Time' Instead it's supposed to give a +0000 or -0000 result. ---------- messages: 245860 nosy: dendory priority: normal severity: normal status: open title: %z does not work in time.strftime() versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 21:18:28 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 26 Jun 2015 19:18:28 +0000 Subject: [issue24517] %z does not work in time.strftime() In-Reply-To: <1435346025.05.0.415032825862.issue24517@psf.upfronthosting.co.za> Message-ID: <1435346308.38.0.0563649891017.issue24517@psf.upfronthosting.co.za> R. David Murray added the comment: That's a platform peculiarity. See issue 20281. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> time.strftime %z format specifier is the same as %Z _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 21:43:43 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 26 Jun 2015 19:43:43 +0000 Subject: [issue24485] Function source inspection fails on closures In-Reply-To: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za> Message-ID: <1435347823.46.0.798285345758.issue24485@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I verified (Win7, but should be irrelevant) that test.py works on 2.7.10 and 3.4.3. The failure in 3.5.0b2 is omitting the body of inner. Add another line to inner and both are omitted, so 'body' seems correct Add another line to outer, and nothing is omitted. def outer(): def inner(): inner1 inner2 outer2 is displayed completely. So the omission is the body of an inner function that is the last statement of outer. This rule is not recursive, in the sense that for def outer(): def middle(): def inner(): inner1 "def inner ..." is entirely omitted, not just 'inner1'. The omission seems specific to 'def' as it does not occur with the other compound statements I tested (if, while). ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 21:53:45 2015 From: report at bugs.python.org (dendory) Date: Fri, 26 Jun 2015 19:53:45 +0000 Subject: [issue24517] %z does not work in time.strftime() In-Reply-To: <1435346025.05.0.415032825862.issue24517@psf.upfronthosting.co.za> Message-ID: <1435348425.27.0.248695254853.issue24517@psf.upfronthosting.co.za> dendory added the comment: Uh? But that's completely besides the point. Windows provides timezone offset information in a different way than Linux does (through the Registry) but it's still available. It's trivial to do in .NET for example: Console.WriteLine(TimeZone.CurrentTimeZone.GetUtcOffset(DateTime.Now)); Aren't a lot of things implemented differently in Linux and Windows? I'm not familiar with Python's internals, but I'm sure a lot of functions are implemented differently cross platform. This bug is certainly valid, as any code using this function will not work as expected on this platform. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 22:14:06 2015 From: report at bugs.python.org (dendory) Date: Fri, 26 Jun 2015 20:14:06 +0000 Subject: [issue20281] time.strftime %z format specifier is the same as %Z In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za> Message-ID: <1435349646.62.0.0589439583662.issue20281@psf.upfronthosting.co.za> dendory added the comment: Why is the focus on documentation entries when the real work should be on trying to make this function to work on all platforms? I understand that Windows's implementation of strftime() defines %z and %Z to return the same thing, but timezone information is still available in other ways. For example, _get_timezone() returns the offset in seconds between localtime and UTC. I don't have VC++ 2010 installed so I can't test it but this seems like a fairly simple thing to fix. Just take that result and multiply. ref: https://msdn.microsoft.com/en-us/library/38wx0s70%28v=vs.100%29.aspx ---------- nosy: +dendory _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 22:25:44 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 26 Jun 2015 20:25:44 +0000 Subject: [issue20281] time.strftime %z format specifier is the same as %Z In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za> Message-ID: <1435350344.92.0.400284840172.issue20281@psf.upfronthosting.co.za> R. David Murray added the comment: Because there's a different issue for making strftime system independent, issue 3173. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 22:27:48 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 26 Jun 2015 20:27:48 +0000 Subject: [issue24517] %z does not work in time.strftime() In-Reply-To: <1435346025.05.0.415032825862.issue24517@psf.upfronthosting.co.za> Message-ID: <1435350468.6.0.716856531026.issue24517@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, but the Microsoft C runtime doesn't use that interface, and it is currently the C runtime that we use to implement strftime. This could change, but that's an enhancement. See issue 3173 for example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 22:46:38 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 26 Jun 2015 20:46:38 +0000 Subject: [issue24485] Function source inspection fails on closures In-Reply-To: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za> Message-ID: <1435351598.91.0.0702642823042.issue24485@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The test suite must lack, and therefore needs, a simple testcase as in test.py. In 3.4 and 3.5, getsource() joins the list of lines returned by getsourcelines(). In both versions, getsourcelines uses findsource(), which seems to be unchanged. In 3.5, the output of findsource for code, function, and method objects is postprocessed by _line_number_helper(code_object). The bug applies to methods also. class C: def outer(): def inner(): inner1 from inspect import getsource print(getsource(C.outer)) omits 'inner1', but getsource(C) does not. I believe the regression is due to ac86e5b2d45b in #21217. (At first glance, it would seem that the fixup in _line_number_helper should be in the code object part of findsource itself.) I requested on that issue that the authors take a look at this. ---------- stage: needs patch -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 22:46:46 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 26 Jun 2015 20:46:46 +0000 Subject: [issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator In-Reply-To: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za> Message-ID: <1435351606.43.0.436023256328.issue21217@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I strongly suspect that ac86e5b2d45b is the cause of the regression reported in #24485. def outer(): def inner(): inner1 from inspect import getsource print(getsource(outer)) omits the body of inner. Ditto if outer is a method. All is okay if outer is a method and the source of the class is requested. Could the authors, Allison and Thomas, take a look and try to fix _line_number_helper to pass the added test (and possibly incorporate it into findsource)? Since there is a new issue already, this one can be left closed and further work posted to #24485. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 23:05:19 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 26 Jun 2015 21:05:19 +0000 Subject: [issue24492] using custom objects as modules: AttributeErrors new in 3.5 In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za> Message-ID: <1435352719.37.0.597841818603.issue24492@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I view having a string __name__ attribute as part of quacking like a module (or class or function). Hence pseudonames like '' (lambda expression) or (the module name for interactive input, where n is the line number). Is there a good reason for custom 'module' objects to not have a name? If so, the 'graceful muddle' precedent is to give them a pseudoname, such as , perhaps with a prefix or suffix. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 23:07:25 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 26 Jun 2015 21:07:25 +0000 Subject: [issue24498] Should ptags and eptags be removed from repo? In-Reply-To: <1435155990.35.0.688744790399.issue24498@psf.upfronthosting.co.za> Message-ID: <1435352845.25.0.417645220495.issue24498@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- components: +Demos and Tools stage: -> needs patch title: Shoudl ptags and eptags be removed from repo? -> Should ptags and eptags be removed from repo? type: -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 23:07:54 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 26 Jun 2015 21:07:54 +0000 Subject: [issue24492] using custom objects as modules: AttributeErrors new in 3.5 In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za> Message-ID: <1435352874.23.0.432692712942.issue24492@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jun 26 23:20:18 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 26 Jun 2015 21:20:18 +0000 Subject: [issue24515] docstring of isinstance In-Reply-To: <1435312150.5.0.444169583356.issue24515@psf.upfronthosting.co.za> Message-ID: <1435353618.07.0.903720805027.issue24515@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree that the tuple explanation if ok. But "Return whether an object is an instance of a class or of a subclass thereof." (3.5) seems wrong. I believe 'subclass' should be 'superclass'. >>> class C: pass >>> class Csub(C): pass >>> isinstance(C(), Csub) False >>> isinstance(Csub(), C) True ---------- nosy: +terry.reedy versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 00:15:00 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 26 Jun 2015 22:15:00 +0000 Subject: [issue24515] docstring of isinstance In-Reply-To: <1435353618.07.0.903720805027.issue24515@psf.upfronthosting.co.za> Message-ID: <20150626221442.GW20701@ando.pearwood.info> Steven D'Aprano added the comment: On Fri, Jun 26, 2015 at 09:20:18PM +0000, Terry J. Reedy wrote: > I agree that the tuple explanation if ok. But "Return whether an > object is an instance of a class or of a subclass thereof." (3.5) > seems wrong. I believe 'subclass' should be 'superclass'. No, the current description is correct. > >>> class C: pass > >>> class Csub(C): pass > >>> isinstance(C(), Csub) > False In this case, the instance C() is an instance of a *superclass* of Csub, and isinstance returns False. > >>> isinstance(Csub(), C) > True In this case, the instance Csub() is an instance of a *subclass* of C, and isinstance returns True. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 00:22:48 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Jun 2015 22:22:48 +0000 Subject: [issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator In-Reply-To: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za> Message-ID: <1435357368.83.0.672370132709.issue21217@psf.upfronthosting.co.za> Yury Selivanov added the comment: Here's an update on #24485 regression. Looks like getsource() is now using code objects instead of tokenizer to determine blocks first/last lines. The problem with this particular case is that "inner" function's code object is completely independent from "outer"'s. So, for an outer() function below: def outer(): def inner(): never_reached1 never_reached2 the code object contains the following opcodes: 71 0 LOAD_CONST 1 () 3 LOAD_CONST 2 ('outer1..inner') 6 MAKE_FUNCTION 0 9 STORE_FAST 0 (inner) 12 LOAD_CONST 0 (None) 15 RETURN_VALUE The correct solution is to use co_lnotab along with co_firstlineno to iterate through opcodes recursively accounting for MAKE_FUNCTION's code objects. *However*, I don't think we can solve this for classes, i.e. def outer_with_class(): class Foo: b = 1 a = 2 there is no way (as far as I know) to get information about the Foo class start/end lineno. I think that the only way we can solve this is to revert the patch for this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 00:23:17 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 26 Jun 2015 22:23:17 +0000 Subject: [issue24485] Function source inspection fails on closures In-Reply-To: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za> Message-ID: <1435357397.91.0.490874640772.issue24485@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks, Terry. I posted some findings to #21217. ---------- nosy: +ncoghlan, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 00:59:43 2015 From: report at bugs.python.org (Catherine Devlin) Date: Fri, 26 Jun 2015 22:59:43 +0000 Subject: [issue24518] json.dumps should accept key function for ``sort_keys`` Message-ID: <1435359583.87.0.439013044096.issue24518@psf.upfronthosting.co.za> New submission from Catherine Devlin: Right now, json.dumps can be called with True or False, but it would be easy to also support accepting a key function, which then could be used to control the order of keys arbitrarily in the serialized JSON output. ---------- components: Library (Lib) messages: 245874 nosy: catherinedevlin priority: normal severity: normal status: open title: json.dumps should accept key function for ``sort_keys`` type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 01:42:41 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 26 Jun 2015 23:42:41 +0000 Subject: [issue24515] docstring of isinstance In-Reply-To: <1435312150.5.0.444169583356.issue24515@psf.upfronthosting.co.za> Message-ID: <1435362161.18.0.268709741818.issue24515@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Right. Close this unless something else is offered. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 03:10:37 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 27 Jun 2015 01:10:37 +0000 Subject: [issue24516] SSL create_default_socket purpose insufficiently documented In-Reply-To: <1435323940.35.0.0347196481189.issue24516@psf.upfronthosting.co.za> Message-ID: <1435367437.0.0.189161291602.issue24516@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 04:17:30 2015 From: report at bugs.python.org (Meador Inge) Date: Sat, 27 Jun 2015 02:17:30 +0000 Subject: [issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator In-Reply-To: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za> Message-ID: <1435371450.72.0.416928837354.issue21217@psf.upfronthosting.co.za> Meador Inge added the comment: > I think that the only way we can solve this is to revert the patch for this issue. I agree with this. It seems like doing this analysis at the bytecode level is the wrong approach. Perhaps the syntactical analysis being used before should be beefed up to handle things like the lambda case. ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 04:49:34 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 27 Jun 2015 02:49:34 +0000 Subject: [issue22609] Constructors of some mapping classes don't accept `self` keyword argument In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za> Message-ID: <1435373374.18.0.404141885778.issue22609@psf.upfronthosting.co.za> Yury Selivanov added the comment: Left some feedback in the code review. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 06:30:58 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 27 Jun 2015 04:30:58 +0000 Subject: [issue24449] Please add async write method to asyncio.StreamWriter In-Reply-To: <1434268250.18.0.99884254892.issue24449@psf.upfronthosting.co.za> Message-ID: <1435379458.69.0.50614981803.issue24449@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 11:22:06 2015 From: report at bugs.python.org (Zahari Dim) Date: Sat, 27 Jun 2015 09:22:06 +0000 Subject: [issue24519] multiprocessing.Pool with maxtasksperchild starts too many processes Message-ID: <1435396926.55.0.634788943007.issue24519@psf.upfronthosting.co.za> New submission from Zahari Dim: The following example should start two processes, but instead it starts three, even though only two do_work(). A third process is incorrectly started after the first one finishes. import os import time from multiprocessing import Pool def initprocess(): print("Starting PID: %d" % os.getpid()) def do_work(x): print("Doing work in %d" % os.getpid()) time.sleep(x**2) if __name__ == '__main__': p = Pool(2, initializer=initprocess,maxtasksperchild=1) results = p.map(do_work, (1,2), chunksize=1) ---------- components: Library (Lib) messages: 245878 nosy: Zahari.Dim priority: normal severity: normal status: open title: multiprocessing.Pool with maxtasksperchild starts too many processes type: resource usage versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 11:52:20 2015 From: report at bugs.python.org (Zahari Dim) Date: Sat, 27 Jun 2015 09:52:20 +0000 Subject: [issue24519] multiprocessing.Pool with maxtasksperchild starts too many processes In-Reply-To: <1435396926.55.0.634788943007.issue24519@psf.upfronthosting.co.za> Message-ID: <1435398740.8.0.395363817971.issue24519@psf.upfronthosting.co.za> Changes by Zahari Dim : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 13:30:43 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 27 Jun 2015 11:30:43 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <1435404643.89.0.517537479045.issue24336@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 17:08:23 2015 From: report at bugs.python.org (Andrew Turner) Date: Sat, 27 Jun 2015 15:08:23 +0000 Subject: [issue24520] Stop using deprecated floating-point environment functions on FreeBSD Message-ID: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za> New submission from Andrew Turner: The attached patch moves to use the fenv functions on FreeBSD to control the floating-point environment. This will be needed as I don't expect FreeBSD will have these functions on arm64. I would expect a similar change should be applied to any supported development branch. ---------- components: Interpreter Core files: use_fenv_freebsd.diff keywords: patch messages: 245879 nosy: Andrew Turner priority: normal severity: normal status: open title: Stop using deprecated floating-point environment functions on FreeBSD type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file39822/use_fenv_freebsd.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 17:09:59 2015 From: report at bugs.python.org (Catherine Devlin) Date: Sat, 27 Jun 2015 15:09:59 +0000 Subject: [issue24518] json.dumps should accept key function for ``sort_keys`` In-Reply-To: <1435359583.87.0.439013044096.issue24518@psf.upfronthosting.co.za> Message-ID: <1435417799.96.0.235855119641.issue24518@psf.upfronthosting.co.za> Catherine Devlin added the comment: Implementation for the enhancement. Includes tests. ---------- keywords: +patch Added file: http://bugs.python.org/file39823/json_callable_sort_24518.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 17:45:04 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 27 Jun 2015 15:45:04 +0000 Subject: [issue24508] Backport 3.5's Windows build project files to 2.7 In-Reply-To: <1435206408.67.0.0166063443293.issue24508@psf.upfronthosting.co.za> Message-ID: <1435419904.58.0.62150609297.issue24508@psf.upfronthosting.co.za> Steve Dower added the comment: Looks like the required install configuration is: * VS 2008 + VS 2010, or * VS 2008 + VS 2013 or later + Windows SDK 7.1 The SDK is at http://www.microsoft.com/en-us/download/details.aspx?id=8279 and contains MSVC10 and platform toolset files for both VC9 and 10. Neither VS 2008 nor VS 2013 include the VC9 platform toolset. The VC for Python package is also not sufficient, as it doesn't include rc.exe (though I'd be surprised if the output of newer versions of rc.exe aren't compatible). I haven't checked thoroughly to see what else may be missing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 17:48:57 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 27 Jun 2015 15:48:57 +0000 Subject: [issue24508] Backport 3.5's Windows build project files to 2.7 In-Reply-To: <1435206408.67.0.0166063443293.issue24508@psf.upfronthosting.co.za> Message-ID: <1435420137.3.0.0440645500735.issue24508@psf.upfronthosting.co.za> Steve Dower added the comment: 32-bit build was fine (VS 2013 + SDK 7.1 + VS 2008), but something has gone funny with the 64-bit. Need to go AFK for a bit now, but I'll try and figure that out later today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 17:55:41 2015 From: report at bugs.python.org (George Jenkins) Date: Sat, 27 Jun 2015 15:55:41 +0000 Subject: [issue1182143] making builtin exceptions more informative Message-ID: <1435420541.05.0.703528089648.issue1182143@psf.upfronthosting.co.za> George Jenkins added the comment: Thanks for the response. In terms of python API changes - I exposed the 'name' attribute on UnboundLocalError and NameError exceptions. (This can be seen (& is verified) by the changes to test_exceptions.py exceptions test cases in the patch) In terms of the wider changes in the patch - I factored UnboundLocalError and NameError to have specific native implementations, rather than been based off SimpleExtendsException. And thus able to accept the name of the variable causing the exception. And I agree with your comment on the exact API never been agreed on. Since there are now native implementations of UnboundLocalError and NameError, I can happily change their implementation to expose whatever can be decided to be better (comments?!) Thanks, George ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 19:26:57 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Jun 2015 17:26:57 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1435426017.81.0.468984519863.issue24120@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> patch review versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 19:29:50 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Jun 2015 17:29:50 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1435426190.18.0.0980692968955.issue24120@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you Ulrich for the patch. I basically agree with the solution you proposed (I'm not a fan of the non-ASCII "ASCII art", by the way, but I won't block the patch on that :-)). Have you tested the patch and tests under Windows? Otherwise, I (or someone else) will have to do that before accepting it. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 19:33:48 2015 From: report at bugs.python.org (Bob Alexander) Date: Sat, 27 Jun 2015 17:33:48 +0000 Subject: [issue24505] shutil.which wrong result on Windows In-Reply-To: <1435202763.03.0.678757712734.issue24505@psf.upfronthosting.co.za> Message-ID: Bob Alexander added the comment: Hi R. David -- My report is just to notify y'all of a bug that I noticed. The bug is causing me no problem, and it's your option as to whether to fix it or not. I offered a fix, but I haven't the time to perform diffs, etc. You could make that diff yourself, since I sent my modified "which" function. Just replace the existing "which" function in the version of shutil you would like to fix, and perform the diff. Bob On Wed, Jun 24, 2015 at 8:26 PM, R. David Murray wrote: > > R. David Murray added the comment: > > Could you please submit your proposal as a patch? (A diff -u against the > existing version). > > ---------- > nosy: +r.david.murray > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 19:49:01 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 27 Jun 2015 17:49:01 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <1435427341.06.0.520488263978.issue24336@psf.upfronthosting.co.za> Yury Selivanov added the comment: lgtm.. Serhiy, I think you should just commit it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 21:19:43 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Jun 2015 19:19:43 +0000 Subject: [issue24505] shutil.which wrong result on Windows In-Reply-To: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za> Message-ID: <1435432783.98.0.329660030905.issue24505@psf.upfronthosting.co.za> R. David Murray added the comment: That's fine. Perhaps someone will be interested enough to pick this up and work on it. ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 21:24:48 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 27 Jun 2015 19:24:48 +0000 Subject: [issue24521] Integer overflow in _pickle.c Message-ID: <1435433088.12.0.599666977394.issue24521@psf.upfronthosting.co.za> New submission from Benjamin Peterson: Reported by Kurucsai Istvan on the security list: I. Summary There is an integer overflow in the _Unpickler_ResizeMemoList function in _pickle.c. It is reachable e.g. via the LONG_BINPUT opcode. II. Source code The functions in question: static int load_long_binput(UnpicklerObject *self) { PyObject *value; Py_ssize_t idx; char *s; if (_Unpickler_Read(self, &s, 4) < 0) return -1; <> idx = calc_binsize(s, 4); 1. if (idx < 0) { PyErr_SetString(PyExc_ValueError, "negative LONG_BINPUT argument"); return -1; } return _Unpickler_MemoPut(self, idx, value); } static int _Unpickler_MemoPut(UnpicklerObject *self, Py_ssize_t idx, PyObject *value) { PyObject *old_item; if (idx >= self->memo_size) { 2. if (_Unpickler_ResizeMemoList(self, idx * 2) < 0) return -1; assert(idx < self->memo_size); } <> } static int _Unpickler_ResizeMemoList(UnpicklerObject *self, Py_ssize_t new_size) { <> 3. memo = PyMem_REALLOC(self->memo, new_size * sizeof(PyObject *)); if (memo == NULL) { PyErr_NoMemory(); return -1; } self->memo = memo; 4. for (i = self->memo_size; i < new_size; i++) self->memo[i] = NULL; self->memo_size = new_size; return 0; } 1. 0 < idx < PY_SSIZE_T_MAX, we choose idx = 0x20000000 2. and 3. together multiply idx by 8 on a 32 bit arch, 0x20000000 * 8 wraps to 0. 4. buffer overflow III. Proof of concept The bug can be triggered using the following pickle: d:\Python34\python.exe -m pickletools G:\dump\python\memo1 0: I INT 1 3: r LONG_BINPUT 536870912 8: . STOP highest protocol among opcodes = 1 Running the following causes the crash below (also tested on 3.5.0b2). Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:43:06) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> pickle.loads(b'I1\nr\x00\x00\x00\x20\x2e') (1600.2664): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=0000d3c4 ebx=1d84d1d0 ecx=778c28ac edx=01e700f0 esi=001f8a48 edi=40000000 eip=1d5ce5d3 esp=0057f65c ebp=0057f668 iopl=0 nv up ei ng nz na po cy cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010283 python34!_Unpickler_ResizeMemoList+0x33: 1d5ce5d3 c7048200000000 mov dword ptr [edx+eax*4],0 ds:002b:01ea5000=???????? 0:000> kb ChildEBP RetAddr Args to Child 0057f658 1d5ce627 00301ff4 00000004 0057f684 python34!_Unpickler_ResizeMemoList+0x33 [c:\users\martin\34\python\modules\_pickle.c @ 1275] 0057f668 1d5d3503 20000000 00301ff3 001f8a48 python34!_Unpickler_MemoPut+0x17 [c:\users\martin\34\python\modules\_pickle.c @ 1298] 0057f684 1d5d4027 001f8a48 0059b440 001f8a48 python34!load_long_binput+0x73 [c:\users\martin\34\python\modules\_pickle.c @ 5653] 0057f6a0 1d5d4e44 0059b440 00000000 0057f6dc python34!load+0x2c7 [c:\users\martin\34\python\modules\_pickle.c @ 6134] 0057f6b0 1d5d5461 00301fe0 00000001 1d6ff9d0 python34!_pickle_loads_impl+0x54 [c:\users\martin\34\python\modules\_pickle.c @ 7060] 0057f6dc 1d674f15 00597780 002cf6b0 00000000 python34!_pickle_loads+0x61 [c:\users\martin\34\python\modules\clinic\_pickle.c.h @ 540] 0057f6fc 1d6c591f 0059b440 002cf6b0 00000000 python34!PyCFunction_Call+0x65 [c:\users\martin\34\python\objects\methodobject.c @ 99] 0057f72c 1d6c79d9 0057f760 00000000 002d1d40 python34!call_function+0x28f [c:\users\martin\34\python\python\ceval.c @ 4237] 0057f7a0 1d6c89fd 002ff7b0 00000000 01e55958 python34!PyEval_EvalFrameEx+0x1ff9 [c:\users\martin\34\python\python\ceval.c @ 2840] 0057f7dc 1d6c8b64 002d1d40 002ff7b0 002960f8 python34!PyEval_EvalCodeEx+0x55d [c:\users\martin\34\python\python\ceval.c @ 3588] 0057f810 1d6f1f7d 002d1d40 002960f8 002960f8 python34!PyEval_EvalCode+0x24 [c:\users\martin\34\python\python\ceval.c @ 780] 0057f82c 1d6f39fd 01e5e098 002960f8 002960f8 python34!run_mod+0x2d [c:\users\martin\34\python\python\pythonrun.c @ 2180] 0057f868 1d6f4520 703c3008 0030a728 0057f8f4 python34!PyRun_InteractiveOneObject+0x25d [c:\users\martin\34\python\python\pythonrun.c @ 1446] 0057f88c 1d6f459d 703c3008 1d706acc 0057f8f4 python34!PyRun_InteractiveLoopFlags+0xc0 [c:\users\martin\34\python\python\pythonrun.c @ 1324] 0057f8a8 1d5fdc75 703c3008 1d706acc 00000000 python34!PyRun_AnyFileExFlags+0x2d [c:\users\martin\34\python\python\pythonrun.c @ 1286] 0057f8c8 1d5fe336 703c3008 0057f8f4 1cd73378 python34!run_file+0x95 [c:\users\martin\34\python\modules\main.c @ 319] 0057f940 1cd71184 00000001 01fd1420 01fd5be8 python34!Py_Main+0x696 [c:\users\martin\34\python\modules\main.c @ 751] 0057f984 7621337a 7efde000 0057f9d0 778b92e2 python!__tmainCRTStartup+0x122 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 552] 0057f990 778b92e2 7efde000 2345c114 00000000 kernel32!BaseThreadInitThunk+0xe 0057f9d0 778b92b5 1cd712ec 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70 0057f9e8 00000000 1cd712ec 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b ---------- components: Extension Modules messages: 245888 nosy: benjamin.peterson priority: normal severity: normal status: open title: Integer overflow in _pickle.c type: crash versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 21:27:00 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 27 Jun 2015 19:27:00 +0000 Subject: [issue24521] Integer overflow in _pickle.c In-Reply-To: <1435433088.12.0.599666977394.issue24521@psf.upfronthosting.co.za> Message-ID: <1435433220.09.0.366435043307.issue24521@psf.upfronthosting.co.za> Benjamin Peterson added the comment: https://hg.python.org/cpython/rev/acd5c9118931 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 21:52:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 27 Jun 2015 19:52:38 +0000 Subject: [issue24481] hotshot pack_string Heap Buffer Overflow In-Reply-To: <1434832847.29.0.0777461609837.issue24481@psf.upfronthosting.co.za> Message-ID: <20150627195235.19397.42207@psf.io> Roundup Robot added the comment: New changeset 4f48b1e982ca by Benjamin Peterson in branch '2.7': ensure internal buffer is large enough for string after flushing (closes #24481) https://hg.python.org/cpython/rev/4f48b1e982ca ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 22:00:12 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 27 Jun 2015 20:00:12 +0000 Subject: [issue24522] Integer overflow in _json_encode_unicode leads to crash (heap-buffer-overflow) Message-ID: <1435435212.2.0.881179193959.issue24522@psf.upfronthosting.co.za> New submission from Benjamin Peterson: Reported by Brendon Tiszka on the security list: # static PyObject * # escape_unicode(PyObject *pystr) # { # /* Take a PyUnicode pystr and return a new escaped PyUnicode */ # Py_ssize_t i; # Py_ssize_t input_chars; # Py_ssize_t output_size; # Py_ssize_t chars; # PyObject *rval; # void *input; # int kind; # Py_UCS4 maxchar; # # if (PyUnicode_READY(pystr) == -1) # return NULL; # # maxchar = PyUnicode_MAX_CHAR_VALUE(pystr); # input_chars = PyUnicode_GET_LENGTH(pystr); # input = PyUnicode_DATA(pystr); # kind = PyUnicode_KIND(pystr); # # /* Compute the output size */ # for (i = 0, output_size = 2; i < input_chars; i++) { # Py_UCS4 c = PyUnicode_READ(kind, input, i); # switch (c) { # case '\\': case '"': case '\b': case '\f': # case '\n': case '\r': case '\t': # output_size += 2; # break; # default: # if (c <= 0x1f) # output_size += 6; # else # output_size++; # } # } # # rval = PyUnicode_New(output_size, maxchar); # # 1.) if c is <= 0x1f then output_size += 6. There are no overflow checks on this variable. # 2.) rval buffer is too small to hold results # # Crash: # ------ # # Program received signal SIGSEGV, Segmentation fault. # 0xb7a2e9be in escape_unicode (pystr=pystr at entry=0x8cf81018) # at /home/pail/cpython/Modules/_json.c:306 # 306 ENCODE_OUTPUT; # # OS info # -------- # %./python -V # > Python 3.6.0a0 # % uname -a # Linux Pail0verflow 3.13.0-52-generic #85-Ubuntu SMP Wed Apr 29 16:44:56 UTC 2015 i686 i686 i686 GNU/Linux # # ASAN Info (details in other file) # ================================================================= # ==6512== ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb5c00000 at pc 0xb5f17356 bp 0xbfaa0eb8 sp 0xbfaa0eac # WRITE of size 1 at 0xb5c00000 thread T0 import json sp = "\x13"*715827883 #((2**32)/6 + 1) json.dumps([sp], ensure_ascii=False) ---------- components: Extension Modules messages: 245891 nosy: benjamin.peterson priority: normal severity: normal status: open title: Integer overflow in _json_encode_unicode leads to crash (heap-buffer-overflow) type: security versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 22:01:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 27 Jun 2015 20:01:23 +0000 Subject: [issue24522] Integer overflow in _json_encode_unicode leads to crash (heap-buffer-overflow) In-Reply-To: <1435435212.2.0.881179193959.issue24522@psf.upfronthosting.co.za> Message-ID: <20150627200120.4098.77043@psf.io> Roundup Robot added the comment: New changeset 0540e14c4b64 by Benjamin Peterson in branch '3.5': prevent integer overflow in escape_unicode (closes #24522) https://hg.python.org/cpython/rev/0540e14c4b64 New changeset fc799b2edf21 by Benjamin Peterson in branch 'default': merge 3.5 (#24522) https://hg.python.org/cpython/rev/fc799b2edf21 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jun 27 22:29:16 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 27 Jun 2015 20:29:16 +0000 Subject: [issue24508] Backport 3.5's Windows build project files to 2.7 In-Reply-To: <1435206408.67.0.0166063443293.issue24508@psf.upfronthosting.co.za> Message-ID: <1435436956.95.0.870265205157.issue24508@psf.upfronthosting.co.za> Steve Dower added the comment: 64-bit build didn't work (couldn't find ws2_32.lib) until I ran the SDK Configuration utility and selected v6.0A as the default SDK. This may be because I forgot to explicitly select the 64-bit compilers when I initially installed VS 2008, but it's a worthwhile troubleshooting approach. Still building some of the big projects now, and I have to leave it again, but it looks like everything is okay once you get past setup. I'm +0 on this change now, and I really hope the buildbots will pick up any subtle changes in the build. We should also run as many tests as possible against existing extension modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 00:51:29 2015 From: report at bugs.python.org (Cyd Haselton) Date: Sat, 27 Jun 2015 22:51:29 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1435445489.03.0.565040651732.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: I've run into an error when building python in preparation for running tests (i. e. with --with-pydebug in the ./configure params). ./libpython3.4dm.so: undefined reference to `_PyUnicode_CheckConsistency' It doesn't seem to be defined anywhere in source that I can see and i'm not sure why. Google turns up a few hits from the bug-tracker but none have resolutions http://bugs.python.org/issue13869 http://bugs.python.org/msg151986 Any thoughts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 03:08:09 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 28 Jun 2015 01:08:09 +0000 Subject: [issue24512] multiprocessing should log a warning when forking multithreaded process In-Reply-To: <1435256394.21.0.131332757316.issue24512@psf.upfronthosting.co.za> Message-ID: <1435453689.73.0.544564135577.issue24512@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +davin, sbt versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 05:02:27 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Jun 2015 03:02:27 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <1435460547.1.0.750892572702.issue24336@psf.upfronthosting.co.za> Nick Coghlan added the comment: My apologies Serhiy, I forgot this was directly assigned to me - all yours now! ---------- assignee: ncoghlan -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 05:02:50 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Jun 2015 03:02:50 +0000 Subject: [issue20357] Mention buildbots in the core dev section of the devguide In-Reply-To: <1390447097.09.0.000203036921559.issue20357@psf.upfronthosting.co.za> Message-ID: <1435460570.25.0.698019597022.issue20357@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 05:02:54 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Jun 2015 03:02:54 +0000 Subject: [issue23188] Provide a C helper function to chain raised (but not yet caught) exceptions In-Reply-To: <1420687041.12.0.12728944273.issue23188@psf.upfronthosting.co.za> Message-ID: <1435460574.59.0.12166565609.issue23188@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 05:03:16 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Jun 2015 03:03:16 +0000 Subject: [issue22352] Ensure opcode names and args fit in disassembly output In-Reply-To: <1410065891.58.0.12430207232.issue22352@psf.upfronthosting.co.za> Message-ID: <1435460596.9.0.631141769178.issue22352@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 05:03:23 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Jun 2015 03:03:23 +0000 Subject: [issue16961] No regression tests for -E and individual environment vars In-Reply-To: <1358164994.53.0.497203238771.issue16961@psf.upfronthosting.co.za> Message-ID: <1435460603.63.0.763307752846.issue16961@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 05:03:46 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Jun 2015 03:03:46 +0000 Subject: [issue19518] Add new PyRun_xxx() functions to not encode the filename In-Reply-To: <1383824880.09.0.781641455514.issue19518@psf.upfronthosting.co.za> Message-ID: <1435460626.53.0.845303816126.issue19518@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 05:20:04 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Jun 2015 03:20:04 +0000 Subject: [issue17311] use distutils terminology in "PyPI package display" section In-Reply-To: <1361988977.92.0.980923457558.issue17311@psf.upfronthosting.co.za> Message-ID: <1435461604.27.0.770209809426.issue17311@psf.upfronthosting.co.za> Nick Coghlan added the comment: Sorry for the long silence on this one folks. I agree the use of "package" and "home page" in the referenced section is confusing. For "home page", I'd suggest using the phrase "distribution page" instead (unless Donald has a different suggestion based on his current work on the next generation PyPI implementation). As far as the ambiguous "package" goes, for the PyPA docs, we ended up settling on the following set of terms (from https://packaging.python.org/en/latest/glossary.html): import package = the runtime meaning of the term "package" distribution package = the PyPI meaning of the term "package" distribution = shortened term for "distribution package" package = short for either "import package" or "distribution package", depending on context. For a great many packages, there's a one-to-one correspondence between the import package and the distribution package, which is why folks are often surprised to learn there's a difference. With the distutils docs normally using "package" to mean "import package", then they should use the explicit "distribution" or "distribution package" when they mean the other sense. ---------- assignee: ncoghlan -> nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 05:21:22 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Jun 2015 03:21:22 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1435461682.12.0.0100144231863.issue22166@psf.upfronthosting.co.za> Nick Coghlan added the comment: Victor, would you be willing to take over pushing this one forward? I believe you have a much better idea of what's still needed than I do. ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 05:21:42 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Jun 2015 03:21:42 +0000 Subject: [issue17960] Clarify the required behaviour of locals() In-Reply-To: <1368344807.52.0.116896667629.issue17960@psf.upfronthosting.co.za> Message-ID: <1435461702.81.0.906519008006.issue17960@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 05:23:27 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Jun 2015 03:23:27 +0000 Subject: [issue16217] Tracebacks are unnecessarily verbose when using 'python -m' In-Reply-To: <1350132701.04.0.542395484982.issue16217@psf.upfronthosting.co.za> Message-ID: <1435461807.3.0.522595906745.issue16217@psf.upfronthosting.co.za> Nick Coghlan added the comment: Hmm, when I haven't moved an issue forward in over two years, I guess that's a fair sign I'm not *actually* working on it... ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 08:03:13 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Jun 2015 06:03:13 +0000 Subject: [issue15403] Refactor package creation support code into a common location In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za> Message-ID: <1435471393.7.0.241829119011.issue15403@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 08:03:43 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Jun 2015 06:03:43 +0000 Subject: [issue18576] Document test.support.script_helper In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za> Message-ID: <1435471423.54.0.515999945811.issue18576@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 08:03:48 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Jun 2015 06:03:48 +0000 Subject: [issue15376] Refactor the test_runpy walk_package support code into a common location In-Reply-To: <1342509049.53.0.303616016829.issue15376@psf.upfronthosting.co.za> Message-ID: <1435471428.9.0.530608834119.issue15376@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 08:03:56 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Jun 2015 06:03:56 +0000 Subject: [issue15358] Test pkgutil.walk_packages in test_pkgutil instead of test_runpy In-Reply-To: <1342346071.33.0.869652246152.issue15358@psf.upfronthosting.co.za> Message-ID: <1435471436.0.0.524674077251.issue15358@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 08:04:04 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 28 Jun 2015 06:04:04 +0000 Subject: [issue18578] Rename and document test.bytecode_helper as test.support.bytecode_helper In-Reply-To: <1375014946.89.0.0130176350727.issue18578@psf.upfronthosting.co.za> Message-ID: <1435471444.62.0.934278348767.issue18578@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: ncoghlan -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 08:30:54 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sun, 28 Jun 2015 06:30:54 +0000 Subject: [issue24523] coroutine asyncio.wait() does not preserve order of elements Message-ID: <1435473054.25.0.727716281024.issue24523@psf.upfronthosting.co.za> New submission from ???? ?????????: If I pass an list of futures/coroutines as (done, _) = asyncio.wait([...]), order of elements in `done` does NOT match order of elements in `wait`'s argument. This is not documented, and I don't know if that is a bug or not. Also, documentation say: Wait for the Futures and coroutine objects given by the SEQUENCE futures to complete. Really, this should be SET, since order is not preserved. Or, sources should be patched to preserve the order. I think, it is not hard to preserve order [in asyncio code]. P.S. For example, in Tornado, it is guaranteed (and documented) that order is preserved, so I can write [res1, res2] = yield [fut1(), fut2()] and it is guaranteed, that res1 - is a result of fut1() ---------- components: asyncio messages: 245899 nosy: gvanrossum, haypo, mmarkk, yselivanov priority: normal severity: normal status: open title: coroutine asyncio.wait() does not preserve order of elements type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 08:40:22 2015 From: report at bugs.python.org (Ingo Ruhnke) Date: Sun, 28 Jun 2015 06:40:22 +0000 Subject: [issue23906] poplib maxline behaviour may be wrong In-Reply-To: <1428679593.1.0.415911204922.issue23906@psf.upfronthosting.co.za> Message-ID: <1435473622.11.0.217615867872.issue23906@psf.upfronthosting.co.za> Ingo Ruhnke added the comment: This also breaks mail retrieval from both gmx.de and gmail.com (two rather large and popular mail provider). After setting _MAXLINE in/usr/lib/python2.7/poplib.py to some arbitrary higher number mail retrieval from both services worked fine again. This this 2048 does definitively looks badly broken. ---------- nosy: +Ingo Ruhnke _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 08:48:32 2015 From: report at bugs.python.org (Ingo Ruhnke) Date: Sun, 28 Jun 2015 06:48:32 +0000 Subject: [issue16041] poplib: unlimited readline() from connection In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za> Message-ID: <1435474112.98.0.851975220158.issue16041@psf.upfronthosting.co.za> Ingo Ruhnke added the comment: This "fix" has broken mail retrieval from both gmx.de, gmail.com and plenty of other provider. It manifests in getmail as: Retrieval error: server for BrokenUIDLPOP3SSLRetriever:1860228 at pop.gmx.net:995 is broken; offered message 239 but failed to provide it. Please notify the administrator of the server. Skipping message... After setting the _MAXLINE in /usr/lib/python2.7/poplib.py to something higher everything was working again. See issue #23906 ---------- nosy: +Ingo Ruhnke _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 09:25:15 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 28 Jun 2015 07:25:15 +0000 Subject: [issue24523] coroutine asyncio.wait() does not preserve order of elements In-Reply-To: <1435473054.25.0.727716281024.issue24523@psf.upfronthosting.co.za> Message-ID: <1435476315.24.0.182319946612.issue24523@psf.upfronthosting.co.za> Guido van Rossum added the comment: The docs say that it returns two *sets* and Python's set datatype is unordered. So that's all you need to know. I don't think there's anything else needed in the docs. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 14:40:41 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 28 Jun 2015 12:40:41 +0000 Subject: [issue24481] hotshot pack_string Heap Buffer Overflow In-Reply-To: <1434832847.29.0.0777461609837.issue24481@psf.upfronthosting.co.za> Message-ID: <1435495241.12.0.334277861991.issue24481@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 14:41:56 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 28 Jun 2015 12:41:56 +0000 Subject: [issue24521] Integer overflow in _pickle.c In-Reply-To: <1435433088.12.0.599666977394.issue24521@psf.upfronthosting.co.za> Message-ID: <1435495316.3.0.373318575729.issue24521@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 14:43:16 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 28 Jun 2015 12:43:16 +0000 Subject: [issue24522] Integer overflow in _json_encode_unicode leads to crash (heap-buffer-overflow) In-Reply-To: <1435435212.2.0.881179193959.issue24522@psf.upfronthosting.co.za> Message-ID: <1435495396.14.0.706440344764.issue24522@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 15:47:36 2015 From: report at bugs.python.org (Russell Keith-Magee) Date: Sun, 28 Jun 2015 13:47:36 +0000 Subject: [issue23670] Modifications to support iOS as a cross-compilation target In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za> Message-ID: <1435499256.5.0.327155780037.issue23670@psf.upfronthosting.co.za> Russell Keith-Magee added the comment: Another patch update - the code now passes the full Python test suite on the iOS simulator. There are still a couple of failures on device; as before, these appear to be due to ctypes problems and a permissions issue with os.mkdir. ---------- Added file: http://bugs.python.org/file39824/20150628.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 16:12:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 28 Jun 2015 14:12:26 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <20150628141222.1304.65774@psf.io> Roundup Robot added the comment: New changeset f0053d05ed6d by Serhiy Storchaka in branch '3.4': Issue #24336: The contextmanager decorator now works with functions with https://hg.python.org/cpython/rev/f0053d05ed6d New changeset 20aa7083057e by Serhiy Storchaka in branch '3.5': Issue #24336: The contextmanager decorator now works with functions with https://hg.python.org/cpython/rev/20aa7083057e New changeset d4e4bfabc21f by Serhiy Storchaka in branch 'default': Issue #24336: The contextmanager decorator now works with functions with https://hg.python.org/cpython/rev/d4e4bfabc21f New changeset 85c78d4db242 by Serhiy Storchaka in branch '2.7': Issue #24336: Backported test for contextmanager. Patch by Martin Panter. https://hg.python.org/cpython/rev/85c78d4db242 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 16:13:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 28 Jun 2015 14:13:49 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <1435500829.72.0.480875034385.issue24336@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Martin for your patch. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 16:57:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 28 Jun 2015 14:57:01 +0000 Subject: [issue24456] audioop.adpcm2lin Buffer Over-read In-Reply-To: <1434401846.51.0.0422696666136.issue24456@psf.upfronthosting.co.za> Message-ID: <20150628145657.93714.34613@psf.io> Roundup Robot added the comment: New changeset 1f6c096ee772 by Serhiy Storchaka in branch '2.7': Issue #24456: Fixed possible buffer over-read in adpcm2lin() and lin2adpcm() https://hg.python.org/cpython/rev/1f6c096ee772 New changeset fd17e168b59f by Serhiy Storchaka in branch '3.4': Issue #24456: Fixed possible buffer over-read in adpcm2lin() and lin2adpcm() https://hg.python.org/cpython/rev/fd17e168b59f New changeset 3039cb5b673c by Serhiy Storchaka in branch '3.5': Issue #24456: Fixed possible buffer over-read in adpcm2lin() and lin2adpcm() https://hg.python.org/cpython/rev/3039cb5b673c New changeset 0e1d9018e74b by Serhiy Storchaka in branch 'default': Issue #24456: Fixed possible buffer over-read in adpcm2lin() and lin2adpcm() https://hg.python.org/cpython/rev/0e1d9018e74b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 16:58:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 28 Jun 2015 14:58:06 +0000 Subject: [issue24456] audioop.adpcm2lin Buffer Over-read In-Reply-To: <1434401846.51.0.0422696666136.issue24456@psf.upfronthosting.co.za> Message-ID: <1435503486.34.0.577702828092.issue24456@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch for 2.7 also fixed SystemError and possible memory leak. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 17:17:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 28 Jun 2015 15:17:53 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <20150628151749.74493.51973@psf.io> Roundup Robot added the comment: New changeset b784c842a63c by Jason R. Coombs in branch '3.4': Issue #20387: Add test capturing failure to roundtrip indented code in tokenize module. https://hg.python.org/cpython/rev/b784c842a63c New changeset 49323e5f6391 by Jason R. Coombs in branch '3.4': Issue #20387: Correct test to properly capture expectation. https://hg.python.org/cpython/rev/49323e5f6391 New changeset ff47efeeed48 by Dingyuan Wang in branch '3.4': Issue #20387: Restore retention of indentation during untokenize. https://hg.python.org/cpython/rev/ff47efeeed48 New changeset 4856ae883041 by Jason R. Coombs in branch '3.4': Issue #20387: Update Misc/NEWS https://hg.python.org/cpython/rev/4856ae883041 New changeset 330e28b28334 by Jason R. Coombs in branch '3.4': Issue #20387: Merge patch and test https://hg.python.org/cpython/rev/330e28b28334 New changeset 9ce5c1f371f7 by Jason R. Coombs in branch '3.4': Issue #20387: Merge https://hg.python.org/cpython/rev/9ce5c1f371f7 New changeset 98380a6e037c by Jason R. Coombs in branch '3.5': Issue #20387: Merge test and patch from 3.4.4 https://hg.python.org/cpython/rev/98380a6e037c New changeset f2f5d1c928eb by Jason R. Coombs in branch 'default': Issue #20387: Merge with 3.5 https://hg.python.org/cpython/rev/f2f5d1c928eb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 17:40:38 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 28 Jun 2015 15:40:38 +0000 Subject: [issue23906] poplib maxline behaviour may be wrong In-Reply-To: <1428679593.1.0.415911204922.issue23906@psf.upfronthosting.co.za> Message-ID: <1435506038.18.0.392739588266.issue23906@psf.upfronthosting.co.za> R. David Murray added the comment: The RFC is in fact not clear on this point. It is entirely possible to read it as saying that each line of a mulitline response is limited to 512 octets. I agree, however, that that is not the most reasonable interpretation. Instead, the line length of RETR message lines should be governed by RFC 5322, which specifies a maximum line length of 998 octets. That, however, means that technically dovecot is still broken, since 2048 is quite a bit larger than 998. In reality, it means that the *internet* is broken, in that I presume the root of the problem is that there are mail originators out there that are not obeying RFC 5322 (and its predecessors...this limit goes back to 821/822). We use 8192 in smtplib, and that hasn't caused any problems...but then again smtplib is originating email, not receiving it. The IMAP protocol has its own problems, quite aside from the length of message body lines, so we ended up with a very large MAXLINE there. It may be that we have no choice except to do something similar in poplib. An interesting question in this context is what smtp servers do. since if anyone was going to reject messages with overlong lines, it would be the smtp server's job to do it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 17:41:06 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 28 Jun 2015 15:41:06 +0000 Subject: [issue23906] poplib maxline behaviour may be wrong In-Reply-To: <1428679593.1.0.415911204922.issue23906@psf.upfronthosting.co.za> Message-ID: <1435506066.97.0.195776949833.issue23906@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 17:47:54 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 28 Jun 2015 15:47:54 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <1435506474.19.0.871892054293.issue20387@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Patch and test applied to 3.4+. I'm inclined to backport this to Python 2.7, as that was where I encountered it originally. ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 17:49:17 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 28 Jun 2015 15:49:17 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <1435506557.13.0.296530257751.issue20387@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Benjamin, any objections to a backport of this patch? ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 18:07:25 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 28 Jun 2015 16:07:25 +0000 Subject: [issue18578] Rename and document test.bytecode_helper as test.support.bytecode_helper In-Reply-To: <1375014946.89.0.0130176350727.issue18578@psf.upfronthosting.co.za> Message-ID: <1435507645.51.0.409674007262.issue18578@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 18:31:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 28 Jun 2015 16:31:26 +0000 Subject: [issue24456] audioop.adpcm2lin Buffer Over-read In-Reply-To: <1434401846.51.0.0422696666136.issue24456@psf.upfronthosting.co.za> Message-ID: <1435509086.35.0.462659456083.issue24456@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 19:09:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 28 Jun 2015 17:09:01 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <20150628170858.20146.78325@psf.io> Roundup Robot added the comment: New changeset 524a0e755797 by Jason R. Coombs in branch '2.7': Issue #20387: Backport test from Python 3.4 https://hg.python.org/cpython/rev/524a0e755797 New changeset cb9df1ae287b by Jason R. Coombs in branch '2.7': Issue #20387: Backport fix from Python 3.4 https://hg.python.org/cpython/rev/cb9df1ae287b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 19:11:10 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 28 Jun 2015 17:11:10 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <1435511470.06.0.348148991016.issue20387@psf.upfronthosting.co.za> Jason R. Coombs added the comment: For the sake of expediency, I've gone ahead and backported and pushed the fix to 2.7. Please back out the changes if appropriate. ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 19:11:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 28 Jun 2015 17:11:18 +0000 Subject: [issue24467] bytearray pop and remove Buffer Over-read In-Reply-To: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za> Message-ID: <1435511478.06.0.645985597926.issue24467@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka stage: -> patch review versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 19:11:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 28 Jun 2015 17:11:39 +0000 Subject: [issue24462] bytearray.find Buffer Over-read In-Reply-To: <1434551199.93.0.25363766054.issue24462@psf.upfronthosting.co.za> Message-ID: <1435511499.56.0.0552694986899.issue24462@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 21:15:44 2015 From: report at bugs.python.org (Meador Inge) Date: Sun, 28 Jun 2015 19:15:44 +0000 Subject: [issue24485] Function source inspection fails on closures In-Reply-To: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za> Message-ID: <1435518944.88.0.267517396266.issue24485@psf.upfronthosting.co.za> Meador Inge added the comment: Here is a first cut patch that moves things back to using a syntax-level analysis instead of a bytecode-level one. I extended `BlockFinder` to skip decorators. ---------- keywords: +patch nosy: +meador.inge stage: test needed -> patch review Added file: http://bugs.python.org/file39825/issue24485-v0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 21:17:56 2015 From: report at bugs.python.org (Meador Inge) Date: Sun, 28 Jun 2015 19:17:56 +0000 Subject: [issue21217] inspect.getsourcelines finds wrong lines when lambda used argument to decorator In-Reply-To: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za> Message-ID: <1435519076.35.0.984624908603.issue21217@psf.upfronthosting.co.za> Meador Inge added the comment: FYI, I posted a patch to handle this case and the regression noted in issue24485 on issue24485. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jun 28 21:26:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 28 Jun 2015 19:26:46 +0000 Subject: [issue24467] bytearray pop and remove Buffer Over-read In-Reply-To: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za> Message-ID: <1435519606.91.0.604496489147.issue24467@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The bytearray object allocates one byte more for trailing null byte. ob_size always should be less than ob_alloc if ob_alloc != 0. But in rare cases when the bytearray is initialized with an iterator, this rule can be violated. Following patch restores this property. PyByteArray_AS_STRING() now always returns null-terminated string. ---------- Added file: http://bugs.python.org/file39826/bytearray_init_trailing_null.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 00:01:27 2015 From: report at bugs.python.org (Tomas Nordin) Date: Sun, 28 Jun 2015 22:01:27 +0000 Subject: [issue24524] python crash using Tkinter Message-ID: <1435528887.92.0.932065002837.issue24524@psf.upfronthosting.co.za> New submission from Tomas Nordin: $ python Python 2.7.9 (default, Mar 1 2015, 18:22:53) [GCC 4.9.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. The readline tab completion thing should be loaded. (pythonstartup.py @home) >>> import Tkinter as tk >>> import tkFileDialog as tfd >>> tk.Tk() >>> tk.Tk() >>> tfd.askopenfilename() u'/home/tomas/.emacs' >>> # closing the root window ... >>> alloc: invalid block: 0x99ddcd8: 88 9 Aborted $ $ uname -a Linux debian 3.2.0-4-686-pae #1 SMP Debian 3.2.68-1+deb7u1 i686 GNU/Linux See also #22810 ---------- components: Tkinter messages: 245917 nosy: tomnor priority: normal severity: normal status: open title: python crash using Tkinter type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 00:09:16 2015 From: report at bugs.python.org (DmitryJ) Date: Sun, 28 Jun 2015 22:09:16 +0000 Subject: [issue24467] bytearray pop and remove Buffer Over-read In-Reply-To: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za> Message-ID: <1435529356.61.0.155994104099.issue24467@psf.upfronthosting.co.za> DmitryJ added the comment: If this is the case, then issue24462 should be fixed by this patch as well. I'm sorry about missing the root cause here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 00:26:44 2015 From: report at bugs.python.org (Christie) Date: Sun, 28 Jun 2015 22:26:44 +0000 Subject: [issue24033] Update _test_multiprocessing.py to use script helpers In-Reply-To: <1429748807.96.0.769250379827.issue24033@psf.upfronthosting.co.za> Message-ID: <1435530404.54.0.409777254595.issue24033@psf.upfronthosting.co.za> Christie added the comment: If #18576 gets merged before this does, I have some updated docs for the new helper functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 00:28:13 2015 From: report at bugs.python.org (Christie) Date: Sun, 28 Jun 2015 22:28:13 +0000 Subject: [issue9517] Make test.script_helper more comprehensive, and use it in the test suite In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za> Message-ID: <1435530493.59.0.345697056836.issue9517@psf.upfronthosting.co.za> Christie added the comment: Hello all! So the following are waiting for review: * #24033 * #23981 * #24279 I'm going to hold off on continuing to refactor any other modules for the moment, would be great to get the above wrapped up and eventually merged when possible. Thanks! - Christie ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 00:28:59 2015 From: report at bugs.python.org (Christie) Date: Sun, 28 Jun 2015 22:28:59 +0000 Subject: [issue18576] Document test.support.script_helper In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za> Message-ID: <1435530539.4.0.0158614084571.issue18576@psf.upfronthosting.co.za> Christie added the comment: Hey @vadmium! I've finally responded to your review feedback. I've attached a new patch, hopefully this time actually review-able. I've removed the docs for methods I added in @24033 so that this could be merged without it. Let me know if you have any more feedback, or if this could be merged. Thanks! ---------- Added file: http://bugs.python.org/file39827/issue18576.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 08:54:23 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 29 Jun 2015 06:54:23 +0000 Subject: [issue17546] Document the circumstances where the locals() dict get updated In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za> Message-ID: <1435560863.71.0.0546205650454.issue17546@psf.upfronthosting.co.za> Martin Panter added the comment: Here is another attempt with different words: ''' .. note:: The dictionary returned by :func:`locals` is an accurate snapshot of the local namespace at the time it is called. If the namespace changes after the call, the dictionary may become out of date, but it may also automatically update at any time. The contents of the dictionary should not be modified by the user; it is undefined whether such changes affect the namespace or not. ''' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 09:05:18 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 29 Jun 2015 07:05:18 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1435561518.53.0.603444243412.issue24134@psf.upfronthosting.co.za> Robert Collins added the comment: Hi, catching up (see my mail to -dev about not getting tracker mail). Deprecations++. Being nice for folk whom consume unittest2 which I backport to everything is important to me :). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 09:39:56 2015 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 29 Jun 2015 07:39:56 +0000 Subject: [issue17546] Document the circumstances where the locals() dict get updated In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za> Message-ID: <1435563596.56.0.885463560799.issue17546@psf.upfronthosting.co.za> Nick Coghlan added the comment: I mostly like Martin's suggested wording, but would also note that I filed issue 17960 to tighten up the requirements for when we expect assigning to locals() to work. To save folks reading the whole referenced email, I think it would be worth defining that modifying the namespace returned by locals() will affect the runtime namespace at module and class scope and when using exec, but will have no effect at function scope (as locals() returns a copy of the namespace in that case). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 10:19:05 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 29 Jun 2015 08:19:05 +0000 Subject: [issue18576] Document test.support.script_helper In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za> Message-ID: <1435565945.22.0.394027004807.issue18576@psf.upfronthosting.co.za> Martin Panter added the comment: I left some more comments on Reitveld. The main one is I think stderr gets stripped with assert_python_ok(), but I don?t think stdout is touched. Correct me if I?m wrong though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 10:20:22 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 29 Jun 2015 08:20:22 +0000 Subject: [issue24279] Update test_base64 to use test.support.script_helper In-Reply-To: <1432498391.21.0.154907178378.issue24279@psf.upfronthosting.co.za> Message-ID: <1435566022.88.0.168430467592.issue24279@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 10:48:31 2015 From: report at bugs.python.org (Vincent Legoll) Date: Mon, 29 Jun 2015 08:48:31 +0000 Subject: [issue24525] [doc] missing word Message-ID: <1435567711.2.0.215374180363.issue24525@psf.upfronthosting.co.za> New submission from Vincent Legoll: Here is a patch to fix a missing word in the urllib doc ---------- assignee: docs at python components: Documentation files: python-doc-fix.hgpatch messages: 245927 nosy: docs at python, vincent-legoll priority: normal severity: normal status: open title: [doc] missing word type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file39828/python-doc-fix.hgpatch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 12:19:03 2015 From: report at bugs.python.org (bhaskar) Date: Mon, 29 Jun 2015 10:19:03 +0000 Subject: [issue24526] Exponent function bug Message-ID: <1435573143.55.0.102498891735.issue24526@psf.upfronthosting.co.za> New submission from bhaskar: the value of a -ve number when raised by a power of even number always results in a +ve number. I tried it with -1**10 , -1**2, -9**4 these all are resulting in -ve numbers which is mathematically incorrect. ps. the same example is in the attachment ---------- components: IDLE files: pythonabc.png messages: 245928 nosy: bhaskar priority: normal severity: normal status: open title: Exponent function bug type: compile error versions: Python 3.6 Added file: http://bugs.python.org/file39829/pythonabc.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 12:19:44 2015 From: report at bugs.python.org (bhaskar) Date: Mon, 29 Jun 2015 10:19:44 +0000 Subject: [issue24526] Exponent function bug In-Reply-To: <1435573143.55.0.102498891735.issue24526@psf.upfronthosting.co.za> Message-ID: <1435573184.33.0.801775381286.issue24526@psf.upfronthosting.co.za> Changes by bhaskar : Added file: http://bugs.python.org/file39830/pythonabc.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 12:53:33 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Jun 2015 10:53:33 +0000 Subject: [issue24526] Exponent function bug In-Reply-To: <1435573143.55.0.102498891735.issue24526@psf.upfronthosting.co.za> Message-ID: <1435575213.92.0.761391798521.issue24526@psf.upfronthosting.co.za> R. David Murray added the comment: This bit of python's precedence rules often catches people by surprise. ** binds tighter than -, so what python is evaluating is -(1**10). ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 13:11:47 2015 From: report at bugs.python.org (Sebastian Noack) Date: Mon, 29 Jun 2015 11:11:47 +0000 Subject: [issue24527] The MimeTypes class cannot ignore global files per instance Message-ID: <1435576307.84.0.535097012645.issue24527@psf.upfronthosting.co.za> New submission from Sebastian Noack: In order to prevent the mimetypes module from considering global files and registry entries, you have to call mimetypes.init([]). However, this will enforce that behavior globally, and only works if the module wasn't initialized yet. There is also a similar argument in the mimetypes.MimeTypes() constructor, however the list of files passed there are considered additionally. But there is no way to prevent an individual MinmeTypes instance to consider global files. Adding a "ignore_global_types" option would be trivial too add to the MimeTypes constructor, and would be extremely useful. ---------- components: Library (Lib) messages: 245930 nosy: Sebastian Noack priority: normal severity: normal status: open title: The MimeTypes class cannot ignore global files per instance type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 13:28:43 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Mon, 29 Jun 2015 11:28:43 +0000 Subject: [issue24528] Misleading exeption for await in comprehensions. Message-ID: <1435577323.48.0.769775989737.issue24528@psf.upfronthosting.co.za> New submission from Ivan Levkivskyi: The following code: async def foo(): lst = [await coro(i) for i in range(10)] return lst gives SyntaxError: 'await' outside async function I understand that this is because the comprehensions are implemented using a function scope (see also #10544), but such behavior is unintuitive. IMO there are two possibilities here: 1) make comprehensions behave more like a for loop; 2) change the exception text to something like "SyntaxError: 'await's in comprehensions are not supported". I understand that the first option is probably not for 3.5 (it is beta already), but I will be happy if the second option will be implemented in 3.5 ---------- components: Interpreter Core, asyncio messages: 245931 nosy: gvanrossum, haypo, levkivskyi, yselivanov priority: normal severity: normal status: open title: Misleading exeption for await in comprehensions. type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 14:00:37 2015 From: report at bugs.python.org (Wladimir Palant) Date: Mon, 29 Jun 2015 12:00:37 +0000 Subject: [issue24527] The MimeTypes class cannot ignore global files per instance In-Reply-To: <1435576307.84.0.535097012645.issue24527@psf.upfronthosting.co.za> Message-ID: <1435579237.94.0.535174862411.issue24527@psf.upfronthosting.co.za> Changes by Wladimir Palant : ---------- nosy: +Wladimir Palant _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 14:09:24 2015 From: report at bugs.python.org (Cyd Haselton) Date: Mon, 29 Jun 2015 12:09:24 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1435579764.95.0.771671035101.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: FYI, Figured out that running ./configure with --with-pydebug does NOT define Py_DEBUG in pyconfig.h. Defining it in pyconfig.h got me past the "undefined reference to `_PyUnicode_CheckConsistency'" error, but i'm now getting this: if test $? -ne 0 ; then \ echo "generate-posix-vars failed" ; \ rm -f ./pybuilddir.txt ; \ exit 1 ; \ fi Debug memory block at address p=0x90b7b0: API '' 2416312320 bytes originally requested The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb): at p-3: 0x00 *** OUCH at p-2: 0x00 *** OUCH at p-1: 0x00 *** OUCH Because memory is corrupted at the start, the count of bytes requested may be bogus, and checking the trailing pad bytes may segfault. The 4 pad bytes at tail=0x9096b7b0 are Segmentation fault generate-posix-vars failed make: *** [pybuilddir.txt] Error 1 Will re-check patch application and try again ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 14:10:13 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Mon, 29 Jun 2015 12:10:13 +0000 Subject: [issue19217] Calling assertEquals for moderately long list takes too long In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za> Message-ID: <1435579813.41.0.83372412437.issue19217@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 14:10:48 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Mon, 29 Jun 2015 12:10:48 +0000 Subject: [issue21253] unittest assertSequenceEqual can lead to Difflib.compare() crashing on mostly different sequences In-Reply-To: <1397663686.19.0.71446048811.issue21253@psf.upfronthosting.co.za> Message-ID: <1435579848.56.0.753950488223.issue21253@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 14:11:31 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Mon, 29 Jun 2015 12:11:31 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1435579891.27.0.0275583060512.issue11352@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 14:12:46 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Mon, 29 Jun 2015 12:12:46 +0000 Subject: [issue5945] PyMapping_Check returns 1 for lists In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za> Message-ID: <1435579966.98.0.0371363296806.issue5945@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 14:12:52 2015 From: report at bugs.python.org (Tal Einat) Date: Mon, 29 Jun 2015 12:12:52 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1435579972.23.0.261012790002.issue24483@psf.upfronthosting.co.za> Tal Einat added the comment: With clru_cache_known_hash_4.patch on the current default branch, the entire test suite passes here (OSX 10.10). ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 14:13:06 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Mon, 29 Jun 2015 12:13:06 +0000 Subject: [issue21827] textwrap.dedent() fails when largest common whitespace is a substring of smallest leading whitespace In-Reply-To: <1403455487.85.0.474137406062.issue21827@psf.upfronthosting.co.za> Message-ID: <1435579986.2.0.300281950333.issue21827@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 14:22:27 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Mon, 29 Jun 2015 12:22:27 +0000 Subject: [issue24272] PEP 484 docs In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za> Message-ID: <1435580547.32.0.96589122732.issue24272@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 14:56:45 2015 From: report at bugs.python.org (Tal Einat) Date: Mon, 29 Jun 2015 12:56:45 +0000 Subject: [issue24514] tarfile fails to extract archive (handled fine by gnu tar and bsdtar) In-Reply-To: <1435310337.24.0.0720447050888.issue24514@psf.upfronthosting.co.za> Message-ID: <1435582605.67.0.501557421093.issue24514@psf.upfronthosting.co.za> Tal Einat added the comment: The patch is very simple, but this needs tests. At the very least, a simple tar file which reproduces this issue could be added to the tests. Taking this a step further would be writing some unit tests for the internal nti() and itn() functions, and perhaps also stn() and nts(). ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 15:25:29 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 29 Jun 2015 13:25:29 +0000 Subject: [issue24420] Documentation regressions from adding subprocess.run() In-Reply-To: <1433909056.73.0.964707918197.issue24420@psf.upfronthosting.co.za> Message-ID: <1435584329.71.0.627193044653.issue24420@psf.upfronthosting.co.za> Martin Panter added the comment: New patch dropping the [, input] parameter from the signature. I also removed the bit about *stdout*, since it should be obvious from the equivalent run() call given, and equally applies to *check*. ---------- Added file: http://bugs.python.org/file39831/high-args.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 15:32:23 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Mon, 29 Jun 2015 13:32:23 +0000 Subject: [issue24514] tarfile fails to extract archive (handled fine by gnu tar and bsdtar) In-Reply-To: <1435310337.24.0.0720447050888.issue24514@psf.upfronthosting.co.za> Message-ID: <1435584743.39.0.994705216191.issue24514@psf.upfronthosting.co.za> Lars Gust?bel added the comment: I think a simple addition to the existing unittest for nti() will be enough. itn() seems well-tested, and nts() and stn() are not affected, because they don't operate on numbers. ---------- Added file: http://bugs.python.org/file39832/issue24514.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 15:46:27 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 29 Jun 2015 13:46:27 +0000 Subject: [issue24528] Misleading exeption for await in comprehensions. In-Reply-To: <1435577323.48.0.769775989737.issue24528@psf.upfronthosting.co.za> Message-ID: <1435585587.37.0.403431741363.issue24528@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- assignee: -> yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 16:00:01 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Mon, 29 Jun 2015 14:00:01 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1435579764.95.0.771671035101.issue23496@psf.upfronthosting.co.za> Message-ID: Ryan Gonzalez added the comment: You compiled with -fPIE and GCC, right? I know the Android Clang seems broken. On June 29, 2015 7:09:25 AM CDT, Cyd Haselton wrote: > >Cyd Haselton added the comment: > >FYI, Figured out that running ./configure with --with-pydebug does NOT >define Py_DEBUG in pyconfig.h. > >Defining it in pyconfig.h got me past the "undefined reference to >`_PyUnicode_CheckConsistency'" error, but i'm now getting this: > >if test $? -ne 0 ; then \ > echo "generate-posix-vars failed" ; \ > rm -f ./pybuilddir.txt ; \ > exit 1 ; \ >fi >Debug memory block at address p=0x90b7b0: API '' > 2416312320 bytes originally requested > The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb): > at p-3: 0x00 *** OUCH > at p-2: 0x00 *** OUCH > at p-1: 0x00 *** OUCH > Because memory is corrupted at the start, the count of bytes requested > may be bogus, and checking the trailing pad bytes may segfault. > The 4 pad bytes at tail=0x9096b7b0 are Segmentation fault >generate-posix-vars failed >make: *** [pybuilddir.txt] Error 1 > >Will re-check patch application and try again > >---------- > >_______________________________________ >Python tracker > >_______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 16:29:35 2015 From: report at bugs.python.org (Cyd Haselton) Date: Mon, 29 Jun 2015 14:29:35 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: Message-ID: <1B217915-A56B-4FD0-8436-8D12BFE9C8E9@gmail.com> Cyd Haselton added the comment: No...haven't upgraded to Android 5.0 yet. On June 29, 2015 9:00:01 AM CDT, Ryan Gonzalez wrote: > >Ryan Gonzalez added the comment: > >You compiled with -fPIE and GCC, right? I know the Android Clang seems >broken. > >On June 29, 2015 7:09:25 AM CDT, Cyd Haselton >wrote: >> >>Cyd Haselton added the comment: >> >>FYI, Figured out that running ./configure with --with-pydebug does NOT >>define Py_DEBUG in pyconfig.h. >> >>Defining it in pyconfig.h got me past the "undefined reference to >>`_PyUnicode_CheckConsistency'" error, but i'm now getting this: >> >>if test $? -ne 0 ; then \ >> echo "generate-posix-vars failed" ; \ >> rm -f ./pybuilddir.txt ; \ >> exit 1 ; \ >>fi >>Debug memory block at address p=0x90b7b0: API '' >> 2416312320 bytes originally requested >> The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb): >> at p-3: 0x00 *** OUCH >> at p-2: 0x00 *** OUCH >> at p-1: 0x00 *** OUCH >> Because memory is corrupted at the start, the count of bytes >requested >> may be bogus, and checking the trailing pad bytes may segfault. >> The 4 pad bytes at tail=0x9096b7b0 are Segmentation fault >>generate-posix-vars failed >>make: *** [pybuilddir.txt] Error 1 >> >>Will re-check patch application and try again >> >>---------- >> >>_______________________________________ >>Python tracker >> >>_______________________________________ > >---------- > >_______________________________________ >Python tracker > >_______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 16:41:47 2015 From: report at bugs.python.org (Dustin J. Mitchell) Date: Mon, 29 Jun 2015 14:41:47 +0000 Subject: [issue3353] make built-in tokenizer available via Python C API In-Reply-To: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za> Message-ID: <1435588907.12.0.54637347859.issue3353@psf.upfronthosting.co.za> Dustin J. Mitchell added the comment: This seems to have stalled out after the PyCon sprints. Any chance the final patch can be reviewed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 16:42:56 2015 From: report at bugs.python.org (SylvainDe) Date: Mon, 29 Jun 2015 14:42:56 +0000 Subject: [issue24529] Same MemoryError object gets thrown from different places. Message-ID: <1435588975.99.0.915406015973.issue24529@psf.upfronthosting.co.za> New submission from SylvainDe: Disclaimer: This is very minor, impacts only Python 2 and is maybe not even a bug. Context: I was "randomly" changing attribute of Exception objects when I discovered something I did not expect : sometimes when an exception occurs, a new object is raised (which is what I expected), sometimes a previously thrown exception is re-thrown (which surprised me). More specifically, MemoryError objects seem to be reused while most of the other exceptions I've played with where newly created. One can easily see this happening in the following piece of code : - first a NameError is caught and updated - then, we run the same code and print the re-caught exception : it is a new one - then, a MemoryError is caught and updated - then, we run the same code and print the re-caught exception : it is the same as previously. 
from __future__ import print_function

old_e = None
try:
    foobar
except NameError as old_e:
    print("old_e:", old_e)
    old_e.args = tuple(['NEW VALUE'])
    print("old_e:", old_e)
try:
    foobar
except NameError as new_e:
    print("new_e:", new_e)
    print(old_e is new_e)

old_e = None
try:
    l = [0] * 999999999999999999
except MemoryError as old_e:
    print("old_e:", old_e)
    old_e.args = tuple(['NEW VALUE'])
    print("old_e:", old_e)
try:
    l = [0] * 999999999999999999
except MemoryError as new_e:
    print("new_e:", new_e)
    print(old_e is new_e)
For the record, I am quite aware that this shouldn't impact anyone using Python normally. I was just messing around as part of a toy project where I try to enhance exception messages for a better user experience ( https://github.com/SylvainDe/DidYouMean-Python ). ---------- components: Interpreter Core messages: 245940 nosy: SylvainDe priority: normal severity: normal status: open title: Same MemoryError object gets thrown from different places. versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 16:49:34 2015 From: report at bugs.python.org (Dustin J. Mitchell) Date: Mon, 29 Jun 2015 14:49:34 +0000 Subject: [issue24530] `import..as` fails where `import` does not Message-ID: <1435589374.69.0.0263102389919.issue24530@psf.upfronthosting.co.za> New submission from Dustin J. Mitchell: Reproduction: # main.py import foo.bar # foo/__init__.py # (empty) # foo/bar/__init__.py import foo.bar.bing as bing # foo/bar/bing.py # (empty) Result: dustin at euclid ~/tmp $ python3.3 main.py Traceback (most recent call last): File "main.py", line 1, in import foo.bar File "/home/dustin/tmp/foo/bar/__init__.py", line 1, in import foo.bar.bing as bing AttributeError: 'module' object has no attribute 'bar' dustin at euclid ~/tmp $ python2.7 main.py Traceback (most recent call last): File "main.py", line 1, in import foo.bar File "/home/dustin/tmp/foo/bar/__init__.py", line 1, in import foo.bar.bing as bing AttributeError: 'module' object has no attribute 'bar' If you remove the `as bing` from `foo/bar/__init__.py`, all is well. Similarly, `from foo.bar import bing` works fine, as does `from foo.bar import bing as bing`. I don't see anything in https://docs.python.org/3/reference/simple_stmts.html#import that suggests this is expected behavior. ---------- components: Interpreter Core messages: 245941 nosy: djmitche priority: normal severity: normal status: open title: `import..as` fails where `import` does not type: behavior versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 17:09:56 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 29 Jun 2015 15:09:56 +0000 Subject: [issue17546] Document the circumstances where the locals() dict get updated In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za> Message-ID: <1435590596.59.0.134132228015.issue17546@psf.upfronthosting.co.za> Martin Panter added the comment: I quickly scanned through the email thread from Issue 17960. I guess it makes sense to specify that locals() can be used to directly get a class?s namespace. Probably doesn?t hurt to say locals() is equivalent to globals() at module level, although this seems like a fairly redundant feature. Here is locals_doc.03.patch, which uses my wording for function namespaces, and also adds more for class and global namespaces, as suggested by Nick. ---------- Added file: http://bugs.python.org/file39833/locals_doc.03.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 17:32:31 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 29 Jun 2015 15:32:31 +0000 Subject: [issue24518] json.dumps should accept key function for ``sort_keys`` In-Reply-To: <1435359583.87.0.439013044096.issue24518@psf.upfronthosting.co.za> Message-ID: <1435591951.36.0.43469332764.issue24518@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The idea and patch look reasonable. Bob, what do you think? ---------- assignee: -> bob.ippolito nosy: +bob.ippolito, rhettinger versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 17:35:13 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 29 Jun 2015 15:35:13 +0000 Subject: [issue22609] Constructors of some mapping classes don't accept `self` keyword argument In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za> Message-ID: <1435592113.32.0.241698524535.issue22609@psf.upfronthosting.co.za> Martin Panter added the comment: Patch looks fine to me. I understand Yury withdrew his comment. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 17:38:47 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 29 Jun 2015 15:38:47 +0000 Subject: [issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za> Message-ID: <1435592327.64.0.64131622271.issue19176@psf.upfronthosting.co.za> Martin Panter added the comment: inherit-doctype.v3.patch looks good to me ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 17:42:25 2015 From: report at bugs.python.org (Jakub Wilk) Date: Mon, 29 Jun 2015 15:42:25 +0000 Subject: [issue24531] please document that no code preceding encoding declaration is allowed Message-ID: <1435592545.23.0.229313024646.issue24531@psf.upfronthosting.co.za> New submission from Jakub Wilk: If the encoding is declared on the second line, the first line must not contain anything except comments. However, this fact is not documented. The Python Language reference says only that "the encoding declaration must appear on a line of its own"; and PEP 263 says only that "there must not be any Python statement on the line that contains the encoding declaration". For example, Python ignores this encoding declaration: spam = True # encoding=ISO-8859-2 despite the fact that it appears on a line of its own. ---------- assignee: docs at python components: Documentation messages: 245946 nosy: docs at python, jwilk priority: normal severity: normal status: open title: please document that no code preceding encoding declaration is allowed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 17:56:05 2015 From: report at bugs.python.org (Bob Ippolito) Date: Mon, 29 Jun 2015 15:56:05 +0000 Subject: [issue24518] json.dumps should accept key function for ``sort_keys`` In-Reply-To: <1435359583.87.0.439013044096.issue24518@psf.upfronthosting.co.za> Message-ID: <1435593365.69.0.846898116655.issue24518@psf.upfronthosting.co.za> Bob Ippolito added the comment: Seems like a good idea to me, I'll make sure this gets in simplejson as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 18:11:11 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Jun 2015 16:11:11 +0000 Subject: [issue24529] Same MemoryError object gets thrown from different places. In-Reply-To: <1435588975.99.0.915406015973.issue24529@psf.upfronthosting.co.za> Message-ID: <1435594271.32.0.321159685066.issue24529@psf.upfronthosting.co.za> R. David Murray added the comment: If the same memory exception object were not used, we'd have to allocate memory for the new one... ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 18:12:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 29 Jun 2015 16:12:18 +0000 Subject: [issue24529] Same MemoryError object gets thrown from different places. In-Reply-To: <1435588975.99.0.915406015973.issue24529@psf.upfronthosting.co.za> Message-ID: <1435594338.9.0.0236653315239.issue24529@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 18:16:54 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Jun 2015 16:16:54 +0000 Subject: [issue24530] `import..as` fails where `import` does not In-Reply-To: <1435589374.69.0.0263102389919.issue24530@psf.upfronthosting.co.za> Message-ID: <1435594614.09.0.161707824691.issue24530@psf.upfronthosting.co.za> R. David Murray added the comment: I'm pretty sure this has already been reported, but I have no idea how to search for the issue :) If I remember correctly there's a doc patch, so I suppose it hasn't been applied. But I could be misremembering. ---------- nosy: +brett.cannon, eric.snow, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 18:25:12 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Jun 2015 16:25:12 +0000 Subject: [issue24531] please document that no code preceding encoding declaration is allowed In-Reply-To: <1435592545.23.0.229313024646.issue24531@psf.upfronthosting.co.za> Message-ID: <1435595112.83.0.484213096521.issue24531@psf.upfronthosting.co.za> R. David Murray added the comment: What docs are you looking at? https://docs.python.org/3/reference/lexical_analysis.html#encoding-declarations? I suspect the author thought that "If a comment in the first or second line..." implied both lines needed to be comments, but I agree that the wording is not clear. ---------- nosy: +r.david.murray stage: -> needs patch type: -> behavior versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 18:29:18 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 29 Jun 2015 16:29:18 +0000 Subject: [issue24528] Misleading exeption for await in comprehensions. In-Reply-To: <1435577323.48.0.769775989737.issue24528@psf.upfronthosting.co.za> Message-ID: <1435595358.31.0.248696884731.issue24528@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks for discovering this, Ivan. The patch is attached. ---------- keywords: +needs review, patch nosy: +ncoghlan stage: -> patch review Added file: http://bugs.python.org/file39834/awaitcomp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 19:25:51 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Mon, 29 Jun 2015 17:25:51 +0000 Subject: [issue24532] asyncio.sock_recv() blocks normal ioloop actions. Message-ID: <1435598751.58.0.199860778997.issue24532@psf.upfronthosting.co.za> New submission from ???? ?????????: Suppose that program: ==================================== import asyncio import socket def receiver(loop): (a, b) = socket.socketpair() loop.call_later(1, lambda: print('Should be called inside the loop')) end = loop.time() + 3 print('Starting busy receiver') while loop.time() < end: a.send(b'test') yield from loop.sock_recv(b, 65536) # yield from asyncio.sleep(0) # <===================== print('Busy receiver complete') # just not to stop ioloop immediatelly yield from asyncio.sleep(0.5) def main(): loop = asyncio.get_event_loop() loop.run_until_complete(receiver(loop)) loop.close() if __name__ == '__main__': main() ==================================== Without asyncio.sleep(0) it will not fire time-delayed calls! If I add asyncio.sleep(0), everything work right. As I think, It is because recv() syscall is always succeeded, and we never return to ioloop (to epoll() I mean). In other words, it is classical `reader starvation` as mentioned in "man epoll". It is not documented, that this function may block event loop, in spite of it returns coroutine! I thought that this function will setup EPOLLIN event for socket's FD + call recv() after that. I spent many time to debug program. ---------- components: asyncio messages: 245952 nosy: gvanrossum, haypo, mmarkk, yselivanov priority: normal severity: normal status: open title: asyncio.sock_recv() blocks normal ioloop actions. type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 20:13:42 2015 From: report at bugs.python.org (Bob Ippolito) Date: Mon, 29 Jun 2015 18:13:42 +0000 Subject: [issue24518] json.dumps should accept key function for ``sort_keys`` In-Reply-To: <1435359583.87.0.439013044096.issue24518@psf.upfronthosting.co.za> Message-ID: <1435601622.15.0.2411631772.issue24518@psf.upfronthosting.co.za> Bob Ippolito added the comment: On further investigation, simplejson has implemented this functionality under a different name since 2.5.0 (2012-03-29). """ If item_sort_key is a callable (not the default), then the output of dictionaries will be sorted with it. The callable will be used like this: sorted(dct.items(), key=item_sort_key). This option takes precedence over sort_keys. Changed in version 2.5.0: item_sort_key is new in 2.5.0. """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 20:19:27 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 29 Jun 2015 18:19:27 +0000 Subject: [issue24467] bytearray pop and remove Buffer Over-read In-Reply-To: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za> Message-ID: <20150629181924.16528.7401@psf.io> Roundup Robot added the comment: New changeset a887ce8611d2 by Serhiy Storchaka in branch '2.7': Issue #24467: Fixed possible buffer over-read in bytearray. The bytearray https://hg.python.org/cpython/rev/a887ce8611d2 New changeset c95d7ffa492e by Serhiy Storchaka in branch '3.4': Issue #24467: Fixed possible buffer over-read in bytearray. The bytearray https://hg.python.org/cpython/rev/c95d7ffa492e New changeset 942860bada14 by Serhiy Storchaka in branch '3.5': Issue #24467: Fixed possible buffer over-read in bytearray. The bytearray https://hg.python.org/cpython/rev/942860bada14 New changeset 97a24bc714ec by Serhiy Storchaka in branch 'default': Issue #24467: Fixed possible buffer over-read in bytearray. The bytearray https://hg.python.org/cpython/rev/97a24bc714ec ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 20:22:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 29 Jun 2015 18:22:24 +0000 Subject: [issue24467] bytearray pop and remove Buffer Over-read In-Reply-To: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za> Message-ID: <1435602144.3.0.542151192759.issue24467@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Interpreter Core resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 20:25:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 29 Jun 2015 18:25:33 +0000 Subject: [issue24462] bytearray.find Buffer Over-read In-Reply-To: <1434551199.93.0.25363766054.issue24462@psf.upfronthosting.co.za> Message-ID: <1435602333.73.0.574867234338.issue24462@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch for issue24467 also fixed this issue in different way. In any case thank you Dmitry for your patches. ---------- components: +Interpreter Core resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> bytearray pop and remove Buffer Over-read _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 20:34:47 2015 From: report at bugs.python.org (Charles Nodell) Date: Mon, 29 Jun 2015 18:34:47 +0000 Subject: [issue24533] Increased Test Coverage for Lib/random.py Message-ID: <1435602887.43.0.963223854079.issue24533@psf.upfronthosting.co.za> New submission from Charles Nodell: This patch just extends test coverage on the random library by a few lines. ---------- components: Tests files: mywork.patch keywords: patch messages: 245956 nosy: Charles Nodell priority: normal severity: normal status: open title: Increased Test Coverage for Lib/random.py type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file39835/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 21:16:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 29 Jun 2015 19:16:00 +0000 Subject: [issue24532] asyncio.sock_recv() blocks normal ioloop actions. In-Reply-To: <1435598751.58.0.199860778997.issue24532@psf.upfronthosting.co.za> Message-ID: <1435605360.83.0.667618108111.issue24532@psf.upfronthosting.co.za> STINNER Victor added the comment: You should develop using asyncio debug mode: https://docs.python.org/dev/library/asyncio-dev.html#asyncio-dev haypo at selma$ PYTHONASYNCIODEBUG=1 ./python x.py Starting busy receiver Traceback (most recent call last): File "x.py", line 21, in main() File "x.py", line 18, in main loop.run_until_complete(receiver(loop)) File "/home/haypo/prog/python/default/Lib/asyncio/base_events.py", line 341, in run_until_complete return future.result() File "/home/haypo/prog/python/default/Lib/asyncio/futures.py", line 276, in result raise self._exception File "/home/haypo/prog/python/default/Lib/asyncio/tasks.py", line 238, in _step result = coro.send(value) File "x.py", line 11, in receiver yield from loop.sock_recv(b, 65536) File "/home/haypo/prog/python/default/Lib/asyncio/selector_events.py", line 316, in sock_recv raise ValueError("the socket must be non-blocking") ValueError: the socket must be non-blocking /home/haypo/prog/python/default/Lib/asyncio/base_events.py:384: ResourceWarning: unclosed event loop <_UnixSelectorEventLoop running=False closed=False debug=True> sys:1: ResourceWarning: unclosed sys:1: ResourceWarning: unclosed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 21:23:15 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 29 Jun 2015 19:23:15 +0000 Subject: [issue24532] asyncio.sock_recv() blocks normal ioloop actions. In-Reply-To: <1435598751.58.0.199860778997.issue24532@psf.upfronthosting.co.za> Message-ID: <1435605795.17.0.399031709497.issue24532@psf.upfronthosting.co.za> Yury Selivanov added the comment: > You should develop using asyncio debug mode: Maybe we should promote this check to the production mode? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 21:30:39 2015 From: report at bugs.python.org (Min RK) Date: Mon, 29 Jun 2015 19:30:39 +0000 Subject: [issue24534] disable executing code in .pth files Message-ID: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za> New submission from Min RK: .pth files currently allow execution of arbitrary code, triggered by lines starting with `import`. This is a rarely understood, and often misbehaving feature. easy_install has used this feature to ensure that its packages are highest priority (even higher than stdlib). This is one of the unfortunate behaviors that pip undoes from easy_install, in part due to the problems it can cause. There is currently a proposal in setuptools to stop using this, even for easy_install. The attached patch removes support for executing code in .pth files, throwing an ImportWarning if any such attempts at import are seen. General question that might result in rejecting this patch: Are there any good/valid use cases for .pth files being able to execute arbitrary code at interpreter start time? If this is accepted, some implementation questions: 1. if the feature is removed in 3.6, should a DeprecationWarning be added to 3.5? 2. Is ImportWarning the right warning class (or should there even be a warning)? ---------- components: Installation files: 0001-disable-executing-code-in-.pth-files.patch keywords: patch messages: 245959 nosy: minrk priority: normal severity: normal status: open title: disable executing code in .pth files versions: Python 3.6 Added file: http://bugs.python.org/file39836/0001-disable-executing-code-in-.pth-files.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 21:49:45 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 29 Jun 2015 19:49:45 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za> Message-ID: <1435607385.31.0.371687237954.issue24534@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +brett.cannon, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 21:50:17 2015 From: report at bugs.python.org (Jakub Wilk) Date: Mon, 29 Jun 2015 19:50:17 +0000 Subject: [issue24531] please document that no code preceding encoding declaration is allowed In-Reply-To: <1435592545.23.0.229313024646.issue24531@psf.upfronthosting.co.za> Message-ID: <1435607417.43.0.194588490515.issue24531@psf.upfronthosting.co.za> Jakub Wilk added the comment: Right, I meant . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 21:57:36 2015 From: report at bugs.python.org (Tim Smith) Date: Mon, 29 Jun 2015 19:57:36 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za> Message-ID: <1435607856.84.0.20774334013.issue24534@psf.upfronthosting.co.za> Tim Smith added the comment: In Homebrew we occasionally use .pth files to call site.addsitedir. This is useful when we want to add a directory to sys.path that contains .pth files that also need to be processed (for example, when adding a directory to sys.path that contains namespace packages). It would be helpful to retain a mechanism for adding site dirs from a .pth file. Homebrew also writes temporary probe .pths containing "import site; site.homebrew_was_here = True" in order to check whether .pth files are processed in a particular path, though we could equivalently write a temporary path to a .pth file and verify that it ends up in sys.path. Finally, Homebrew asks users to write .pth files with imports in some places where we could use usercustomize instead. ---------- nosy: +tdsmith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 21:58:17 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 29 Jun 2015 19:58:17 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1435607897.63.0.608865066139.issue24400@psf.upfronthosting.co.za> Stefan Behnel added the comment: > isawaitable(), however, should continue using abc.Awaitable, since it only checks for __await__ presence on the type (or should we just drop it?) I'd really remove it. It's not referring to an actual type, so it doesn't fit the purpose of the inspect module. The fact that the only place where "collections.abc" is used in this module is in isawaitable() should be a clear indication that it's misplaced. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 22:12:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 29 Jun 2015 20:12:28 +0000 Subject: [issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za> Message-ID: <20150629201222.47065.3655@psf.io> Roundup Robot added the comment: New changeset 75571407dcd3 by Serhiy Storchaka in branch '3.4': Issue #19176: Fixed doctype() related bugs in C implementation of ElementTree. https://hg.python.org/cpython/rev/75571407dcd3 New changeset 6ae8842e9b60 by Serhiy Storchaka in branch '3.5': Issue #19176: Fixed doctype() related bugs in C implementation of ElementTree. https://hg.python.org/cpython/rev/6ae8842e9b60 New changeset d792dc240456 by Serhiy Storchaka in branch 'default': Issue #19176: Fixed doctype() related bugs in C implementation of ElementTree. https://hg.python.org/cpython/rev/d792dc240456 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 22:18:47 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Jun 2015 20:18:47 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za> Message-ID: <1435609127.53.0.0430671769726.issue24534@psf.upfronthosting.co.za> R. David Murray added the comment: I'm guessing this feature has been around too long and is used in too many ways to remove. I believe it is effectively disabled by -I (if it is not, that would be a valid feature request). However, since setuptools was the pioneer in this area, if setuptools is no longer using it, perhaps a deprecation would be possible. I think it would probably have to happen over more than one release, to insure enough time to implement any features needed to replace the deprecated functionality. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From mal at egenix.com Mon Jun 29 22:27:13 2015 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 29 Jun 2015 22:27:13 +0200 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za> References: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za> Message-ID: <5591AA21.9070001@egenix.com> On 29.06.2015 21:30, Min RK wrote: > > .pth files currently allow execution of arbitrary code, triggered by lines starting with `import`. This is a rarely understood, and often misbehaving feature. easy_install has used this feature to ensure that its packages are highest priority (even higher than stdlib). This is one of the unfortunate behaviors that pip undoes from easy_install, in part due to the problems it can cause. There is currently a proposal in setuptools to stop using this, even for easy_install. > > The attached patch removes support for executing code in .pth files, throwing an ImportWarning if any such attempts at import are seen. Such a change will require a PEP, since it's an essential feature that has been documented for a very long time: https://docs.python.org/3.5/library/site.html and is used by a lot of existing setuptools installations, which would break if Python were to remove support for this. The PEP would also need to address the reasons for removing the feature, e.g. explain possible attack vectors, confusion caused by this, etc. You can then reference this patch in the PEP. Thanks, -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Mon Jun 29 22:27:16 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 29 Jun 2015 20:27:16 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za> Message-ID: <5591AA21.9070001@egenix.com> Marc-Andre Lemburg added the comment: On 29.06.2015 21:30, Min RK wrote: > > .pth files currently allow execution of arbitrary code, triggered by lines starting with `import`. This is a rarely understood, and often misbehaving feature. easy_install has used this feature to ensure that its packages are highest priority (even higher than stdlib). This is one of the unfortunate behaviors that pip undoes from easy_install, in part due to the problems it can cause. There is currently a proposal in setuptools to stop using this, even for easy_install. > > The attached patch removes support for executing code in .pth files, throwing an ImportWarning if any such attempts at import are seen. Such a change will require a PEP, since it's an essential feature that has been documented for a very long time: https://docs.python.org/3.5/library/site.html and is used by a lot of existing setuptools installations, which would break if Python were to remove support for this. The PEP would also need to address the reasons for removing the feature, e.g. explain possible attack vectors, confusion caused by this, etc. You can then reference this patch in the PEP. Thanks, -- Marc-Andre Lemburg eGenix.com ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 22:41:47 2015 From: report at bugs.python.org (Daniel Neuberger) Date: Mon, 29 Jun 2015 20:41:47 +0000 Subject: [issue24475] The docs never define what a pool "task" is In-Reply-To: <1434733537.74.0.146405679971.issue24475@psf.upfronthosting.co.za> Message-ID: <1435610507.7.0.000954062471978.issue24475@psf.upfronthosting.co.za> Daniel Neuberger added the comment: I second this. I was definitely confused at first and it took me a little while of googling to realize that jobs are not what one (at least me) would intuitively think they are. ---------- nosy: +Daniel Neuberger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 22:41:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 29 Jun 2015 20:41:57 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za> Message-ID: <1435610517.61.0.980816113982.issue24534@psf.upfronthosting.co.za> STINNER Victor added the comment: > The attached patch removes support for executing code in .pth files This change will basically break all Python applications. Don't do that. If you believe that we can smoothly move to a world without .pth files, you should propose an overall plan, step by step. It implies to add an option to Python to disable .pth files. It might be enabled by the -I command line option. https://docs.python.org/dev/using/cmdline.html#cmdoption-I ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 22:44:43 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 29 Jun 2015 20:44:43 +0000 Subject: [issue3530] ast.NodeTransformer doc bug In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za> Message-ID: <1435610683.78.0.840867406363.issue3530@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am reopening this as a doc bug because RewriteName is a copy (with 'ast.' prefixes added) of a buggy example in the doc. The bug is that the new .value Name and Str attributes do not get the required 'lineno' and 'col_offset' attributes. As Armin said, copy_location is not recursive and does not fix children of the node it fixes. Also, the recursive .visit method does not recurse into children of replacement nodes (and if it did, the new Str node would still not be fixed). The fix could be to reuse the Name node and add another copy_location call: the following works. def visit_Name(self, node): return ast.copy_location( ast.Subscript( value=node, slice=ast.Index(value=ast.copy_location( ast.Str(s=node.id), node)), ctx=node.ctx), node) but I think this illustrates that comment in the fix_missing_locations() entry that locations are "tedious to fill in for generated nodes". So I think the doc fix should use Armin's version of RewriteName and say to call fix_missing_locations on the result of .visit if new nodes are added. (I checked that his code still works in 3.5). The entry for NodeTransformer might mention that .visit does not recurse into replacement nodes. The missing lineno error came up in this python-list thread: https://mail.python.org/pipermail/python-list/2015-June/693316.html ---------- assignee: -> docs at python components: +Documentation nosy: +benjamin.peterson, docs at python, terry.reedy resolution: not a bug -> stage: -> needs patch status: closed -> open title: ast.NodeTransformer bug -> ast.NodeTransformer doc bug type: -> behavior versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 22:50:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 29 Jun 2015 20:50:13 +0000 Subject: [issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za> Message-ID: <1435611013.97.0.811971684366.issue19176@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In 2.7 XMLParser is a function, not a class, and therefore can't be subclassed. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 22:53:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 29 Jun 2015 20:53:12 +0000 Subject: [issue24533] Increased Test Coverage for Lib/random.py In-Reply-To: <1435602887.43.0.963223854079.issue24533@psf.upfronthosting.co.za> Message-ID: <1435611192.82.0.990155947676.issue24533@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +mark.dickinson, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jun 29 23:17:57 2015 From: report at bugs.python.org (John Jones) Date: Mon, 29 Jun 2015 21:17:57 +0000 Subject: [issue14046] argparse: assertion failure if optional argument has square/round brackets in metavar In-Reply-To: <1329542509.5.0.84021889574.issue14046@psf.upfronthosting.co.za> Message-ID: <1435612677.59.0.188674080653.issue14046@psf.upfronthosting.co.za> John Jones added the comment: Im kind of surprised this bug has lasted for so many years :) setting part_regexp to: r'\(.*?\(.*?\).*?\)+|\[.*?\[.*?\].*?\]+|\S+' fixes the issue for me, although its not very elegant ---------- nosy: +John Jones _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 00:32:21 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 29 Jun 2015 22:32:21 +0000 Subject: [issue24530] `import..as` fails where `import` does not In-Reply-To: <1435589374.69.0.0263102389919.issue24530@psf.upfronthosting.co.za> Message-ID: <1435617141.29.0.00749604613183.issue24530@psf.upfronthosting.co.za> Martin Panter added the comment: Maybe Issue 23203, proposing to fix the compiled bytecode. ---------- nosy: +vadmium resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Aliasing import of sub-{module,package} from the package raises AttributeError on import. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 00:34:11 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Jun 2015 22:34:11 +0000 Subject: [issue24530] `import..as` fails where `import` does not In-Reply-To: <1435589374.69.0.0263102389919.issue24530@psf.upfronthosting.co.za> Message-ID: <1435617251.85.0.810667259138.issue24530@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, yes, that is the issue I was thinking of. So, bug, not doc issue :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 04:42:30 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 30 Jun 2015 02:42:30 +0000 Subject: [issue24532] asyncio.sock_recv() blocks normal ioloop actions. In-Reply-To: <1435598751.58.0.199860778997.issue24532@psf.upfronthosting.co.za> Message-ID: <1435632150.71.0.952069095595.issue24532@psf.upfronthosting.co.za> ???? ????????? added the comment: Adding of b.setblocking(0) after socketpair() does not help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 04:43:46 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 30 Jun 2015 02:43:46 +0000 Subject: [issue24532] asyncio.sock_recv() blocks normal ioloop actions. In-Reply-To: <1435598751.58.0.199860778997.issue24532@psf.upfronthosting.co.za> Message-ID: <1435632226.37.0.707480187995.issue24532@psf.upfronthosting.co.za> ???? ????????? added the comment: $ PYTHONASYNCIODEBUG=1 ./bug.py Starting busy receiver Busy receiver complete Executing wait_for= cb=[_run_until_complete_cb() at /usr/lib/python3.4/asyncio/base_events.py:123] created at /usr/lib/python3.4/asyncio/base_events.py:296> took 3.001 seconds Should be called inside the loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 05:56:36 2015 From: report at bugs.python.org (Nick Levinson) Date: Tue, 30 Jun 2015 03:56:36 +0000 Subject: [issue24535] SELinux reporting writes, executes, and dac_overwrites Message-ID: <1435636596.24.0.22907134947.issue24535@psf.upfronthosting.co.za> New submission from Nick Levinson: Suddenly, SELinux in my Fedora 20 Linux laptop is reporting many problems with /usr/bin/python2.7 and I don't know if there's a bug in python2.7 or if something else is going on. File/s or directory/ies on which writes were attempted were on unspecified file/s or drectory/ies. Thirteen alerts occurred within the same minute soon after a cold boot, although I at first thought it was only one alert until I clicked buttons. Each alert apparently represents multiple alert-worthy events. Following are the data reported by SELinux, separated by rows of equals signs. ===== Occurred "12" & later occurred "7" (I assume 12 and 7 times, respectively, unless the numbers mean something else): ===== SELinux is preventing /usr/bin/python2.7 from using the dac_override capability. ***** Plugin dac_override (91.4 confidence) suggests ********************** If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system Then turn on full auditing to get path information about the offending file and generate the error again. Do Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that python2.7 should have the dac_override capability by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep python /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:blueman_t:s0-s0:c0.c1023 Target Context system_u:system_r:blueman_t:s0-s0:c0.c1023 Target Objects [ capability ] Source python Source Path /usr/bin/python2.7 Port Host localhost.localdomain Source RPM Packages python-2.7.5-16.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-197.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 3.19.8-100.fc20.x86_64 #1 SMP Tue May 12 17:08:50 UTC 2015 x86_64 x86_64 Alert Count 12 First Seen 2015-06-28 11:16:53 EDT Last Seen 2015-06-28 17:04:49 EDT Local ID 146e4bfb-abdf-44a1-86da-3b538f53fac8 Raw Audit Messages type=AVC msg=audit(1435525489.77:442): avc: denied { dac_override } for pid=2232 comm="python" capability=1 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tclass=capability permissive=0 type=SYSCALL msg=audit(1435525489.77:442): arch=x86_64 syscall=access success=no exit=EACCES a0=7ffcd4229aba a1=2 a2=0 a3=79 items=0 ppid=2231 pid=2232 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=python exe=/usr/bin/python2.7 subj=system_u:system_r:blueman_t:s0-s0:c0.c1023 key=(null) Hash: python,blueman_t,blueman_t,capability,dac_override ===== Occurred "7": ===== SELinux is preventing /usr/bin/python2.7 from execute access on the file . ***** Plugin catchall (100. confidence) suggests ************************** If you believe that python2.7 should be allowed execute access on the file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep python /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:blueman_t:s0-s0:c0.c1023 Target Context system_u:object_r:blueman_var_run_t:s0 Target Objects [ file ] Source python Source Path /usr/bin/python2.7 Port Host localhost.localdomain Source RPM Packages python-2.7.5-16.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-197.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 3.19.8-100.fc20.x86_64 #1 SMP Tue May 12 17:08:50 UTC 2015 x86_64 x86_64 Alert Count 7 First Seen 2015-06-28 11:16:53 EDT Last Seen 2015-06-28 17:04:49 EDT Local ID 76953ff5-42e6-4c2b-a057-cd59b586dd12 Raw Audit Messages type=AVC msg=audit(1435525489.78:445): avc: denied { execute } for pid=2232 comm="python" path=2F72756E2F66666971584B4A3755202864656C6574656429 dev="tmpfs" ino=32567 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:blueman_var_run_t:s0 tclass=file permissive=0 type=SYSCALL msg=audit(1435525489.78:445): arch=x86_64 syscall=mmap success=no exit=EACCES a0=0 a1=1000 a2=5 a3=1 items=0 ppid=2231 pid=2232 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=python exe=/usr/bin/python2.7 subj=system_u:system_r:blueman_t:s0-s0:c0.c1023 key=(null) Hash: python,blueman_t,blueman_var_run_t,file,execute ===== Occurred "7": ===== SELinux is preventing /usr/bin/python2.7 from write access on the directory . ***** Plugin setenforce (91.4 confidence) suggests ************************ If you believe /usr/bin/python2.7 tried to disable SELinux. Then you may be under attack by a hacker, since confined applications should never need this access. Do contact your security administrator and report this issue. ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that python2.7 should be allowed write access on the directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep python /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:blueman_t:s0-s0:c0.c1023 Target Context system_u:object_r:security_t:s0 Target Objects [ dir ] Source python Source Path /usr/bin/python2.7 Port Host localhost.localdomain Source RPM Packages python-2.7.5-16.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-197.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 3.19.8-100.fc20.x86_64 #1 SMP Tue May 12 17:08:50 UTC 2015 x86_64 x86_64 Alert Count 7 First Seen 2015-06-28 11:16:53 EDT Last Seen 2015-06-28 17:04:49 EDT Local ID 09c40fd9-63ae-4dcb-8ff7-e7e496102bde Raw Audit Messages type=AVC msg=audit(1435525489.79:448): avc: denied { write } for pid=2232 comm="python" name="/" dev="selinuxfs" ino=1 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=dir permissive=0 type=SYSCALL msg=audit(1435525489.79:448): arch=x86_64 syscall=access success=no exit=EACCES a0=7ffcd4229aba a1=2 a2=0 a3=0 items=0 ppid=2231 pid=2232 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=python exe=/usr/bin/python2.7 subj=system_u:system_r:blueman_t:s0-s0:c0.c1023 key=(null) Hash: python,blueman_t,security_t,dir,write ===== Occurred "8" and, if that's a count of occurrences, 69 more times (77 total): ===== SELinux is preventing /usr/bin/python2.7 from write access on the directory . ***** Plugin catchall (100. confidence) suggests ************************** If you believe that python2.7 should be allowed write access on the directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep python /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:blueman_t:s0-s0:c0.c1023 Target Context system_u:object_r:debugfs_t:s0 Target Objects [ dir ] Source python Source Path /usr/bin/python2.7 Port Host localhost.localdomain Source RPM Packages python-2.7.5-16.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-197.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 3.19.8-100.fc20.x86_64 #1 SMP Tue May 12 17:08:50 UTC 2015 x86_64 x86_64 Alert Count 8 First Seen 2015-06-28 11:16:53 EDT Last Seen 2015-06-28 17:04:49 EDT Local ID afd472d0-9c1a-4b15-bd94-3eaefd0382d4 Raw Audit Messages type=AVC msg=audit(1435525489.80:451): avc: denied { write } for pid=2232 comm="python" name="/" dev="debugfs" ino=1 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:debugfs_t:s0 tclass=dir permissive=0 type=SYSCALL msg=audit(1435525489.80:451): arch=x86_64 syscall=access success=no exit=EACCES a0=7ffcd4229ab8 a1=2 a2=0 a3=0 items=0 ppid=2231 pid=2232 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=python exe=/usr/bin/python2.7 subj=system_u:system_r:blueman_t:s0-s0:c0.c1023 key=(null) Hash: python,blueman_t,debugfs_t,dir,write ===== ---------- messages: 245975 nosy: Nick priority: normal severity: normal status: open title: SELinux reporting writes, executes, and dac_overwrites type: security versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 06:55:07 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 30 Jun 2015 04:55:07 +0000 Subject: [issue24535] SELinux reporting writes, executes, and dac_overwrites In-Reply-To: <1435636596.24.0.22907134947.issue24535@psf.upfronthosting.co.za> Message-ID: <1435640107.78.0.229279095255.issue24535@psf.upfronthosting.co.za> Ned Deily added the comment: This is not a Python problem; note in particular the blueman references in the messages. A quick web searching suggests there is a conflict between blueman and SELinux security policies that need to be resolved; see, for example, https://bugzilla.redhat.com/show_bug.cgi?id=1198272 that suggests the problem has been fixed in Fedora 21. ---------- nosy: +ned.deily resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 07:18:33 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 30 Jun 2015 05:18:33 +0000 Subject: [issue24533] Increased Test Coverage for Lib/random.py In-Reply-To: <1435602887.43.0.963223854079.issue24533@psf.upfronthosting.co.za> Message-ID: <1435641513.2.0.637861468821.issue24533@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't mind adding a test but would like it to written somewhat differently. I'll work something up when I get a chance. Marking this as a low priority because the code is already working fine and this is just a nice addition to improve coverage. ---------- assignee: -> rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 08:17:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Jun 2015 06:17:49 +0000 Subject: [issue24532] asyncio.sock_recv() blocks normal ioloop actions. In-Reply-To: <1435605795.17.0.399031709497.issue24532@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Le lundi 29 juin 2015, Yury Selivanov a ?crit : > > > > You should develop using asyncio debug mode: > > Maybe we should promote this check to the production mode? > asyncio must be slow. The check has a cost, I prefer to keep it only in debug mode. It's probably more a doc issue. We should maybe repeat the info at the beginning of the asyncio doc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 08:54:22 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Tue, 30 Jun 2015 06:54:22 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1435647262.75.0.0223365787803.issue24259@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Martin, I followed your suggestion to raise ReadError. This needed an additional change in copyfileobj() because it is used both for adding file data to an archive and extracting file data from an archive. But I think the patch is in good shape now. ---------- Added file: http://bugs.python.org/file39837/issue24259-3.x-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 09:19:17 2015 From: report at bugs.python.org (Jonathan Slenders) Date: Tue, 30 Jun 2015 07:19:17 +0000 Subject: [issue24536] os.pipe() should return a structsequence (or namedtuple.) Message-ID: <1435648757.18.0.0558265298673.issue24536@psf.upfronthosting.co.za> New submission from Jonathan Slenders: As discussed on python-ideas, os.pipe should return a structsequence instead of a plain tuple. To be decided is the naming for the read and write end. Personally, I'm in favour of using readfd/writefd. > our_pipe = pipe() > os.write(our_pipe.writefd, b'data') > os.read(our_pipe.readfd, 1024) ---------- components: IO messages: 245980 nosy: jonathan.slenders priority: normal severity: normal status: open title: os.pipe() should return a structsequence (or namedtuple.) versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 09:31:00 2015 From: report at bugs.python.org (Chris Angelico) Date: Tue, 30 Jun 2015 07:31:00 +0000 Subject: [issue24536] os.pipe() should return a structsequence (or namedtuple.) In-Reply-To: <1435648757.18.0.0558265298673.issue24536@psf.upfronthosting.co.za> Message-ID: <1435649460.16.0.112103585682.issue24536@psf.upfronthosting.co.za> Chris Angelico added the comment: Another good option is read/write without the 'fd' suffix. Either works, I'd prefer the shorter one but by a small margin. ---------- nosy: +Rosuav _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 10:20:54 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 30 Jun 2015 08:20:54 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za> Message-ID: <1435652454.9.0.161284530132.issue24534@psf.upfronthosting.co.za> Nick Coghlan added the comment: As others have noted, we're not going to change this default in the standard CPython executable (due to the degree of disruption involved), and the -S and -I switches already effectively turn it off (by disabling site module processing entirely) However, it could be reasonable to consider offering a way to disable *just* the execution of arbitrary code from .pth files, while otherwise allowing the site module to run. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 10:42:20 2015 From: report at bugs.python.org (Christian Heimes) Date: Tue, 30 Jun 2015 08:42:20 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za> Message-ID: <1435653740.73.0.860929548683.issue24534@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 12:04:31 2015 From: report at bugs.python.org (Dana Christen) Date: Tue, 30 Jun 2015 10:04:31 +0000 Subject: [issue24537] Py_Initialize unable to load the file system codec Message-ID: <1435658671.67.0.0806508765667.issue24537@psf.upfronthosting.co.za> New submission from Dana Christen: I'm using the C API to embed the Python interpreter (see the attached example). Everything works fine until I try to run the resulting executable on a machine without a Python installation. In that case, the call to Py_Initialize fails with the following message: Fatal Python error: Py_Initialize: unable to load the file system codec ImportError: No module named 'encodings' This was on Windows 7 64 bit, and the program was compiled using MS Visual Studio 2010 in x64 Release mode, using the official Python 3.4.3 64 bit release (v3.4.3:9b73f1c3e601). ---------- components: Extension Modules files: python_api_hello.c messages: 245984 nosy: Dana Christen priority: normal severity: normal status: open title: Py_Initialize unable to load the file system codec type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39838/python_api_hello.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 14:00:07 2015 From: report at bugs.python.org (koobs) Date: Tue, 30 Jun 2015 12:00:07 +0000 Subject: [issue24520] Stop using deprecated floating-point environment functions on FreeBSD In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za> Message-ID: <1435665607.07.0.0403355972632.issue24520@psf.upfronthosting.co.za> Changes by koobs : ---------- keywords: +needs review nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 14:00:26 2015 From: report at bugs.python.org (Ed Maste) Date: Tue, 30 Jun 2015 12:00:26 +0000 Subject: [issue24520] Stop using deprecated floating-point environment functions on FreeBSD In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za> Message-ID: <1435665626.69.0.354086282345.issue24520@psf.upfronthosting.co.za> Changes by Ed Maste : ---------- nosy: +emaste _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 14:07:21 2015 From: report at bugs.python.org (Gerrit Holl) Date: Tue, 30 Jun 2015 12:07:21 +0000 Subject: [issue24538] os.setxattr PermissionError on panfs propagates up causing `copystat`, `copytree`, and `pip install .` to fail unhepfully Message-ID: <1435666041.75.0.103684760482.issue24538@psf.upfronthosting.co.za> New submission from Gerrit Holl: `shutil.copystat` fails on [panfs](https://en.wikipedia.org/wiki/Panasas#PanFS) if the source file lacks u+w, because setting extended attributes results in a `PermissionError`. This leads to higher end functions such as `shutil.copytree` to fail. More seriously, it leads to `pip install .` to fail, as I [reported here](https://github.com/pypa/pip/issues/2941): In [55]: shutil.copystat("/src/on/panfs", "/tmp/fubar") --------------------------------------------------------------------------- PermissionError Traceback (most recent call last) in () ----> 1 shutil.copystat("/home/users/gholl/checkouts/pyatmlab/.git/objects/pack/pack-c1449559ec4287b3830efe2913608dddf2f21391.pack", "/tmp/fubar") /home/users/gholl/lib/python3.4/shutil.py in copystat(src, dst, follow_symlinks) 211 else: 212 raise --> 213 _copyxattr(src, dst, follow_symlinks=follow) 214 215 def copy(src, dst, *, follow_symlinks=True): /home/users/gholl/lib/python3.4/shutil.py in _copyxattr(src, dst, follow_symlinks) 151 try: 152 value = os.getxattr(src, name, follow_symlinks=follow_symlinks) --> 153 os.setxattr(dst, name, value, follow_symlinks=follow_symlinks) 154 except OSError as e: 155 if e.errno not in (errno.EPERM, errno.ENOTSUP, errno.ENODATA): PermissionError: [Errno 13] Permission denied: '/tmp/fubar' This occurs for any source file where the user write bit is not set. Now, I'm not sure if this should be addressed in `pip`, `shutil.copytree`, `shutil.copystat`, `setxattr`, `panfs`, or in none of the above. I'm reporting it in different places; please close this issue if this is the wrong place. ---------- components: Library (Lib) messages: 245985 nosy: Gerrit.Holl priority: normal severity: normal status: open title: os.setxattr PermissionError on panfs propagates up causing `copystat`, `copytree`, and `pip install .` to fail unhepfully versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 14:07:29 2015 From: report at bugs.python.org (Gerrit Holl) Date: Tue, 30 Jun 2015 12:07:29 +0000 Subject: [issue24538] os.setxattr PermissionError on panfs propagates up causing `copystat`, `copytree`, and `pip install .` to fail unhepfully In-Reply-To: <1435666041.75.0.103684760482.issue24538@psf.upfronthosting.co.za> Message-ID: <1435666049.88.0.46205712361.issue24538@psf.upfronthosting.co.za> Changes by Gerrit Holl : ---------- type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 14:54:46 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 30 Jun 2015 12:54:46 +0000 Subject: [issue24539] StreamReaderProtocol.eof_received() should return True to keep the transport open Message-ID: <1435668886.87.0.254771488213.issue24539@psf.upfronthosting.co.za> New submission from Guido van Rossum: See https://github.com/python/asyncio/issues/251. I'm on vacation and may or may not find the time to actually fix this (it needs a unittest written). ---------- components: asyncio messages: 245986 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: StreamReaderProtocol.eof_received() should return True to keep the transport open versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 15:08:49 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 30 Jun 2015 13:08:49 +0000 Subject: [issue24538] os.setxattr PermissionError on panfs propagates up causing `copystat`, `copytree`, and `pip install .` to fail unhepfully In-Reply-To: <1435666041.75.0.103684760482.issue24538@psf.upfronthosting.co.za> Message-ID: <1435669729.7.0.0634622687615.issue24538@psf.upfronthosting.co.za> R. David Murray added the comment: There are a couple of related open issues. I think there is an stdlib problem here, but I"m not sure what the solution is. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 15:14:34 2015 From: report at bugs.python.org (Cyd Haselton) Date: Tue, 30 Jun 2015 13:14:34 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1B217915-A56B-4FD0-8436-8D12BFE9C8E9@gmail.com> Message-ID: <65D683B5-A3BC-42A8-9DAD-4B7B4BF5422B@gmail.com> Cyd Haselton added the comment: Your question about -fPIE brings up a question: How should the differences between Android 5 and previous versions be handled in regards to this issue? Other than mandatory -fPIE, there are changes to Android[s libc that may make patches for python on Android 4.x incompatible with Android 5. Thoughts? On June 29, 2015 9:29:35 AM CDT, Cyd Haselton wrote: > >Cyd Haselton added the comment: > >No...haven't upgraded to Android 5.0 yet. > >On June 29, 2015 9:00:01 AM CDT, Ryan Gonzalez >wrote: >> >>Ryan Gonzalez added the comment: >> >>You compiled with -fPIE and GCC, right? I know the Android Clang seems >>broken. >> >>On June 29, 2015 7:09:25 AM CDT, Cyd Haselton >>wrote: >>> >>>Cyd Haselton added the comment: >>> >>>FYI, Figured out that running ./configure with --with-pydebug does >NOT >>>define Py_DEBUG in pyconfig.h. >>> >>>Defining it in pyconfig.h got me past the "undefined reference to >>>`_PyUnicode_CheckConsistency'" error, but i'm now getting this: >>> >>>if test $? -ne 0 ; then \ >>> echo "generate-posix-vars failed" ; \ >>> rm -f ./pybuilddir.txt ; \ >>> exit 1 ; \ >>>fi >>>Debug memory block at address p=0x90b7b0: API '' >>> 2416312320 bytes originally requested >>> The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb): >>> at p-3: 0x00 *** OUCH >>> at p-2: 0x00 *** OUCH >>> at p-1: 0x00 *** OUCH >>> Because memory is corrupted at the start, the count of bytes >>requested >>> may be bogus, and checking the trailing pad bytes may >segfault. >>> The 4 pad bytes at tail=0x9096b7b0 are Segmentation fault >>>generate-posix-vars failed >>>make: *** [pybuilddir.txt] Error 1 >>> >>>Will re-check patch application and try again >>> >>>---------- >>> >>>_______________________________________ >>>Python tracker >>> >>>_______________________________________ >> >>---------- >> >>_______________________________________ >>Python tracker >> >>_______________________________________ > >---------- > >_______________________________________ >Python tracker > >_______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 15:26:51 2015 From: report at bugs.python.org (Gerrit Holl) Date: Tue, 30 Jun 2015 13:26:51 +0000 Subject: [issue24538] os.setxattr PermissionError on panfs propagates up causing `copystat`, `copytree`, and `pip install .` to fail unhepfully In-Reply-To: <1435666041.75.0.103684760482.issue24538@psf.upfronthosting.co.za> Message-ID: <1435670811.02.0.77582527693.issue24538@psf.upfronthosting.co.za> Gerrit Holl added the comment: Perhaps the solution would be some kind of flag, at least for copytree and possibly others, on what to do when attributes cannot be completely copied ? a bit like numpys options to raise, warn, or ignore? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 16:20:45 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Tue, 30 Jun 2015 14:20:45 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <65D683B5-A3BC-42A8-9DAD-4B7B4BF5422B@gmail.com> Message-ID: <89E3B300-7997-406C-8E06-C483CA794F51@gmail.com> Ryan Gonzalez added the comment: On June 30, 2015 8:14:34 AM CDT, Cyd Haselton wrote: > >Cyd Haselton added the comment: > >Your question about -fPIE brings up a question: How should the >differences between Android 5 and previous versions be handled in >regards to this issue? > >Other than mandatory -fPIE, there are changes to Android[s libc that >may make patches for python on Android 4.x incompatible with Android >5. > WHAT??? :( I can't find a list anywhere; how do you know? >Thoughts? Not really... > >On June 29, 2015 9:29:35 AM CDT, Cyd Haselton >wrote: >> >>Cyd Haselton added the comment: >> >>No...haven't upgraded to Android 5.0 yet. >> >>On June 29, 2015 9:00:01 AM CDT, Ryan Gonzalez > >>wrote: >>> >>>Ryan Gonzalez added the comment: >>> >>>You compiled with -fPIE and GCC, right? I know the Android Clang >seems >>>broken. >>> >>>On June 29, 2015 7:09:25 AM CDT, Cyd Haselton > >>>wrote: >>>> >>>>Cyd Haselton added the comment: >>>> >>>>FYI, Figured out that running ./configure with --with-pydebug does >>NOT >>>>define Py_DEBUG in pyconfig.h. >>>> >>>>Defining it in pyconfig.h got me past the "undefined reference to >>>>`_PyUnicode_CheckConsistency'" error, but i'm now getting this: >>>> >>>>if test $? -ne 0 ; then \ >>>> echo "generate-posix-vars failed" ; \ >>>> rm -f ./pybuilddir.txt ; \ >>>> exit 1 ; \ >>>>fi >>>>Debug memory block at address p=0x90b7b0: API '' >>>> 2416312320 bytes originally requested >>>> The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb): >>>> at p-3: 0x00 *** OUCH >>>> at p-2: 0x00 *** OUCH >>>> at p-1: 0x00 *** OUCH >>>> Because memory is corrupted at the start, the count of bytes >>>requested >>>> may be bogus, and checking the trailing pad bytes may >>segfault. >>>> The 4 pad bytes at tail=0x9096b7b0 are Segmentation fault >>>>generate-posix-vars failed >>>>make: *** [pybuilddir.txt] Error 1 >>>> >>>>Will re-check patch application and try again >>>> >>>>---------- >>>> >>>>_______________________________________ >>>>Python tracker >>>> >>>>_______________________________________ >>> >>>---------- >>> >>>_______________________________________ >>>Python tracker >>> >>>_______________________________________ >> >>---------- >> >>_______________________________________ >>Python tracker >> >>_______________________________________ > >---------- > >_______________________________________ >Python tracker > >_______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 16:52:10 2015 From: report at bugs.python.org (Ethan Furman) Date: Tue, 30 Jun 2015 14:52:10 +0000 Subject: [issue24536] os.pipe() should return a structsequence (or namedtuple.) In-Reply-To: <1435648757.18.0.0558265298673.issue24536@psf.upfronthosting.co.za> Message-ID: <1435675930.62.0.324061850982.issue24536@psf.upfronthosting.co.za> Ethan Furman added the comment: 'read'/'write' is sufficient. +1 for the proposal. ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 16:57:17 2015 From: report at bugs.python.org (Jonathan Slenders) Date: Tue, 30 Jun 2015 14:57:17 +0000 Subject: [issue24536] os.pipe() should return a structsequence (or namedtuple.) In-Reply-To: <1435648757.18.0.0558265298673.issue24536@psf.upfronthosting.co.za> Message-ID: <1435676237.17.0.387802263426.issue24536@psf.upfronthosting.co.za> Jonathan Slenders added the comment: Niki Spahiev made a valid argument saying that the following code is common: if not hasattr(src, 'read'): src = open(src) This will break if we name it 'read'/'write' like the methods of a file object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 17:09:08 2015 From: report at bugs.python.org (Cyd Haselton) Date: Tue, 30 Jun 2015 15:09:08 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <89E3B300-7997-406C-8E06-C483CA794F51@gmail.com> Message-ID: <64983CB3-7254-4988-90B6-9D6AD0C99547@gmail.com> Cyd Haselton added the comment: On June 30, 2015 9:20:45 AM CDT, Ryan Gonzalez wrote: > >Ryan Gonzalez added the comment: > >On June 30, 2015 8:14:34 AM CDT, Cyd Haselton >wrote: >> >>Cyd Haselton added the comment: >> >>Your question about -fPIE brings up a question: How should the >>differences between Android 5 and previous versions be handled in >>regards to this issue? >> >>Other than mandatory -fPIE, there are changes to Android[s libc that >>may make patches for python on Android 4.x incompatible with Android >>5. >> > >WHAT??? :( I can't find a list anywhere; how do you know? > I tried building GCC for Android 5 on device and ran into a bunch of errors like 'undefined symbol __swbuf.' Googling the errors led to this page: https://developer.android.com/ndk/downloads/revision_history.html. Relevant Part here: " Removed the following symbols from all architectures:?get_malloc_leak_info,free_malloc_leak_info,?__srget,?__swbuf,?__srefill,__swsetup,?__sdidinit,?__sflags,?__sfp,?__sinit,?__smakebuf,__sflush,?__sread,?__swrite,?__sseek,?__sclose,?_fwalk,__sglue,?__get_thread,?__wait4,?__futex_wake,?__open,__get_tls,?__getdents64, and?dlmalloc." >>Thoughts? > >Not really... Would setting up two repos be advisable...one for 5 and one for 4.x and earlier? > >> >>On June 29, 2015 9:29:35 AM CDT, Cyd Haselton >>wrote: >>> >>>Cyd Haselton added the comment: >>> >>>No...haven't upgraded to Android 5.0 yet. >>> >>>On June 29, 2015 9:00:01 AM CDT, Ryan Gonzalez >> >>>wrote: >>>> >>>>Ryan Gonzalez added the comment: >>>> >>>>You compiled with -fPIE and GCC, right? I know the Android Clang >>seems >>>>broken. >>>> >>>>On June 29, 2015 7:09:25 AM CDT, Cyd Haselton >> >>>>wrote: >>>>> >>>>>Cyd Haselton added the comment: >>>>> >>>>>FYI, Figured out that running ./configure with --with-pydebug does >>>NOT >>>>>define Py_DEBUG in pyconfig.h. >>>>> >>>>>Defining it in pyconfig.h got me past the "undefined reference to >>>>>`_PyUnicode_CheckConsistency'" error, but i'm now getting this: >>>>> >>>>>if test $? -ne 0 ; then \ >>>>> echo "generate-posix-vars failed" ; \ >>>>> rm -f ./pybuilddir.txt ; \ >>>>> exit 1 ; \ >>>>>fi >>>>>Debug memory block at address p=0x90b7b0: API '' >>>>> 2416312320 bytes originally requested >>>>> The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb): >>>>> at p-3: 0x00 *** OUCH >>>>> at p-2: 0x00 *** OUCH >>>>> at p-1: 0x00 *** OUCH >>>>> Because memory is corrupted at the start, the count of bytes >>>>requested >>>>> may be bogus, and checking the trailing pad bytes may >>>segfault. >>>>> The 4 pad bytes at tail=0x9096b7b0 are Segmentation fault >>>>>generate-posix-vars failed >>>>>make: *** [pybuilddir.txt] Error 1 >>>>> >>>>>Will re-check patch application and try again >>>>> >>>>>---------- >>>>> >>>>>_______________________________________ >>>>>Python tracker >>>>> >>>>>_______________________________________ >>>> >>>>---------- >>>> >>>>_______________________________________ >>>>Python tracker >>>> >>>>_______________________________________ >>> >>>---------- >>> >>>_______________________________________ >>>Python tracker >>> >>>_______________________________________ >> >>---------- >> >>_______________________________________ >>Python tracker >> >>_______________________________________ > >---------- > >_______________________________________ >Python tracker > >_______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 17:37:01 2015 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 30 Jun 2015 15:37:01 +0000 Subject: [issue24294] DeprecationWarnings should be visible by default in the interactive REPL In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za> Message-ID: <1435678621.96.0.602742001718.issue24294@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: Note that I've signed the CLA, and it has been taken into account, as now I have a small star agains my name (if it was the limiting factor, we never know). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 18:49:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Jun 2015 16:49:26 +0000 Subject: [issue24528] Misleading exeption for await in comprehensions. In-Reply-To: <1435577323.48.0.769775989737.issue24528@psf.upfronthosting.co.za> Message-ID: <20150630164921.19972.34126@psf.io> Roundup Robot added the comment: New changeset 30b676e8b21f by Yury Selivanov in branch '3.5': Issue #24528: Improve error message for awaits in comprehensions https://hg.python.org/cpython/rev/30b676e8b21f New changeset 9598bc916186 by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24528) https://hg.python.org/cpython/rev/9598bc916186 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 18:49:56 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 30 Jun 2015 16:49:56 +0000 Subject: [issue24528] Misleading exeption for await in comprehensions. In-Reply-To: <1435577323.48.0.769775989737.issue24528@psf.upfronthosting.co.za> Message-ID: <1435682996.75.0.940150893488.issue24528@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 20:52:18 2015 From: report at bugs.python.org (Min RK) Date: Tue, 30 Jun 2015 18:52:18 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za> Message-ID: <1435690338.75.0.928174828158.issue24534@psf.upfronthosting.co.za> Min RK added the comment: Thanks for the feedback, I thought it might be a long shot. I will go back to removing the *use* of the feature everywhere I can find it, since it is so problematic and rarely, if ever, desirable. > it's an essential feature that has been documented for a very long time > https://docs.python.org/3.5/library/site.html The entirety of the documentation of this feature appears to be this sentence on that page: > Lines starting with import (followed by space or tab) are executed. No explanation or examples are given, nor any reasoning about the feature or why one might use it. > This change will basically break all Python applications This surprises me. Can you elaborate? I have not seen an application rely on executing code in .pth files. > If you believe that we can smoothly move to a world without .pth files, > you should propose an overall plan, step by step. I have no desire to remove .pth files. .pth files are a fine way to add locations to sys.path. It's .pth files *executing arbitrary code* that's the problem, very surprising, and a source of many errors (especially how it is used in setuptools). ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 22:16:22 2015 From: report at bugs.python.org (Matthew Havard) Date: Tue, 30 Jun 2015 20:16:22 +0000 Subject: [issue24540] Documentation about skipkeys parameter for json.dumps is incorrect Message-ID: <1435695382.36.0.927622903083.issue24540@psf.upfronthosting.co.za> New submission from Matthew Havard: The documentation from json.dumps says this about skipkeys: If ``skipkeys`` is false then ``dict`` keys that are not basic types (``str``, ``int``, ``float``, ``bool``, ``None``) will be skipped instead of raising a ``TypeError``. However, that contradicts the docstrings for JSONEncoder in the encoder.py file, and json.dump in the same file, __init__.py: json.dump: If ``skipkeys`` is true then ``dict`` keys that are not basic types (``str``, ``int``, ``float``, ``bool``, ``None``) will be skipped instead of raising a ``TypeError``. JSONEncoder: If skipkeys is false, then it is a TypeError to attempt encoding of keys that are not str, int, long, float or None. If skipkeys is True, such items are simply skipped. So the fix is just that the word "false" to "true". ---------- messages: 245997 nosy: Matthew Havard priority: normal severity: normal status: open title: Documentation about skipkeys parameter for json.dumps is incorrect versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 22:36:24 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 30 Jun 2015 20:36:24 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435690338.75.0.928174828158.issue24534@psf.upfronthosting.co.za> Message-ID: <5592FDC5.2080900@egenix.com> Marc-Andre Lemburg added the comment: On 30.06.2015 20:52, Min RK wrote: > > Thanks for the feedback, I thought it might be a long shot. I will go back to removing the *use* of the feature everywhere I can find it, since it is so problematic and rarely, if ever, desirable. Could you please post an example of where the feature is problematic ? >> it's an essential feature that has been documented for a very long time >> https://docs.python.org/3.5/library/site.html > > The entirety of the documentation of this feature appears to be this sentence on that page: > >> Lines starting with import (followed by space or tab) are executed. Yep, but it's enough to be in active use. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 22:49:45 2015 From: report at bugs.python.org (Min RK) Date: Tue, 30 Jun 2015 20:49:45 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za> Message-ID: <1435697385.56.0.101659110923.issue24534@psf.upfronthosting.co.za> Min RK added the comment: > Could you please post an example of where the feature is problematic ? setuptools/easy_install is the major one, which effectively does `sys.path[:0] = pth_contents`, breaking import priority. This has been known to result in adding `/usr/lib/pythonX.Y/dist-packages` to the front of sys.path, having higher priority that the stdlib or `--user` -installed packages (I helped a user deal with a completely broken installation that was a result of exactly this last week). The result can often be that `pip list` doesn't accurately describe the versions of packages that are imported. It also causes `pip install -e` to result in completely different import priority from `pip install`, which doesn't use easy-install.pth. Removing the code execution from `easy-install.pth` solves all of these problems. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 23:15:27 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 30 Jun 2015 21:15:27 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435697385.56.0.101659110923.issue24534@psf.upfronthosting.co.za> Message-ID: <559306EB.90807@egenix.com> Marc-Andre Lemburg added the comment: On 30.06.2015 22:49, Min RK wrote: > >> Could you please post an example of where the feature is problematic ? > > setuptools/easy_install is the major one, which effectively does `sys.path[:0] = pth_contents`, breaking import priority. This has been known to result in adding `/usr/lib/pythonX.Y/dist-packages` to the front of sys.path, having higher priority that the stdlib or `--user` -installed packages (I helped a user deal with a completely broken installation that was a result of exactly this last week). The result can often be that `pip list` doesn't accurately describe the versions of packages that are imported. It also causes `pip install -e` to result in completely different import priority from `pip install`, which doesn't use easy-install.pth. Removing the code execution from `easy-install.pth` solves all of these problems. Ok, so you regard the way that setuptools uses the feature as problematic. I'm sure some people will agree (including myself), but this is not a good reason to remove the feature altogether. Just because a feature can be misused doesn't make it a bad feature. Otherwise, we'd have quite a few things we'd have to remove from Python :-) I'd suggest to try to fix the setuptools uses of the feature instead - in a way that doesn't break all setuptools installations, of course. Perhaps you could submit a fix for this to the setuptools maintainers instead. Thanks, -- Marc-Andre Lemburg eGenix.com ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jun 30 23:54:29 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 30 Jun 2015 21:54:29 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1435701269.42.0.0363744606241.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: > > isawaitable(), however, should continue using abc.Awaitable, since it only checks for __await__ presence on the type (or should we just drop it?) > I'd really remove it. It's not referring to an actual type, so it doesn't fit the purpose of the inspect module. The fact that the only place where "collections.abc" is used in this module is in isawaitable() should be a clear indication that it's misplaced. +1. I added 'isawaitable()' before we decided to add ABCs, and now it is redundant (and we don't have isiterable, ishashable etc) Ben, I saw that you're using isawaitable() in tornado, but it looks like you can easily switch the code to use Awaitable ABC, right? ---------- _______________________________________ Python tracker _______________________________________