From report at bugs.python.org Fri May 1 00:03:21 2015 From: report at bugs.python.org (Jim Jewett) Date: Thu, 30 Apr 2015 22:03:21 +0000 Subject: [issue24088] yield expression confusion Message-ID: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za> New submission from Jim Jewett: https://docs.python.org/3/reference/expressions.html#yield-expressions Current: """ When a generator function is called, it returns an iterator known as a generator. That generator then controls the execution of a generator function. The execution starts when one of the generator?s methods is called. """ At a minimum, that seems to be using "generator function" in two different ways, but I think there are other problems. Proposed: """ When a generator function is called, it returns a special kind of iterator known as a generator. The iteration starts when one of the generator?s methods is called. """ ---------- assignee: docs at python components: Documentation, asyncio messages: 242289 nosy: Jim.Jewett, docs at python, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: yield expression confusion type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 00:24:28 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 30 Apr 2015 22:24:28 +0000 Subject: [issue24088] yield expression confusion In-Reply-To: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za> Message-ID: <1430432668.19.0.747372005539.issue24088@psf.upfronthosting.co.za> Guido van Rossum added the comment: You can't just drop the middle sentence. Awkward though it is, it is attempting to describe that the generator object controls suspension and resumption of the stack frame representing execution of the generator function's body. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 01:13:29 2015 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Thu, 30 Apr 2015 23:13:29 +0000 Subject: [issue23572] functools.singledispatch fails when "not BaseClass" is True In-Reply-To: <1425385029.2.0.304023107943.issue23572@psf.upfronthosting.co.za> Message-ID: <1430435609.33.0.231265244595.issue23572@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Yes, this needs addressing. ---------- assignee: -> lukasz.langa versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 01:17:09 2015 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Thu, 30 Apr 2015 23:17:09 +0000 Subject: [issue24086] Configparser interpolation is unexpected In-Reply-To: <1430421130.2.0.837084015548.issue24086@psf.upfronthosting.co.za> Message-ID: <1430435829.91.0.383647221791.issue24086@psf.upfronthosting.co.za> ?ukasz Langa added the comment: This is expected behaviour but I agree the error message should be improved. There are people using interpolation in .pypirc, if you don't want that, just use a double % sign and it will do the right thing. You don't have to change your password. I'll leave that open to find what's the source of the exception and maybe add a more helpful message there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 01:20:29 2015 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Thu, 30 Apr 2015 23:20:29 +0000 Subject: [issue2651] Strings passed to KeyError do not round trip In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za> Message-ID: <1430436029.72.0.586223963334.issue2651@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Agreed that this can be addressed now for Python 3.5. ---------- assignee: -> lukasz.langa versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 01:35:11 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 30 Apr 2015 23:35:11 +0000 Subject: [issue24076] sum() several times slower on Python 3 In-Reply-To: <1430332618.4.0.236828536627.issue24076@psf.upfronthosting.co.za> Message-ID: <1430436911.8.0.759769446068.issue24076@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It seems we (like the benchmarks posted) are spending a whole lot of time on something that's probably not relevant to any real-world situation. If someone has actual code that suffers from this, it would be good to know about it. (note by the way that summing on a range() can be done O(1): it's just a variation on a arithmetic series) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 01:45:26 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 30 Apr 2015 23:45:26 +0000 Subject: [issue10435] Document unicode C-API in reST In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za> Message-ID: <1430437526.88.0.871050625722.issue10435@psf.upfronthosting.co.za> Mark Lawrence added the comment: List of just about everything that's in the header file but not in the rst file as I'm not sure which bits you normally wouldn't bother with. Py_USING_UNICODE Py_UNICODE_SIZE Py_UNICODE_WIDE Py_UNICODE_COPY Py_UNICODE_FILL Py_UNICODE_HIGH_SURROGATE Py_UNICODE_LOW_SURROGATE Py_UNICODE_MATCH PyUnicode_WSTR_LENGTH PyUnicode_AS_DATA PyUnicode_IS_ASCII PyUnicode_IS_COMPACT PyUnicode_IS_COMPACT_ASCII PyUnicode_IS_READY Py_UNICODE_REPLACEMENT_CHARACTER PyUnicode_FromString PyUnicode_GetMax PyUnicode_Resize PyUnicode_InternImmortal PyUnicode_CHECK_INTERNED PyUnicode_FromOrdinal PyUnicode_GetDefaultEncoding PyUnicode_AsDecodedObject PyUnicode_AsDecodedUnicode PyUnicode_AsEncodedObject PyUnicode_AsEncodedUnicode PyUnicode_BuildEncodingMap PyUnicode_DecodeCodePageStateful PyUnicode_EncodeDecimal PyUnicode_Append PyUnicode_AppendAndDel PyUnicode_Partition PyUnicode_RPartition PyUnicode_RSplit PyUnicode_IsIdentifier Py_UNICODE_strlen Py_UNICODE_strcpy Py_UNICODE_strcat Py_UNICODE_strncpy Py_UNICODE_strcmp Py_UNICODE_strncmp Py_UNICODE_strchr Py_UNICODE_strrchr ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 02:47:14 2015 From: report at bugs.python.org (Anthony Sottile) Date: Fri, 01 May 2015 00:47:14 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430441234.26.0.0208326460146.issue24085@psf.upfronthosting.co.za> Anthony Sottile added the comment: Adding `import gc; gc.collect()` doesn't change the outcome afaict ---------- nosy: +asottile _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 03:45:00 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 01 May 2015 01:45:00 +0000 Subject: [issue24074] string, center, ljust, rjust, width paramter should accept None In-Reply-To: <1430289844.83.0.648544192653.issue24074@psf.upfronthosting.co.za> Message-ID: <1430444700.22.0.487518677259.issue24074@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Marking as rejected because 0 works fine and accepting None just complicates the parsing and documentation without any incremental benefit. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 04:56:36 2015 From: report at bugs.python.org (Jaivish Kothari) Date: Fri, 01 May 2015 02:56:36 +0000 Subject: [issue24005] Documentation Error: Extra line Break In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za> Message-ID: <1430448996.9.0.594155034463.issue24005@psf.upfronthosting.co.za> Jaivish Kothari added the comment: Thank you Tim. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 05:45:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 May 2015 03:45:48 +0000 Subject: [issue23572] functools.singledispatch fails when "not BaseClass" is True In-Reply-To: <1425385029.2.0.304023107943.issue23572@psf.upfronthosting.co.za> Message-ID: <1430451948.75.0.817351130249.issue23572@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 06:45:58 2015 From: report at bugs.python.org (SpaceOne) Date: Fri, 01 May 2015 04:45:58 +0000 Subject: [issue24089] argparse crashes with AssertionError Message-ID: <1430455558.24.0.369924072386.issue24089@psf.upfronthosting.co.za> New submission from SpaceOne: Just add an argument with metavar='[PROTOCOL://]HOST[:PORT]' ([...] twice in the string) causes the following traceback: Traceback (most recent call last): File "curl.py", line 182, in arguments = parser.parse_args() File "/usr/lib/python2.7/argparse.py", line 1701, in parse_args args, argv = self.parse_known_args(args, namespace) File "/usr/lib/python2.7/argparse.py", line 1733, in parse_known_args namespace, args = self._parse_known_args(args, namespace) File "/usr/lib/python2.7/argparse.py", line 1939, in _parse_known_args start_index = consume_optional(start_index) File "/usr/lib/python2.7/argparse.py", line 1879, in consume_optional take_action(action, args, option_string) File "/usr/lib/python2.7/argparse.py", line 1807, in take_action action(self, namespace, argument_values, option_string) File "/usr/lib/python2.7/argparse.py", line 996, in __call__ parser.print_help() File "/usr/lib/python2.7/argparse.py", line 2340, in print_help self._print_message(self.format_help(), file) File "/usr/lib/python2.7/argparse.py", line 2314, in format_help return formatter.format_help() File "/usr/lib/python2.7/argparse.py", line 281, in format_help help = self._root_section.format_help() File "/usr/lib/python2.7/argparse.py", line 211, in format_help func(*args) File "/usr/lib/python2.7/argparse.py", line 332, in _format_usage assert ' '.join(opt_parts) == opt_usage AssertionError ---------- components: Distutils messages: 242299 nosy: dstufft, eric.araujo, spaceone priority: normal severity: normal status: open title: argparse crashes with AssertionError type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 08:09:58 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 01 May 2015 06:09:58 +0000 Subject: [issue24076] sum() several times slower on Python 3 In-Reply-To: <1430332618.4.0.236828536627.issue24076@psf.upfronthosting.co.za> Message-ID: <1430460598.09.0.779088464881.issue24076@psf.upfronthosting.co.za> Stefan Behnel added the comment: I don't think it's irrelevant. Throw-away integers are really not uncommon. For-loops use them quite often, non-trivial arithmetic expressions can create a lot of intermediate temporaries. Speeding up the create-delete cycle of PyLong sounds like a very obvious thing to do. Imagine some code that iterates over a list of integers, applies some calculation to them, and then stores them in a new list, maybe even using a list comprehension or so. If you could speed up the intermediate calculation by avoiding overhead in creating temporary PyLong objects, such code could benefit a lot. I suspect that adding a free-list for single-digit PyLong objects (the most common case) would provide some visible benefit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 09:19:24 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 01 May 2015 07:19:24 +0000 Subject: [issue23572] functools.singledispatch fails when "not BaseClass" is True In-Reply-To: <1425385029.2.0.304023107943.issue23572@psf.upfronthosting.co.za> Message-ID: <1430464764.4.0.106190449054.issue23572@psf.upfronthosting.co.za> Changes by Paul Moore : ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 12:40:39 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 01 May 2015 10:40:39 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430476839.64.0.85039453938.issue24085@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Adding `import gc; gc.collect()` doesn't change the outcome afaict Of course it doesn't. The memory has already been released. "ru_maxrss" is the maximum memory consumption during the whole process lifetime. Add the following at the end of your script (Linux): import os, re, resource print(resource.getrusage(resource.RUSAGE_SELF).ru_maxrss) with open("/proc/%d/status" % os.getpid(), "r") as f: for line in f: if line.split(':')[0] in ('VmHWM', 'VmRSS'): print(line.strip()) And you'll see that VmRSS has already fallen back to the same level as when the pyc is not recompiled (it's a little bit more, perhaps due to fragmentation): $ rm -r __pycache__/; ./python -c "import repro" 19244 VmHWM: 19244 kB VmRSS: 12444 kB $ ./python -c "import repro" 12152 VmHWM: 12152 kB VmRSS: 12152 kB ("VmHWM" - the HighWater Mark - is the same as ru_maxrss) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 12:44:15 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 01 May 2015 10:44:15 +0000 Subject: [issue24076] sum() several times slower on Python 3 In-Reply-To: <1430460598.09.0.779088464881.issue24076@psf.upfronthosting.co.za> Message-ID: <554358FB.3030409@free.fr> Antoine Pitrou added the comment: Le 01/05/2015 08:09, Stefan Behnel a ?crit : > > I don't think it's irrelevant. Throw-away integers are really not uncommon. For-loops use them quite often, non-trivial arithmetic expressions can create a lot of intermediate temporaries. Speeding up the create-delete cycle of PyLong sounds like a very obvious thing to do. That may be a good thing indeed. I'm just saying that the benchmarks people are worried about here are completely pointless. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 13:20:48 2015 From: report at bugs.python.org (irdb) Date: Fri, 01 May 2015 11:20:48 +0000 Subject: [issue24090] Add a "copy variable to clipboard" option to the edit menu Message-ID: <1430479248.08.0.880712455727.issue24090@psf.upfronthosting.co.za> New submission from irdb: I suggest adding a "Copy variable to clipboard" menu option to the edit menu of IDLE. Sometimes I need to copy a variable to clipboard, but because the variable is so long, printing it in the IDLE window makes IDLE sluggish and then selecting and copying the printed value becomes a little cumbersome. Of-coarse as it is suggested in [1], I can do copy the variable `v` using the following commands: from Tkinter import Tk r = Tk() r.withdraw() r.clipboard_clear() r.clipboard_append(str(v)) r.destroy() but I think it's too much and it would be nice to have such menu option that after clicking on it a dialog box appears asking for variable name and after entering the name causes the str content of the variable to be copied to the clipboard. [1]: https://stackoverflow.com/questions/579687/how-do-i-copy-a-string-to-the-clipboard-on-windows-using-python ---------- components: IDLE messages: 242303 nosy: irdb priority: normal severity: normal status: open title: Add a "copy variable to clipboard" option to the edit menu type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 13:52:53 2015 From: report at bugs.python.org (irdb) Date: Fri, 01 May 2015 11:52:53 +0000 Subject: [issue19042] Idle: add option to autosave 'Untitled' edit window In-Reply-To: <1379438454.05.0.402533666166.issue19042@psf.upfronthosting.co.za> Message-ID: <1430481173.92.0.144510119789.issue19042@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 13:56:33 2015 From: report at bugs.python.org (irdb) Date: Fri, 01 May 2015 11:56:33 +0000 Subject: [issue6143] IDLE - an extension to clear the shell window In-Reply-To: <1243631391.82.0.146122427664.issue6143@psf.upfronthosting.co.za> Message-ID: <1430481393.6.0.91322630067.issue6143@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 13:56:59 2015 From: report at bugs.python.org (irdb) Date: Fri, 01 May 2015 11:56:59 +0000 Subject: [issue1442493] IDLE shell window gets very slow when displaying long lines Message-ID: <1430481419.36.0.733059820823.issue1442493@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 14:19:22 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 01 May 2015 12:19: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: <1430482762.81.0.0161440712075.issue24017@psf.upfronthosting.co.za> Stefan Behnel added the comment: > I don't think it's necessary to have slots for __aiter__, __anext__, __aenter__ and __aexit__. Async iteration will never be as fast as regular iteration, and there is plenty overhead in it. You seem to be assuming that the outer loop is the asyncio I/O loop. That might not be the case. It might be a thread-pool executor, it might be an in-memory task switcher, or it might just be something passing on items from a list. At least "__anext__" is worth being fast, IMHO. Also note that one advantage of slots is that the user can cache their value to keep calling the same C function multiple times. That is not the case for a Python method, which can easily be replaced. Some iterators do that with their __next__ method, and it's perfectly valid. Having to look up the Python method on each iteration and calling through it sounds like unnecessary overhead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 15:56:07 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 13:56:07 +0000 Subject: [issue24091] Use after free in Element.extend (1) Message-ID: <1430488567.85.0.132864592859.issue24091@psf.upfronthosting.co.za> New submission from paul: # 1055 for (i = 0; i < seqlen; i++) { # (gdb) n # 1056 PyObject* element = PySequence_Fast_GET_ITEM(seq, i); # (gdb) n # 1057 if (!PyObject_IsInstance(element, (PyObject *)&Element_Type)) { # (gdb) print *element # $19 = {_ob_next = 0x4060e6fc, _ob_prev = 0x4056cd8c, ob_refcnt = 1, ob_type = 0x406de3e4} # (gdb) n # 1066 if (element_add_subelement(self, element) < 0) { # (gdb) print *element # $20 = {_ob_next = 0xdbdbdbdb, _ob_prev = 0xdbdbdbdb, ob_refcnt = -606348325, ob_type = 0xdbdbdbdb} # # Fatal Python error: /home/p/Python-3.4.1/Modules/_elementtree.c:267 object at 0x4056c4cc has negative ref count -606348326 # # "element" is removed in __getattribute__ method. ---------- files: poc_elt_extend1.py messages: 242305 nosy: pkt priority: normal severity: normal status: open title: Use after free in Element.extend (1) type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39240/poc_elt_extend1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 15:57:05 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 13:57:05 +0000 Subject: [issue24092] Use after free in Element.extend (2) Message-ID: <1430488625.39.0.290044967832.issue24092@psf.upfronthosting.co.za> New submission from paul: # Program received signal SIGSEGV, Segmentation fault. # 0x4063cf19 in element_extend (self=0x405ddf74, args=([],)) at /home/p/Python-3.4.1/Modules/_elementtree.c:1056 # 1056 PyObject* element = PySequence_Fast_GET_ITEM(seq, i); # (gdb) print i # $3 = 1337 # (gdb) print *(PyListObject*)seq # $4 = {ob_base = {ob_base = {_ob_next = 0x406373ec, _ob_prev = 0x405ddf74, ob_refcnt = 3, ob_type = 0x830e1c0 }, # ob_size = 0}, ob_item = 0x0, allocated = 0} # # Controlled read (resulting from a use after free). "seq" is cleared in a custom # destructor (Y.__del__()). # ---------- files: poc_elt_extend2.py messages: 242306 nosy: pkt priority: normal severity: normal status: open title: Use after free in Element.extend (2) type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39241/poc_elt_extend2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 15:58:08 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 13:58:08 +0000 Subject: [issue24093] Use after free in Element.remove Message-ID: <1430488688.91.0.916599584274.issue24093@psf.upfronthosting.co.za> New submission from paul: # Program received signal SIGABRT, Aborted. # 0x40022424 in __kernel_vsyscall () # (gdb) bt # #0 0x40022424 in __kernel_vsyscall () # #1 0x400bb1df in raise () from /lib/i386-linux-gnu/libc.so.6 # #2 0x400be825 in abort () from /lib/i386-linux-gnu/libc.so.6 # #3 0x08067030 in Py_FatalError ( # msg=0xbfed7a20 "/home/p/Python-3.4.1/Modules/_elementtree.c:1436 object at 0x405743ec has negative ref count -606348326") # at Python/pythonrun.c:2633 # #4 0x080f1374 in _Py_NegativeRefcount (fname=0x40646100 "/home/p/Python-3.4.1/Modules/_elementtree.c", lineno=1436, # op=) at Objects/object.c:203 # #5 0x4063dfa6 in element_remove (self=0x40583c34, args=(,)) # at /home/p/Python-3.4.1/Modules/_elementtree.c:1436 # (gdb) frame 5 # #5 0x4063dfa6 in element_remove (self=0x40583c34, args=(,)) # at /home/p/Python-3.4.1/Modules/_elementtree.c:1436 # 1436 Py_DECREF(self->extra->children[i]); # (gdb) print i # $1 = 1 # (gdb) print *(PyObject*)self->extra->children # $3 = {_ob_next = 0x4057437c, _ob_prev = 0x405743ec, ob_refcnt = 1079461180, ob_type = 0x4057461c} # # Fatal Python error: /home/p/Python-3.4.1/Modules/_elementtree.c:1436 object at 0x405743ec has negative ref count -606348326 # # "self->extra->children" is cleared in custom __eq__ method. Py_DECREF handles # stale pointer. Use after free. # ---------- files: poc_elt_remove.py messages: 242307 nosy: pkt priority: normal severity: normal status: open title: Use after free in Element.remove type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39242/poc_elt_remove.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:00:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 May 2015 14:00:46 +0000 Subject: [issue24091] Use after free in Element.extend (1) In-Reply-To: <1430488567.85.0.132864592859.issue24091@psf.upfronthosting.co.za> Message-ID: <1430488846.28.0.359904004093.issue24091@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Extension Modules, XML nosy: +eli.bendersky, scoder, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:00:58 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 14:00:58 +0000 Subject: [issue24094] Use after free during json encoding (PyType_IsSubtype) Message-ID: <1430488858.91.0.915527926564.issue24094@psf.upfronthosting.co.za> New submission from paul: # Breakpoint 1, encoder_listencode_dict (s=0x405b23fc, acc=0xbfc4038c, dct=, indent_level=0) # at /home/p/Python-3.4.1/Modules/_json.c:1540 # 1540 items = PyMapping_Keys(dct); # (gdb) n # 1541 if (items == NULL) # (gdb) print *items # $1 = {_ob_next = 0x405c8af4, _ob_prev = 0x4059006c, ob_refcnt = 2, ob_type = 0x830e1c0 } # (gdb) n # 1543 if (!PyList_Check(items)) { # (gdb) n # 1547 if (PyList_Sort(items) < 0) # (gdb) n # 1549 nitems = PyList_GET_SIZE(items); # (gdb) n # 1550 for (i = 0; i < nitems; i++) { # (gdb) print nitems # $2 = 1122 # (gdb) n # 1552 key = PyList_GET_ITEM(items, i); # (gdb) n # 1553 value = PyDict_GetItem(dct, key); # (gdb) print *key # $3 = {_ob_next = 0x4058eedc, _ob_prev = 0x40590d1c, ob_refcnt = 1, ob_type = 0x405afd1c} # (gdb) n # # Program received signal SIGSEGV, Segmentation fault. # 0x08108825 in PyType_IsSubtype (a=0xdbdbdbdb, b=0x830f1a0 ) at Objects/typeobject.c:1292 # 1292 mro = a->tp_mro; # (gdb) bt # #0 0x08108825 in PyType_IsSubtype (a=0xdbdbdbdb, b=0x830f1a0 ) at Objects/typeobject.c:1292 # #1 0x080f22d6 in do_richcompare (v=1337, w=, op=2) at Objects/object.c:643 # #2 0x080f263d in PyObject_RichCompare (v=1337, w=, op=2) at Objects/object.c:701 # #3 0x080f26ce in PyObject_RichCompareBool (v=1337, w=, op=2) at Objects/object.c:723 # #4 0x080df7b5 in lookdict (mp=0x405c8b34, key=, hash=1337, value_addr=0xbfc40200) # at Objects/dictobject.c:485 # #5 0x080e145d in PyDict_GetItem (op=, key=) at Objects/dictobject.c:1095 # #6 0x405bf6f9 in encoder_listencode_dict (s=0x405b23fc, acc=0xbfc4038c, dct=, indent_level=0) # # Deleting the object in __hash__() method triggers an use after free in PyType_IsSubtype. ---------- files: poc_enc_dict1.py messages: 242308 nosy: pkt priority: normal severity: normal status: open title: Use after free during json encoding (PyType_IsSubtype) type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39243/poc_enc_dict1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:02:15 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 14:02:15 +0000 Subject: [issue24095] Use after free during json encoding a dict (2) Message-ID: <1430488935.49.0.703786529764.issue24095@psf.upfronthosting.co.za> New submission from paul: # Breakpoint 1, encoder_listencode_dict (s=0x405b23fc, acc=0xbfaf96ec, dct=, indent_level=0) # at /home/p/Python-3.4.1/Modules/_json.c:1540 # 1540 items = PyMapping_Keys(dct); # (gdb) print *items # $1 = {_ob_next = 0x4059029c, _ob_prev = 0x405c8ab4, ob_refcnt = 1, ob_type = 0x830f1a0 } # (gdb) n # 1541 if (items == NULL) # (gdb) n # 1543 if (!PyList_Check(items)) { # (gdb) n # 1547 if (PyList_Sort(items) < 0) # (gdb) n # 1549 nitems = PyList_GET_SIZE(items); # (gdb) n # 1550 for (i = 0; i < nitems; i++) { # (gdb) n # 1552 key = PyList_GET_ITEM(items, i); # (gdb) n # 1553 value = PyDict_GetItem(dct, key); # (gdb) n # 1554 item = PyTuple_Pack(2, key, value); # (gdb) print *key # $2 = {_ob_next = 0xdbdbdbdb, _ob_prev = 0xdbdbdbdb, ob_refcnt = -606348325, ob_type = 0xdbdbdbdb} # (gdb) n # # Program received signal SIGSEGV, Segmentation fault. # 0x08104047 in PyTuple_Pack (n=2) at Objects/tupleobject.c:216 # 216 Py_INCREF(o); # # We circumvent use after free bug in PyType_IsSubtype (poc_enc_dict1.py) by # returning -1 from the __hash__() method. This way PyDict_GetItem bails # quickly, without triggering the problematic code. # PyTuple_Pack handles a stale "key" pointer and crashes. Use after free. ---------- files: poc_enc_dict2.py messages: 242309 nosy: pkt priority: normal severity: normal status: open title: Use after free during json encoding a dict (2) type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39244/poc_enc_dict2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:02:21 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 01 May 2015 14:02:21 +0000 Subject: [issue24076] sum() several times slower on Python 3 In-Reply-To: <1430332618.4.0.236828536627.issue24076@psf.upfronthosting.co.za> Message-ID: <1430488941.32.0.124414957859.issue24076@psf.upfronthosting.co.za> Stefan Behnel added the comment: I tried implementing a freelist. Patch attached, mostly adapted from the one in dictobject.c, but certainly needs a bit of cleanup. The results are not bad, about 10-20% faster: Original: $ ./python -m timeit 'sum(range(1, 100000))' 1000 loops, best of 3: 1.86 msec per loop $ ./python -m timeit -s 'l = list(range(1000, 10000))' '[(i*2+5) // 7 for i in l]' 1000 loops, best of 3: 1.05 msec per loop With freelist: $ ./python -m timeit 'sum(range(1, 100000))' 1000 loops, best of 3: 1.52 msec per loop $ ./python -m timeit -s 'l = list(range(1000, 10000))' '[(i*2+5) // 7 for i in l]' 1000 loops, best of 3: 931 usec per loop ---------- keywords: +patch Added file: http://bugs.python.org/file39245/pylong_freelist.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:03:23 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 14:03:23 +0000 Subject: [issue24096] Use after free during json encoding a dict (3) Message-ID: <1430489003.72.0.86735316643.issue24096@psf.upfronthosting.co.za> New submission from paul: # Program received signal SIGSEGV, Segmentation fault. # 0x40036740 in encoder_listencode_dict (s=0x405b43fc, acc=0xbf86438c, dct=, indent_level=0) # at /home/p/Python-3.4.1/Modules/_json.c:1557 # 1557 PyList_SET_ITEM(items, i, item); # (gdb) print *(PyListObject*)items # $1 = {ob_base = {ob_base = {_ob_next = 0x405bcab4, _ob_prev = 0x40591184, ob_refcnt = 2, ob_type = 0x830e1c0 }, # ob_size = 0}, ob_item = 0x0, allocated = 0} # (gdb) print i # $2 = 112233 # # "items" was cleared in __hash__, so we get a wild write at a controlled address. ---------- files: poc_enc_dict3.py messages: 242311 nosy: pkt priority: normal severity: normal status: open title: Use after free during json encoding a dict (3) type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39246/poc_enc_dict3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:04:37 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 14:04:37 +0000 Subject: [issue24096] Use after free in get_filter In-Reply-To: <1430489003.72.0.86735316643.issue24096@psf.upfronthosting.co.za> Message-ID: <1430489077.52.0.868131537913.issue24096@psf.upfronthosting.co.za> paul added the comment: # Program received signal SIGSEGV, Segmentation fault. # 0x080f2c17 in PyObject_GetAttr (v=, name='match') at Objects/object.c:872 # 872 if (tp->tp_getattro != NULL) # (gdb) bt # #0 0x080f2c17 in PyObject_GetAttr (v=, name='match') at Objects/object.c:872 # #1 0x080f2b42 in _PyObject_GetAttrId (v=, name=0x8328354 ) at Objects/object.c:835 # #2 0x0809c3a6 in _PyObject_CallMethodId (o=, name=0x8328354 , format=0x829552c "O") # at Objects/abstract.c:2215 # #3 0x0817e48b in check_matched (obj=, arg='c') at Python/_warnings.c:28 # #4 0x0817e88b in get_filter (category=, text='', lineno=4, module='c', item=0xbfa87c88) # (gdb) frame 4 # #4 0x0817e88b in get_filter (category=, text='', lineno=4, module='c', item=0xbfa87c88) # at Python/_warnings.c:152 # 152 good_mod = check_matched(mod, module); # (gdb) print *mod # $1 = {_ob_next = 0xdbdbdbdb, _ob_prev = 0xdbdbdbdb, ob_refcnt = -606348325, ob_type = 0xdbdbdbdb} # # "mod" object is deleted in "match" method. Use after free. # ---------- title: Use after free during json encoding a dict (3) -> Use after free in get_filter Added file: http://bugs.python.org/file39247/poc_get_filter.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:05:35 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 14:05:35 +0000 Subject: [issue24097] Use after free in PyObject_GetState Message-ID: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> New submission from paul: # Program received signal SIGSEGV, Segmentation fault. # 0x080f27b2 in PyObject_Hash (v=) at Objects/object.c:746 # 746 if (tp->tp_hash != NULL) # (gdb) bt # #0 0x080f27b2 in PyObject_Hash (v=) at Objects/object.c:746 # #1 0x080e1717 in PyDict_SetItem (op={}, key=, value=None) at Objects/dictobject.c:1201 # #2 0x0810e8a0 in _PyObject_GetState (obj=) at Objects/typeobject.c:3657 # #3 0x081100e9 in reduce_2 (obj=) at Objects/typeobject.c:3949 # #4 0x08110551 in _common_reduce (self=, proto=2) at Objects/typeobject.c:4012 # #5 0x08110641 in object_reduce (self=, args=(2,)) at Objects/typeobject.c:4032 # # (gdb) frame 2 # #2 0x0810e8a0 in _PyObject_GetState (obj=) at Objects/typeobject.c:3657 # 3657 int err = PyDict_SetItem(slots, name, value); # (gdb) print *name # $1 = {_ob_next = 0xdbdbdbdb, _ob_prev = 0xdbdbdbdb, ob_refcnt = -606348325, ob_type = 0xdbdbdbdb} # # "name" is freed inside __getattr__ and is later used by PyDict_SetItem. ---------- files: poc_getstate.py messages: 242313 nosy: pkt priority: normal severity: normal status: open title: Use after free in PyObject_GetState type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39248/poc_getstate.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:08:58 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:08:58 +0000 Subject: [issue24096] Use after free in get_filter In-Reply-To: <1430489003.72.0.86735316643.issue24096@psf.upfronthosting.co.za> Message-ID: <1430489338.29.0.0400252985107.issue24096@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules nosy: +christian.heimes stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:09:49 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:09:49 +0000 Subject: [issue24096] Use after free in get_filter In-Reply-To: <1430489003.72.0.86735316643.issue24096@psf.upfronthosting.co.za> Message-ID: <1430489389.5.0.23013164383.issue24096@psf.upfronthosting.co.za> Christian Heimes added the comment: In 3.5 the segfault occurs at #0 0x00007ffff073e55e in encoder_listencode_dict (s=s at entry=0x7ffff09aa988, acc=acc at entry=0x7fffffffcf20, dct=dct at entry=, indent_level=indent_level at entry=0) at /home/heimes/dev/python/cpython/Modules/_json.c:1686 #1 0x00007ffff073ee85 in encoder_listencode_obj (s=s at entry=0x7ffff09aa988, acc=acc at entry=0x7fffffffcf20, obj=, indent_level=0) at /home/heimes/dev/python/cpython/Modules/_json.c:1561 #2 0x00007ffff073f392 in encoder_call (self=<_json.Encoder at remote 0x7ffff09aa988>, args=(, 0), kwds=0x0) at /home/heimes/dev/python/cpython/Modules/_json.c:1386 #3 0x000000000044edf8 in PyObject_Call (func=func at entry=<_json.Encoder at remote 0x7ffff09aa988>, arg=arg at entry=(, 0), kw=kw at entry=0x0) at Objects/abstract.c:2147 #4 0x000000000052be56 in do_call (func=func at entry=<_json.Encoder at remote 0x7ffff09aa988>, pp_stack=pp_stack at entry=0x7fffffffd098, na=na at entry=2, nk=nk at entry=0) at Python/ceval.c:4515 #5 0x000000000053663c in call_function (pp_stack=pp_stack at entry=0x7fffffffd098, oparg=oparg at entry=2) at Python/ceval.c:4311 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:10:29 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 14:10:29 +0000 Subject: [issue24098] Multiple use after frees in obj2ast_* methods Message-ID: <1430489429.65.0.587999729774.issue24098@psf.upfronthosting.co.za> New submission from paul: # 3617 for (i = 0; i < len; i++) { # (gdb) print *(PyListObject*)tmp # $1 = {ob_base = {ob_base = {_ob_next = 0x4056f8f4, _ob_prev = 0x4057329c, ob_refcnt = 2, ob_type = 0x830e1c0 }, # ob_size = 1337}, ob_item = 0x8491ae0, allocated = 1432} # (gdb) n # 3619 res = obj2ast_stmt(PyList_GET_ITEM(tmp, i), &value, arena); # (gdb) n # 3620 if (res != 0) goto failed; # (gdb) print *(PyListObject*)tmp # $2 = {ob_base = {ob_base = {_ob_next = 0x4056f8f4, _ob_prev = 0x4057329c, ob_refcnt = 2, ob_type = 0x830e1c0 }, # ob_size = 1}, ob_item = 0x8491ae0, allocated = 4} # (gdb) c # Continuing. # # Program received signal SIGSEGV, Segmentation fault. # 0x080f2c17 in PyObject_GetAttr (v=, name='lineno') at Objects/object.c:872 # 872 if (tp->tp_getattro != NULL) # # Objects freed in __getattr__ are used later in the loop above. There are two # bugs actually. One is the use-after-free and the second is using a stale size # variable "len" to control the for(...) loop. "body" can be mutated inside # obj2ast_stmt. This construct: for (i = 0; i < len; i++) { stmt_ty value; res = obj2ast_stmt(PyList_GET_ITEM(tmp, i), &value, arena); if (res != 0) goto failed; asdl_seq_SET(body, i, value); } is repeated multiple times in multiple obj2ast_ methods. It contains two bugs: 1. tmp[i] isn't protected from deletion inside python code (refcnt is not increased by GET_ITEM), 2. tmp's length can drop below "len" resulting in an OOB read, because the loop counter is static. ---------- files: poc_obj2mod.py messages: 242315 nosy: pkt priority: normal severity: normal status: open title: Multiple use after frees in obj2ast_* methods type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39249/poc_obj2mod.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:11:20 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 14:11:20 +0000 Subject: [issue24099] Use after free in siftdown (1) Message-ID: <1430489480.16.0.0840319770251.issue24099@psf.upfronthosting.co.za> New submission from paul: # _siftdown(PyListObject *heap, Py_ssize_t startpos, Py_ssize_t pos) # ... # newitem = PyList_GET_ITEM(heap, pos); # Py_INCREF(newitem); # /* Follow the path to the root, moving parents down until finding # a place newitem fits. */ # while (pos > startpos){ # parentpos = (pos - 1) >> 1; # 1 parent = PyList_GET_ITEM(heap, parentpos); # 2 cmp = PyObject_RichCompareBool(newitem, parent, Py_LT); # if (cmp == -1) { # Py_DECREF(newitem); # return -1; # } # 3 if (size != PyList_GET_SIZE(heap)) { # Py_DECREF(newitem); # PyErr_SetString(PyExc_RuntimeError, # "list changed size during iteration"); # return -1; # } # if (cmp == 0) # break; # 4 Py_INCREF(parent); # ... # # 1. parent isn't protected (refcnt==1) # 2. custom compare function deletes all objects in "heap" and repopulates it with # fresh instances. "parent" is freed # 3. check is ineffective. Heap was mutated while preserving its size # 4. use after free. Crash will manifest itself later. ---------- files: poc_siftdown1.py messages: 242316 nosy: pkt priority: normal severity: normal status: open title: Use after free in siftdown (1) type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39250/poc_siftdown1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:11:23 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:11:23 +0000 Subject: [issue24092] Use after free in Element.extend (2) In-Reply-To: <1430488625.39.0.290044967832.issue24092@psf.upfronthosting.co.za> Message-ID: <1430489483.65.0.955551009227.issue24092@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:11:38 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:11:38 +0000 Subject: [issue24093] Use after free in Element.remove In-Reply-To: <1430488688.91.0.916599584274.issue24093@psf.upfronthosting.co.za> Message-ID: <1430489498.09.0.362005793554.issue24093@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules nosy: +christian.heimes versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:12:21 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 14:12:21 +0000 Subject: [issue24100] Use after free in siftdown (2) Message-ID: <1430489541.93.0.209728480757.issue24100@psf.upfronthosting.co.za> New submission from paul: # _siftdown(PyListObject *heap, Py_ssize_t startpos, Py_ssize_t pos) # ... # while (pos > startpos){ # parentpos = (pos - 1) >> 1; # parent = PyList_GET_ITEM(heap, parentpos); # 1 cmp = PyObject_RichCompareBool(newitem, parent, Py_LT); # ... # 2 if (size != PyList_GET_SIZE(heap)) { # Py_DECREF(newitem); # PyErr_SetString(PyExc_RuntimeError, # "list changed size during iteration"); # return -1; # } # if (cmp == 0) # 3 break; # ... # } # 4 Py_DECREF(PyList_GET_ITEM(heap, pos)); # 5 PyList_SET_ITEM(heap, pos, newitem); # # 1. custom compare function replaces object at index "pos" with a fresh # instance with refcnt==1 # 2. check is ineffective, since mutation was done without altering size # 3. break out of the loop # 4. refcnt drops to 0 and __del__ method is called. Destructed clears the heap # 5. SET_ITEM doesn't do any bounds checking and does a wild write. # # "pos" is under our control and is restricted only by the amount of free # memory. pos==X requires heap of size X-1. # # gX global var is necessary. Without it, python crashes in debug checks inside # Py_ForgetReference. Seems like clearing L puts objects in a bad state. # # GDB # --- # Program received signal SIGSEGV, Segmentation fault. # 0x4002ed73 in _siftdown (heap=0x4058edfc, startpos=0, pos=112233) at /home/p/Python-3.4.1/Modules/_heapqmodule.c:58 # 58 PyList_SET_ITEM(heap, pos, newitem); # (gdb) print *heap # $1 = {ob_base = {ob_base = {_ob_next = 0x405913f4, _ob_prev = 0x4058ee6c, ob_refcnt = 2, ob_type = 0x830e1c0 }, # ob_size = 0}, ob_item = 0x0, allocated = 0} # (gdb) print pos # $2 = 112233 ---------- files: poc_siftdown2.py messages: 242317 nosy: pkt priority: normal severity: normal status: open title: Use after free in siftdown (2) type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39251/poc_siftdown2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:12:23 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:12:23 +0000 Subject: [issue24091] Use after free in Element.extend (1) In-Reply-To: <1430488567.85.0.132864592859.issue24091@psf.upfronthosting.co.za> Message-ID: <1430489543.45.0.987995356542.issue24091@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:12:33 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:12:33 +0000 Subject: [issue24094] Use after free during json encoding (PyType_IsSubtype) In-Reply-To: <1430488858.91.0.915527926564.issue24094@psf.upfronthosting.co.za> Message-ID: <1430489553.89.0.257315042206.issue24094@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules nosy: +christian.heimes stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:12:43 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:12:43 +0000 Subject: [issue24095] Use after free during json encoding a dict (2) In-Reply-To: <1430488935.49.0.703786529764.issue24095@psf.upfronthosting.co.za> Message-ID: <1430489563.39.0.288027453697.issue24095@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules nosy: +christian.heimes stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:12:55 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:12:55 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <1430489575.13.0.651509613743.issue24097@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:12:55 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 14:12:55 +0000 Subject: [issue24101] Use after free in siftup Message-ID: <1430489575.51.0.442803283693.issue24101@psf.upfronthosting.co.za> New submission from paul: # Breakpoint 1, _siftup (heap=0x4056b344, pos=65534) at /home/p/Python-3.4.1/Modules/_heapqmodule.c:121 # warning: Source file is more recent than executable. # 121 Py_DECREF(PyList_GET_ITEM(heap, pos)); # (gdb) print *heap->ob_item[pos] # $1 = {_ob_next = 0x41812058, _ob_prev = 0x831159c , ob_refcnt = 1, ob_type = 0x4058fd1c} # (gdb) n # 122 PyList_SET_ITEM(heap, pos, newitem); # (gdb) print *heap->ob_item[pos] # Cannot access memory at address 0x3fff8 # (gdb) print *heap # $2 = {ob_base = {ob_base = {_ob_next = 0x4059c0b4, _ob_prev = 0x405903b4, ob_refcnt = 2, ob_type = 0x830e1c0 }, # ob_size = 0}, ob_item = 0x0, allocated = 0} # (gdb) n # # Program received signal SIGSEGV, Segmentation fault. # 0x4002f150 in _siftup (heap=0x4056b344, pos=65534) at /home/p/Python-3.4.1/Modules/_heapqmodule.c:122 # 122 PyList_SET_ITEM(heap, pos, newitem); ---------- files: poc_siftup.py messages: 242318 nosy: pkt priority: normal severity: normal status: open title: Use after free in siftup type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39252/poc_siftup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:13:06 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:13:06 +0000 Subject: [issue24098] Multiple use after frees in obj2ast_* methods In-Reply-To: <1430489429.65.0.587999729774.issue24098@psf.upfronthosting.co.za> Message-ID: <1430489586.04.0.478427463889.issue24098@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:13:14 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:13:14 +0000 Subject: [issue24099] Use after free in siftdown (1) In-Reply-To: <1430489480.16.0.0840319770251.issue24099@psf.upfronthosting.co.za> Message-ID: <1430489594.54.0.582510347117.issue24099@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:13:25 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:13:25 +0000 Subject: [issue24092] Use after free in Element.extend (2) In-Reply-To: <1430488625.39.0.290044967832.issue24092@psf.upfronthosting.co.za> Message-ID: <1430489605.48.0.753167913523.issue24092@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:13:30 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:13:30 +0000 Subject: [issue24099] Use after free in siftdown (1) In-Reply-To: <1430489480.16.0.0840319770251.issue24099@psf.upfronthosting.co.za> Message-ID: <1430489610.38.0.780653655916.issue24099@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:13:35 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:13:35 +0000 Subject: [issue24098] Multiple use after frees in obj2ast_* methods In-Reply-To: <1430489429.65.0.587999729774.issue24098@psf.upfronthosting.co.za> Message-ID: <1430489615.05.0.313394604295.issue24098@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:14:06 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 14:14:06 +0000 Subject: [issue24102] Multiple type confusions in unicode error handlers Message-ID: <1430489646.71.0.827069473585.issue24102@psf.upfronthosting.co.za> New submission from paul: # Breakpoint 1, PyUnicodeEncodeError_GetEnd (exc=, end=0xbf9e8f7c) at Objects/exceptions.c:1643 # 1643 PyObject *obj = get_unicode(((PyUnicodeErrorObject *)exc)->object, # (gdb) s # get_unicode (attr=, name=0x82765ea "object") at Objects/exceptions.c:1516 # 1516 if (!attr) { # (gdb) print *attr # $4 = {_ob_next = 0xfefefefe, _ob_prev = 0xfefefefe, ob_refcnt = -16843010, ob_type = 0xfefefefe} # (gdb) c # Continuing. # # Program received signal SIGSEGV, Segmentation fault. # 0x080bc7d9 in get_unicode (attr=, name=0x82765ea "object") at Objects/exceptions.c:1521 # 1521 if (!PyUnicode_Check(attr)) { # # Type confusion. IsInstance check is ineffective because of custom # __getattribute__ method. Contents of string instance is interpreted as # an exception object. ---------- files: poc_unicode_errors.py messages: 242319 nosy: pkt priority: normal severity: normal status: open title: Multiple type confusions in unicode error handlers type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39253/poc_unicode_errors.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:14:43 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:14:43 +0000 Subject: [issue24101] Use after free in siftup In-Reply-To: <1430489575.51.0.442803283693.issue24101@psf.upfronthosting.co.za> Message-ID: <1430489683.67.0.96984297503.issue24101@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules nosy: +christian.heimes stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:15:15 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 14:15:15 +0000 Subject: [issue24103] Use after free in xmlparser_setevents (1) Message-ID: <1430489715.59.0.155743746692.issue24103@psf.upfronthosting.co.za> New submission from paul: # xmlparser_setevents(XMLParserObject *self, PyObject* args) # { # ... # /* clear out existing events */ # Py_CLEAR(target->start_event_obj); # 1 Py_CLEAR(target->end_event_obj); # Py_CLEAR(target->start_ns_event_obj); # Py_CLEAR(target->end_ns_event_obj); # # ... # # seqlen = PySequence_Size(events_seq); # for (i = 0; i < seqlen; ++i) { # 3 PyObject *event_name_obj = PySequence_Fast_GET_ITEM(events_seq, i); # ... # # if (event_name == NULL) { # ... # return NULL; # } else if (strcmp(event_name, "start") == 0) { # ... # } else if (strcmp(event_name, "end") == 0) { # Py_INCREF(event_name_obj); # 2 Py_XDECREF(target->end_event_obj); # target->end_event_obj = event_name_obj; # } # ... # } # ... # } # # This one leverages nested _setevents invocations. First invocation sets # target->end_event_obj to S1 instance. On seconds invocation, # target->end_event_obj has refcnt==1, so DECREF at line 1 triggers S1.__del__(). # Destructor invokes _setevents again and sets target->end_event_obj to a S3 # instance (with refcnt==1). After we return from nested call at line 1, # execution continues until it hits an "end" element. At line 2 S3.__del__() is # called and it deallocates "events_seq". This triggers a controlled OOB (we can # call it a use after free too) read at line 3. We can control a PyObject pointer. # # Program received signal SIGSEGV, Segmentation fault. # 0x4068563b in xmlparser_setevents (self=0x40669e4c, args=([], [])) at /home/p/Python-3.4.1/Modules/_elementtree.c:3560 # 3560 PyObject *event_name_obj = PySequence_Fast_GET_ITEM(events_seq, i); # (gdb) print i # $1 = 1337 # (gdb) print *(PyListObject*)events_seq # $2 = {ob_base = {ob_base = {_ob_next = 0x40669df4, _ob_prev = 0x4055f814, ob_refcnt = 3, ob_type = 0x830e1c0 }, # ob_size = 0}, ob_item = 0x0, allocated = 0} # ---------- files: poc_xml_setevents1.py messages: 242320 nosy: pkt priority: normal severity: normal status: open title: Use after free in xmlparser_setevents (1) type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39254/poc_xml_setevents1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:15:37 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:15:37 +0000 Subject: [issue24102] Multiple type confusions in unicode error handlers In-Reply-To: <1430489646.71.0.827069473585.issue24102@psf.upfronthosting.co.za> Message-ID: <1430489737.57.0.677133096783.issue24102@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules nosy: +christian.heimes stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:15:42 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 14:15:42 +0000 Subject: [issue24104] Use after free in xmlparser_setevents (2) Message-ID: <1430489742.91.0.610954411273.issue24104@psf.upfronthosting.co.za> New submission from paul: # Program received signal SIGSEGV, Segmentation fault. # 0x4068565c in xmlparser_setevents (self=0x4064b13c, args=([], [])) # at /home/p/Python-3.4.1/Modules/_elementtree.c:3562 # 3562 if (PyUnicode_Check(event_name_obj)) { # (gdb) print *event_name_obj # $6 = {_ob_next = 0xdbdbdbdb, _ob_prev = 0xdbdbdbdb, ob_refcnt = -606348325, ob_type = 0xdbdbdbdb} # # # "event_name_obj" is deleted inside a custom destructor. Use after free. ---------- files: poc_xml_setevents2.py messages: 242321 nosy: pkt priority: normal severity: normal status: open title: Use after free in xmlparser_setevents (2) type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39255/poc_xml_setevents2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:18:13 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:18:13 +0000 Subject: [issue24103] Use after free in xmlparser_setevents (1) In-Reply-To: <1430489715.59.0.155743746692.issue24103@psf.upfronthosting.co.za> Message-ID: <1430489893.37.0.151641728816.issue24103@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:18:37 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:18:37 +0000 Subject: [issue24104] Use after free in xmlparser_setevents (2) In-Reply-To: <1430489742.91.0.610954411273.issue24104@psf.upfronthosting.co.za> Message-ID: <1430489917.64.0.602817775394.issue24104@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Extension Modules nosy: +christian.heimes stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:19:50 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 14:19:50 +0000 Subject: [issue24105] Use after free during json encoding a dict (3) Message-ID: <1430489990.8.0.117941995919.issue24105@psf.upfronthosting.co.za> New submission from paul: # Program received signal SIGSEGV, Segmentation fault. # 0x40036740 in encoder_listencode_dict (s=0x405b43fc, acc=0xbf86438c, dct=, indent_level=0) # at /home/p/Python-3.4.1/Modules/_json.c:1557 # 1557 PyList_SET_ITEM(items, i, item); # (gdb) print *(PyListObject*)items # $1 = {ob_base = {ob_base = {_ob_next = 0x405bcab4, _ob_prev = 0x40591184, ob_refcnt = 2, ob_type = 0x830e1c0 }, # ob_size = 0}, ob_item = 0x0, allocated = 0} # (gdb) print i # $2 = 112233 # # "items" was cleared in __hash__, so we get a wild write at a controlled address. ---------- files: poc_enc_dict3.py messages: 242322 nosy: pkt priority: normal severity: normal status: open title: Use after free during json encoding a dict (3) type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39256/poc_enc_dict3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:20:15 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 14:20:15 +0000 Subject: [issue24096] Use after free in get_filter In-Reply-To: <1430489003.72.0.86735316643.issue24096@psf.upfronthosting.co.za> Message-ID: <1430490015.76.0.825511670706.issue24096@psf.upfronthosting.co.za> Changes by paul : Removed file: http://bugs.python.org/file39246/poc_enc_dict3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:22:16 2015 From: report at bugs.python.org (paul) Date: Fri, 01 May 2015 14:22:16 +0000 Subject: [issue24096] Use after free in get_filter In-Reply-To: <1430489003.72.0.86735316643.issue24096@psf.upfronthosting.co.za> Message-ID: <1430490136.31.0.437136537045.issue24096@psf.upfronthosting.co.za> paul added the comment: Issue for poc_enc_dict3.py is here: https://bugs.python.org/issue24105 Please ignore first and third message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:37:44 2015 From: report at bugs.python.org (Anthony Sottile) Date: Fri, 01 May 2015 14:37:44 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430491064.79.0.908935819877.issue24085@psf.upfronthosting.co.za> Anthony Sottile added the comment: I'm still seeing a very large difference: asottile at work:/tmp$ python repro.py ready 72604 VmHWM: 72604 kB VmRSS: 60900 kB asottile at work:/tmp$ rm *.pyc; python repro.py ready 1077232 VmHWM: 1077232 kB VmRSS: 218040 kB This file is significantly larger than the one attached, not sure if it makes much of a difference. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 16:42:22 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 14:42:22 +0000 Subject: [issue24096] Use after free in get_filter In-Reply-To: <1430489003.72.0.86735316643.issue24096@psf.upfronthosting.co.za> Message-ID: <1430491342.38.0.914316284852.issue24096@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks Paul! May I ask how you found that many use-after-free bugs? Are you using some sort of tool for static code analysis or fuzzying? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 17:18:54 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 May 2015 15:18:54 +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: <1430493534.45.0.0505091884212.issue24017@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think we can continue this discussion *after* the PEP's been accepted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 17:32:39 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 01 May 2015 15:32:39 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430494359.08.0.13898611837.issue24085@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Which Python version is that? Can you try with 3.4 or 3.5? (is it under GNU/Linux?) > This file is significantly larger than the one attached, not sure > if it makes much of a difference. Python doesn't make a difference internally, but perhaps it has some impact on your OS' memory management. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 17:39:09 2015 From: report at bugs.python.org (Anthony Sottile) Date: Fri, 01 May 2015 15:39:09 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430494749.54.0.908651067032.issue24085@psf.upfronthosting.co.za> Anthony Sottile added the comment: 3.4 seems happier: asottile at work:/tmp$ rm *.pyc; python3.4 repro.py ready 77472 VmHWM: 77472 kB VmRSS: 65228 kB asottile at work:/tmp$ python3.4 repro.py ready 77472 VmHWM: 77472 kB VmRSS: 65232 kB The nasty result above is from 2.7: $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 3.3 also seems to have the same exaggerated problem: $ rm *.pyc -f; python3.3 repro.py ready 1112996 VmHWM: 1112996 kB VmRSS: 133468 kB asottile at work:/tmp$ python3.3 repro.py ready 81392 VmHWM: 81392 kB VmRSS: 69304 kB $ python3.3 Python 3.3.6 (default, Jan 28 2015, 17:27:09) [GCC 4.8.2] on linux So seems the leaky behaviour was fixed at some point, any ideas of what change fixed it and is there a possibility of backporting it to 2.7? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 17:40:46 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 01 May 2015 15:40:46 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430494846.32.0.685078278161.issue24085@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note under 3.x, you need to "rm -r __pycache__", not "rm *.pyc", since the pyc files are now stored in the __pycache__ subdirectory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 17:42:21 2015 From: report at bugs.python.org (Anthony Sottile) Date: Fri, 01 May 2015 15:42:21 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430494941.02.0.522280742972.issue24085@psf.upfronthosting.co.za> Anthony Sottile added the comment: Ah, then 3.4 still has the problem: $ rm -rf __pycache__/ *.pyc; python3.4 repro.py ready 1112892 VmHWM: 1112892 kB VmRSS: 127196 kB asottile at work:/tmp$ python3.4 repro.py ready 77468 VmHWM: 77468 kB VmRSS: 65228 kB ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 17:47:39 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 01 May 2015 15:47:39 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430495259.47.0.237786156876.issue24085@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Is there any chance you can upload a script that's large enough to exhibit the problem? (perhaps with anonymized data if there's something sensitive in there) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 17:59:20 2015 From: report at bugs.python.org (Anthony Sottile) Date: Fri, 01 May 2015 15:59:20 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430495960.11.0.493039737972.issue24085@psf.upfronthosting.co.za> Anthony Sottile added the comment: Attached is repro2.py (slightly different so my editor doesn't hate itself when editing the file) I'll attach the other file in another comment since it seems I can only do one at a time ---------- Added file: http://bugs.python.org/file39257/repro2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 18:03:09 2015 From: report at bugs.python.org (Anthony Sottile) Date: Fri, 01 May 2015 16:03:09 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430496189.05.0.384359170319.issue24085@psf.upfronthosting.co.za> Changes by Anthony Sottile : Added file: http://bugs.python.org/file39259/anon_city_hoods.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 18:30:23 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 01 May 2015 16:30:23 +0000 Subject: [issue24100] Use after free in siftdown (2) In-Reply-To: <1430489541.93.0.209728480757.issue24100@psf.upfronthosting.co.za> Message-ID: <1430497823.42.0.877980238063.issue24100@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 18:38:31 2015 From: report at bugs.python.org (Chris Rebert) Date: Fri, 01 May 2015 16:38:31 +0000 Subject: [issue24064] Make the property doctstring writeable In-Reply-To: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> Message-ID: <1430498311.1.0.478315676213.issue24064@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 18:55:09 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 01 May 2015 16:55:09 +0000 Subject: [issue24100] Use after free in siftdown (2) In-Reply-To: <1430489541.93.0.209728480757.issue24100@psf.upfronthosting.co.za> Message-ID: <1430499309.46.0.0236457517727.issue24100@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Paul, this was nice work. Thanks. Attaching a patch to make 3.4 match the Python 3.5 version of the code which rearranges the object pointers without changing their reference counts. With that patch, your crasher no longer seg-faults, but gives this instead: len(L): 112234 __del__ __del__ Exception ignored in: > Traceback (most recent call last): File "heap_crasher.py", line 18, in __del__ IndexError: list index out of range ---------- keywords: +patch versions: +Python 2.7 Added file: http://bugs.python.org/file39260/sc2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 19:02:18 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 01 May 2015 17:02:18 +0000 Subject: [issue24099] Use after free in siftdown (1) In-Reply-To: <1430489480.16.0.0840319770251.issue24099@psf.upfronthosting.co.za> Message-ID: <1430499738.35.0.0770533455059.issue24099@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 19:05:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 May 2015 17:05:18 +0000 Subject: [issue24064] Make the property doctstring writeable In-Reply-To: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> Message-ID: <1430499918.9.0.0863570243946.issue24064@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If make docstrings writable, it would be good to ensure that they exactly are strings. And if make the property doctstring writable, may be make other docstrings writable? It may be useful for setting the same docstring for Python implementation and C accelerator. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 19:14:09 2015 From: report at bugs.python.org (James Edwards) Date: Fri, 01 May 2015 17:14:09 +0000 Subject: [issue24078] inspect.getsourcelines ignores context and returns wrong line # In-Reply-To: <1430348672.59.0.934013457033.issue24078@psf.upfronthosting.co.za> Message-ID: <1430500449.1.0.573925611957.issue24078@psf.upfronthosting.co.za> James Edwards added the comment: Inspect could probably be updated to use 3.3's __qualname__ in the case of classes-in-classes; classes-in-functions or functions-in-functions would likely be harder, but I'm not sure it's impossible. ---------- nosy: +jedwards _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 19:15:47 2015 From: report at bugs.python.org (jentyk) Date: Fri, 01 May 2015 17:15:47 +0000 Subject: [issue24106] Messed up indentation makes undesired piece of code being run! Message-ID: <1430500547.87.0.88978573823.issue24106@psf.upfronthosting.co.za> New submission from jentyk: In [14]: for i in xrange(10): ....: if 1==1: ....: print "It's true" ....: else: ....: print "It isn't true. Seriously??" ....: It's true It's true It's true It's true It's true It's true It's true It's true It's true It's true It isn't true. Seriously?? Is the behaviour intentional? I do not think so... ---------- components: Interpreter Core messages: 242336 nosy: jentyk priority: normal severity: normal status: open title: Messed up indentation makes undesired piece of code being run! type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 19:16:14 2015 From: report at bugs.python.org (James Edwards) Date: Fri, 01 May 2015 17:16:14 +0000 Subject: [issue24078] inspect.getsourcelines ignores context and returns wrong line # In-Reply-To: <1430348672.59.0.934013457033.issue24078@psf.upfronthosting.co.za> Message-ID: <1430500574.68.0.191276998619.issue24078@psf.upfronthosting.co.za> Changes by James Edwards : ---------- nosy: +pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 19:18:26 2015 From: report at bugs.python.org (James Edwards) Date: Fri, 01 May 2015 17:18:26 +0000 Subject: [issue24078] inspect.getsourcelines ignores context and returns wrong line # In-Reply-To: <1430348672.59.0.934013457033.issue24078@psf.upfronthosting.co.za> Message-ID: <1430500706.09.0.0577757713774.issue24078@psf.upfronthosting.co.za> James Edwards added the comment: Added Yury (inspect module) and Antoine (PEP 3155) to nosy -- apologies if you're not interested. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 19:26:27 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 May 2015 17:26:27 +0000 Subject: [issue24106] Messed up indentation makes undesired piece of code being run! In-Reply-To: <1430500547.87.0.88978573823.issue24106@psf.upfronthosting.co.za> Message-ID: <1430501187.14.0.762464543731.issue24106@psf.upfronthosting.co.za> R. David Murray added the comment: Whitespace is significant in Python. This is a fundamental part of the language. So yes, this is intentional. (Look up what the 'else' clause means on an if statement in the language reference.) ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 19:31:44 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 01 May 2015 17:31:44 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430501504.08.0.629668765197.issue24085@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I can reproduce: $ rm -r __pycache__/; ./python repro2.py ready 1047656 VmHWM: 1047656 kB VmRSS: 50660 kB $ ./python repro2.py ready 77480 VmHWM: 77480 kB VmRSS: 15664 kB My guess is that memory fragmentation prevents the RSS mark to drop any further, though one cannot rule out the possibility of an actual memory leak. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 19:32:41 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 01 May 2015 17:32:41 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430501561.32.0.248705076631.issue24085@psf.upfronthosting.co.za> Antoine Pitrou added the comment: (by the way, my numbers are with Python 3.5 - the in-development version - on 64-bit Linux) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 19:45:25 2015 From: report at bugs.python.org (Cory Benfield) Date: Fri, 01 May 2015 17:45:25 +0000 Subject: [issue24107] Add support for retrieving the certificate chain Message-ID: <1430502325.36.0.624144757291.issue24107@psf.upfronthosting.co.za> New submission from Cory Benfield: In order to perform HTTP Public Key Pinning (HPKP), it's necessary to have access to every certificate in the certificate trust chain. This is because the pinned key may actually be an intermediate or root certificate, rather than the leaf certificate. PyOpenSSL offers this functionality, and it ought to be a relatively simple enhancement to expose the equivalent function in the stdlib. For more background, see the urllib3 issue tracking the HPKP feature: https://github.com/shazow/urllib3/pull/607 ---------- components: Library (Lib) messages: 242341 nosy: Lukasa priority: normal severity: normal status: open title: Add support for retrieving the certificate chain type: enhancement versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 19:46:17 2015 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 01 May 2015 17:46:17 +0000 Subject: [issue24107] Add support for retrieving the certificate chain In-Reply-To: <1430502325.36.0.624144757291.issue24107@psf.upfronthosting.co.za> Message-ID: <1430502377.22.0.200272617721.issue24107@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 19:50:32 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 May 2015 17:50:32 +0000 Subject: [issue24107] Add support for retrieving the certificate chain In-Reply-To: <1430502325.36.0.624144757291.issue24107@psf.upfronthosting.co.za> Message-ID: <1430502632.37.0.495481518768.issue24107@psf.upfronthosting.co.za> Christian Heimes added the comment: I have an experimental branch that adds the feature and also exposes the subject public key information. https://github.com/tiran/cpython/tree/feature/x509cert ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 19:51:30 2015 From: report at bugs.python.org (Geoffrey Spear) Date: Fri, 01 May 2015 17:51:30 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430502690.9.0.486766799126.issue24085@psf.upfronthosting.co.za> Changes by Geoffrey Spear : ---------- components: +Interpreter Core nosy: +geoffreyspear type: -> resource usage versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 19:55:49 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 01 May 2015 17:55:49 +0000 Subject: [issue24106] Messed up indentation makes undesired piece of code being run! In-Reply-To: <1430500547.87.0.88978573823.issue24106@psf.upfronthosting.co.za> Message-ID: <1430502949.18.0.43529285367.issue24106@psf.upfronthosting.co.za> Eric V. Smith added the comment: I think David meant the "else" clause on a "for" statement: https://docs.python.org/2/reference/compound_stmts.html#the-for-statement ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 19:59:39 2015 From: report at bugs.python.org (Charles F. Bearden) Date: Fri, 01 May 2015 17:59:39 +0000 Subject: [issue13044] pdb throws AttributeError at end of debugging session In-Reply-To: <1316968582.76.0.94343164649.issue13044@psf.upfronthosting.co.za> Message-ID: <1430503179.4.0.808726135618.issue13044@psf.upfronthosting.co.za> Charles F. Bearden added the comment: I can reproduce this bug on Ubuntu 14.04.2 LTS with Python 2.7.6 using akl's debug.py. ---------- nosy: +cfbearden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 20:11:54 2015 From: report at bugs.python.org (Ian Cordasco) Date: Fri, 01 May 2015 18:11:54 +0000 Subject: [issue24107] Add support for retrieving the certificate chain In-Reply-To: <1430502325.36.0.624144757291.issue24107@psf.upfronthosting.co.za> Message-ID: <1430503914.93.0.104308600909.issue24107@psf.upfronthosting.co.za> Changes by Ian Cordasco : ---------- nosy: +icordasc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 20:13:18 2015 From: report at bugs.python.org (Charles F. Bearden) Date: Fri, 01 May 2015 18:13:18 +0000 Subject: [issue13044] pdb throws AttributeError at end of debugging session In-Reply-To: <1316968582.76.0.94343164649.issue13044@psf.upfronthosting.co.za> Message-ID: <1430503998.83.0.746517577842.issue13044@psf.upfronthosting.co.za> Charles F. Bearden added the comment: One further observation: the exception is thrown only if a breakpoint (apart from the call to pdb.set_trace) is set. If no breakpoint is set, the exception is not raised. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 21:36:55 2015 From: report at bugs.python.org (Christophe BAL) Date: Fri, 01 May 2015 19:36:55 +0000 Subject: [issue24108] fnmatch.translate('*.txt') fails Message-ID: <1430509015.84.0.479562940364.issue24108@psf.upfronthosting.co.za> New submission from Christophe BAL: Hello. I find the following bug on Python 3.4. >>> import fnmatch, re >>> regex = fnmatch.translate('*.txt') >>> regex '.*\\.txt\\Z(?ms)' The string regex should be '.*\\.txt$'. ---------- components: asyncio messages: 242346 nosy: gvanrossum, haypo, projetmbc, yselivanov priority: normal severity: normal status: open title: fnmatch.translate('*.txt') fails versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 21:38:50 2015 From: report at bugs.python.org (Keith Gray) Date: Fri, 01 May 2015 19:38:50 +0000 Subject: [issue24109] Documentation for difflib uses optparse Message-ID: <1430509130.15.0.798081297108.issue24109@psf.upfronthosting.co.za> New submission from Keith Gray: The documentation for optparse states it has been deprecated in favor of argparse since 2.7. However, the library documentation for difflib still uses optparse in the example. https://docs.python.org/2/library/difflib.html#a-command-line-interface-to-difflib https://docs.python.org/3.5/library/difflib.html#a-command-line-interface-to-difflib I am willing to update the documentation if there is agreement that it is needed. ---------- assignee: docs at python components: Documentation messages: 242347 nosy: docs at python, idahogray priority: normal severity: normal status: open title: Documentation for difflib uses optparse 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 May 1 21:42:47 2015 From: report at bugs.python.org (Merlijn van Deen) Date: Fri, 01 May 2015 19:42:47 +0000 Subject: [issue24108] fnmatch.translate('*.txt') fails In-Reply-To: <1430509015.84.0.479562940364.issue24108@psf.upfronthosting.co.za> Message-ID: <1430509367.12.0.130720637774.issue24108@psf.upfronthosting.co.za> Merlijn van Deen added the comment: As far as I can see, the regex is correct: \Z Matches only at the end of the string. (?iLmsux) The group matches the empty string; the letters set the corresponding flags: (...) - re.M (multi-line), - re.S (dot matches all) See https://docs.python.org/3.4/library/re.html Do you have an example where the regex does not match a file it should match (or matches a file it shouldn't)? ---------- nosy: +valhallasw _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 21:52:22 2015 From: report at bugs.python.org (Christophe BAL) Date: Fri, 01 May 2015 19:52:22 +0000 Subject: [issue24108] fnmatch.translate('*.txt') fails In-Reply-To: <1430509367.12.0.130720637774.issue24108@psf.upfronthosting.co.za> Message-ID: Christophe BAL added the comment: Ok. But in that case, the official documentation should be updated because it saids that string regex is *'.*\\.txt\\Z(?ms)'* and not *'.*\\.txt$'*. On the other hand, using this writing seems a bit strange. The 2nd one should do the job. *Christophe BAL* *Enseignant de math?matiques en Lyc?e **et d?veloppeur Python amateur* *---* *French math teacher in a "Lyc?e" **and **Python **amateur developer* 2015-05-01 21:42 GMT+02:00 Merlijn van Deen : > > Merlijn van Deen added the comment: > > As far as I can see, the regex is correct: > > \Z > Matches only at the end of the string. > > (?iLmsux) > The group matches the empty string; the letters set the corresponding > flags: (...) > - re.M (multi-line), > - re.S (dot matches all) > > See https://docs.python.org/3.4/library/re.html > > Do you have an example where the regex does not match a file it should > match (or matches a file it shouldn't)? > > ---------- > nosy: +valhallasw > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 21:54:12 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 01 May 2015 19:54:12 +0000 Subject: [issue24108] fnmatch.translate('*.txt') fails In-Reply-To: <1430509015.84.0.479562940364.issue24108@psf.upfronthosting.co.za> Message-ID: <1430510052.04.0.0803777594972.issue24108@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: -yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 22:16:46 2015 From: report at bugs.python.org (Merlijn van Deen) Date: Fri, 01 May 2015 20:16:46 +0000 Subject: [issue24108] fnmatch.translate('*.txt') fails In-Reply-To: <1430509015.84.0.479562940364.issue24108@psf.upfronthosting.co.za> Message-ID: <1430511406.97.0.334570684006.issue24108@psf.upfronthosting.co.za> Merlijn van Deen added the comment: They are subtly different; the new regex also matches filenames with newlines, the old one doesn't (see Issue #6665 [1]). Patch (although crazily minor) attached. With some fuzz, it applies on everything from 2.6..default. [1] https://bugs.python.org/issue6665 ---------- assignee: -> docs at python components: +Documentation -asyncio keywords: +patch nosy: +docs at python Added file: http://bugs.python.org/file39261/default.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 22:32:11 2015 From: report at bugs.python.org (Buck Evan) Date: Fri, 01 May 2015 20:32:11 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430512331.2.0.096588586186.issue24085@psf.upfronthosting.co.za> Buck Evan added the comment: New data: The memory consumption seems to be in the compiler rather than the marshaller: ``` $ PYTHONDONTWRITEBYTECODE=1 python -c 'import repro' 16032 $ PYTHONDONTWRITEBYTECODE=1 python -c 'import repro' 16032 $ PYTHONDONTWRITEBYTECODE=1 python -c 'import repro' 16032 $ python -c 'import repro' 16032 $ PYTHONDONTWRITEBYTECODE=1 python -c 'import repro' 8984 $ PYTHONDONTWRITEBYTECODE=1 python -c 'import repro' 8984 $ PYTHONDONTWRITEBYTECODE=1 python -c 'import repro' 8984 ``` We were trying to use PYTHONDONTWRITEBYTECODE as a workaround to this issue, but it didn't help us because of this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 22:37:01 2015 From: report at bugs.python.org (David D. Riddle) Date: Fri, 01 May 2015 20:37:01 +0000 Subject: [issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x) In-Reply-To: <1429893933.08.0.150501464744.issue24054@psf.upfronthosting.co.za> Message-ID: <1430512621.93.0.853490735724.issue24054@psf.upfronthosting.co.za> David D. Riddle added the comment: I have made the changes you suggested. Please look at lines 87-97. I am not certain if that is correct behavior. I was surprised that a SyntaxError is thrown in addition to the UnicodeDecodeError when linecache.getlines takes a file with bad unicode. Please tell me if this or other parts of the patch need work. ---------- Added file: http://bugs.python.org/file39262/new.mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 22:58:11 2015 From: report at bugs.python.org (Christophe BAL) Date: Fri, 01 May 2015 20:58:11 +0000 Subject: [issue24108] fnmatch.translate('*.txt') fails In-Reply-To: <1430511406.97.0.334570684006.issue24108@psf.upfronthosting.co.za> Message-ID: Christophe BAL added the comment: You're totally wrong and I am wrong. There is still the tiny problem of the documentation. Thanks for all. *Christophe BAL* *Enseignant de math?matiques en Lyc?e **et d?veloppeur Python amateur* *---* *French math teacher in a "Lyc?e" **and **Python **amateur developer* 2015-05-01 22:16 GMT+02:00 Merlijn van Deen : > > Merlijn van Deen added the comment: > > They are subtly different; the new regex also matches filenames with > newlines, the old one doesn't (see Issue #6665 [1]). > > Patch (although crazily minor) attached. With some fuzz, it applies on > everything from 2.6..default. > > [1] https://bugs.python.org/issue6665 > > ---------- > assignee: -> docs at python > components: +Documentation -asyncio > keywords: +patch > nosy: +docs at python > Added file: http://bugs.python.org/file39261/default.diff > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 23:04:12 2015 From: report at bugs.python.org (Christophe BAL) Date: Fri, 01 May 2015 21:04:12 +0000 Subject: [issue24108] fnmatch.translate('*.txt') fails In-Reply-To: Message-ID: Christophe BAL added the comment: Oups, sorry I want to say that you are totally RIGHT, and I am definitely WRONG. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 23:14:29 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 May 2015 21:14:29 +0000 Subject: [issue24108] fnmatch.translate('*.txt') fails In-Reply-To: <1430509015.84.0.479562940364.issue24108@psf.upfronthosting.co.za> Message-ID: <1430514869.97.0.140016646179.issue24108@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 23:30:03 2015 From: report at bugs.python.org (July Tikhonov) Date: Fri, 01 May 2015 21:30:03 +0000 Subject: [issue24110] zipfile.ZipFile.write() does not accept bytes arcname Message-ID: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za> New submission from July Tikhonov: In documentation of zipfile.ZipFile.write() there is following notice: "There is no official file name encoding for ZIP files. If you have unicode file names, you must convert them to byte strings in your desired encoding before passing them to write()." I understand it as that 'arcname' argument to write() shouldn't be of type str, but rather bytes. But it is str that works, and bytes that does not: $ ./python Python 3.5.0a4+ (default:6f6e78931875, May 1 2015, 23:18:40) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import zipfile >>> zf = zipfile.ZipFile('foo.zip', 'w') >>> zf.write('python', 'a') >>> zf.write('python', b'b') Traceback (most recent call last): File "", line 1, in File "/home/july/source/python/Lib/zipfile.py", line 1442, in write zinfo = ZipInfo(arcname, date_time) File "/home/july/source/python/Lib/zipfile.py", line 322, in __init__ null_byte = filename.find(chr(0)) TypeError: a bytes-like object is required, not 'str' (ZipInfo ostensibly attempts to find a zero byte in the filename, but searches instead for a unicode character chr(0). There are several other places in ZipInfo class that assume filename being str rather than bytes.) I consider this a documentation issue: the notice is misleading. Although maybe there is someone who wants to fix the behavior of ZipInfo to allow bytes filename. ---------- assignee: docs at python components: Documentation messages: 242355 nosy: docs at python, july priority: normal severity: normal status: open title: zipfile.ZipFile.write() does not accept bytes arcname type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 23:31:23 2015 From: report at bugs.python.org (July Tikhonov) Date: Fri, 01 May 2015 21:31:23 +0000 Subject: [issue24110] zipfile.ZipFile.write() does not accept bytes arcname In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za> Message-ID: <1430515883.38.0.887727337997.issue24110@psf.upfronthosting.co.za> Changes by July Tikhonov : ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 1 23:41:52 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Fri, 01 May 2015 21:41:52 +0000 Subject: [issue24110] zipfile.ZipFile.write() does not accept bytes arcname In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za> Message-ID: St?phane Wirtel added the comment: This documentation is correct for python2 but maybe not for python3. To check. ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 01:46:19 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 01 May 2015 23:46:19 +0000 Subject: [issue24076] sum() several times slower on Python 3 In-Reply-To: <1430332618.4.0.236828536627.issue24076@psf.upfronthosting.co.za> Message-ID: <1430523979.74.0.87033017927.issue24076@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Antoine asked: > If someone has actual code that suffers from this, it would be good to know about it. You might have missed ?ukasz' earlier comment: "In this particular case, there's internal usage at Twitter that unearthed it. The example is just a simplified repro." ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 01:49:42 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 01 May 2015 23:49:42 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430524182.55.0.905504628175.issue24085@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 02:00:49 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 02 May 2015 00:00:49 +0000 Subject: [issue24069] Option to delete obsolete bytecode files In-Reply-To: <1430239459.0.0.172566043873.issue24069@psf.upfronthosting.co.za> Message-ID: <1430524849.53.0.2082125223.issue24069@psf.upfronthosting.co.za> Steven D'Aprano added the comment: This would be risky, as byte-code only libraries do exist. I think that deleting orphaned .pyc files from inside the __pycache__ directory is safe, but deleting orphaned .pyc files outside of that risks deleting legitimate byte-code libraries which are in use. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 02:13:52 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 02 May 2015 00:13:52 +0000 Subject: [issue24052] sys.exit(code) returns "success" to the OS for some nonzero values of code In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za> Message-ID: <1430525632.61.0.933338130622.issue24052@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Maybe I've misunderstood RDM's comment, but if sys.exit(code) starts automatically printing the return code, that's going to break a lot of scripts. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 02:21:26 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 02 May 2015 00:21:26 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1430526086.14.0.0378078320709.issue24056@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Describing generator functions as such is a great idea. But how about Marking closure functions as such is a bit more subtle. However, there ia a real point that closure functions have a hidden input. If it is mutated or rebound, the function will not be deterministic with respect to its overt input arguments. Closure functions are similar to methods in this respect. Await functions (Guido's name choice as of today), if the PEP is approved, will also need to be identified as such. I propose a uniform format of no prefix, a single prefic or a (tuple) of prefixes. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 02:46:05 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 00:46:05 +0000 Subject: [issue24066] send_message should take all the addresses in the To: header into account In-Reply-To: <1430169972.74.0.338342255395.issue24066@psf.upfronthosting.co.za> Message-ID: <1430527565.17.0.681209498221.issue24066@psf.upfronthosting.co.za> R. David Murray added the comment: Can you write a test that shows the failure? There is an existing test that demonstrates sending to multiple addresses (testSendMessageWithAddresses), so you must have found an edge case that isn't tested. (Either that, or the existing test is broken.) ---------- stage: patch review -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 03:00:15 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 01:00:15 +0000 Subject: [issue24068] statistics module - incorrect results with boolean input In-Reply-To: <1430211206.61.0.689765465928.issue24068@psf.upfronthosting.co.za> Message-ID: <1430528415.93.0.538053746821.issue24068@psf.upfronthosting.co.za> R. David Murray added the comment: I wonder if it would be better to reject Bool data in this context? Bool is only a numeric type for historical reasons. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 03:20:27 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 01:20:27 +0000 Subject: [issue24071] Python 2.7.8, 2.7.9 re.MULTILINE failure In-Reply-To: <1430249128.2.0.387298041566.issue24071@psf.upfronthosting.co.za> Message-ID: <1430529627.36.0.492770390132.issue24071@psf.upfronthosting.co.za> R. David Murray added the comment: It is, however, frequently reported as a bug, if that makes you feel any better :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 03:25:20 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 02 May 2015 01:25:20 +0000 Subject: [issue24090] Add a "copy vale to clipboard" option to the debugger In-Reply-To: <1430479248.08.0.880712455727.issue24090@psf.upfronthosting.co.za> Message-ID: <1430529920.93.0.591633506265.issue24090@psf.upfronthosting.co.za> Terry J. Reedy added the comment: As presented, this idea seems out of scope for Idle. First, Idle is concerned with editing code, submitting it for execution, and displaying stdout and seterr output from the execution. Idle normally knows nothing about name bindings created by user code in the user process. The code for menu commands is executed in the Idle process. The code you displayed would have to be executed in the user process as part of user code. Second, your request is for a very specific personal need. Running for i in range(1000): print('a'*100) in 3.4.3 does not make Shell sluggish for me. How much output, on what system, with what version, is a problem for you? However, selecting a 1000 line block -- which is at least as likely to be output (as above) as an output representation -- is not pleasant. A new Select Block option, active in Shell, would be generally useful. The selected block could then be copied. Deletion is not currently possible, but I might like to change that too. The debugger is an exception to Idle's normal ignorance of user code global and local namespaces. The debugger window (which needs upgrading) can display names and object representations of both namespaces. I do not know what it currently does with long representations (say 1000 chars or more), but they are clearly problematical and might best be truncated if not already. Once the debugger has already pulled a string representation into the Idle process. reusing the existing Copy (to clipboard) function should be fairly easy. ---------- nosy: +terry.reedy title: Add a "copy variable to clipboard" option to the edit menu -> Add a "copy vale to clipboard" option to the debugger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 03:25:38 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 02 May 2015 01:25:38 +0000 Subject: [issue24090] Add a "copy value to clipboard" option to the debugger In-Reply-To: <1430479248.08.0.880712455727.issue24090@psf.upfronthosting.co.za> Message-ID: <1430529938.21.0.759039201865.issue24090@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: Add a "copy vale to clipboard" option to the debugger -> Add a "copy value to clipboard" option to the debugger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 03:49:59 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 01:49:59 +0000 Subject: [issue24081] Obsolete caveat in reload() docs In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za> Message-ID: <1430531399.96.0.795876970956.issue24081@psf.upfronthosting.co.za> R. David Murray added the comment: This generally comes up in the context of a module importing another module, and *that* module fails to import. The first module is left in sys.modules as a stub. Try that experiment, I'm pretty sure that is still true. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 03:55:46 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 01:55:46 +0000 Subject: [issue24082] Obsolete note in argument parsing (c-api/arg.rst) In-Reply-To: <1430403570.61.0.800757161817.issue24082@psf.upfronthosting.co.za> Message-ID: <1430531746.18.0.96843573311.issue24082@psf.upfronthosting.co.za> R. David Murray added the comment: The note is still valid concerning the length. (Perhaps Victor should have deprected u instead of fixing it.) ---------- nosy: +haypo, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 03:57:25 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 01:57:25 +0000 Subject: [issue24052] sys.exit(code) returns "success" to the OS for some nonzero values of code In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za> Message-ID: <1430531845.79.0.496906877302.issue24052@psf.upfronthosting.co.za> R. David Murray added the comment: I meant when it is otherwise out of range. That is, treat it like any other object that can't be returned as the return code: print it. But only if it can't otherwise be used as the exit code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 04:08:49 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 02:08:49 +0000 Subject: [issue24060] Clearify necessities for logging with timestamps In-Reply-To: <1429996624.15.0.693068386122.issue24060@psf.upfronthosting.co.za> Message-ID: <1430532529.95.0.853929462797.issue24060@psf.upfronthosting.co.za> R. David Murray added the comment: Sounds good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 04:15:04 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 02:15:04 +0000 Subject: [issue24088] yield expression confusion In-Reply-To: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za> Message-ID: <1430532904.05.0.102413823653.issue24088@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, and it is not using generator function in two different ways: it is literally the case that calling the generator function returns a generator object, which in turn controls the execution of the generator function. The text then goes on to explain how this works. I think it would make sense to change "controls execution of a generator function" to "controls execution of the generator function", but I can't think of any other change that would make things clearer. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 04:20:27 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 02 May 2015 02:20:27 +0000 Subject: [issue24068] statistics module - incorrect results with boolean input In-Reply-To: <1430211206.61.0.689765465928.issue24068@psf.upfronthosting.co.za> Message-ID: <1430533227.39.0.959069293647.issue24068@psf.upfronthosting.co.za> Steven D'Aprano added the comment: The patch seems simple and straightforward enough. It just needs some tests, and a Round Tuit. ---------- assignee: -> steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 04:20:49 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 02 May 2015 02:20:49 +0000 Subject: [issue24068] statistics module - incorrect results with boolean input In-Reply-To: <1430211206.61.0.689765465928.issue24068@psf.upfronthosting.co.za> Message-ID: <1430533249.41.0.211188623676.issue24068@psf.upfronthosting.co.za> Changes by Steven D'Aprano : ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 04:21:37 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 02:21:37 +0000 Subject: [issue24106] Messed up indentation makes undesired piece of code being run! In-Reply-To: <1430500547.87.0.88978573823.issue24106@psf.upfronthosting.co.za> Message-ID: <1430533297.21.0.184900547355.issue24106@psf.upfronthosting.co.za> R. David Murray added the comment: Oops. Yes, that's what I meant :) Thanks for the correction and link, Eric. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 04:28:00 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 02:28:00 +0000 Subject: [issue24109] Documentation for difflib uses optparse In-Reply-To: <1430509130.15.0.798081297108.issue24109@psf.upfronthosting.co.za> Message-ID: <1430533680.37.0.831595844165.issue24109@psf.upfronthosting.co.za> R. David Murray added the comment: It wouldn't be a bad idea. Of course, you'd also need to update Tools/script/diff.py. Tests should be added as well, since we have started adding tests for things in Tools. The tests should be written first, to make sure that the behavior of 'diff' does not change, since I know there are people actively using it (on Windows). I think it would also be a good idea to change the docs so that the actual diff script is embedded in the docs (sphinx has a directive for doing that), rather that duplicating the code. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 04:36:20 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 02:36:20 +0000 Subject: [issue24110] zipfile.ZipFile.write() does not accept bytes arcname In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za> Message-ID: <1430534180.83.0.474931850236.issue24110@psf.upfronthosting.co.za> R. David Murray added the comment: We should either make it work with byte filenames, or allow control of the filename encoding. See also issue 20329. Unfortunately that part is probably a new feature. In the meantime the docs should be fixed: I believe we automatically encode the filename using the default zip filename codec (but someone should check). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:10:02 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 02 May 2015 04:10:02 +0000 Subject: [issue24101] Use after free in siftup In-Reply-To: <1430489575.51.0.442803283693.issue24101@psf.upfronthosting.co.za> Message-ID: <1430539802.85.0.782057618225.issue24101@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:30:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:30:28 +0000 Subject: [issue24110] zipfile.ZipFile.write() does not accept bytes arcname In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za> Message-ID: <1430541028.26.0.88236344501.issue24110@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Indeed, the note is outdated and incorrect. First, general unicode filename are allowed. They are encoded with UTF-8 internally. Second, currently there is no way to create an entry without encoding the filename to UTF-8 (if it is not ASCII-only). So you can't create ZIP file with arbitrary encoding (e.g. cp866) for old DOS/Windows unzippers. Adding support of bytes filenames is different issue (issue10757). ---------- nosy: +serhiy.storchaka stage: -> needs patch versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:42:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:42:21 +0000 Subject: [issue24052] sys.exit(code) returns "success" to the OS for some nonzero values of code In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za> Message-ID: <1430541741.35.0.716349881588.issue24052@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Python 2 prints large return code only by accident, because it have unsupported type (sys.exit supports only int, not long). This is considered as a bug (issue14376) because small return codes of type long (0L or 1L) are printed too. I don't think this issue need other fix besides a note that the program can return "success" for some non-zero values. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:46:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:46:00 +0000 Subject: [issue24092] Use after free in Element.extend (2) In-Reply-To: <1430488625.39.0.290044967832.issue24092@psf.upfronthosting.co.za> Message-ID: <1430541960.0.0.803145138007.issue24092@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +eli.bendersky, scoder, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:46:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:46:44 +0000 Subject: [issue24093] Use after free in Element.remove In-Reply-To: <1430488688.91.0.916599584274.issue24093@psf.upfronthosting.co.za> Message-ID: <1430542004.52.0.550107629094.issue24093@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +eli.bendersky, scoder, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:47:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:47:20 +0000 Subject: [issue24094] Use after free during json encoding (PyType_IsSubtype) In-Reply-To: <1430488858.91.0.915527926564.issue24094@psf.upfronthosting.co.za> Message-ID: <1430542040.36.0.294202163237.issue24094@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +ezio.melotti, pitrou, rhettinger, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:47:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:47:46 +0000 Subject: [issue24095] Use after free during json encoding a dict (2) In-Reply-To: <1430488935.49.0.703786529764.issue24095@psf.upfronthosting.co.za> Message-ID: <1430542066.31.0.656268161458.issue24095@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +ezio.melotti, pitrou, rhettinger, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:48:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:48:34 +0000 Subject: [issue24096] Use after free in get_filter In-Reply-To: <1430489003.72.0.86735316643.issue24096@psf.upfronthosting.co.za> Message-ID: <1430542114.19.0.412338579.issue24096@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +ezio.melotti, pitrou, rhettinger, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:49:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:49:13 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <1430542153.36.0.938997356583.issue24097@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +alexandre.vassalotti, pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:49:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:49:57 +0000 Subject: [issue24098] Multiple use after frees in obj2ast_* methods In-Reply-To: <1430489429.65.0.587999729774.issue24098@psf.upfronthosting.co.za> Message-ID: <1430542197.82.0.270473227523.issue24098@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:50:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:50:28 +0000 Subject: [issue24099] Use after free in siftdown (1) In-Reply-To: <1430489480.16.0.0840319770251.issue24099@psf.upfronthosting.co.za> Message-ID: <1430542228.87.0.253126308154.issue24099@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:50:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:50:40 +0000 Subject: [issue24100] Use after free in siftdown (2) In-Reply-To: <1430489541.93.0.209728480757.issue24100@psf.upfronthosting.co.za> Message-ID: <1430542240.35.0.865339470047.issue24100@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:51:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:51:10 +0000 Subject: [issue24100] Use after free in siftdown (2) In-Reply-To: <1430489541.93.0.209728480757.issue24100@psf.upfronthosting.co.za> Message-ID: <1430542270.98.0.719083555786.issue24100@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:51:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:51:26 +0000 Subject: [issue24101] Use after free in siftup In-Reply-To: <1430489575.51.0.442803283693.issue24101@psf.upfronthosting.co.za> Message-ID: <1430542286.84.0.242404577024.issue24101@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:52:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:52:15 +0000 Subject: [issue24102] Multiple type confusions in unicode error handlers In-Reply-To: <1430489646.71.0.827069473585.issue24102@psf.upfronthosting.co.za> Message-ID: <1430542335.45.0.397874958097.issue24102@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Interpreter Core, Unicode nosy: +doerwalter, ezio.melotti, haypo, lemburg, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:53:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:53:13 +0000 Subject: [issue24103] Use after free in xmlparser_setevents (1) In-Reply-To: <1430489715.59.0.155743746692.issue24103@psf.upfronthosting.co.za> Message-ID: <1430542393.61.0.950433747317.issue24103@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +XML nosy: +christian.heimes, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:53:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:53:31 +0000 Subject: [issue24104] Use after free in xmlparser_setevents (2) In-Reply-To: <1430489742.91.0.610954411273.issue24104@psf.upfronthosting.co.za> Message-ID: <1430542411.82.0.0873539148404.issue24104@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +XML nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:54:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:54:02 +0000 Subject: [issue24105] Use after free during json encoding a dict (3) In-Reply-To: <1430489990.8.0.117941995919.issue24105@psf.upfronthosting.co.za> Message-ID: <1430542442.73.0.104015106925.issue24105@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Extension Modules nosy: +ezio.melotti, pitrou, rhettinger, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 06:59:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 04:59:52 +0000 Subject: [issue24082] Obsolete note in argument parsing (c-api/arg.rst) In-Reply-To: <1430403570.61.0.800757161817.issue24082@psf.upfronthosting.co.za> Message-ID: <1430542792.72.0.905441479543.issue24082@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: About wording see also issue23088. About possible deprecating see issue24009. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 07:08:06 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 02 May 2015 05:08:06 +0000 Subject: [issue24105] Use after free during json encoding a dict (3) In-Reply-To: <1430489990.8.0.117941995919.issue24105@psf.upfronthosting.co.za> Message-ID: <1430543286.14.0.0522537809828.issue24105@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Please don't file a multiple tracker items for the same module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 07:16:58 2015 From: report at bugs.python.org (paul) Date: Sat, 02 May 2015 05:16:58 +0000 Subject: [issue24105] Use after free during json encoding a dict (3) In-Reply-To: <1430489990.8.0.117941995919.issue24105@psf.upfronthosting.co.za> Message-ID: <1430543818.14.0.277561035714.issue24105@psf.upfronthosting.co.za> paul added the comment: You want multiple bugs in the same module grouped in one issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 07:29:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 05:29:37 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430544577.47.0.31900336545.issue24085@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The use of PYTHONDONTWRITEBYTECODE is not a workaround because it makes your to have memory overhead unconditionally. The compiler needs more momory than require compiled data itself. If this is an issue, I suggest to use different representation for the data: JSON, pickle, or just marshal. Also it may be faster. Try also CSV or custom simple format if it is appropriate. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 07:35:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 05:35:39 +0000 Subject: [issue24105] Use after free during json encoding a dict (3) In-Reply-To: <1430543818.14.0.277561035714.issue24105@psf.upfronthosting.co.za> Message-ID: <3385254.4OV3JcnmVY@raxxla> Serhiy Storchaka added the comment: Yes, if they are related. I didn't look at the code close, but at first glance all your recently opened issues look related (may be I wrong). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 08:19:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 06:19:35 +0000 Subject: [issue23572] functools.singledispatch fails when "not BaseClass" is True In-Reply-To: <1425385029.2.0.304023107943.issue23572@psf.upfronthosting.co.za> Message-ID: <1430547575.15.0.624368359879.issue23572@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: An example is Enum. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 08:59:50 2015 From: report at bugs.python.org (Antony Lee) Date: Sat, 02 May 2015 06:59:50 +0000 Subject: [issue24111] Valgrind suppression file should be updated Message-ID: <1430549990.4.0.860597056405.issue24111@psf.upfronthosting.co.za> New submission from Antony Lee: Since PEP445, the suppressions should target _PyObject_{Free,Realloc} instead of PyObject_{Free,Realloc}. ---------- messages: 242382 nosy: Antony.Lee priority: normal severity: normal status: open title: Valgrind suppression file should be updated versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 09:34:36 2015 From: report at bugs.python.org (Petr Viktorin) Date: Sat, 02 May 2015 07:34:36 +0000 Subject: [issue24081] Obsolete caveat in reload() docs In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za> Message-ID: <1430552076.06.0.469206723616.issue24081@psf.upfronthosting.co.za> Petr Viktorin added the comment: Not true (on 3.3 & 2.7). >>> import sys >>> import x Traceback (most recent call last): File "", line 1, in File "/tmp/x.py", line 1, in import y File "/tmp/y.py", line 1, in 1/0 ZeroDivisionError: division by zero >>> sys.modules['x'] Traceback (most recent call last): File "", line 1, in KeyError: 'x' >>> sys.modules['y'] Traceback (most recent call last): File "", line 1, in KeyError: 'y' For 3.4, PEP 451 explicitly specifies ``del sys.modules[spec.name]`` if ``loader.exec_module`` fails [0]. [0] https://www.python.org/dev/peps/pep-0451/#how-loading-will-work ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 10:07:58 2015 From: report at bugs.python.org (paul) Date: Sat, 02 May 2015 08:07:58 +0000 Subject: [issue24105] Use after free during json encoding a dict (3) In-Reply-To: <1430489990.8.0.117941995919.issue24105@psf.upfronthosting.co.za> Message-ID: <1430554078.72.0.548093477389.issue24105@psf.upfronthosting.co.za> paul added the comment: @Serhiy: Not all of my bugs are in the same module. Sure, I will group them by module in the future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 10:11:38 2015 From: report at bugs.python.org (Kirill Elagin) Date: Sat, 02 May 2015 08:11:38 +0000 Subject: [issue24066] send_message should take all the addresses in the To: header into account In-Reply-To: <1430169972.74.0.338342255395.issue24066@psf.upfronthosting.co.za> Message-ID: <1430554298.54.0.534248095198.issue24066@psf.upfronthosting.co.za> Kirill Elagin added the comment: Ah, I?m so dumb. Of course the tests work as there are multiple addresses but still just one field. Here is the test for multiple fields. ---------- Added file: http://bugs.python.org/file39263/multiple_fields_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 10:47:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 May 2015 08:47:46 +0000 Subject: [issue24060] Clearify necessities for logging with timestamps In-Reply-To: <1429996624.15.0.693068386122.issue24060@psf.upfronthosting.co.za> Message-ID: <20150502084743.11922.69219@psf.io> Roundup Robot added the comment: New changeset 5ce760e2cc59 by Vinay Sajip in branch '2.7': Issue #24060: Made logging.Formatter documentation a little clearer. https://hg.python.org/cpython/rev/5ce760e2cc59 New changeset 88c141233d1e by Vinay Sajip in branch '3.4': Issue #24060: Made logging.Formatter documentation a little clearer. https://hg.python.org/cpython/rev/88c141233d1e New changeset 1c72e9c1b3b4 by Vinay Sajip in branch 'default': Closes #24060: Merged documentation update from 3.4. https://hg.python.org/cpython/rev/1c72e9c1b3b4 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 12:19:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 10:19:43 +0000 Subject: [issue24105] Use after free during json encoding a dict (3) In-Reply-To: <1430489990.8.0.117941995919.issue24105@psf.upfronthosting.co.za> Message-ID: <1430561983.03.0.792765236946.issue24105@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch fixes three related issues: issue24094, issue24095 and issue24105. ---------- assignee: -> serhiy.storchaka keywords: +patch stage: -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file39264/json_encode_mutated_dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 12:29:18 2015 From: report at bugs.python.org (Bob Stein) Date: Sat, 02 May 2015 10:29:18 +0000 Subject: [issue24112] %b does not work, as a binary output formatter Message-ID: <1430562558.49.0.749759966096.issue24112@psf.upfronthosting.co.za> New submission from Bob Stein: `"%b"%42` produces a ValueError exception instead of outputting '101010' Details here: http://stackoverflow.com/a/29997703/673991 ---------- messages: 242388 nosy: BobStein priority: normal severity: normal status: open title: %b does not work, as a binary output formatter type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 12:57:22 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 02 May 2015 10:57:22 +0000 Subject: [issue24112] %b does not work, as a binary output formatter In-Reply-To: <1430562558.49.0.749759966096.issue24112@psf.upfronthosting.co.za> Message-ID: <1430564242.52.0.192670747044.issue24112@psf.upfronthosting.co.za> Steven D'Aprano added the comment: This is not a bug, since %b is not supported in Python 2, only in Python 3: https://docs.python.org/2/library/stdtypes.html#string-formatting-operations No new features will be added to 2.7, so if you need %b you can use Python 3, or in Python 2.7 you can use the newer string format method instead: py> "{:b}".format(42) '101010' ---------- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 13:04:13 2015 From: report at bugs.python.org (Bob Stein) Date: Sat, 02 May 2015 11:04:13 +0000 Subject: [issue24112] %b does not work, as a binary output formatter In-Reply-To: <1430562558.49.0.749759966096.issue24112@psf.upfronthosting.co.za> Message-ID: <1430564653.3.0.95275717104.issue24112@psf.upfronthosting.co.za> Bob Stein added the comment: Ah, you're right, my mistake. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 13:42:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 11:42:23 +0000 Subject: [issue24102] Multiple type confusions in unicode error handlers In-Reply-To: <1430489646.71.0.827069473585.issue24102@psf.upfronthosting.co.za> Message-ID: <1430566943.66.0.184436382763.issue24102@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is simpler reproducer: import codecs class X(str): __class__ = UnicodeEncodeError codecs.ignore_errors(X()) The problem is that PyObject_IsInstance() is fooled by custom __class__, but then builtin error handlers handle error object as having UnicodeEncodeError layout, while it doesn't. Here is a patch that fixes the issue by using PyObject_IsSubclass() of exc->ob_type instead of PyObject_IsInstance(). ---------- assignee: -> serhiy.storchaka stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 13:43:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 11:43:19 +0000 Subject: [issue24102] Multiple type confusions in unicode error handlers In-Reply-To: <1430489646.71.0.827069473585.issue24102@psf.upfronthosting.co.za> Message-ID: <1430566999.85.0.901706639127.issue24102@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file39265/codecs_error_handlers_issubclass.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 14:31:29 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 12:31:29 +0000 Subject: [issue24110] zipfile.ZipFile.write() does not accept bytes arcname In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za> Message-ID: <1430569889.79.0.904967743329.issue24110@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, I *thought* there was an issue for that, but I didn't find it when I searched. So this is just a doc issue to fix the docs to reflect current reality. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 14:37:16 2015 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Sat, 02 May 2015 12:37:16 +0000 Subject: [issue24102] Multiple type confusions in unicode error handlers In-Reply-To: <1430489646.71.0.827069473585.issue24102@psf.upfronthosting.co.za> Message-ID: <1430570236.05.0.446518249463.issue24102@psf.upfronthosting.co.za> Walter D?rwald added the comment: The patch does indeed fix the segmentation fault. However the exception message looks confusing: TypeError: don't know how to handle UnicodeEncodeError in error callback ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 14:39:56 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 12:39:56 +0000 Subject: [issue24066] send_message should take all the addresses in the To: header into account In-Reply-To: <1430169972.74.0.338342255395.issue24066@psf.upfronthosting.co.za> Message-ID: <1430570396.21.0.5039124938.issue24066@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, but that is intentional. Those fields can only appear once per message, per the RFC. The new email API will raise an error if you attempt to add them more than once. Perhaps we should raise an error instead of ignoring the duplicates, given that we are actively inspecting those headers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 14:45:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 12:45:18 +0000 Subject: [issue24102] Multiple type confusions in unicode error handlers In-Reply-To: <1430489646.71.0.827069473585.issue24102@psf.upfronthosting.co.za> Message-ID: <1430570718.64.0.456222360487.issue24102@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that makes error message consistent with type checking. ---------- Added file: http://bugs.python.org/file39266/codecs_error_handlers_issubclass_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 15:04:06 2015 From: report at bugs.python.org (Kirill Elagin) Date: Sat, 02 May 2015 13:04:06 +0000 Subject: [issue24066] send_message should take all the addresses in the To: header into account In-Reply-To: <1430169972.74.0.338342255395.issue24066@psf.upfronthosting.co.za> Message-ID: <1430571846.65.0.158981655145.issue24066@psf.upfronthosting.co.za> Kirill Elagin added the comment: Oh, I see now. It is a good idea to raise an error either in `send_message` or at the moment when a second `To`/`Cc`/`Bcc` header is added to the message. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 15:05:28 2015 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Sat, 02 May 2015 13:05:28 +0000 Subject: [issue24102] Multiple type confusions in unicode error handlers In-Reply-To: <1430489646.71.0.827069473585.issue24102@psf.upfronthosting.co.za> Message-ID: <1430571928.05.0.156980697959.issue24102@psf.upfronthosting.co.za> Walter D?rwald added the comment: Looks much better. However shouldn't: exc->ob_type->tp_name be: Py_TYPE(exc)->tp_name (although there are still many spots in the source that still use ob_type->tp_name) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 15:10:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 13:10:50 +0000 Subject: [issue24102] Multiple type confusions in unicode error handlers In-Reply-To: <1430489646.71.0.827069473585.issue24102@psf.upfronthosting.co.za> Message-ID: <1430572250.72.0.302332696667.issue24102@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Py_TYPE() is necessary when the argument is not of type PyObject* (e.g. PyUnicodeObject*). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 15:41:50 2015 From: report at bugs.python.org (Michael Smith) Date: Sat, 02 May 2015 13:41:50 +0000 Subject: [issue24113] shlex constructor unreachable code Message-ID: <1430574110.71.0.619526001392.issue24113@psf.upfronthosting.co.za> New submission from Michael Smith: In its __init__ method, shlex.shlex sets self.debug = 0. An `if self.debug:` statement follows shortly thereafter and without allowing the user to change self.debug. The code inside the if statement is unreachable. Users should either be permitted to set debug on via an optional __init__ parameter, or debug should be taken out of the initializer altogether. ---------- components: Library (Lib) messages: 242399 nosy: Michael.Smith priority: normal severity: normal status: open title: shlex constructor unreachable code 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 Sat May 2 15:44:00 2015 From: report at bugs.python.org (Michael Smith) Date: Sat, 02 May 2015 13:44:00 +0000 Subject: [issue24113] shlex constructor unreachable code In-Reply-To: <1430574110.71.0.619526001392.issue24113@psf.upfronthosting.co.za> Message-ID: <1430574240.12.0.596902741944.issue24113@psf.upfronthosting.co.za> Michael Smith added the comment: Hat tip abarnert on StackOverflow for digging in. http://stackoverflow.com/questions/29996208/putting-shlex-in-debug-mode This code was introduced in https://hg.python.org/cpython/rev/81a121d21340 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 17:03:15 2015 From: report at bugs.python.org (Kees Bos) Date: Sat, 02 May 2015 15:03:15 +0000 Subject: [issue24114] ctypes.utils uninitialized variable 'path' Message-ID: <1430578995.23.0.112303250331.issue24114@psf.upfronthosting.co.za> New submission from Kees Bos: In certain corner cases, the ctypes.util can raise an error for a uninitialized variable 'path' when with sunos5 the clre program exists, but fails to return valid output lines. (Also in 2.7.10rc0) ---------- components: ctypes files: ctypes.util-path.patch keywords: patch messages: 242401 nosy: kees priority: normal severity: normal status: open title: ctypes.utils uninitialized variable 'path' type: crash versions: Python 2.7 Added file: http://bugs.python.org/file39267/ctypes.util-path.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 17:21:24 2015 From: report at bugs.python.org (Keith Gray) Date: Sat, 02 May 2015 15:21:24 +0000 Subject: [issue24109] Documentation for difflib uses optparse In-Reply-To: <1430509130.15.0.798081297108.issue24109@psf.upfronthosting.co.za> Message-ID: <1430580084.26.0.188873183116.issue24109@psf.upfronthosting.co.za> Keith Gray added the comment: I took a look at Tools/scripts/diff.py and it looks like it got converted to use argparse 9 months ago. I think I should be able to just include that in the difflib documentation directly. My next question is which branches need to have this changed? Do I just make the documentation change to the default branch or do I need to change it in 2.7, 3.2, 3.3, and 3.4 as well? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 17:29:47 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 02 May 2015 15:29:47 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1430526086.14.0.0378078320709.issue24056@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: The main reason I suggest using the postfix parenthetical syntax is to make it clear that we're exposing "behavioural feature flags" for a single underlying type. A prefix syntax would make them look like distinct types, which would be misleading in a different way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 17:50:38 2015 From: report at bugs.python.org (Keith Gray) Date: Sat, 02 May 2015 15:50:38 +0000 Subject: [issue24109] Documentation for difflib uses optparse In-Reply-To: <1430509130.15.0.798081297108.issue24109@psf.upfronthosting.co.za> Message-ID: <1430581838.28.0.828848008871.issue24109@psf.upfronthosting.co.za> Keith Gray added the comment: Here is the patch. I have tested it against tip. Let me know if you need anything else. ---------- keywords: +patch Added file: http://bugs.python.org/file39268/issue-24109.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 18:46:22 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 16:46:22 +0000 Subject: [issue24109] Documentation for difflib uses optparse In-Reply-To: <1430509130.15.0.798081297108.issue24109@psf.upfronthosting.co.za> Message-ID: <1430585182.89.0.707415205292.issue24109@psf.upfronthosting.co.za> R. David Murray added the comment: Since the Tools script was only changed in 3.5 (I was looking at the wrong branch), I think the docs should only be changed for 3.5. ---------- stage: -> commit review versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 18:46:27 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 16:46:27 +0000 Subject: [issue24109] Documentation for difflib uses optparse In-Reply-To: <1430509130.15.0.798081297108.issue24109@psf.upfronthosting.co.za> Message-ID: <1430585187.05.0.721045593574.issue24109@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- versions: +Python 3.5 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 18:48:58 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 16:48:58 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1430585338.66.0.594894844841.issue24056@psf.upfronthosting.co.za> R. David Murray added the comment: Although I like the look of the repr Terry proposes better, I agree with Nick: it would imply that the types were distinct, which they are not. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 18:56:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 16:56:26 +0000 Subject: [issue24115] PyObject_IsInstance() and PyObject_IsSubclass() can fail Message-ID: <1430585786.54.0.583087529416.issue24115@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: PyObject_IsInstance() and PyObject_IsSubclass() cat return 0, 1, or -1. But some code use "if (PyObject_IsInstance(...))" or "if (!PyObject_IsInstance(...))". This should be fixed. ---------- assignee: serhiy.storchaka components: Extension Modules, Interpreter Core messages: 242407 nosy: serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: PyObject_IsInstance() and PyObject_IsSubclass() can fail type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 19:07:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 May 2015 17:07:44 +0000 Subject: [issue24099] Use after free in siftdown (1) In-Reply-To: <1430489480.16.0.0840319770251.issue24099@psf.upfronthosting.co.za> Message-ID: <20150502170741.7792.98795@psf.io> Roundup Robot added the comment: New changeset 813854f49f9d by Raymond Hettinger in branch '3.4': Issues #24099, #24100, and #24101: Fix free-after-use bug in heapq. https://hg.python.org/cpython/rev/813854f49f9d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 19:07:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 May 2015 17:07:44 +0000 Subject: [issue24100] Use after free in siftdown (2) In-Reply-To: <1430489541.93.0.209728480757.issue24100@psf.upfronthosting.co.za> Message-ID: <20150502170741.7792.20394@psf.io> Roundup Robot added the comment: New changeset 813854f49f9d by Raymond Hettinger in branch '3.4': Issues #24099, #24100, and #24101: Fix free-after-use bug in heapq. https://hg.python.org/cpython/rev/813854f49f9d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 19:07:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 May 2015 17:07:45 +0000 Subject: [issue24101] Use after free in siftup In-Reply-To: <1430489575.51.0.442803283693.issue24101@psf.upfronthosting.co.za> Message-ID: <20150502170741.7792.6140@psf.io> Roundup Robot added the comment: New changeset 813854f49f9d by Raymond Hettinger in branch '3.4': Issues #24099, #24100, and #24101: Fix free-after-use bug in heapq. https://hg.python.org/cpython/rev/813854f49f9d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 19:15:11 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 17:15:11 +0000 Subject: [issue24081] Obsolete caveat in reload() docs In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za> Message-ID: <1430586911.08.0.358907290196.issue24081@psf.upfronthosting.co.za> R. David Murray added the comment: OK, I can't reproduce it either, neither in python3 nor python2. Brett, is this left over from a long time ago? Heh. I just tried another experiment and got an interesting result: rdmurray at pydev:~/python/p34>cat temp1.py import temp2 foo = 1 rdmurray at pydev:~/python/p34>cat temp2.py import temp1 badval rdmurray at pydev:~/python/p34>./python Python 3.4.3+ (3.4:b53cfcfdfe47, May 2 2015, 12:51:46) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import temp2 Traceback (most recent call last): File "", line 1, in File "/home/rdmurray/python/p34/temp2.py", line 3, in badval NameError: name 'badval' is not defined >>> import sys >>> sorted(sys.modules.keys()) ['__main__', '_codecs', '_collections_abc', '_frozen_importlib', '_imp', '_io', '_sitebuiltins', '_stat', '_sysconfigdata', '_thread', '_warnings', '_weakref', '_weakrefset', 'abc', 'atexit', 'builtins', 'codecs', 'encodings', 'encodings.aliases', 'encodings.latin_1', 'encodings.utf_8', 'errno', 'genericpath', 'io', 'marshal', 'os', 'os.path', 'posix', 'posixpath', 'readline', 'rlcompleter', 'signal', 'site', 'stat', 'sys', 'sysconfig', 'temp1', 'zipimport'] >>> import temp1 >>> temp1.temp2 >>> sorted(sys.modules.keys()) ['__main__', '_codecs', '_collections_abc', '_frozen_importlib', '_imp', '_io', '_sitebuiltins', '_stat', '_sysconfigdata', '_thread', '_warnings', '_weakref', '_weakrefset', 'abc', 'atexit', 'builtins', 'codecs', 'encodings', 'encodings.aliases', 'encodings.latin_1', 'encodings.utf_8', 'errno', 'genericpath', 'io', 'marshal', 'os', 'os.path', 'posix', 'posixpath', 'readline', 'rlcompleter', 'signal', 'site', 'stat', 'sys', 'sysconfig', 'temp1', 'zipimport'] More or less the reverse of the passage in question. ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 19:19:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 17:19:02 +0000 Subject: [issue24100] Use after free in siftdown (2) In-Reply-To: <1430489541.93.0.209728480757.issue24100@psf.upfronthosting.co.za> Message-ID: <1430587142.31.0.228151427183.issue24100@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be nice to add tests based on provided demo scripts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 19:22:00 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 17:22:00 +0000 Subject: [issue24081] Obsolete caveat in reload() docs In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za> Message-ID: <1430587320.72.0.0919565315533.issue24081@psf.upfronthosting.co.za> R. David Murray added the comment: Note that calling reload on temp1.temp2 will fail with an error that temp2 is not in sys.modules. So maybe the caveat needs rewording rather than deletion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 19:27:06 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 May 2015 17:27:06 +0000 Subject: [issue24100] Use after free in siftdown (2) In-Reply-To: <1430489541.93.0.209728480757.issue24100@psf.upfronthosting.co.za> Message-ID: <20150502172703.8936.60077@psf.io> Roundup Robot added the comment: New changeset d356e68de236 by Raymond Hettinger in branch '2.7': Issues #24099, #24100, and #24101: Fix free-after-use bug in heapq. https://hg.python.org/cpython/rev/d356e68de236 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 19:27:06 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 May 2015 17:27:06 +0000 Subject: [issue24101] Use after free in siftup In-Reply-To: <1430489575.51.0.442803283693.issue24101@psf.upfronthosting.co.za> Message-ID: <20150502172703.8936.70664@psf.io> Roundup Robot added the comment: New changeset d356e68de236 by Raymond Hettinger in branch '2.7': Issues #24099, #24100, and #24101: Fix free-after-use bug in heapq. https://hg.python.org/cpython/rev/d356e68de236 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 19:27:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 May 2015 17:27:07 +0000 Subject: [issue24099] Use after free in siftdown (1) In-Reply-To: <1430489480.16.0.0840319770251.issue24099@psf.upfronthosting.co.za> Message-ID: <20150502172703.8936.89644@psf.io> Roundup Robot added the comment: New changeset d356e68de236 by Raymond Hettinger in branch '2.7': Issues #24099, #24100, and #24101: Fix free-after-use bug in heapq. https://hg.python.org/cpython/rev/d356e68de236 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 19:36:34 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 May 2015 17:36:34 +0000 Subject: [issue24081] Obsolete caveat in reload() docs In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za> Message-ID: <1430588194.17.0.418903370028.issue24081@psf.upfronthosting.co.za> Eric Snow added the comment: Either the docs are out-of-date or they are really poorly worded. Most likely it's the former, but I'm taking a look. ---------- _______________________________________ Python tracker _______________________________________ From stephane at wirtel.be Fri May 1 23:41:50 2015 From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) Date: Fri, 01 May 2015 23:41:50 +0200 Subject: [issue24110] zipfile.ZipFile.write() does not accept bytes arcname In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za> References: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za> Message-ID: This documentation is correct for python2 but maybe not for python3. To check. From report at bugs.python.org Sat May 2 19:53:42 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 17:53:42 +0000 Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a null-terminated string In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za> Message-ID: <1430589222.53.0.0752883811341.issue23088@psf.upfronthosting.co.za> R. David Murray added the comment: Added some review comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 20:01:04 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 May 2015 18:01:04 +0000 Subject: [issue24081] Obsolete caveat in reload() docs In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za> Message-ID: <1430589664.05.0.0739090622747.issue24081@psf.upfronthosting.co.za> Eric Snow added the comment: I've verified that the documentation is correct under Python 2.3. The behavior changed under Python 2.4 (and the docs were not updated). I expect that the change in behavior is an unintended consequence of a change in the import system for 2.4. There were 7 in 2.4, so I'm checking to see which did it. FYI, our backward-compatibility policy would preclude a change like this, which is why I think it was unintentional. That no one noticed implies that we did not have a unit test for the case and that folks really weren't relying on the behavior anyway (at least not enough to open a bug). :) I suppose there could be an old bug on this, but if that the case then someone decided not to change it back. Regardless, the docs should be fixed by removing the referenced paragraph. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 20:03:15 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 18:03:15 +0000 Subject: [issue24081] Obsolete caveat in reload() docs In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za> Message-ID: <1430589795.06.0.196133074344.issue24081@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 20:14:53 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 May 2015 18:14:53 +0000 Subject: [issue24081] Obsolete caveat in reload() docs In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za> Message-ID: <1430590493.65.0.595171442387.issue24081@psf.upfronthosting.co.za> Eric Snow added the comment: I'm pretty sure this is the culprit: changeset: 32882:331e60d8ce6da19b168849418776fea0940787ec branch: legacy-trunk user: Tim Peters date: Mon Aug 02 03:52:12 2004 +0000 summary: PyImport_ExecCodeModuleEx(): remove module from sys.modules in error cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 20:17:16 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 May 2015 18:17:16 +0000 Subject: [issue24081] Obsolete caveat in reload() docs In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za> Message-ID: <1430590636.64.0.473938660129.issue24081@psf.upfronthosting.co.za> Eric Snow added the comment: patch LGTM for the 3 branches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 21:02:55 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 May 2015 19:02:55 +0000 Subject: [issue24081] Obsolete caveat in reload() docs In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za> Message-ID: <20150502190252.8141.18095@psf.io> Roundup Robot added the comment: New changeset 3cdeafd18e61 by R David Murray in branch '3.4': #24081: Remove obsolete caveat from import docs. https://hg.python.org/cpython/rev/3cdeafd18e61 New changeset d57e0c6d292d by R David Murray in branch 'default': Merge: #24081: Remove obsolete caveat from import docs. https://hg.python.org/cpython/rev/d57e0c6d292d New changeset fd1549dd8065 by R David Murray in branch '2.7': #24081: Remove obsolete caveat from import docs. https://hg.python.org/cpython/rev/fd1549dd8065 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 21:03:50 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 19:03:50 +0000 Subject: [issue24081] Obsolete caveat in reload() docs In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za> Message-ID: <1430593430.74.0.126309976053.issue24081@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Petr. (And Eric.) ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 21:09:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 May 2015 19:09:49 +0000 Subject: [issue24108] fnmatch.translate('*.txt') fails In-Reply-To: <1430509015.84.0.479562940364.issue24108@psf.upfronthosting.co.za> Message-ID: <20150502190946.98679.95278@psf.io> Roundup Robot added the comment: New changeset c5c65ef84a77 by R David Murray in branch '3.4': #24108: Update fnmatch.translate example to show correct output. https://hg.python.org/cpython/rev/c5c65ef84a77 New changeset cc6aed8ecb0d by R David Murray in branch 'default': Merge: #24108: Update fnmatch.translate example to show correct output. https://hg.python.org/cpython/rev/cc6aed8ecb0d New changeset 5d356223f075 by R David Murray in branch '2.7': #24108: Update fnmatch.translate example to show correct output. https://hg.python.org/cpython/rev/5d356223f075 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 21:10:55 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 19:10:55 +0000 Subject: [issue24108] fnmatch.translate('*.txt') fails In-Reply-To: <1430509015.84.0.479562940364.issue24108@psf.upfronthosting.co.za> Message-ID: <1430593855.68.0.489599797167.issue24108@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks Christophe and Merlijn. ---------- nosy: +r.david.murray resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 21:38:35 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 19:38:35 +0000 Subject: [issue21327] socket.type value changes after using settimeout() In-Reply-To: <1398167707.44.0.251945553674.issue21327@psf.upfronthosting.co.za> Message-ID: <1430595515.21.0.854127501937.issue21327@psf.upfronthosting.co.za> R. David Murray added the comment: The behavior of s.type has changed in 3.5: it now behaves like the proposed new method behaves. Looking at the source I can't figure out why this is so. It doesn't seem as though it should be, but this needs to be sorted out before we can proceed. ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 21:40:06 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 19:40:06 +0000 Subject: [issue21327] socket.type value changes after using settimeout() In-Reply-To: <1398167707.44.0.251945553674.issue21327@psf.upfronthosting.co.za> Message-ID: <1430595606.94.0.707870369929.issue21327@psf.upfronthosting.co.za> R. David Murray added the comment: Wait, I take it back. I must have run the test incorrectly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 22:05:30 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Sat, 02 May 2015 20:05:30 +0000 Subject: [issue24068] statistics module - incorrect results with boolean input In-Reply-To: <1430211206.61.0.689765465928.issue24068@psf.upfronthosting.co.za> Message-ID: <1430597130.05.0.655955549071.issue24068@psf.upfronthosting.co.za> Wolfgang Maier added the comment: uploading an alternate, possibly slightly clearer version of the patch ---------- Added file: http://bugs.python.org/file39269/statistics._sum.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 22:18:12 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 May 2015 20:18:12 +0000 Subject: [issue21327] socket.type value changes after using settimeout() In-Reply-To: <1398167707.44.0.251945553674.issue21327@psf.upfronthosting.co.za> Message-ID: <1430597892.16.0.963787186777.issue21327@psf.upfronthosting.co.za> R. David Murray added the comment: I added some review comments. Something I don't understand: if settimeout sets NONBLOCK, and CLOEXEC is always set now, why does s=socket.socket() yield something whose type is SOCK_STREAM, while settimeout causes type to change? I don't understand the relationship between SOCK_NONBLOCK and O_NONBLOCK, either. Whoever came up with this API in linux was crazy, if you ask me. On the other hand, having type return what it does is clearly correct, given that we are mirroring the C API. Having a new sock_type attribute that provides the value without the extra flags makes sense in that context, IMO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 22:34:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 20:34:44 +0000 Subject: [issue24091] Use after free in Element.extend (1) In-Reply-To: <1430488567.85.0.132864592859.issue24091@psf.upfronthosting.co.za> Message-ID: <1430598884.21.0.145415541276.issue24091@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that fixes issue24091, issue24092, issue24093, and several other similar bugs. ---------- assignee: -> serhiy.storchaka keywords: +patch stage: -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file39270/etree_crashes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 22:36:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 20:36:25 +0000 Subject: [issue24092] Use after free in Element.extend (2) In-Reply-To: <1430488625.39.0.290044967832.issue24092@psf.upfronthosting.co.za> Message-ID: <1430598985.02.0.450441410734.issue24092@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch for issue24091 fixes this issue. ---------- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> Use after free in Element.extend (1) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 22:36:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 May 2015 20:36:29 +0000 Subject: [issue24093] Use after free in Element.remove In-Reply-To: <1430488688.91.0.916599584274.issue24093@psf.upfronthosting.co.za> Message-ID: <1430598989.03.0.961955867436.issue24093@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch for issue24091 fixes this issue. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Use after free in Element.extend (1) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 22:47:49 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 May 2015 20:47:49 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430599669.79.0.131750663751.issue23911@psf.upfronthosting.co.za> Eric Snow added the comment: Here's an updated patch with "_pathy.py" changed to "_bootstrap_external.py" (and similar changes with freezing). The patch does not include fixing the venv test (i.e. the bundled pip). Also, I'll be adding a note to NEWS. ---------- Added file: http://bugs.python.org/file39271/path-based-importlib.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 22:52:41 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 May 2015 20:52:41 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430599961.79.0.650794002707.issue23911@psf.upfronthosting.co.za> Eric Snow added the comment: As I mentioned, I'm pretty sure that the failing venv test is due to the bundled pip. Here's the test output: test test_venv failed -- Traceback (most recent call last): File "/home/esnow/projects/cpython/Lib/test/test_venv.py", line 356, in test_with_pip with_pip=True) subprocess.CalledProcessError: Command '['/tmp/tmphxh1zztf/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/esnow/projects/cpython/Lib/test/test_venv.py", line 362, in test_with_pip self.fail(msg.format(exc, details)) AssertionError: Command '['/tmp/tmphxh1zztf/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1 **Subprocess Output** Traceback (most recent call last): File "/home/esnow/projects/cpython/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/home/esnow/projects/cpython/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/esnow/projects/cpython/Lib/ensurepip/__main__.py", line 4, in ensurepip._main() File "/home/esnow/projects/cpython/Lib/ensurepip/__init__.py", line 209, in _main default_pip=args.default_pip, File "/home/esnow/projects/cpython/Lib/ensurepip/__init__.py", line 116, in bootstrap _run_pip(args + [p[0] for p in _PROJECTS], additional_paths) File "/home/esnow/projects/cpython/Lib/ensurepip/__init__.py", line 40, in _run_pip import pip File "", line 958, in _find_and_load File "", line 947, in _find_and_load_unlocked File "", line 655, in _load_unlocked File "", line 625, in _load_backward_compatible File "/tmp/tmp57j9vkrt/pip-6.1.1-py2.py3-none-any.whl/pip/__init__.py", line 13, in File "", line 958, in _find_and_load File "", line 947, in _find_and_load_unlocked File "", line 655, in _load_unlocked File "", line 625, in _load_backward_compatible File "/tmp/tmp57j9vkrt/pip-6.1.1-py2.py3-none-any.whl/pip/utils/__init__.py", line 22, in File "", line 958, in _find_and_load File "", line 947, in _find_and_load_unlocked File "", line 655, in _load_unlocked File "", line 625, in _load_backward_compatible File "/tmp/tmp57j9vkrt/pip-6.1.1-py2.py3-none-any.whl/pip/_vendor/pkg_resources/__init__.py", line 1712, in AttributeError: module 'importlib._bootstrap' has no attribute 'SourceFileLoader' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 23:25:37 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 May 2015 21:25:37 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430601937.79.0.127813273074.issue23911@psf.upfronthosting.co.za> Eric Snow added the comment: Looks like setuptool's pkg_resources is directly importing importlib._bootstrap. I've filed a bug: https://bitbucket.org/pypa/setuptools/issue/378. In the meantime, what are our options for getting that test passing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 23:42:11 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 02 May 2015 21:42:11 +0000 Subject: [issue24100] Use after free in siftdown (2) In-Reply-To: <1430489541.93.0.209728480757.issue24100@psf.upfronthosting.co.za> Message-ID: <1430602931.44.0.66707863347.issue24100@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Go ahead and add tests if you like. I don't see the point. The fix was to simply backport code that was already in Py3.5. and the code exercised by the exploit scripts is no longer there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 23:57:44 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 May 2015 21:57:44 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430603864.33.0.0228131430545.issue23911@psf.upfronthosting.co.za> Eric Snow added the comment: Here's the correct patch. ---------- Added file: http://bugs.python.org/file39272/path-based-importlib.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 2 23:57:57 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 May 2015 21:57:57 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430603877.49.0.364768383182.issue23911@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file39271/path-based-importlib.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 00:22:30 2015 From: report at bugs.python.org (Thomas Wouters) Date: Sat, 02 May 2015 22:22:30 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1430605350.22.0.586895446601.issue2292@psf.upfronthosting.co.za> Thomas Wouters added the comment: The latest patch looks good to me. No need to do the additional AST refactoring if it's going to make PEP 492's implementor's life harder (but I do read Guido's comment as a reason to check this in sooner rather than later :>) So, unless anyone objects I'll check in the latest patch on Monday. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 01:26:59 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 02 May 2015 23:26:59 +0000 Subject: [issue24081] Obsolete caveat in reload() docs In-Reply-To: <1430590493.65.0.595171442387.issue24081@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: I vaguely recall discussing that change, and my recollection is that it was deliberate in order to evict improperly configured modules - we didn't count it as a significant compatibility break because it solely affected an error handling path. I guess we never thought to check if the old misbehaviour was formally documented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 01:31:39 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 02 May 2015 23:31:39 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1430603877.53.0.267327327219.issue23911@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: As a compatibility hack for setuptools versions with the issue, I'd suggest making importlib._bootstrap.setup alias SourceFileLoader back into importlib._bootstrap, with an explanation and link to back to this issue in a comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 01:56:13 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 02 May 2015 23:56:13 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430610973.72.0.266423982806.issue23911@psf.upfronthosting.co.za> Eric Snow added the comment: Gah. I had tried exactly that but did it in the wrong spot. Here's an updated patch which fixes the test. ---------- Added file: http://bugs.python.org/file39273/path-based-importlib.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 02:02:28 2015 From: report at bugs.python.org (Eric Snow) Date: Sun, 03 May 2015 00:02:28 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430611348.89.0.298357045228.issue23911@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file39273/path-based-importlib.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 02:03:19 2015 From: report at bugs.python.org (Eric Snow) Date: Sun, 03 May 2015 00:03:19 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430611399.24.0.81669108792.issue23911@psf.upfronthosting.co.za> Changes by Eric Snow : Added file: http://bugs.python.org/file39274/path-based-importlib.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 02:05:32 2015 From: report at bugs.python.org (Eric Snow) Date: Sun, 03 May 2015 00:05:32 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430611532.6.0.737951009852.issue23911@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file39274/path-based-importlib.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 02:05:47 2015 From: report at bugs.python.org (Eric Snow) Date: Sun, 03 May 2015 00:05:47 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430611547.41.0.502084368305.issue23911@psf.upfronthosting.co.za> Changes by Eric Snow : Added file: http://bugs.python.org/file39275/path-based-importlib.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 02:11:49 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 03 May 2015 00:11:49 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1430611909.73.0.393869636219.issue2292@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks for the review Thomas! And yes, that's what I meant. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 03:02:17 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 03 May 2015 01:02:17 +0000 Subject: [issue24100] Use after free in siftdown (2) In-Reply-To: <1430489541.93.0.209728480757.issue24100@psf.upfronthosting.co.za> Message-ID: <1430614937.26.0.544691926138.issue24100@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I should add that the crasher scripts share common features and could perhaps be built into a unified test tool. Also, some care should be taken to make the tool mostly independent of non-guaranteed "del" behavior or CPython specific ref-counting logic to trigger a particular sequence of events. For example, pypy gives a different result than CPython 3.5 for for the various poc_sift* scripts. The reason is that the "__del__" method isn't reliably triggered in a gc-only environment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 03:23:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 May 2015 01:23:58 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <20150503012354.8139.29342@psf.io> Roundup Robot added the comment: New changeset 02e3bf65b2f8 by Eric Snow in branch 'default': Issue #23911: Move path-based bootstrap code to a separate frozen module. https://hg.python.org/cpython/rev/02e3bf65b2f8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 03:24:31 2015 From: report at bugs.python.org (Eric Snow) Date: Sun, 03 May 2015 01:24:31 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430616271.77.0.408739803853.issue23911@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 Sun May 3 03:51:38 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 03 May 2015 01:51:38 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1430617898.78.0.498770833792.issue24018@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yeah, looks good -- ?uke, can you commit this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 03:52:21 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 03 May 2015 01:52:21 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1430617941.05.0.870448306539.issue2292@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It certainly would be nice to have documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 04:30:50 2015 From: report at bugs.python.org (George Jenkins) Date: Sun, 03 May 2015 02:30:50 +0000 Subject: [issue1182143] making builtin exceptions more informative Message-ID: <1430620250.07.0.960181676551.issue1182143@psf.upfronthosting.co.za> George Jenkins added the comment: Heh, just noticed this issue passed its 10 year anniversary! If someone has time to review my patch, that would be much appreciated. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 04:37:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 May 2015 02:37:22 +0000 Subject: [issue24094] Use after free during json encoding (PyType_IsSubtype) In-Reply-To: <1430488858.91.0.915527926564.issue24094@psf.upfronthosting.co.za> Message-ID: <20150503023718.98669.55314@psf.io> Roundup Robot added the comment: New changeset 0e8c9cf1fede by Benjamin Peterson in branch '3.3': just sort the items tuple directly (closes #24094) https://hg.python.org/cpython/rev/0e8c9cf1fede New changeset f9027b10b3c4 by Benjamin Peterson in branch '3.4': merge 3.3 (#24094) https://hg.python.org/cpython/rev/f9027b10b3c4 New changeset 3bdf1816f561 by Benjamin Peterson in branch 'default': merge 3.4 (#24094) https://hg.python.org/cpython/rev/3bdf1816f561 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 06:08:46 2015 From: report at bugs.python.org (paul j3) Date: Sun, 03 May 2015 04:08:46 +0000 Subject: [issue24089] argparse crashes with AssertionError In-Reply-To: <1430455558.24.0.369924072386.issue24089@psf.upfronthosting.co.za> Message-ID: <1430626126.18.0.623349418241.issue24089@psf.upfronthosting.co.za> paul j3 added the comment: It's the spaces and/or brackets in the metavar, along with a usage line that is long enough to wrap, that is raising this error. It's a known problem. http://bugs.python.org/issue11874 ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 07:55:23 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 05:55:23 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1430632523.15.0.460142833203.issue14376@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 07:55:39 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 05:55:39 +0000 Subject: [issue24045] Behavior of large returncodes (sys.exit(nn)) In-Reply-To: <1429836429.07.0.888331603842.issue24045@psf.upfronthosting.co.za> Message-ID: <1430632539.13.0.341330627361.issue24045@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 07:55:53 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 05:55:53 +0000 Subject: [issue24052] sys.exit(code) returns "success" to the OS for some nonzero values of code In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za> Message-ID: <1430632553.92.0.709737723034.issue24052@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 07:57:46 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 May 2015 05:57:46 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1430632666.76.0.55592384335.issue23955@psf.upfronthosting.co.za> Steve Dower added the comment: Added a patch that: * adds the applocal option to pyvenv.cfg * updates the docs to describe how pyvenv.cfg (home and applocal) affect sys.path * puts a default pyvenv.cfg in the ZIP distribution * adds significantly more buffer overflow protection to getpathp.c * prevents a case where sys.path may include multiple blank entries Currently none of this applies to Linux or Mac builds, though I'm led to believe there would be some value if it did. I'm not the one who can figure all the intricacies out for those platforms though. ---------- keywords: +patch Added file: http://bugs.python.org/file39276/23955_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:09:27 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 03 May 2015 06:09:27 +0000 Subject: [issue24068] statistics module - incorrect results with boolean input In-Reply-To: <1430211206.61.0.689765465928.issue24068@psf.upfronthosting.co.za> Message-ID: <1430633367.4.0.454110411019.issue24068@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I wonder if it would be better to reject Bool data in this context? It's not uncommon (and quite useful) in NumPy world to compute basic statistics on arrays of boolean dtype: the sum of such an array gives a count of the `True`s, and the mean gives the proportion of `True` entries. I think it would be handy to allow the statistics module to work with lists of bools, if possible. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:13:37 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 03 May 2015 06:13:37 +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: <1430633617.43.0.801549550265.issue20357@psf.upfronthosting.co.za> Mark Lawrence added the comment: I couldn't see anything obvious in the devguide so I'm assuming that still needs doing. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:18:15 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 03 May 2015 06:18:15 +0000 Subject: [issue10965] dev task of documenting undocumented APIs In-Reply-To: <1295566423.14.0.859020697485.issue10965@psf.upfronthosting.co.za> Message-ID: <1430633895.58.0.825118177943.issue10965@psf.upfronthosting.co.za> Mark Lawrence added the comment: Where do we stand on this as #10224 has been closed as "out of date"? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:43:47 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 06:43:47 +0000 Subject: [issue24091] Use after free in Element.extend (1) In-Reply-To: <1430488567.85.0.132864592859.issue24091@psf.upfronthosting.co.za> Message-ID: <1430635427.67.0.198071917015.issue24091@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:43:54 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 06:43:54 +0000 Subject: [issue24092] Use after free in Element.extend (2) In-Reply-To: <1430488625.39.0.290044967832.issue24092@psf.upfronthosting.co.za> Message-ID: <1430635434.85.0.276040392141.issue24092@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:44:43 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 06:44:43 +0000 Subject: [issue24093] Use after free in Element.remove In-Reply-To: <1430488688.91.0.916599584274.issue24093@psf.upfronthosting.co.za> Message-ID: <1430635483.49.0.666382465542.issue24093@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:45:58 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 06:45:58 +0000 Subject: [issue24094] Use after free during json encoding (PyType_IsSubtype) In-Reply-To: <1430488858.91.0.915527926564.issue24094@psf.upfronthosting.co.za> Message-ID: <1430635558.98.0.266754257475.issue24094@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:46:23 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 06:46:23 +0000 Subject: [issue24095] Use after free during json encoding a dict (2) In-Reply-To: <1430488935.49.0.703786529764.issue24095@psf.upfronthosting.co.za> Message-ID: <1430635583.66.0.489576820973.issue24095@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:47:24 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 06:47:24 +0000 Subject: [issue24096] Use after free in get_filter In-Reply-To: <1430489003.72.0.86735316643.issue24096@psf.upfronthosting.co.za> Message-ID: <1430635644.05.0.856559670585.issue24096@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:47:42 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 06:47:42 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <1430635662.56.0.727053940613.issue24097@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:48:04 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 06:48:04 +0000 Subject: [issue24098] Multiple use after frees in obj2ast_* methods In-Reply-To: <1430489429.65.0.587999729774.issue24098@psf.upfronthosting.co.za> Message-ID: <1430635684.41.0.746550542631.issue24098@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:50:15 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 03 May 2015 06:50:15 +0000 Subject: [issue20749] shutil.unpack_archive(): security concerns not documented In-Reply-To: <1393190017.96.0.0939250007559.issue20749@psf.upfronthosting.co.za> Message-ID: <1430635815.47.0.164756961896.issue20749@psf.upfronthosting.co.za> Mark Lawrence added the comment: If there is an agreed standard for security warnings I'll prepare a patch for this. ---------- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:50:22 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 06:50:22 +0000 Subject: [issue24099] Use after free in siftdown (1) In-Reply-To: <1430489480.16.0.0840319770251.issue24099@psf.upfronthosting.co.za> Message-ID: <1430635822.52.0.555115599735.issue24099@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:51:12 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 06:51:12 +0000 Subject: [issue24100] Use after free in siftdown (2) In-Reply-To: <1430489541.93.0.209728480757.issue24100@psf.upfronthosting.co.za> Message-ID: <1430635872.92.0.491391993984.issue24100@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:52:14 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 06:52:14 +0000 Subject: [issue24101] Use after free in siftup In-Reply-To: <1430489575.51.0.442803283693.issue24101@psf.upfronthosting.co.za> Message-ID: <1430635934.68.0.505830429507.issue24101@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:53:59 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 06:53:59 +0000 Subject: [issue24102] Multiple type confusions in unicode error handlers In-Reply-To: <1430489646.71.0.827069473585.issue24102@psf.upfronthosting.co.za> Message-ID: <1430636039.96.0.817736985341.issue24102@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:54:23 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 06:54:23 +0000 Subject: [issue24103] Use after free in xmlparser_setevents (1) In-Reply-To: <1430489715.59.0.155743746692.issue24103@psf.upfronthosting.co.za> Message-ID: <1430636063.87.0.16501431399.issue24103@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:55:25 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 06:55:25 +0000 Subject: [issue24104] Use after free in xmlparser_setevents (2) In-Reply-To: <1430489742.91.0.610954411273.issue24104@psf.upfronthosting.co.za> Message-ID: <1430636125.82.0.770691903002.issue24104@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 08:56:24 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 06:56:24 +0000 Subject: [issue24105] Use after free during json encoding a dict (3) In-Reply-To: <1430489990.8.0.117941995919.issue24105@psf.upfronthosting.co.za> Message-ID: <1430636184.32.0.147688062247.issue24105@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 09:14:32 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 07:14:32 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1430637272.41.0.406610824088.issue24056@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 09:14:38 2015 From: report at bugs.python.org (aleb) Date: Sun, 03 May 2015 07:14:38 +0000 Subject: [issue24116] --with-pydebug has no effect when the final python binary is compiled Message-ID: <1430637278.73.0.597162622661.issue24116@psf.upfronthosting.co.za> New submission from aleb: This is how I configure and build: $ ./configure --prefix=/usr \ --with-threads \ --with-computed-gotos \ --enable-ipv6 \ --with-system-expat \ --with-dbmliborder=gdbm:ndbm \ --with-system-ffi \ --with-system-libmpdec \ --enable-loadable-sqlite-extensions \ --without-ensurepip \ --with-pydebug $ make "CFLAGS=-g -fno-inline -fno-strict-aliasing -O0" ... gcc -pthread -c -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -g -fno-inline -fno-strict-aliasing -O0 -Werror=declaration-after-statement -I. -IInclude -I./Include -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c ... gcc -pthread -Wl,-O1,--sort-common,--as-needed,-z,relro -Wl,-O1,--sort-common,--as-needed,-z,relro -Xlinker -export-dynamic -o python Modules/python.o libpython3.4dm.a -lpthread -ldl -lutil -lm Notice the specified CFLAGS are used when building "-o Modules/python.o" for example (as many others), but are not used when building the "-o python" binary. ---------- components: Build messages: 242455 nosy: aleb priority: normal severity: normal status: open title: --with-pydebug has no effect when the final python binary is compiled type: compile error versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 09:18:36 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 07:18:36 +0000 Subject: [issue24115] PyObject_IsInstance() and PyObject_IsSubclass() can fail In-Reply-To: <1430585786.54.0.583087529416.issue24115@psf.upfronthosting.co.za> Message-ID: <1430637516.45.0.0457666475148.issue24115@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 09:26:23 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 03 May 2015 07:26:23 +0000 Subject: [issue24116] --with-pydebug has no effect when the final python binary is compiled In-Reply-To: <1430637278.73.0.597162622661.issue24116@psf.upfronthosting.co.za> Message-ID: <1430637983.48.0.372129702801.issue24116@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Set CFLAGS when calling configure, not make. ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 10:16:59 2015 From: report at bugs.python.org (Ma Lin) Date: Sun, 03 May 2015 08:16:59 +0000 Subject: [issue24117] A small bug in GB18030 decoder. Message-ID: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> New submission from Ma Lin: Hi, There is a small bug in GB18030 decoder. For 4-byte sequence, the legal range is: 0x81-0xFE for the 1st byte 0x30-0x39 for the 2nd byte 0x81-0xFE for the 3rd byte 0x30-0x39 for the 4th byte The current code forgets to check 0xFE of the 1st and 3rd byte. Therefore, there are 8630 illegal 4-byte sequences can be decoded by GB18030 codec, here is an example: # legal sequence 0x81319130 is decoded to U+060A, it's fine. b = bytes([0x81, 0x31, 0x81, 0x30]) uchar = b.decode('gb18030') print(ord(uchar)) # illegal sequence 0x8130FF30 can be decoded to U+060A as well. b = bytes([0x81, 0x30, 0xFF, 0x30]) uchar = b.decode('gb18030') print(ord(uchar)) ---------- components: Unicode files: forpy27.patch keywords: patch messages: 242457 nosy: Ma Lin, ezio.melotti, haypo priority: normal severity: normal status: open title: A small bug in GB18030 decoder. versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39277/forpy27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 10:17:37 2015 From: report at bugs.python.org (Ma Lin) Date: Sun, 03 May 2015 08:17:37 +0000 Subject: [issue24117] A small bug in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1430641057.82.0.657316395956.issue24117@psf.upfronthosting.co.za> Changes by Ma Lin : ---------- type: -> behavior Added file: http://bugs.python.org/file39278/forpy3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 10:31:41 2015 From: report at bugs.python.org (Ma Lin) Date: Sun, 03 May 2015 08:31:41 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1430641901.29.0.985078700812.issue24117@psf.upfronthosting.co.za> Changes by Ma Lin : ---------- title: A small bug in GB18030 decoder. -> Wrong range checking in GB18030 decoder. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 10:47:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 May 2015 08:47:40 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1430642860.56.0.42049903231.issue24117@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +lemburg, loewis, serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 11:43:54 2015 From: report at bugs.python.org (aleb) Date: Sun, 03 May 2015 09:43:54 +0000 Subject: [issue24116] --with-pydebug has no effect when the final python binary is compiled In-Reply-To: <1430637278.73.0.597162622661.issue24116@psf.upfronthosting.co.za> Message-ID: <1430646234.71.0.158811694661.issue24116@psf.upfronthosting.co.za> aleb added the comment: It's confusing that the CFLAGS specified when running make are passed further sometimes but not always. So I guess that's a workaround? Or CFLAGS should never be specified to make directly? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 12:32:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 May 2015 10:32:22 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <20150503103219.84478.98622@psf.io> Roundup Robot added the comment: New changeset eb6052605fd8 by Serhiy Storchaka in branch 'default': Issue #22619: Added negative limit support in the traceback module. https://hg.python.org/cpython/rev/eb6052605fd8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 12:47:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 May 2015 10:47:40 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1430650060.33.0.735616609694.issue22619@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Dmitry. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 13:06:31 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 03 May 2015 11:06:31 +0000 Subject: [issue22881] show median in benchmark results In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za> Message-ID: <1430651191.69.0.551994525394.issue22881@psf.upfronthosting.co.za> Stefan Behnel added the comment: > for the even number case, I think you shouldn't do // 2, but / 2. Right. I updated the patch. ---------- Added file: http://bugs.python.org/file39279/show_median.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 13:13:00 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 03 May 2015 11:13:00 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1430651580.95.0.458817024088.issue24117@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Adding Hye-Shik who wrote the codec. ---------- nosy: +hyeshik.chang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 13:14:33 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 03 May 2015 11:14:33 +0000 Subject: [issue22881] show median in benchmark results In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za> Message-ID: <1430651673.2.0.486582128286.issue22881@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Have you found the median to be more stable than the minimum here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 13:41:46 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 03 May 2015 11:41:46 +0000 Subject: [issue22881] show median in benchmark results In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za> Message-ID: <1430653306.08.0.55977692531.issue22881@psf.upfronthosting.co.za> Stefan Behnel added the comment: I'm actually not sure how it relates to the minimum. The more runs you have, the higher the chance of hitting the actual minimum at least once. And if none of the runs hits the real minimum, you're simply out of luck. However, it should tend to give a much better result than the (currently printed) average, which suffers from outliers. And outliers are almost always too high for benchmarks and never too low, due to various external influences. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 13:45:44 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 03 May 2015 11:45:44 +0000 Subject: [issue22881] show median in benchmark results In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za> Message-ID: <1430653544.19.0.321132916063.issue22881@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Then let's just replace the average with the median? I don't think it makes sense to add more statistical information to the output (IMHO, there is already too much of it :-)). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 13:52:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 May 2015 11:52:11 +0000 Subject: [issue22881] show median in benchmark results In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za> Message-ID: <1430653931.06.0.726690634252.issue22881@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be just drop 5% of largest values to avoid the impact of outliers? See also issue23552. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 13:58:09 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 03 May 2015 11:58:09 +0000 Subject: [issue22881] show median in benchmark results In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za> Message-ID: <1430654289.66.0.678482758038.issue22881@psf.upfronthosting.co.za> Stefan Behnel added the comment: Well, we can apply a kludge, or apply statistics. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 14:18:06 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 03 May 2015 12:18:06 +0000 Subject: [issue24116] --with-pydebug has no effect when the final python binary is compiled In-Reply-To: <1430637278.73.0.597162622661.issue24116@psf.upfronthosting.co.za> Message-ID: <1430655486.95.0.91925081648.issue24116@psf.upfronthosting.co.za> R. David Murray added the comment: Sounds like this is a duplicate of issue 9189? (--with-pydebug certainly works for me). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 14:25:33 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 03 May 2015 12:25:33 +0000 Subject: [issue22881] show median in benchmark results In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za> Message-ID: <1430655933.19.0.0441830841881.issue22881@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > May be just drop 5% of largest values to avoid the impact of outliers? In fast mode (option "-f"), there may not be enough samples for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 15:18:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 May 2015 13:18:50 +0000 Subject: [issue23330] h2py.py regular expression missing In-Reply-To: <1422357197.95.0.836847227653.issue23330@psf.upfronthosting.co.za> Message-ID: <20150503131845.98667.32850@psf.io> Roundup Robot added the comment: New changeset b32ca610c9e6 by Serhiy Storchaka in branch '2.7': Issue #23330: h2py now supports arbitrary filenames in #include. https://hg.python.org/cpython/rev/b32ca610c9e6 New changeset 0079465a9425 by Serhiy Storchaka in branch '3.4': Issue #23330: h2py now supports arbitrary filenames in #include. https://hg.python.org/cpython/rev/0079465a9425 New changeset f49e7e315d65 by Serhiy Storchaka in branch 'default': Issue #23330: h2py now supports arbitrary filenames in #include. https://hg.python.org/cpython/rev/f49e7e315d65 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 15:18:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 May 2015 13:18:50 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <20150503131845.98667.62404@psf.io> Roundup Robot added the comment: New changeset 1eaaf27b3956 by Serhiy Storchaka in branch 'default': Issue #20179: Converted the _ssl module to Argument Clinic. https://hg.python.org/cpython/rev/1eaaf27b3956 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 15:18:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 May 2015 13:18:49 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <20150503131845.98667.872@psf.io> Roundup Robot added the comment: New changeset d5f78a855355 by Serhiy Storchaka in branch 'default': Issue #20148: Converted the _sre module to Argument Clinic. https://hg.python.org/cpython/rev/d5f78a855355 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 15:18:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 May 2015 13:18:49 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <20150503131845.98667.2501@psf.io> Roundup Robot added the comment: New changeset b22ced894d51 by Serhiy Storchaka in branch 'default': Issue #20168: Converted the _tkinter module to Argument Clinic. https://hg.python.org/cpython/rev/b22ced894d51 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 15:21:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 May 2015 13:21:14 +0000 Subject: [issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files In-Reply-To: <1389138499.96.0.517173661563.issue20175@psf.upfronthosting.co.za> Message-ID: <1430659274.08.0.801904731559.issue20175@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Peter for the fix. Applied by Christian in 743c54a2830f. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 15:33:35 2015 From: report at bugs.python.org (Christian Heimes) Date: Sun, 03 May 2015 13:33:35 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1430660015.03.0.636688891719.issue20179@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm with Alex. The move to argument clinic is going to make it very hard to port patches to older versions of Python, especially Python 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 16:25:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 May 2015 14:25:16 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1430663116.45.0.346147204672.issue20182@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added new comments. issue20182.signalmodule.patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 16:27:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 May 2015 14:27:21 +0000 Subject: [issue23330] h2py.py regular expression missing In-Reply-To: <1422357197.95.0.836847227653.issue23330@psf.upfronthosting.co.za> Message-ID: <1430663241.31.0.295084794065.issue23330@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 16:29:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 May 2015 14:29:20 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1430663360.78.0.592393353475.issue20179@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry. Should I rollback 1eaaf27b3956? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 16:31:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 May 2015 14:31:49 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1430663509.87.0.352647716174.issue20168@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: wantobjects() was not converted due to a bug in Argument Clinic (issue24051). ---------- dependencies: -Argument Clinic no longer works with single optional argument resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 16:32:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 May 2015 14:32:13 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430663533.11.0.795775396656.issue20148@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 May 3 16:33:44 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 03 May 2015 14:33:44 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1430663624.84.0.218790107671.issue20179@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I have no opinion on whether this is a good thing or not. Security backports should be few and far between, so I don't think it's a big problem if they are a bit more difficult. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 16:34:31 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 03 May 2015 14:34:31 +0000 Subject: [issue24105] Use after free during json encoding a dict (3) In-Reply-To: <1430489990.8.0.117941995919.issue24105@psf.upfronthosting.co.za> Message-ID: <1430663671.61.0.0716777476565.issue24105@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I applied a very similar patch for #24094. ---------- nosy: +benjamin.peterson resolution: -> duplicate status: open -> closed superseder: -> Use after free during json encoding (PyType_IsSubtype) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 16:34:58 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 03 May 2015 14:34:58 +0000 Subject: [issue24095] Use after free during json encoding a dict (2) In-Reply-To: <1430488935.49.0.703786529764.issue24095@psf.upfronthosting.co.za> Message-ID: <1430663698.58.0.223806691002.issue24095@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> duplicate status: open -> closed superseder: -> Use after free during json encoding (PyType_IsSubtype) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 16:35:55 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 14:35:55 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1430663755.38.0.599265736292.issue20179@psf.upfronthosting.co.za> Larry Hastings added the comment: How often are patches backported to 2.7? While I understand the sentiment, I'd like to understand the scale of the objection being raised. I suspect it's infrequent, making the objection a minor one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 16:36:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 May 2015 14:36:41 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1430663801.44.0.844039230777.issue20180@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For now almost all generated code are written in separate file, so it doesn't attract attention (if you believe Argument Clinic). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 16:39:28 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 03 May 2015 14:39:28 +0000 Subject: [issue24118] http.client example is no longer valid Message-ID: <1430663968.45.0.585003367103.issue24118@psf.upfronthosting.co.za> New submission from Steven D'Aprano: The example code for http.client shows www.python.org/parrot.spam return a 404: https://docs.python.org/3/library/http.client.html#examples >>> # Example of an invalid request >>> conn.request("GET", "/parrot.spam") >>> r2 = conn.getresponse() >>> print(r2.status, r2.reason) 404 Not Found However it no longer does that, instead it returns a 301 Moved Permanently. ---------- assignee: docs at python components: Documentation messages: 242483 nosy: docs at python, steven.daprano priority: normal severity: normal status: open title: http.client example is no longer valid versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 16:41:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 May 2015 14:41:33 +0000 Subject: [issue24105] Use after free during json encoding a dict (3) In-Reply-To: <1430489990.8.0.117941995919.issue24105@psf.upfronthosting.co.za> Message-ID: <1430664093.64.0.825291593762.issue24105@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a disadvantage of opening several issues for similar bugs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 17:21:10 2015 From: report at bugs.python.org (Brett Cannon) Date: Sun, 03 May 2015 15:21:10 +0000 Subject: [issue24119] Carry comments with the AST Message-ID: <1430666470.75.0.339272692521.issue24119@psf.upfronthosting.co.za> New submission from Brett Cannon: One thing about https://www.python.org/dev/peps/pep-0484/ is that it makes comments potentially semantically meaningful. Unfortunately the AST doesn't carry comments with it in any way, making it difficult to build a tool to implement a linter for PEP 484 using purely the ast module. Even if comments were carried along side-band and could do correlation by line number would be useful in this scenario. I thought an issue had previously existed for this topic but I could find it. ---------- components: Library (Lib) messages: 242485 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Carry comments with the AST type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 17:30:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 May 2015 15:30:09 +0000 Subject: [issue24096] Use after free in get_filter In-Reply-To: <1430489003.72.0.86735316643.issue24096@psf.upfronthosting.co.za> Message-ID: <20150503153006.84498.98658@psf.io> Roundup Robot added the comment: New changeset ffc1f9d1c8b3 by Benjamin Peterson in branch '3.3': be more robust against the filters list changing under us (closes #24096) https://hg.python.org/cpython/rev/ffc1f9d1c8b3 New changeset 47f4c3a5d86a by Benjamin Peterson in branch '3.4': merge 3.3 (#24096) https://hg.python.org/cpython/rev/47f4c3a5d86a New changeset bfea101f9402 by Benjamin Peterson in branch 'default': merge 3.4 (#24096) https://hg.python.org/cpython/rev/bfea101f9402 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 17:36:31 2015 From: report at bugs.python.org (Brett Cannon) Date: Sun, 03 May 2015 15:36:31 +0000 Subject: [issue10965] dev task of documenting undocumented APIs In-Reply-To: <1295566423.14.0.859020697485.issue10965@psf.upfronthosting.co.za> Message-ID: <1430667391.9.0.868081270189.issue10965@psf.upfronthosting.co.za> Brett Cannon added the comment: The issue is still valid and waiting for someone to submit a patch to the devguide. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 17:38:48 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 03 May 2015 15:38:48 +0000 Subject: [issue1182143] making builtin exceptions more informative Message-ID: <1430667528.44.0.590769986125.issue1182143@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 17:48:36 2015 From: report at bugs.python.org (Tal Einat) Date: Sun, 03 May 2015 15:48:36 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1430668116.51.0.938845458368.issue20182@psf.upfronthosting.co.za> Tal Einat added the comment: Do you mean the v2.patch file, or the one before it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 17:55:19 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 03 May 2015 15:55:19 +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: <1430668519.71.0.621492227163.issue9517@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 17:56:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 May 2015 15:56:38 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1430668598.6.0.908027246617.issue20182@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't see the v2 patch for the signal module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 18:14:46 2015 From: report at bugs.python.org (Carol Willing) Date: Sun, 03 May 2015 16:14:46 +0000 Subject: [issue10965] dev task of documenting undocumented APIs In-Reply-To: <1295566423.14.0.859020697485.issue10965@psf.upfronthosting.co.za> Message-ID: <1430669686.22.0.108730305204.issue10965@psf.upfronthosting.co.za> Carol Willing added the comment: Add key points from linked email in msg126662 to documentation section of the devguide. * provide developers guidance on how to document undocumented APIs * when and how to use __all__ * include rules from the linked email * highlight "do no harm" to existing users as discussed in email ---------- assignee: -> docs at python components: +Devguide nosy: +docs at python, ezio.melotti, willingc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 18:21:19 2015 From: report at bugs.python.org (Petr Viktorin) Date: Sun, 03 May 2015 16:21:19 +0000 Subject: [issue24082] Obsolete note in argument parsing (c-api/arg.rst) In-Reply-To: <1430403570.61.0.800757161817.issue24082@psf.upfronthosting.co.za> Message-ID: <1430670078.99.0.846870637073.issue24082@psf.upfronthosting.co.za> Petr Viktorin added the comment: The note is *correct* concerning the length, but I don't think it's relevant: in a NUL-terminated string without embedded NULs, the length is unambiguous. The other issues are about "u" itself, not the note. (I have nothing against the "it is recommended to use u# or U instead" part, but the reasons the note gives are wrong and irrelevant, respectively.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 18:32:41 2015 From: report at bugs.python.org (Tal Einat) Date: Sun, 03 May 2015 16:32:41 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1430670761.7.0.785484594309.issue20182@psf.upfronthosting.co.za> Tal Einat added the comment: Sorry, my mistake, got mixed up with selectmodule. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 18:41:42 2015 From: report at bugs.python.org (Christian Heimes) Date: Sun, 03 May 2015 16:41:42 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1430671302.94.0.855562564156.issue20179@psf.upfronthosting.co.za> Christian Heimes added the comment: You are right, patches are seldomly backported to Python 2.7. Features are never backported. Well, except for one exception: the ssl module. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 18:48:03 2015 From: report at bugs.python.org (Donald Stufft) Date: Sun, 03 May 2015 16:48:03 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1430671683.45.0.81693558979.issue20179@psf.upfronthosting.co.za> Donald Stufft added the comment: I think it's worthwhile to maintain the ability to easily backport patches from 3.x to 2.7, especially given the security sensitive nature of the ssl module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 19:00:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 May 2015 17:00:46 +0000 Subject: [issue24118] http.client example is no longer valid In-Reply-To: <1430663968.45.0.585003367103.issue24118@psf.upfronthosting.co.za> Message-ID: <20150503170043.8938.96763@psf.io> Roundup Robot added the comment: New changeset 71ec881d8347 by Benjamin Peterson in branch '3.4': update example, since python.org is HTTPS-only now (closes #24118) https://hg.python.org/cpython/rev/71ec881d8347 New changeset 376c2d81d0e2 by Benjamin Peterson in branch '2.7': update example, since python.org is HTTPS-only now (closes #24118) https://hg.python.org/cpython/rev/376c2d81d0e2 New changeset 07571d2968b0 by Benjamin Peterson in branch 'default': merge 3.4 (#24118) https://hg.python.org/cpython/rev/07571d2968b0 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 19:52:28 2015 From: report at bugs.python.org (Gregorio) Date: Sun, 03 May 2015 17:52:28 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception Message-ID: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> New submission from Gregorio: Debian 8 Python 3.4.3 Path.(r)glob stops when it encounters a PermissionDenied exception. However, os.walk just skips files/directories it does not have permission to access. In my opinion, the os.walk behavior is better because it doesn't prevent usage in situations where a single file/directory in a tree has restricted permissions. ---------- components: Library (Lib) messages: 242496 nosy: Gregorio priority: normal severity: normal status: open title: pathlib.(r)glob stops on PermissionDenied exception type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 20:11:06 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 03 May 2015 18:11:06 +0000 Subject: [issue24113] shlex constructor unreachable code In-Reply-To: <1430574110.71.0.619526001392.issue24113@psf.upfronthosting.co.za> Message-ID: <1430676666.59.0.329450989066.issue24113@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report. > Users should either be permitted to set debug on via an optional __init__ parameter, This is already possible via the debug attribute (https://docs.python.org/3/library/shlex.html#shlex.shlex.debug), so I don't think adding a debug parameter to __init__ is necessary. > or debug should be taken out of the initializer altogether. +1. We can just remove the unreachable code. ---------- keywords: +easy nosy: +berker.peksag stage: -> needs patch type: behavior -> enhancement versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 20:31:58 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 03 May 2015 18:31:58 +0000 Subject: [issue10435] Document unicode C-API in reST In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za> Message-ID: <1430677918.95.0.667555401896.issue10435@psf.upfronthosting.co.za> Mark Lawrence added the comment: Py_UNICODE_TOLOWER, Py_UNICODE_TOUPPER and Py_UNICODE_TOTITLE are all labelled deprecated in 3.3 and presumably can be removed completely. Alternatively should these like many others be scheduled for removal in 4.0? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 20:52:45 2015 From: report at bugs.python.org (Mark Shannon) Date: Sun, 03 May 2015 18:52:45 +0000 Subject: [issue24119] Carry comments with the AST In-Reply-To: <1430666470.75.0.339272692521.issue24119@psf.upfronthosting.co.za> Message-ID: <1430679165.83.0.739203582308.issue24119@psf.upfronthosting.co.za> Mark Shannon added the comment: Comments don't belong on the AST. Where would you attach them? The tokenizer module provides all information about comments. Tools can get the information quite easily if they need it. ---------- nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 20:56:08 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 18:56:08 +0000 Subject: [issue24051] Argument Clinic no longer works with single optional argument In-Reply-To: <1429883330.67.0.210732695704.issue24051@psf.upfronthosting.co.za> Message-ID: <1430679368.47.0.146353011719.issue24051@psf.upfronthosting.co.za> Larry Hastings added the comment: Optional groups were designed to support two specific legacy use cases: * functions that have groups of parameters that are * functions with optional parameters to the left of required parameters They are not intended to be used in cases like this. I really, really wish you would stop using them except for these specific legacy cases. Furthermore, the argument parsing for tkinter.tkapp.wantobjects has a very clear translation into Argument Clinic: value: int = -1 / Optional groups should not be used for single-argument functions. I have no interest in fixing this bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 20:58:14 2015 From: report at bugs.python.org (lf) Date: Sun, 03 May 2015 18:58:14 +0000 Subject: [issue24121] collections page doesn't Message-ID: <1430679494.03.0.839245374833.issue24121@psf.upfronthosting.co.za> Changes by lf : ---------- assignee: docs at python components: Documentation nosy: docs at python, lf priority: normal severity: normal status: open title: collections page doesn't 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 Sun May 3 20:58:37 2015 From: report at bugs.python.org (lf) Date: Sun, 03 May 2015 18:58:37 +0000 Subject: [issue24121] collections page doesn't mention that deques are mutable Message-ID: <1430679517.19.0.681843707246.issue24121@psf.upfronthosting.co.za> Changes by lf : ---------- title: collections page doesn't -> collections page doesn't mention that deques are mutable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 20:59:29 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 18:59:29 +0000 Subject: [issue24051] Argument Clinic no longer works with single optional argument In-Reply-To: <1429883330.67.0.210732695704.issue24051@psf.upfronthosting.co.za> Message-ID: <1430679569.48.0.579164857827.issue24051@psf.upfronthosting.co.za> Larry Hastings added the comment: Sorry, I forgot to finish the first bullet point. It should have read: * functions that have groups of parameters that are optional only as a group (e.g. curses.window.getch) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 21:37:43 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 May 2015 19:37:43 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430681863.98.0.928413767283.issue20148@psf.upfronthosting.co.za> Steve Dower added the comment: This broke Windows builds because of unnecessary "static" qualifiers on the forward declarations at lines 1429, 2472 and 2715 (as discussed on #20323). Removing "static" from these lines fixes the build. ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 21:38:10 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 May 2015 19:38:10 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430681890.17.0.0273050361282.issue20148@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 21:39:35 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 May 2015 19:39:35 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1430681975.81.0.733553294448.issue20168@psf.upfronthosting.co.za> Steve Dower added the comment: This broke Windows builds because of unnecessary "static" qualifiers on the forward declarations at lines 2685 and 3006 (as discussed on #20323). Removing "static" from these lines fixes the build. ---------- nosy: +steve.dower resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 21:42:51 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 03 May 2015 19:42:51 +0000 Subject: [issue24122] Install fails after configure sets the extending/embedding install directory to NONE Message-ID: <1430682171.19.0.329693037889.issue24122@psf.upfronthosting.co.za> New submission from Xavier de Gaye: Running configure without the '--prefix' option creates the Makefile with the following line: LIBPL= NONE/lib/python3.5/config-$(VERSION)$(ABIFLAGS) As a result 'make install' fails to install the library and the stuff needed for extending/embedding. The attached patch fixes the problem. ---------- components: Installation files: configure.patch keywords: patch messages: 242504 nosy: twouters, xdegaye priority: normal severity: normal status: open title: Install fails after configure sets the extending/embedding install directory to NONE type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file39280/configure.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 21:48:58 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 19:48:58 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430682538.7.0.934100503011.issue20148@psf.upfronthosting.co.za> Larry Hastings added the comment: Removing "static" breaks GCC on Linux (gcc 4.9.2 on Ubuntu 15.04 x86-64): ./Modules/_sre.c:2780:20: error: static declaration of ?pattern_methods? follows non-static declaration static PyMethodDef pattern_methods[] = { ^ ./Modules/_sre.c:1429:13: note: previous declaration of ?pattern_methods? was here PyMethodDef pattern_methods[]; ^ IMO MSVS is the one being unreasonable here. But obviously we need to find some way of doing this that makes both compilers happy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 21:54:56 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 19:54:56 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430682896.38.0.525675727813.issue20148@psf.upfronthosting.co.za> Larry Hastings added the comment: Steve, does this patch fix the build for Windows? By all rights it oughta. ---------- Added file: http://bugs.python.org/file39281/larry.fix.sre.build.on.windows.diff.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 21:56:07 2015 From: report at bugs.python.org (Ralf Gommers) Date: Sun, 03 May 2015 19:56:07 +0000 Subject: [issue2943] Distutils should generate a better error message when the SDK is not installed In-Reply-To: <1211455981.94.0.404413935613.issue2943@psf.upfronthosting.co.za> Message-ID: <1430682967.33.0.229191280317.issue2943@psf.upfronthosting.co.za> Changes by Ralf Gommers : ---------- nosy: +ralf.gommers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 21:58:52 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 19:58:52 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1430683131.99.0.180936935284.issue20168@psf.upfronthosting.co.za> Larry Hastings added the comment: As mentioned on #20148, removing the "static" from the forward declarations breaks it on GCC. (And, of the two, I think GCC is the one being reasonable here.) Attached is a patch that should fix the build for tkinter. ---------- Added file: http://bugs.python.org/file39282/larry.fix.tkinter.build.on.windows.diff.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 21:59:56 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 May 2015 19:59:56 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430683196.03.0.766311197553.issue20148@psf.upfronthosting.co.za> Steve Dower added the comment: This line (1429 before patch, 1433 after patch) is still being troublesome: static PyMethodDef pattern_methods[]; ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 22:00:39 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 May 2015 20:00:39 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430683239.88.0.68526905583.issue20148@psf.upfronthosting.co.za> Steve Dower added the comment: But looks like it's unnecessary and just wasn't removed in the patch. Everything builds fine without it ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 22:01:16 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 20:01:16 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430683276.65.0.311656000038.issue20148@psf.upfronthosting.co.za> Larry Hastings added the comment: Sorry--you can simply remove that line, it's no longer needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 22:01:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 May 2015 20:01:58 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430683318.37.0.178518971932.issue20148@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Does your patch just move type definition to the end of the file? I think this is only the way to make happy GCC and MS compiler. Strange that no IRC bot complained about compilation failure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 22:03:07 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 20:03:07 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430683387.41.0.354345099762.issue20148@psf.upfronthosting.co.za> Larry Hastings added the comment: Yes, it moves the type declaration to the bottom of the file, and adds forward static declarations for the types to the top of the file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 22:08:58 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 May 2015 20:08:58 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430683738.28.0.10639198225.issue20148@psf.upfronthosting.co.za> Steve Dower added the comment: AFAIK the only buildbot with a nearly-up-to-date MSVC is still marked as unstable (http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x). I keep meaning to get it promoted, but haven't quite gotten around to it yet... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 22:10:48 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 20:10:48 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430683848.57.0.323574516921.issue20148@psf.upfronthosting.co.za> Larry Hastings added the comment: Oh, this is only happening on the *beta* compiler? In that case, I genuinely suggest you file a bug. We can still check in the workaround, but I really do think MSVS's behavior is wrong here. (Why is it only for forward static declarations of arrays of unspecified size?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 22:11:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 May 2015 20:11:23 +0000 Subject: [issue24051] Argument Clinic no longer works with single optional argument In-Reply-To: <1429883330.67.0.210732695704.issue24051@psf.upfronthosting.co.za> Message-ID: <1430683883.41.0.90362012279.issue24051@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Then it would be better to not convert wantobjects() to Argument Clinic. Using -1 as a value for not passed argument is a hack (added in 1ab9978123be) and I don't want to propagate it to the signature. But I afraid that there are other functions that suffer from this bug (may be in the curses module). ---------- status: open -> languishing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 22:14:20 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 20:14:20 +0000 Subject: [issue24051] Argument Clinic no longer works with single optional argument In-Reply-To: <1429883330.67.0.210732695704.issue24051@psf.upfronthosting.co.za> Message-ID: <1430684060.01.0.170867565573.issue24051@psf.upfronthosting.co.za> Larry Hastings added the comment: If the argument currently uses a default value of -1, then I see no problem with converting it to Argument Clinic using a default value of -1. If you claim it's a "hack" then you should discuss that with the author of 1ab9978123be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 22:14:52 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 20:14:52 +0000 Subject: [issue24051] Argument Clinic no longer works with single optional argument In-Reply-To: <1429883330.67.0.210732695704.issue24051@psf.upfronthosting.co.za> Message-ID: <1430684092.52.0.413799190668.issue24051@psf.upfronthosting.co.za> Larry Hastings added the comment: Closing as wontfix. This is not a supported use of optional groups. ---------- resolution: -> wont fix status: languishing -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 22:22:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 May 2015 20:22:23 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430684543.68.0.124800177004.issue20148@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Then the patch LGTM. It is easier to make these changes by hand than make a review for moved code on Rietveld. I'm not sure, but may be forward static declarations of arrays of unspecified size is C99-ism? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 22:32:23 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 May 2015 20:32:23 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430685143.09.0.763536285178.issue20148@psf.upfronthosting.co.za> Steve Dower added the comment: It fails on VC10, 11, 12 and 14, so I doubt it's going to be changed. That said, it looks like the non-static forward definition may be some sort of extension, since it causes a redefinition error (mismatched storage class) on all versions when using /Za to disable extensions. It could be a C99 feature ("tentative definitions" I think), as Serhiy suggests, but if so then it's very likely not going to be added between the RC (released last week) and final versions of the compiler. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 22:42:11 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 May 2015 20:42:11 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430685731.59.0.0746432919207.issue20148@psf.upfronthosting.co.za> Steve Dower added the comment: According to http://compgroups.net/comp.std.c/why-does-the-standard-prohibit-static-int-a/2569729, it's invalid in both C89 and C99, but some compilers accept it as an extension. IMO we should avoid relying on compiler extensions, at least in the code files that are supposed to be portable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 22:47:32 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 20:47:32 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430686052.51.0.373311632651.issue20148@psf.upfronthosting.co.za> Larry Hastings added the comment: I agree. I looked it up in the C99 standard. 6.9.2.2 says: "If the declaration of an identifier for an object is a tentative definition and has internal linkage, the declared type shall not be an incomplete type." And if you'd hurry up and bless my patch for Modules/_tkinter.c in bug #20168, I'd check this fix in ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 22:48:32 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 20:48:32 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430686112.47.0.480835035556.issue20148@psf.upfronthosting.co.za> Larry Hastings added the comment: (sorry, 6.9.2.3) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 23:06:11 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 21:06:11 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1430687171.89.0.479804235847.issue20179@psf.upfronthosting.co.za> Larry Hastings added the comment: We discussed it in IRC a bit (and I got a little education). I can propose three remedies: A) back out the Clinic conversion in _ssl.c B) support Clinic in 2.7 just for _ssl.c C) do a one-time backport of the Clinic generated code for _ssl.c IMO these are in my reverse order of preference; I'd prefer C, then B, then A. But I'm not supporting _ssl.c, you guys are. And I want you maintainers to be happy. So I'll abide by / help you in implementing whatever you prefer. FWIW, option C would mean doing an otherwise-inert backport of the current _ssl.c from trunk to 2.7, so that we could also backport (by hand) Modules/clinic/_ssl.c. Then, if in the future, when you change _ssl.c you still copy that file over and tweak it. But: if you change the arguments to a function, you'd have to *hand-edit* Modules/clinic/_ssl.c to match. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 23:06:49 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 03 May 2015 21:06:49 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1430687171.89.0.479804235847.issue20179@psf.upfronthosting.co.za> Message-ID: <55468DE6.4090401@free.fr> Antoine Pitrou added the comment: Le 03/05/2015 23:06, Larry Hastings a ?crit : > > Larry Hastings added the comment: > > We discussed it in IRC a bit (and I got a little education). Can we have a transcript somewhere? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 23:09:12 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 21:09:12 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1430687352.41.0.467408741888.issue20179@psf.upfronthosting.co.za> Larry Hastings added the comment: Attached. Glad you asked right away, it would have been a lot harder to get later! ---------- Added file: http://bugs.python.org/file39283/irc.transcript.of._ssl.clinic.discussion.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 23:10:55 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 03 May 2015 21:10:55 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1430687455.71.0.608628923921.issue20179@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 23:33:26 2015 From: report at bugs.python.org (Andrew Barnert) Date: Sun, 03 May 2015 21:33:26 +0000 Subject: [issue24113] shlex constructor unreachable code In-Reply-To: <1430574110.71.0.619526001392.issue24113@psf.upfronthosting.co.za> Message-ID: <1430688806.34.0.669471740905.issue24113@psf.upfronthosting.co.za> Andrew Barnert added the comment: Presumably ESR thought that information was useful enough to send Guido a patch to add it. But apparently nobody's missed it in the 15 years it's been checked in but unreachable. If anyone needed to know the `instream` and `lineno` right after initialization, presumably they just printed them directly. So, yeah, seems unnecessary to me. ---------- nosy: +abarnert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 23:43:57 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 May 2015 21:43:57 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1430689437.08.0.528472180777.issue20168@psf.upfronthosting.co.za> Steve Dower added the comment: LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 23:44:19 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 03 May 2015 21:44:19 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430689459.05.0.687920710889.issue20148@psf.upfronthosting.co.za> Steve Dower added the comment: Sorry, wasn't watching the other issue. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 23:49:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 May 2015 21:49:51 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <20150503214949.7796.96680@psf.io> Roundup Robot added the comment: New changeset 7a76c462c7f6 by Larry Hastings in branch 'default': Fix Windows build breakage from checkins on Issues #20148 and #20168. https://hg.python.org/cpython/rev/7a76c462c7f6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 23:49:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 May 2015 21:49:51 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <20150503214949.7796.72680@psf.io> Roundup Robot added the comment: New changeset 7a76c462c7f6 by Larry Hastings in branch 'default': Fix Windows build breakage from checkins on Issues #20148 and #20168. https://hg.python.org/cpython/rev/7a76c462c7f6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 23:53:52 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 21:53:52 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430690032.85.0.351774036861.issue20148@psf.upfronthosting.co.za> Larry Hastings added the comment: Steve, please close this issue when you've confirmed it's now building correctly on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 3 23:53:59 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 May 2015 21:53:59 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1430690039.46.0.957167950136.issue20168@psf.upfronthosting.co.za> Larry Hastings added the comment: Steve, please close this issue when you've confirmed it's now building correctly on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 01:15:38 2015 From: report at bugs.python.org (Jesse Bacon) Date: Sun, 03 May 2015 23:15:38 +0000 Subject: [issue24123] Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary. Message-ID: <1430694938.29.0.0226350460002.issue24123@psf.upfronthosting.co.za> New submission from Jesse Bacon: https://docs.python.org/2/tutorial/stdlib2.html Section 11.6. Weak References The example code below from the python tutorial suggests that the value of a is no persistent when cast into a WeakValueDictionary as entry 'primary' The value persisted in the dictionary aver 'a' was deleted and garbage collection had been called. I did not see a bug report for this already forgive me if there was one already put in. import weakref, gc class A: def __init__(self, value): self.value = value def __repr__(self): return str(self.value) a = A(10) # create a reference d = weakref.WeakValueDictionary() d['primary'] = a # does not create a reference d['primary'] # fetch the object if it is still alive del a # remove the one reference gc.collect() # run garbage collection right away d['primary'] # entry was automatically removed ---------- components: Demos and Tools messages: 242534 nosy: jessembacon priority: normal severity: normal status: open title: Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary. type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 01:16:38 2015 From: report at bugs.python.org (Jesse Bacon) Date: Sun, 03 May 2015 23:16:38 +0000 Subject: [issue24123] Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary. In-Reply-To: <1430694938.29.0.0226350460002.issue24123@psf.upfronthosting.co.za> Message-ID: <1430694998.48.0.719174216365.issue24123@psf.upfronthosting.co.za> Jesse Bacon added the comment: https://docs.python.org/2/tutorial/stdlib2.html Section 11.6. Weak References The example code below from the python tutorial suggests that the value of 'a' is not persistent when cast into a WeakValueDictionary as entry 'primary' The value persisted in the dictionary aver 'a' was deleted and garbage collection had been called. I did not see a bug report for this already forgive me if there was one already put in. import weakref, gc class A: def __init__(self, value): self.value = value def __repr__(self): return str(self.value) a = A(10) # create a reference d = weakref.WeakValueDictionary() d['primary'] = a # does not create a reference d['primary'] # fetch the object if it is still alive del a # remove the one reference gc.collect() # run garbage collection right away d['primary'] # entry was automatically removed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 01:17:56 2015 From: report at bugs.python.org (Jesse Bacon) Date: Sun, 03 May 2015 23:17:56 +0000 Subject: [issue24123] Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary. In-Reply-To: <1430694938.29.0.0226350460002.issue24123@psf.upfronthosting.co.za> Message-ID: <1430695076.91.0.295229872863.issue24123@psf.upfronthosting.co.za> Jesse Bacon added the comment: https://docs.python.org/2/tutorial/stdlib2.html Section 11.6. Weak References The example code below from the python tutorial suggests that the value of 'a' is not persistent when cast into a WeakValueDictionary as entry 'primary' The value persisted in the dictionary after 'a' was deleted and garbage collection had been called. I did not see a bug report for this already forgive me if there was one already put in. import weakref, gc class A: def __init__(self, value): self.value = value def __repr__(self): return str(self.value) a = A(10) # create a reference d = weakref.WeakValueDictionary() d['primary'] = a # does not create a reference d['primary'] # fetch the object if it is still alive del a # remove the one reference gc.collect() # run garbage collection right away d['primary'] # entry was automatically removed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 02:09:40 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 04 May 2015 00:09:40 +0000 Subject: [issue24121] collections page doesn't mention that deques are mutable Message-ID: <1430698180.76.0.211782329748.issue24121@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Mutability is conferred by the presence of mutating methods. Deques are documented to have append, pop, extend, appendleft, popleft, extendleft, and rotate. Also the examples all show mutations. ---------- nosy: +rhettinger resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 02:35:08 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 May 2015 00:35:08 +0000 Subject: [issue21800] Implement RFC 6855 (IMAP Support for UTF-8) in imaplib. In-Reply-To: <1404175815.98.0.684783714649.issue21800@psf.upfronthosting.co.za> Message-ID: <1430699708.22.0.0779967005546.issue21800@psf.upfronthosting.co.za> R. David Murray added the comment: Here is an updated patch based on Milan's work, including docs. I've tweaked the API slightly: no dedicated method for doing the enable (instead it is inlined in authenticate), I added 'enable' to the exposed API (with a doc caveat about not using it for UTF8=ACCEPT), added None as a valid value for enable_UTF8 with the meaning "enable if possible" (True is now "must enable"), and exposed a utf8_enabled attribute so the program can easily tell what mode to use when specifying enable_UTF8=None. Someday, None should become the default. "None" is not the best choice for value, especially when it is not the default, so perhaps someone could suggest better values for that keyword. It would be great if Milan or Maciej could give me a review (or anyone else who feels like it). I want to get this in before the beta deadline. ---------- nosy: +eric.smith, maciej.szulik stage: needs patch -> patch review Added file: http://bugs.python.org/file39284/imaplib_utf8_issue21800.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 02:54:35 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 May 2015 00:54:35 +0000 Subject: [issue24123] Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary. In-Reply-To: <1430694938.29.0.0226350460002.issue24123@psf.upfronthosting.co.za> Message-ID: <1430700875.4.0.143853653605.issue24123@psf.upfronthosting.co.za> R. David Murray added the comment: If I run the example code you pasted using 2.7, I get a KeyError. So the example looks correct to me. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 03:16:34 2015 From: report at bugs.python.org (Jesse Bacon) Date: Mon, 04 May 2015 01:16:34 +0000 Subject: [issue24123] Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary. In-Reply-To: <1430700875.4.0.143853653605.issue24123@psf.upfronthosting.co.za> Message-ID: <62D474BD-BBE3-42E2-AC51-8FF9759E2671@me.com> Jesse Bacon added the comment: Thank you for the second eyes. I just verified that it works using the standard python shell. It looks like the bug is in IPython. I?ll post it there. In [7]: class A: ...: def __init__(self, value): ...: self.value = value ...: def __repr__(self): ...: return str(self.value) ...: In [8]: a = A(10) In [9]: d = weakref.WeakValueDictionary() In [10]: d['primary'] = a In [11]: d['primary'] Out[11]: 10 In [12]: del a In [13]: gc.collect() Out[13]: 148 In [14]: d['primary'] Out[14]: 10 In [15]: sincerely, Jesse Bacon > On May 3, 2015, at 8:54 PM, R. David Murray wrote: > > > R. David Murray added the comment: > > If I run the example code you pasted using 2.7, I get a KeyError. So the example looks correct to me. > > ---------- > nosy: +r.david.murray > > _______________________________________ > Python tracker > > _______________________________________ ---------- title: Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary. -> Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 03:44:21 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 04 May 2015 01:44:21 +0000 Subject: [issue16344] Traceback Internationalization Proposal In-Reply-To: <1351407457.67.0.14897287706.issue16344@psf.upfronthosting.co.za> Message-ID: <1430703861.73.0.462664548235.issue16344@psf.upfronthosting.co.za> Steven D'Aprano added the comment: For what it's worth, there are at least two localised versions of Python: Teuton and ChinesePython. As far as I know, ChinesePython is still in active development. Both translate the keywords and builtins, to German and Chinese respectively. I don't have a link, but I recall that Guido gave his blessing for ChinesePython to call itself a Python implementation. There's a localised, Portuguese version of Stack Overflow: http://blog.stackoverflow.com/2014/02/cant-we-all-be-reasonable-and-speak-english/ so I think that the days when all programmers must learn English are slowly fading away, just like the days when all mathematicians had to learn German. But, I agree with those who say that a PEP is necessary. There are a lot of factors to consider. (Although of course as a third-party library, no PEP would be needed.) ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 04:44:41 2015 From: report at bugs.python.org (Jesse Bacon) Date: Mon, 04 May 2015 02:44:41 +0000 Subject: [issue24123] Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary. In-Reply-To: <1430694938.29.0.0226350460002.issue24123@psf.upfronthosting.co.za> Message-ID: <1430707481.22.0.591267468355.issue24123@psf.upfronthosting.co.za> Jesse Bacon added the comment: After further testing it appears that the bug is in IPython not Python 2.7. The bug has been moved to the Python list at https://github.com/ipython/ipython/issues/8403#issuecomment-98565759 ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 06:36:21 2015 From: report at bugs.python.org (Mariano Reingart) Date: Mon, 04 May 2015 04:36:21 +0000 Subject: [issue16344] Traceback Internationalization Proposal In-Reply-To: <1351407457.67.0.14897287706.issue16344@psf.upfronthosting.co.za> Message-ID: <1430714181.59.0.0374206864501.issue16344@psf.upfronthosting.co.za> Mariano Reingart added the comment: Just for the record, I've presented a "CPython Internationalization proposal" for this year Google Summer of Code program: http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/reingart/5634387206995968 Indeed, that was my third attempt to move it forward (you can look there for the implications, schedule, etc.) Anyway, it didn't get accepted (and I have no more feedback from GSoC than that), so I will not be able to focus on this and finish it in 3 months as planned, but I'll do my best. Currently I'm cloning the CPython repository under my GitHub account to work on it (as I would have done if the GSoC project was approved): https://github.com/reingart/python/ It was exported using hg-git so it can be easily updated or get collaborations back with mercurial, just using GitHub to publish it. BTW, the PEP was hanging around since 2010 (see the attached file in 2012 for example), now I uploaded it in GitHub so it can be collaboratively edited: https://github.com/reingart/python/wiki/PEP-i18n I will re-organize / re-base the patch and update the PEP ASAP. PS: Yes, it seems that "the days when all programmers must learn English" are fading away, Visual Basic 5 was internationalized around 20 years ago (indeed, I learned VB as one of my first "real" languages as it had completely Spanish translations for errors and online built-in F1 help, in a CDROM those days). The first "logo" programming language my father brought to may home around 30 years ago, also was in Spanish IIRC (for a Spectrum TK90). Even gcc and bash are internationalized nowadays :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 07:28:04 2015 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 04 May 2015 05:28:04 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1430717284.43.0.498983197799.issue23857@psf.upfronthosting.co.za> Nick Coghlan added the comment: After further consideration, I realised there's an important difference between this case and the hash randomisation case: having the "-E" switch imply hash randomisation was OK, but having it imply HTTPS certificate verification after the system administrator has explicitly turned it off is going to cause problems. The system administrator controlled configuration file gets around that by not relying on the interpreter's environment variable based configuration support. As a result, I've now recommended pursuing the configuration file based approach, with a PEP to standardise the precise name, format and semantics for the configuration file: https://bugzilla.redhat.com/show_bug.cgi?id=1173041#c8 Redistributors would opt-in by patching their system Python to implement that informational PEP, rather than the feature appearing in upstream CPython itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 09:05:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 May 2015 07:05:27 +0000 Subject: [issue20159] Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1430723127.31.0.0753671612487.issue20159@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Made compatible with Windows compiler (I hope). ---------- Added file: http://bugs.python.org/file39285/etree_clinic_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 09:17:35 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 04 May 2015 07:17:35 +0000 Subject: [issue20159] Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1430723855.94.0.99692081469.issue20159@psf.upfronthosting.co.za> Larry Hastings added the comment: LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 09:47:06 2015 From: report at bugs.python.org (Russell Keith-Magee) Date: Mon, 04 May 2015 07:47:06 +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: <1430725626.44.0.242746802188.issue23670@psf.upfronthosting.co.za> Russell Keith-Magee added the comment: This new patch (20150504.diff) adds support for running the Python test suite The new patch is standalone, and contains everything in the previous patch. An XCode project (Tools/iOS-test) has been added to the source tree; this project contains bootstrap C code to start and run the full Python regression test suite. There's also a new target in the iOS/Makefile meta-buildfile - "make test" - which will compile a debug version of the Python framework, and install it into the iOS-test project. Getting the test suite to run has revealed one major limitation of the iOS platform - system calls like fork, exec*, and spawn* don't work. The OS calls *exist* at an API level - but if you use them, they either crash, or they lock up the device while you wait for a subprocess that will never execute. This makes sense considering the platform itself - there's no such thing as a "background process" in iOS; background tasks are very heavily sandboxed. A number of other minor problems have been identified as a result of running the full test suite; they have been addressed in the patch. The test suite still has 5 failures on the simulator. I'm investigating the cause of these failures. There's a couple of more failures on a physical device - 13 failures in total. These device-specific failures appear to be largely due to ctypes problems and a permissions issue with os.mkdir. If you run the test suite in XCode as a debug binary, the debugger will stop whenever a SIGPIPE, SIGINT, SIGXFSZ, SIGUSR1 or SIGUSR2 signal is raised. You can just hit continue in the debugger, and the test will continue. To work around this, you need to run the following debugger commands before the first signal is raised: process handle SIGPIPE -n true -p true -s false process handle SIGINT -n true -p true -s false process handle SIGXFSZ -n true -p true -s false process handle SIGUSR1 -n true -p true -s false process handle SIGUSR2 -n true -p true -s false I've been doing this by setting a breakpoint in the main.c method; I'm investigating other ways to automate this. ---------- Added file: http://bugs.python.org/file39286/20150504.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 10:50:16 2015 From: report at bugs.python.org (Wessel Badenhorst) Date: Mon, 04 May 2015 08:50:16 +0000 Subject: [issue2824] zipfile to handle duplicate files in archive In-Reply-To: <1210537070.35.0.0613996133193.issue2824@psf.upfronthosting.co.za> Message-ID: <1430729416.67.0.647881674234.issue2824@psf.upfronthosting.co.za> Changes by Wessel Badenhorst : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 10:56:38 2015 From: report at bugs.python.org (Wessel Badenhorst) Date: Mon, 04 May 2015 08:56:38 +0000 Subject: [issue3539] Problem with testembed make dependencies in certain circumstances In-Reply-To: <1218416155.29.0.722740811463.issue3539@psf.upfronthosting.co.za> Message-ID: <1430729798.39.0.0394784081527.issue3539@psf.upfronthosting.co.za> Changes by Wessel Badenhorst : ---------- type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 10:58:23 2015 From: report at bugs.python.org (Wessel Badenhorst) Date: Mon, 04 May 2015 08:58:23 +0000 Subject: [issue3786] _curses, _curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio 12 In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za> Message-ID: <1430729903.08.0.591339512907.issue3786@psf.upfronthosting.co.za> Changes by Wessel Badenhorst : ---------- type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 11:27:30 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 04 May 2015 09:27:30 +0000 Subject: [issue24122] Install fails after configure sets the extending/embedding install directory to NONE In-Reply-To: <1430682171.19.0.329693037889.issue24122@psf.upfronthosting.co.za> Message-ID: <1430731650.74.0.681161672915.issue24122@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 11:57:14 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 04 May 2015 09:57:14 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1430733434.33.0.866503853686.issue15993@psf.upfronthosting.co.za> Mark Lawrence added the comment: Is this now fixed in VS? I don't believe I can test myself as I've only got express/community editions. ---------- components: +Windows nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 12:52:15 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 May 2015 10:52:15 +0000 Subject: [issue24123] Python 2.7 Tutorial Conflicting behavior with WeakValueDictionary. In-Reply-To: <1430694938.29.0.0226350460002.issue24123@psf.upfronthosting.co.za> Message-ID: <1430736735.53.0.738214177098.issue24123@psf.upfronthosting.co.za> R. David Murray added the comment: Well, technically it is probably not a bug. IPython is doubtless holding on to a reference to 'a' because it was defined at the prompt. Perhaps it could use a weakvaluedict for that, though :) On the other hand they might consider it a feature that objects don't go out of scope. ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 13:21:46 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 04 May 2015 11:21:46 +0000 Subject: [issue24099] Use after free in siftdown (1) In-Reply-To: <1430489480.16.0.0840319770251.issue24099@psf.upfronthosting.co.za> Message-ID: <1430738506.5.0.794577174262.issue24099@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 13:22:19 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 04 May 2015 11:22:19 +0000 Subject: [issue24101] Use after free in siftup In-Reply-To: <1430489575.51.0.442803283693.issue24101@psf.upfronthosting.co.za> Message-ID: <1430738539.92.0.737637689559.issue24101@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 13:22:45 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 04 May 2015 11:22:45 +0000 Subject: [issue24100] Use after free in siftdown (2) In-Reply-To: <1430489541.93.0.209728480757.issue24100@psf.upfronthosting.co.za> Message-ID: <1430738565.91.0.6565146173.issue24100@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 13:30:31 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 04 May 2015 11:30:31 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1430739031.59.0.286335670591.issue20179@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I can propose three remedies: > > A) back out the Clinic conversion in _ssl.c > B) support Clinic in 2.7 just for _ssl.c > C) do a one-time backport of the Clinic generated code for _ssl.c I'd rather have A or C than B. By the way, this discussion seems to focus on 2.7, but the same issue happens with 3.4 (although Clinic already exists here, so we can just backport Serhiy's work). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 13:34:48 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 04 May 2015 11:34:48 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1430739288.43.0.346891267148.issue20179@psf.upfronthosting.co.za> Larry Hastings added the comment: Clinic's syntax is diverging from what shipped with 3.4. So if you copied _ssl.c over, it wouldn't work with the Clinic that shipped with 3.4. Maybe the best thing is if Clinic in trunk supports "legacy mode", where the code it generates is compatible with previous Python versions. That's basically B but without doing something crazy like shipping Clinic with 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 14:33:29 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 May 2015 12:33:29 +0000 Subject: [issue20159] Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <20150504123327.1933.71075@psf.io> Roundup Robot added the comment: New changeset fea94f9cb5a0 by Serhiy Storchaka in branch 'default': Issue #20159. Converted the _elementtree module to Argument Clinic. https://hg.python.org/cpython/rev/fea94f9cb5a0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 14:42:35 2015 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 04 May 2015 12:42:35 +0000 Subject: [issue24116] --with-pydebug has no effect when the final python binary is compiled In-Reply-To: <1430637278.73.0.597162622661.issue24116@psf.upfronthosting.co.za> Message-ID: <1430743355.81.0.0380764007965.issue24116@psf.upfronthosting.co.za> Skip Montanaro added the comment: > It's confusing that the CFLAGS specified when running make are passed further sometimes but not always. So I guess that's a workaround? Or CFLAGS should never be specified to make directly? In my experience, all the magic happens in configure. Most of the time, the only flag I give to make is -j to specify parallelism. Is there somewhere in the build docs this could be made clearer? ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 14:47:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 May 2015 12:47:16 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1430743636.58.0.812531061241.issue20168@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 14:47:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 May 2015 12:47:41 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1430743661.26.0.3838699816.issue20148@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 14:51:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 May 2015 12:51:40 +0000 Subject: [issue20159] Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1430743900.39.0.712451450568.issue20159@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Original issue is resolved and I have no any relations to modules added by Larry. ---------- dependencies: -Add docstrings for ElementTree module stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 14:52:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 May 2015 12:52:21 +0000 Subject: [issue20159] Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1430743941.3.0.222788817047.issue20159@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: -serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 15:01:36 2015 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 04 May 2015 13:01:36 +0000 Subject: [issue24124] Two versions of instructions for installing Python modules Message-ID: <1430744496.1.0.475235677565.issue24124@psf.upfronthosting.co.za> New submission from Skip Montanaro: I was hunting around the current website for notes on installing Python. Couldn't find any (BTW), so I looked in the Python source. Imagine my surprise to find two apparently overlapping files describing how to build Python modules: ./Doc/install/index.rst ./Doc/installing/index.rst The former is marked "Legacy version." The latter seems to cover mostly installation of third-party modules using tools like pip. The former covers distutils. Oddly enough, the "legacy" version seems to have been updated more recently than the presumably current version. Do we really need to keep both versions around at this point? Should they be merged into a single document? If they are to both be retained, should the legacy version be marked as such more clearly and refer readers to the pip/pyvenv/virtualenv version? ---------- assignee: docs at python components: Documentation messages: 242555 nosy: docs at python, skip.montanaro priority: normal severity: normal status: open title: Two versions of instructions for installing Python modules versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 15:21:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 May 2015 13:21:06 +0000 Subject: [issue24102] Multiple type confusions in unicode error handlers In-Reply-To: <1430489646.71.0.827069473585.issue24102@psf.upfronthosting.co.za> Message-ID: <1430745666.6.0.754150915504.issue24102@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Also fixed handling errors of PyObject_IsSubclass() (issue24115) in the _codecs module. ---------- Added file: http://bugs.python.org/file39287/codecs_error_handlers_issubclass_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 15:55:45 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 04 May 2015 13:55:45 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430747745.92.0.282076701018.issue23911@psf.upfronthosting.co.za> Larry Hastings added the comment: This checkin broke the buildbots. If you build trunk then run ./python -bb -m test test_site the test fails. "-bb" is used by the normal test runner ("make test"). The problem is in the lines self.assertTrue(os.path.isabs(os__file__), "expected absolute path, got {}".format(os__file__)) self.assertTrue(os.path.isabs(os__cached__), "expected absolute path, got {}".format(os__cached__)) os__file__ and os__cached__ are bytes but you're passing them into .format() on a str. ---------- nosy: +larry resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 16:00:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 May 2015 14:00:11 +0000 Subject: [issue24001] Clinic: use raw types in types= set In-Reply-To: <1429405577.22.0.134829799978.issue24001@psf.upfronthosting.co.za> Message-ID: <20150504140008.8147.19133@psf.io> Roundup Robot added the comment: New changeset 41fb7fd04b5d by Larry Hastings in branch 'default': Issue #24001: Argument Clinic converters now use accept={type} https://hg.python.org/cpython/rev/41fb7fd04b5d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 16:10:50 2015 From: report at bugs.python.org (Jim Jewett) Date: Mon, 04 May 2015 14:10:50 +0000 Subject: [issue24088] yield expression confusion In-Reply-To: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za> Message-ID: <1430748650.29.0.345720111007.issue24088@psf.upfronthosting.co.za> Jim Jewett added the comment: OK, then how about Current: """ When a generator function is called, it returns an iterator known as a generator. That generator then controls the execution of a generator function. The execution starts when one of the generator?s methods is called. """ Proposed: """ When a generator function is called, it does not complete its execution immediately. Instead, it keeps its execution frame intact, and returns a special kind of iterator known as a generator. The iteration starts when one of the generator?s methods is called, and the generator executes within the existing generator frame, rather than creating a new one. """ This still seems to suggest that the generator uses the same frame as the generator function that created it; I was not aware that this was a guarantee. (Reusing the same frame, yes. Reusing that particular frame, no.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 16:15:13 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 04 May 2015 14:15:13 +0000 Subject: [issue24119] Carry comments with the AST In-Reply-To: <1430666470.75.0.339272692521.issue24119@psf.upfronthosting.co.za> Message-ID: <1430748913.53.0.556111371158.issue24119@psf.upfronthosting.co.za> Brett Cannon added the comment: Normally I would agree comments don't belong there, but if we are going to start giving them semantic meaning then I don't think it's not so clear to me anymore. As to where to attach, simple place is off of the Module node. Another is to have it be fundamental like lineno and only attach it when it is a line-trailing comment. Yes, the tokenize module will give you the comments as well, but it is unfortunate you have to parse the code twice in order to get the comments and the AST. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 16:22:31 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 May 2015 14:22:31 +0000 Subject: [issue24088] yield expression confusion In-Reply-To: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za> Message-ID: <1430749351.41.0.731297950498.issue24088@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think anything about frames is guaranteed as part of the language, so I'm not sure that mention of it belongs in the description. Personally, I find your reformulation more confusing that the original with 'a' replaced by 'the'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 16:33:51 2015 From: report at bugs.python.org (Christian Heimes) Date: Mon, 04 May 2015 14:33:51 +0000 Subject: [issue24119] Carry comments with the AST In-Reply-To: <1430666470.75.0.339272692521.issue24119@psf.upfronthosting.co.za> Message-ID: <1430750031.63.0.176282150719.issue24119@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 17:04:21 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 04 May 2015 15:04:21 +0000 Subject: [issue24001] Clinic: use raw types in types= set In-Reply-To: <1429405577.22.0.134829799978.issue24001@psf.upfronthosting.co.za> Message-ID: <1430751861.04.0.746633725716.issue24001@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 17:07:38 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 04 May 2015 15:07:38 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1430752058.43.0.921684442341.issue24000@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's a freshened version of the patch. I updated the Clinic HOWTO. Serhiy: You're right, length and zeroes always have the same value. Would you ever want length without allowing zeroes? Like, in the future, would we ever want str(length=True) so we're passed in the length but we still don't want to allow zeroes? ---------- Added file: http://bugs.python.org/file39288/larry.one.more.clinic.format.unit.map.cleanup.4.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 17:26:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 May 2015 15:26:30 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1430753190.38.0.145370711938.issue24000@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I would say it is very unlikely. In any case, if we have a pointer and a length, we always can check for zeros after parsing. May be rename the str converter to pchar and the Py_UNICODE converter to pwchar? Usually the converter is named by C type, not Python type. "y" and "y#" even don't accept str. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 19:09:03 2015 From: report at bugs.python.org (Trevor Bekolay) Date: Mon, 04 May 2015 17:09:03 +0000 Subject: [issue24086] Configparser interpolation is unexpected In-Reply-To: <1430421130.2.0.837084015548.issue24086@psf.upfronthosting.co.za> Message-ID: <1430759343.91.0.8393317976.issue24086@psf.upfronthosting.co.za> Trevor Bekolay added the comment: Thanks for the quick response! I can see the use case for using interpolation in .pypirc. Unfortunately for me, I push releases for both Python 2 and Python 3, so having the double percent sign will cause problems for me on Python 2. The exception that's being raised is at line 442 (https://hg.python.org/cpython/file/default/Lib/configparser.py#l442). The message itself seems to have the right information, but setuptools seems to mangle it (perhaps InterpolationSyntaxError needs a __repr__ or __str__?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 19:48:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 May 2015 17:48:56 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <20150504174851.7810.62746@psf.io> Roundup Robot added the comment: New changeset 36b902bbc992 by Eric Snow in branch 'default': Issue #23911: Fix mixed bytes/strings. https://hg.python.org/cpython/rev/36b902bbc992 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 19:53:13 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 04 May 2015 17:53:13 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430761993.8.0.96320014497.issue23911@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- resolution: -> fixed status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 20:08:39 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 04 May 2015 18:08:39 +0000 Subject: [issue3367] Uninitialized value read in parsetok.c In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za> Message-ID: <1430762919.14.0.327382873902.issue3367@psf.upfronthosting.co.za> Mark Lawrence added the comment: The fix proposed by Alexander in issue3367.diff has never been applied. How would I go about reproducing the original issue on Windows? ---------- nosy: +BreamoreBoy versions: +Python 3.4, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 20:36:12 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 04 May 2015 18:36:12 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1430764572.31.0.946716546087.issue24000@psf.upfronthosting.co.za> Larry Hastings added the comment: I have no interest in naming "str" to "pchar". Yes, *most* of the other converters are named after the C type they translate to. But so far converter names doesn't mention whether or not they represent pointers to types--it's "object", not "pobject", it's "PyBytesObject", not "pPyBytesObject". That suggests the name "char" for the converter. But we've already got a "char", and it would be confusing to use that one converter for both chars (small ints / single characters) and strings. Adding "p" in front is not a convention we've ever used. The word "pchar" does not appear in the Python source tree. So the name "pchar" has no mnemonic value. If I were to follow your advice, I should prefer the name "char_star". But now we're using nine letters for what is almost certainly the most common converter. And, again, the generic converter for objects is called "object", I do not propose to rename it to "object_star". So this converter's name would be an exception to the rule. But then again, C strings themselves are an exception to the rule. They're not a built-in type as much as they are a *convention*. So any name we give it will ultimately be something of a compromise. And as compromises go "str" is great. So far nobody has been confused by it. It's short, and universally, instantly clear as to its meaning. Furthermore, converters don't actually represent a C type. They represent a *mapping*, from a Python type (or types) to a single C type. So while it's a useful and productive convention to name converters after the type they convert to, it's hardly mandatory. And it would be a shame to squander clarity in service to a needless consistency. p.s. If we hold ourselves to this firm ideal, where every converter is named after its C type, what should we call the "bool" converter? What should we call the "self" converter? What should you call your proposed "boolint" converter? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 20:46:25 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 04 May 2015 18:46:25 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1430765185.21.0.897378751518.issue24000@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's an updated patch where I've removed the "length" parameter to converters, instead relying solely on the "zeroes" parameter. ---------- Added file: http://bugs.python.org/file39289/larry.one.more.clinic.format.unit.map.cleanup.5.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 20:56:47 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 04 May 2015 18:56:47 +0000 Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime Message-ID: <1430765807.85.0.249697963204.issue1100942@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Alexander as the datetime expert could you get this committed in time for 3.5? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 21:11:36 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 04 May 2015 19:11:36 +0000 Subject: [issue17477] update the bsddb module do build with db 5.x versions In-Reply-To: <1363671295.4.0.641867038298.issue17477@psf.upfronthosting.co.za> Message-ID: <1430766696.39.0.796696273971.issue17477@psf.upfronthosting.co.za> Mark Lawrence added the comment: >From http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index.html the latest version is 6.1.23. Given the extended life span of 2.7 I'd assume that the patch here is worth updating. See also #18734. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 21:15:39 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 04 May 2015 19:15:39 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1430766939.35.0.410106598443.issue24000@psf.upfronthosting.co.za> Larry Hastings added the comment: As for "str doesn't even accept str for y and y#", the name "str" is not for the Python type, it's for the C type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 21:17:21 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 04 May 2015 19:17:21 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430767041.68.0.879695713866.issue23911@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 21:28:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 May 2015 19:28:01 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1430767681.45.0.655204909687.issue24000@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why not left the length parameter instead? First, current code uses "length". Second, the main effect from C side is that an argument is a pair (pointer, length), not just a pointer. Third, currently everywhere in Python documentation and error messages the used term is "null character/byte", so if left the zeros parameter, it should be renamed to allow_nulls or allow_nuls. Fourth, "y#" needs zeros=True for distinguish from "y", but "y*" allows nulls and has no the zeros parameter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 21:31:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 May 2015 19:31:09 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1430767869.87.0.087372353981.issue24000@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be "string", or "data", or "buffer" would be better names? "str" looks as Python type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 21:37:08 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 04 May 2015 19:37:08 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1430768228.17.0.476930944298.issue24000@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't think those are better names. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 21:44:31 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 04 May 2015 19:44:31 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1430768671.63.0.312833189219.issue24000@psf.upfronthosting.co.za> Larry Hastings added the comment: As for "why not length instead of zeroes": Because the primary reason for the parameter is specifying that the string can contain embedded zeroes. Returning the length is a side-effect of this, not the main point. If the string didn't have embedded zeroes, we wouldn't need the length. The only reason the code didn't have "zeroes=True" everywhere was because I screwed up and didn't realize all those mappings *should* have specified it. The documentation is very consistent about calling it a NUL. I don't think "NUL=True" or "allow_NUL=true" is particularly attractive; we never (almost never?) use capital letters in parameter names. So any other name is going to be a compromise. "allow_null" and "allow_nul" are misspellings, and don't convey the idea any better; they can confuse the reader with the related concept of NULL or None. At least "zeroes" has the benefit of being an actual word, representing a related concept. Will you be done bikeshedding soon? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 21:58:58 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 04 May 2015 19:58:58 +0000 Subject: [issue21069] test_fileno of test_urllibnet intermittently fails when using www.example.com In-Reply-To: <1395821437.54.0.612861702522.issue21069@psf.upfronthosting.co.za> Message-ID: <1430769538.54.0.698993352843.issue21069@psf.upfronthosting.co.za> Mark Lawrence added the comment: I tried reproducing this on Windows 8.1 with the code snippet from msg216429 but got Traceback (most recent call last): File "C:\Users\Mark\Documents\MyPython\mytest.py", line 9, in with os.fdopen(fd, 'rb') as f: File "c:\python34\lib\os.py", line 980, in fdopen return io.open(fd, *args, **kwargs) OSError: [Errno 9] Bad file descriptor Is there something else that I can try? Is this still an issue that needs looking into? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 22:16:51 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 04 May 2015 20:16:51 +0000 Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX addresses In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za> Message-ID: <1430770611.15.0.830453602253.issue8372@psf.upfronthosting.co.za> Mark Lawrence added the comment: As this is flagged as a high priority security issue shouldn't we be implementing needed source code changes? According to msg138224 "The patches look good to me". ---------- nosy: +BreamoreBoy versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 22:16:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 May 2015 20:16:53 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1430770613.24.0.292378982155.issue24000@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In Python 2 and earlier in Python 3 there were no restrictions that arguments for format units "s", "y", "u", "z" and "Z" (matching Argument Clinic converters with length=False) shouldn't contain NUL. And this was considered as a bug. As for NUL, ask Victor. It argued for naming it "null character/byte" and it was consistently changed almost everywhere (left some documentation, but this will be fixed soon). larry.one.more.clinic.format.unit.map.cleanup.5.txt looks almost good to me, but I hesitate about the zeroes parameter. str_converter has the zeroes parameter, but the length attribute. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 22:36:12 2015 From: report at bugs.python.org (Dmitry Shachnev) Date: Mon, 04 May 2015 20:36:12 +0000 Subject: [issue24125] Fix for #23865 breaks docutils Message-ID: <1430771772.5.0.0533343511671.issue24125@psf.upfronthosting.co.za> New submission from Dmitry Shachnev: Fix for issue #23865 (i.e. https://hg.python.org/cpython/rev/f7ddec2e9e93 in 2.7 branch) introduced a change for xml.sax.expatreader.ExpatParser class that makes its close() method delete _parser object. This breaks docutils, which handles exceptions in parse() and tries to use getColumnNumber() after it fails. The log is available here: . I believe that particular chunk should be reverted. ---------- components: Library (Lib) messages: 242579 nosy: doko, goodger, mitya57, serhiy.storchaka priority: normal severity: normal status: open title: Fix for #23865 breaks docutils versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 22:37:52 2015 From: report at bugs.python.org (Dmitry Shachnev) Date: Mon, 04 May 2015 20:37:52 +0000 Subject: [issue23865] Fix possible leaks in close methods In-Reply-To: <1428145980.2.0.463866688715.issue23865@psf.upfronthosting.co.za> Message-ID: <1430771872.38.0.587530330925.issue23865@psf.upfronthosting.co.za> Dmitry Shachnev added the comment: This broke docutils, see issue #24125. ---------- nosy: +mitya57 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 22:39:05 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 04 May 2015 20:39:05 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1430771945.15.0.186665180935.issue24000@psf.upfronthosting.co.za> Larry Hastings added the comment: The length attribute is an internal implementation detail, so its name is not relevant. It's used in the generation of the accompanying "length" parameter for the impl function for this converter. "length" is a good name for it. "zeroes" is not a good name for it. "zeroes" is, however, a decent name for the converter parameter. I have no quarrel with the documentation using the term NUL. But I don't think the term translates well to use parameter names. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 22:40:01 2015 From: report at bugs.python.org (Matthias Klose) Date: Mon, 04 May 2015 20:40:01 +0000 Subject: [issue24125] Fix for #23865 breaks docutils In-Reply-To: <1430771772.5.0.0533343511671.issue24125@psf.upfronthosting.co.za> Message-ID: <1430772001.86.0.669962961939.issue24125@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- nosy: +benjamin.peterson priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 22:41:20 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 04 May 2015 20:41:20 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1430772080.08.0.48759920098.issue24000@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't know why you're bringing up previous versions of Python. The clinic.py under review here is for 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 22:43:23 2015 From: report at bugs.python.org (Dmitry Shachnev) Date: Mon, 04 May 2015 20:43:23 +0000 Subject: [issue24125] Fix for #23865 breaks docutils In-Reply-To: <1430771772.5.0.0533343511671.issue24125@psf.upfronthosting.co.za> Message-ID: <1430772203.76.0.452395158146.issue24125@psf.upfronthosting.co.za> Changes by Dmitry Shachnev : ---------- nosy: +larry versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 23:31:13 2015 From: report at bugs.python.org (Buck Evan) Date: Mon, 04 May 2015 21:31:13 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430775073.84.0.0182549008025.issue24085@psf.upfronthosting.co.za> Buck Evan added the comment: @serhiy.storchaka This is a very stable piece of a legacy code base, so we're not keen to refactor it so dramatically, although we could. We've worked around this issue by compiling pyc files ahead of time and taking extra care that they're preserved through deployment. This isn't blocking our 2.7 transition anymore. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 4 23:40:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 May 2015 21:40:04 +0000 Subject: [issue24125] Fix for #23865 breaks docutils In-Reply-To: <1430771772.5.0.0533343511671.issue24125@psf.upfronthosting.co.za> Message-ID: <1430775604.34.0.662229816137.issue24125@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that keeps error column and line after closing ExpatParser if error was occurred. ---------- keywords: +patch stage: -> patch review type: -> behavior versions: +Python 3.5 Added file: http://bugs.python.org/file39290/expatreader_keep_col_line.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 00:21:17 2015 From: report at bugs.python.org (David D. Riddle) Date: Mon, 04 May 2015 22:21:17 +0000 Subject: [issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x) In-Reply-To: <1429893933.08.0.150501464744.issue24054@psf.upfronthosting.co.za> Message-ID: <1430778077.23.0.94749939436.issue24054@psf.upfronthosting.co.za> David D. Riddle added the comment: I have made the changes you suggested. Please tell me if any further changes are needed. > The unclosed file suggests a cleanup bug in linecache which we should > fix for hygiene, but is separate :) Should I file a bug report? ---------- Added file: http://bugs.python.org/file39291/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 02:52:20 2015 From: report at bugs.python.org (Ma Lin) Date: Tue, 05 May 2015 00:52:20 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1430787140.94.0.235676634957.issue24117@psf.upfronthosting.co.za> Ma Lin added the comment: I found another bug in hz codec. hz encoding uses 7-bit ASCII to represent Chinese characters, it was popular in USENET networks in the late 1980s and early 1990s. I will do more check and fix them together, then I will invite you to review the patch. u = 'hi~python' b = u.encode('hz') # bug in this step, the right sequence should be b"hi~~python" print(b) # the output is b"hi~python" u = b.decode('hz') # so can't decode, UnicodeDecodeError raised print(u) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 04:45:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 May 2015 02:45:57 +0000 Subject: [issue24113] shlex constructor unreachable code In-Reply-To: <1430574110.71.0.619526001392.issue24113@psf.upfronthosting.co.za> Message-ID: <20150505024551.76598.53731@psf.io> Roundup Robot added the comment: New changeset 395e190ead36 by Raymond Hettinger in branch 'default': Issue #24113: Remove unreachable code in shlex. https://hg.python.org/cpython/rev/395e190ead36 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 04:46:39 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 05 May 2015 02:46:39 +0000 Subject: [issue24113] shlex constructor unreachable code In-Reply-To: <1430574110.71.0.619526001392.issue24113@psf.upfronthosting.co.za> Message-ID: <1430793999.32.0.971908869925.issue24113@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- priority: normal -> low resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 04:51:45 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 05 May 2015 02:51:45 +0000 Subject: [issue24113] shlex constructor unreachable code In-Reply-To: <1430574110.71.0.619526001392.issue24113@psf.upfronthosting.co.za> Message-ID: <1430794305.29.0.426169995031.issue24113@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 08:04:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 May 2015 06:04:04 +0000 Subject: [issue20184] Derby #16: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140504.71.0.617730511292.issue20184@psf.upfronthosting.co.za> Message-ID: <1430805844.23.0.351321933914.issue20184@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that converts 3 functions in the _json module to Argument Clinic. All other functions doesn't fit with Argument Clinic. ---------- Added file: http://bugs.python.org/file39292/json_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 10:02:19 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 05 May 2015 08:02:19 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1430812939.6.0.959126841324.issue23955@psf.upfronthosting.co.za> Nick Coghlan added the comment: Issue 23857 was the one where I thought there might be an overlap with a design consideration on Linux (related to coming up with a conventional for backporting PEP 476 as a CPython redistributor). However, I've now suggested a different path forward there, closer to what happened with PEP 394 (which provides guidance to redistributors on symlink definitions, without making any changes to upstream CPython itself). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 10:37:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 May 2015 08:37:25 +0000 Subject: [issue20303] Argument Clinic: optional groups In-Reply-To: <1390138180.16.0.400473002032.issue20303@psf.upfronthosting.co.za> Message-ID: <1430815045.2.0.940146497778.issue20303@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I tried to make a workaround with using default value instead of optional group, but for the following declaration an incorrect code is generated: /*[clinic input] _curses.window.getstr [ y: int Y-coordinate. x: int X-coordinate. ] n: int = 1023 / [clinic start generated code]*/ Generated code is: static PyObject * _curses_window_getstr(PyCursesWindowObject *self, PyObject *args) { PyObject *return_value = NULL; int group_left_1 = 0; int y = 0; int x = 0; int n = 1023; switch (PyTuple_GET_SIZE(args)) { case 1: if (!PyArg_ParseTuple(args, "i:getstr", &n)) goto exit; break; case 3: if (!PyArg_ParseTuple(args, "iii:getstr", &y, &x, &n)) goto exit; group_left_1 = 1; break; default: PyErr_SetString(PyExc_TypeError, "_curses.window.getstr requires 1 to 3 arguments"); goto exit; } return_value = _curses_window_getstr_impl(self, group_left_1, y, x, n); exit: return return_value; } Expected generated code: static PyObject * _curses_window_getstr(PyCursesWindowObject *self, PyObject *args) { PyObject *return_value = NULL; int group_left_1 = 0; int y = 0; int x = 0; int n = 1023; switch (PyTuple_GET_SIZE(args)) { case 0: case 1: if (!PyArg_ParseTuple(args, "|i:getstr", &n)) goto exit; break; case 2: case 3: if (!PyArg_ParseTuple(args, "ii|i:getstr", &y, &x, &n)) goto exit; group_left_1 = 1; break; default: PyErr_SetString(PyExc_TypeError, "_curses.window.getstr requires 0 to 3 arguments"); goto exit; } return_value = _curses_window_getstr_impl(self, group_left_1, y, x, n); exit: return return_value; } This bug looks similar to issue24051. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 10:53:35 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 05 May 2015 08:53:35 +0000 Subject: [issue24122] Install fails after configure sets the extending/embedding install directory to NONE In-Reply-To: <1430682171.19.0.329693037889.issue24122@psf.upfronthosting.co.za> Message-ID: <1430816015.08.0.458349987711.issue24122@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Installing the april 20 pre-release Python 3.5.0a4: $ tar xJf Python-3.5.0a4.tar.xz $ cd Python-3.5.0a4 && ./configure $ grep "LIBPL=" Makefile LIBPL= NONE/lib/python3.5/config-$(VERSION)$(ABIFLAGS) $ make all $ sudo make install $ ls -ld /usr/local/lib/python3.5/config-3.5* ls: cannot access /usr/local/lib/python3.5/config-3.5*: No such file or directory Installing the default branch patched at changeset bfea101f9402: $ make distclean && ./configure $ grep "LIBPL=" Makefile LIBPL= /usr/local/lib/python3.5/config-$(VERSION)$(ABIFLAGS) $ make all $ sudo make install $ ls -ld /usr/local/lib/python3.5/config-3.5* drwxr-xr-x 2 root root 4.0K May 5 10:32 /usr/local/lib/python3.5/config-3.5dm/ FWIW the regression was introduced by the change to LIBPL in Makefile.pre.in made by changeset 3d3db6d11e8b. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 10:59:02 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 05 May 2015 08:59:02 +0000 Subject: [issue24122] Install fails after configure sets the extending/embedding install directory to NONE In-Reply-To: <1430682171.19.0.329693037889.issue24122@psf.upfronthosting.co.za> Message-ID: <1430816342.15.0.781440574442.issue24122@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > FWIW the regression was introduced by the change to LIBPL in Makefile.pre.in made by changeset 3d3db6d11e8b. Ooops, the regression was made by changeset 84328374ea01. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 11:21:49 2015 From: report at bugs.python.org (Davide Mancusi) Date: Tue, 05 May 2015 09:21:49 +0000 Subject: [issue24126] newlines attribute does not get set after calling readline() Message-ID: <1430817708.97.0.91476502488.issue24126@psf.upfronthosting.co.za> New submission from Davide Mancusi: I have a text file with Windows-style line terminators (\r\n) which I open in universal newlines mode. I would expect the newlines attribute to be set after the first call to the readline() method, but apparently this is not the case: >>> f=open('test_crlf', 'rU') >>> f.newlines >>> f.readline() 'foo\n' >>> f.newlines >>> f.readline() 'bar\n' >>> f.newlines '\r\n' On the other hand, the newlines attribute gets set after the first call to readline() on a file with Unix-style line endings. Also, surprisingly, calling tell() after the first readline() is enough to update the newlines attribute: >>> f=open('test_crlf', 'rU') >>> f.newlines >>> f.readline() 'foo\n' >>> f.newlines >>> f.tell() 77 >>> f.newlines '\r\n' Are these behaviours intended? If so, they should probably be documented. ---------- components: IO messages: 242593 nosy: arekfu priority: normal severity: normal status: open title: newlines attribute does not get set after calling readline() type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 11:32:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 May 2015 09:32:57 +0000 Subject: [issue20171] Derby #2: Convert 115 sites to Argument Clinic in Modules/_cursesmodule.c In-Reply-To: <1389138236.79.0.916600121015.issue20171@psf.upfronthosting.co.za> Message-ID: <1430818377.27.0.935084440607.issue20171@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated to the tip. Unfortunately, Argument Clinic now generates incorrect parsing code for some functions. Tests are failed. ---------- Added file: http://bugs.python.org/file39293/curses_clinic_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 11:41:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 May 2015 09:41:36 +0000 Subject: [issue20171] Derby #2: Convert 115 sites to Argument Clinic in Modules/_cursesmodule.c In-Reply-To: <1389138236.79.0.916600121015.issue20171@psf.upfronthosting.co.za> Message-ID: <1430818896.67.0.621696005747.issue20171@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed signatures generated with macro in _curses_panel. ---------- Added file: http://bugs.python.org/file39294/curses_clinic_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 12:56:53 2015 From: report at bugs.python.org (Davide Mancusi) Date: Tue, 05 May 2015 10:56:53 +0000 Subject: [issue24126] newlines attribute does not get set after calling readline() In-Reply-To: <1430817708.97.0.91476502488.issue24126@psf.upfronthosting.co.za> Message-ID: <1430823413.76.0.410962473467.issue24126@psf.upfronthosting.co.za> Davide Mancusi added the comment: For completeness, here is some versioning information: $ python Python 2.7 (r27:82500, Mar 23 2015, 16:46:39) [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sysconfig >>> print sysconfig.get_config_var('CONFIG_ARGS') '--prefix=/opt/python2.7' '--enable-shared' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 13:42:14 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 05 May 2015 11:42:14 +0000 Subject: [issue20303] Argument Clinic: optional groups In-Reply-To: <1390138180.16.0.400473002032.issue20303@psf.upfronthosting.co.za> Message-ID: <1430826134.16.0.768031001698.issue20303@psf.upfronthosting.co.za> Larry Hastings added the comment: Yes, when I implemented optional groups, I didn't realize that sometimes people mixed them with optional arguments (with default values). Clinic doesn't cope well when you mix the two. Does this work? /*[clinic input] _curses.window.getstr [ y: int Y-coordinate. x: int X-coordinate. ] [ n: int ] I'm surprised people are adding new arguments to a function like curses.window.getstr(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 13:57:06 2015 From: report at bugs.python.org (gavstar) Date: Tue, 05 May 2015 11:57:06 +0000 Subject: [issue24127] Fatal error in launcher: Job information querying failed Message-ID: <1430827026.9.0.339920575451.issue24127@psf.upfronthosting.co.za> New submission from gavstar: Hi All; After a fresh install of Python 2.7 I receive the following error: Fatal error in launcher: Job information querying failed when I type "pip" into the command line. a google search finds this error in relation to wine but I'm not using wine. As this error is not listed as a current issue I suspect the error is due to the install being on windows 10 Tech Preview. Does anyone know how to fix this error? Thanks G. ---------- messages: 242598 nosy: gavstar priority: normal severity: normal status: open title: Fatal error in launcher: Job information querying failed versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 14:12:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 May 2015 12:12:59 +0000 Subject: [issue20303] Argument Clinic: optional groups In-Reply-To: <1390138180.16.0.400473002032.issue20303@psf.upfronthosting.co.za> Message-ID: <1430827979.09.0.998083344571.issue20303@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Does this work? No, Argument Clinic just rejects this (as in msg208478). Perhaps a half of functions that need optional groups, need also support of default argument or other optional group. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 14:30:29 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 May 2015 12:30:29 +0000 Subject: [issue24122] Install fails after configure sets the extending/embedding install directory to NONE In-Reply-To: <1430682171.19.0.329693037889.issue24122@psf.upfronthosting.co.za> Message-ID: <1430829029.62.0.745238911765.issue24122@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 14:34:47 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 May 2015 12:34:47 +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: <1430829287.75.0.072634913789.issue24127@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +Windows nosy: +dstufft, steve.dower, tim.golden, vinay.sajip, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 14:39:04 2015 From: report at bugs.python.org (Tim Golden) Date: Tue, 05 May 2015 12:39:04 +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: <1430829544.47.0.388704477263.issue24127@psf.upfronthosting.co.za> Tim Golden added the comment: To eliminate pip from the equation, can you just try running: "py" on its own command line? Also: what platform are you on? Win7? Win8.1? 32-bit or 64-bit? Are you running in an unusually restrictive user environment? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 14:39:44 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 05 May 2015 12:39: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: <1430829584.63.0.57903604054.issue24127@psf.upfronthosting.co.za> Changes by Paul Moore : ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 14:44:22 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 05 May 2015 12:44:22 +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: <1430829862.15.0.131839062676.issue24127@psf.upfronthosting.co.za> Paul Moore added the comment: Install is noted as being on Windows 10 tech preview. I don't have a Windows 10 installation present, but the similar issues reported in Wine seem to be related to limited support in Wine for Windows job objects. Have there been any changes to Job object support in Windows 10? I couldn't find anything specific from a web search. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 16:32:17 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 05 May 2015 14:32:17 +0000 Subject: [issue24119] Carry comments with the AST In-Reply-To: <1430666470.75.0.339272692521.issue24119@psf.upfronthosting.co.za> Message-ID: <1430836337.72.0.626929638266.issue24119@psf.upfronthosting.co.za> Brett Cannon added the comment: Another option is to provide a tool in 'tokenize' or 'ast' which will take the source and some comment regex and then attach the found comment metadata to the AST. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 16:39:27 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 05 May 2015 14:39:27 +0000 Subject: [issue24119] Carry comments with the AST In-Reply-To: <1430666470.75.0.339272692521.issue24119@psf.upfronthosting.co.za> Message-ID: <1430836767.01.0.123158575879.issue24119@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Or a separate AST node -> comment mapping. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 17:45:21 2015 From: report at bugs.python.org (Matthias Klose) Date: Tue, 05 May 2015 15:45:21 +0000 Subject: [issue24122] Install fails after configure sets the extending/embedding install directory to NONE In-Reply-To: <1430682171.19.0.329693037889.issue24122@psf.upfronthosting.co.za> Message-ID: <1430840721.3.0.138317320348.issue24122@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- assignee: -> doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 20:18:03 2015 From: report at bugs.python.org (David D. Riddle) Date: Tue, 05 May 2015 18:18:03 +0000 Subject: [issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x) In-Reply-To: <1429893933.08.0.150501464744.issue24054@psf.upfronthosting.co.za> Message-ID: <1430849883.1.0.65334178248.issue24054@psf.upfronthosting.co.za> David D. Riddle added the comment: Here is another patch. I fixed a bug in GetLineTestsBadData.test_getline and refactored the code. I think everything is good now. As for the ResourceWarnings they are not caused by linecache. The problem is with tokenize.open (See http://bugs.python.org/issue23840). ---------- Added file: http://bugs.python.org/file39295/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 20:35:45 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 05 May 2015 18:35:45 +0000 Subject: [issue18369] X509 cert class for ssl module In-Reply-To: <1373055037.38.0.259814019718.issue18369@psf.upfronthosting.co.za> Message-ID: <1430850945.74.0.520106487511.issue18369@psf.upfronthosting.co.za> Mark Lawrence added the comment: Presumably too late for 3.5 so do we bump this to 3.6? Alternatively could the Derek Wilson patch make 3.5, there's nearly three weeks until beta 1 is due on 24th May according to https://www.python.org/dev/peps/pep-0478/ ? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 20:45:39 2015 From: report at bugs.python.org (Christian Heimes) Date: Tue, 05 May 2015 18:45:39 +0000 Subject: [issue18369] X509 cert class for ssl module In-Reply-To: <1373055037.38.0.259814019718.issue18369@psf.upfronthosting.co.za> Message-ID: <1430851539.41.0.239819841124.issue18369@psf.upfronthosting.co.za> Christian Heimes added the comment: I've a mostly working prototype at https://github.com/tiran/cpython/tree/feature/x509cert . It's missing documentation, more tests and I have to port it to argument clinic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 20:50:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 May 2015 18:50:50 +0000 Subject: [issue20178] Derby #9: Convert 52 sites to Argument Clinic across 11 files In-Reply-To: <1389140078.91.0.720761635456.issue20178@psf.upfronthosting.co.za> Message-ID: <1430851850.26.0.872470806017.issue20178@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: issue20178-cyptes-01.patch is outdated due to changes in Argument Clinic and ctypes. Here is updated and extended patch. ---------- nosy: +serhiy.storchaka stage: needs patch -> patch review Added file: http://bugs.python.org/file39296/issue20178-cyptes-02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 20:57:43 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 05 May 2015 18:57:43 +0000 Subject: [issue1294959] Problems with /usr/lib64 builds. Message-ID: <1430852263.57.0.304483754696.issue1294959@psf.upfronthosting.co.za> Mark Lawrence added the comment: Also see #15631 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 21:03:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 May 2015 19:03:50 +0000 Subject: [issue24088] yield expression confusion In-Reply-To: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za> Message-ID: <20150505190346.76602.20910@psf.io> Roundup Robot added the comment: New changeset b87d96e0708e by Guido van Rossum in branch '3.4': Issue 24088: Clarify semantics of yield expression. https://hg.python.org/cpython/rev/b87d96e0708e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 21:04:43 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 May 2015 19:04:43 +0000 Subject: [issue24088] yield expression confusion In-Reply-To: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za> Message-ID: <20150505190441.7810.12616@psf.io> Roundup Robot added the comment: New changeset 6e59d82d3d09 by Guido van Rossum in branch 'default': Issue 24088: Clarify semantics of yield expression (merge from 3.4). https://hg.python.org/cpython/rev/6e59d82d3d09 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 21:04:56 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 May 2015 19:04:56 +0000 Subject: [issue24088] yield expression confusion In-Reply-To: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za> Message-ID: <1430852696.23.0.0915631347886.issue24088@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 21:11:10 2015 From: report at bugs.python.org (Dmitry Shachnev) Date: Tue, 05 May 2015 19:11:10 +0000 Subject: [issue24125] Fix for #23865 breaks docutils In-Reply-To: <1430771772.5.0.0533343511671.issue24125@psf.upfronthosting.co.za> Message-ID: <1430853070.22.0.648517737721.issue24125@psf.upfronthosting.co.za> Dmitry Shachnev added the comment: The patch fixes the issue, thanks Serhiy! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 21:12:23 2015 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 05 May 2015 19:12:23 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1430853143.69.0.965466635382.issue24018@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Yup, will do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 21:24:44 2015 From: report at bugs.python.org (levkivskyi) Date: Tue, 05 May 2015 19:24:44 +0000 Subject: [issue24128] Documentation links are forwarded to Python 2 Message-ID: <1430853884.35.0.631016737369.issue24128@psf.upfronthosting.co.za> New submission from levkivskyi: Links to Python library documentation such as: http://docs.python.org/library/functions.html http://docs.python.org/library/itertools.html http://docs.python.org/library/functools.html etc. are automatically forwarded to the Python 2 versions, namely to: https://docs.python.org/2/library/functions.html https://docs.python.org/2/library/itertools.html https://docs.python.org/2/library/functools.html At the same time docs.python.org is forwarded to Python 3 version https://docs.python.org/3/ I believe that all the documentation links should be forwarded to the current version that is Python 3. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 242613 nosy: docs at python, levkivskyi priority: normal severity: normal status: open title: Documentation links are forwarded to Python 2 type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 21:27:37 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 May 2015 19:27:37 +0000 Subject: [issue24128] Documentation links are forwarded to Python 2 In-Reply-To: <1430853884.35.0.631016737369.issue24128@psf.upfronthosting.co.za> Message-ID: <1430854057.57.0.306507344117.issue24128@psf.upfronthosting.co.za> R. David Murray added the comment: I believe that this is intentional, so that old "deep" links do not break. Georg can say for sure. ---------- nosy: +georg.brandl, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 21:35:29 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 05 May 2015 19:35:29 +0000 Subject: [issue24128] Documentation links are forwarded to Python 2 In-Reply-To: <1430853884.35.0.631016737369.issue24128@psf.upfronthosting.co.za> Message-ID: <55491B71.3070405@egenix.com> Marc-Andre Lemburg added the comment: On 05.05.2015 21:24, levkivskyi wrote: > > Links to Python library documentation such as: > http://docs.python.org/library/functions.html > http://docs.python.org/library/itertools.html > http://docs.python.org/library/functools.html > etc. > are automatically forwarded to the Python 2 versions, namely to: > https://docs.python.org/2/library/functions.html > https://docs.python.org/2/library/itertools.html > https://docs.python.org/2/library/functools.html > > At the same time docs.python.org is forwarded to Python 3 version https://docs.python.org/3/ > > I believe that all the documentation links should be forwarded to the current version that is Python 3. This is intentional. All new links to Python documentation should include the version number. To keep existing old links to the documentation working, they redirect to the Python 2 version of the documentation. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 21:44:10 2015 From: report at bugs.python.org (levkivskyi) Date: Tue, 05 May 2015 19:44:10 +0000 Subject: [issue24128] Documentation links are forwarded to Python 2 In-Reply-To: <1430853884.35.0.631016737369.issue24128@psf.upfronthosting.co.za> Message-ID: <1430855050.09.0.345768385698.issue24128@psf.upfronthosting.co.za> levkivskyi added the comment: Is it possible to check whether the Python 3 version exists and redirect to it and if not (like for http://docs.python.org/library/fpformat.html) then redirect to Python 2 ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 21:52:04 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 May 2015 19:52:04 +0000 Subject: [issue24128] Documentation links are forwarded to Python 2 In-Reply-To: <1430853884.35.0.631016737369.issue24128@psf.upfronthosting.co.za> Message-ID: <1430855524.89.0.167358799235.issue24128@psf.upfronthosting.co.za> R. David Murray added the comment: That would defeat the purpose. Existing links are intending to point to python2, not python3. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 22:31:46 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 May 2015 20:31:46 +0000 Subject: [issue24124] Two versions of instructions for installing Python modules In-Reply-To: <1430744496.1.0.475235677565.issue24124@psf.upfronthosting.co.za> Message-ID: <1430857906.3.0.385613149367.issue24124@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 22:39:07 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 May 2015 20:39:07 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1430858347.21.0.128551073267.issue24120@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 22:44:35 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 05 May 2015 20:44:35 +0000 Subject: [issue18713] Clearly document the use of PYTHONIOENCODING to set surrogateescape In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za> Message-ID: <1430858675.74.0.807589860414.issue18713@psf.upfronthosting.co.za> Nikolaus Rath added the comment: The first thing that would come to my mind when reading Nick's proposed document (without first reading this bug report) is "So why the heck is this not the default?". It would probably save a lot of people a lot of anger if there was also a brief explanation addressing this obvious first response :-). ---------- nosy: +nikratio _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 22:48:42 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 May 2015 20:48:42 +0000 Subject: [issue24114] ctypes.utils uninitialized variable 'path' In-Reply-To: <1430578995.23.0.112303250331.issue24114@psf.upfronthosting.co.za> Message-ID: <1430858922.43.0.86704878142.issue24114@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +amaury.forgeotdarc, belopolsky, meador.inge stage: -> patch review type: crash -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 22:51:59 2015 From: report at bugs.python.org (levkivskyi) Date: Tue, 05 May 2015 20:51:59 +0000 Subject: [issue24129] Incorrect (misleading) statement in the execution model documentation Message-ID: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za> New submission from levkivskyi: The documentation on execution model https://docs.python.org/3/reference/executionmodel.html contains the statement """ A class definition is an executable statement that may use and define names. These references follow the normal rules for name resolution. The namespace of the class definition becomes the attribute dictionary of the class. Names defined at the class scope are not visible in methods. """ However, the following code (taken from http://lackingrhoticity.blogspot.ch/2008/08/4-python-variable-binding-oddities.html): x = "xtop" y = "ytop" def func(): x = "xlocal" y = "ylocal" class C: print(x) print(y) y = 1 func() prints xlocal ytop In case of "normal rules for name resolution" it should rise UnboundLocalError. I suggest replacing the mentioned statement with the following: """ A class definition is an executable statement that may use and define names. Free variables follow the normal rules for name resolution, bound variables are looked up in the global namespace. The namespace of the class definition becomes the attribute dictionary of the class. Names defined at the class scope are not visible in methods. """ or a similar one. ---------- assignee: docs at python components: Documentation messages: 242619 nosy: docs at python, levkivskyi priority: normal severity: normal status: open title: Incorrect (misleading) statement in the execution model documentation type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 22:52:26 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 May 2015 20:52:26 +0000 Subject: [issue24111] Valgrind suppression file should be updated In-Reply-To: <1430549990.4.0.860597056405.issue24111@psf.upfronthosting.co.za> Message-ID: <1430859146.13.0.90674949667.issue24111@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +haypo versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 23:05:04 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 May 2015 21:05:04 +0000 Subject: [issue11874] argparse assertion failure with brackets in metavars In-Reply-To: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za> Message-ID: <1430859904.84.0.571269641135.issue11874@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- stage: -> patch review versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 23:06:35 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 May 2015 21:06:35 +0000 Subject: [issue24089] argparse crashes with AssertionError In-Reply-To: <1430455558.24.0.369924072386.issue24089@psf.upfronthosting.co.za> Message-ID: <1430859995.95.0.248224331356.issue24089@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> argparse assertion failure with brackets in metavars _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 23:08:44 2015 From: report at bugs.python.org (SpaceOne) Date: Tue, 05 May 2015 21:08:44 +0000 Subject: [issue11874] argparse assertion failure with brackets in metavars In-Reply-To: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za> Message-ID: <1430860124.8.0.000222457504249.issue11874@psf.upfronthosting.co.za> Changes by SpaceOne : ---------- nosy: +spaceone _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 23:17:36 2015 From: report at bugs.python.org (Maciej Szulik) Date: Tue, 05 May 2015 21:17:36 +0000 Subject: [issue21800] Implement RFC 6855 (IMAP Support for UTF-8) in imaplib. In-Reply-To: <1404175815.98.0.684783714649.issue21800@psf.upfronthosting.co.za> Message-ID: <1430860656.01.0.716519804151.issue21800@psf.upfronthosting.co.za> Maciej Szulik added the comment: David I did the review and there's one thing that worries me the most, actually two: 1. changing the usual meaning of None in the IMAP's __init__ method, where None has the same meaning as True, where I think it should be the opposite. 2. I'm not sure we want to have UTF8 enabled based on the init's flag. I've seen our IMAP library as a wrapper around protocol itself. Whereas the user must be aware of required steps needed to proceed. In this case enabling UTF8 support is just the next command the client can, but doesn't have to sent directly, but only in AUTH state. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 5 23:54:17 2015 From: report at bugs.python.org (David Watson) Date: Tue, 05 May 2015 21:54:17 +0000 Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX addresses In-Reply-To: <1430770611.15.0.830453602253.issue8372@psf.upfronthosting.co.za> Message-ID: <20150505215404.GA6149@localhost.dbwats.plus.com> David Watson added the comment: I've rebased the patches onto all the currently released branches, but since there are now so many variations required, I've bundled the pass-unterminated and test patches into a single set (enable-unterminated-*), and the return-unterminated and addrlen-makesockaddr patches into another (fix-overrun-*), which applies on top. The fix-overrun patches can be applied on their own, but don't include any tests. The 3.5 branch has some more substantial changes which stop the patches applying - I haven't looked into those yet. ---------- Added file: http://bugs.python.org/file39297/enable-unterminated-2.7-2015-05-05.diff Added file: http://bugs.python.org/file39298/fix-overrun-2.7-2015-05-05.diff Added file: http://bugs.python.org/file39299/enable-unterminated-3.2-2015-05-05.diff Added file: http://bugs.python.org/file39300/fix-overrun-3.2-2015-05-05.diff Added file: http://bugs.python.org/file39301/enable-unterminated-3.3-2015-05-05.diff Added file: http://bugs.python.org/file39302/fix-overrun-3.3-2015-05-05.diff Added file: http://bugs.python.org/file39303/enable-unterminated-3.4-2015-05-05.diff Added file: http://bugs.python.org/file39304/fix-overrun-3.4-2015-05-05.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- # HG changeset patch # Parent 376c2d81d0e2e8ec424d4aafabfbd75e42ea3804 Allow AF_UNIX pathnames up to the maximum 108 bytes on Linux, since it does not require sun_path to be null terminated. 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 @@ -1581,6 +1581,44 @@ class TestExceptions(unittest.TestCase): self.assertTrue(issubclass(socket.gaierror, socket.error)) self.assertTrue(issubclass(socket.timeout, socket.error)) + at unittest.skipUnless(sys.platform.startswith('linux'), 'Linux specific test') +class TestLinuxPathLen(unittest.TestCase): + + # Test AF_UNIX path length limits on Linux. + + UNIX_PATH_MAX = 108 + + def setUp(self): + self.sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) + self.to_unlink = [] + + def tearDown(self): + self.sock.close() + for name in self.to_unlink: + test_support.unlink(name) + + def pathname(self, length): + # Return a pathname of the given length. + path = os.path.abspath(test_support.TESTFN) + return path + "a" * (length - len(path)) + + def testPathTooLong(self): + # Check we can't bind to a path longer than the assumed maximum. + path = self.pathname(self.UNIX_PATH_MAX + 1) + with self.assertRaisesRegexp(socket.error, "AF_UNIX path too long"): + self.sock.bind(path) + self.to_unlink.append(path) + + def testMaxPathLen(self): + # Test binding to a path of the maximum length and reading the + # address back. In this case, sun_path is not null terminated, + # and makesockaddr() used to read past the end of it. + path = self.pathname(self.UNIX_PATH_MAX) + self.sock.bind(path) + self.to_unlink.append(path) + self.assertEqual(self.sock.getsockname(), path) + os.stat(path) + @unittest.skipUnless(sys.platform == 'linux', 'Linux specific test') class TestLinuxAbstractNamespace(unittest.TestCase): @@ -1793,6 +1831,7 @@ def test_main(): NetworkConnectionBehaviourTest, ]) tests.append(BasicSocketPairTest) + tests.append(TestLinuxPathLen) tests.append(TestLinuxAbstractNamespace) tests.extend([TIPCTest, TIPCThreadableTest]) diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c --- a/Modules/socketmodule.c +++ b/Modules/socketmodule.c @@ -1251,27 +1251,16 @@ getsockaddrarg(PySocketSockObject *s, Py addr = (struct sockaddr_un*)addr_ret; #ifdef linux - if (len > 0 && path[0] == 0) { - /* Linux abstract namespace extension */ - if (len > sizeof addr->sun_path) { - PyErr_SetString(socket_error, - "AF_UNIX path too long"); - return 0; - } - } - else -#endif /* linux */ - { - /* regular NULL-terminated string */ - if (len >= sizeof addr->sun_path) { - PyErr_SetString(socket_error, - "AF_UNIX path too long"); - return 0; - } - addr->sun_path[len] = 0; + if (len > sizeof(addr->sun_path)) { +#else + if (len >= sizeof(addr->sun_path)) { +#endif + PyErr_SetString(socket_error, "AF_UNIX path too long"); + return 0; } addr->sun_family = s->sock_family; memcpy(addr->sun_path, path, len); + memset(addr->sun_path + len, 0, sizeof(addr->sun_path) - len); #if defined(PYOS_OS2) *len_ret = sizeof(*addr); #else -------------- next part -------------- # HG changeset patch # Parent 55bdf133669c579118bbd19b1e20c23a431614ea When parsing addresses returned by accept(), etc., do not assume null termination of sun_path in AF_UNIX addresses: rely instead on the returned address length. If this is longer then the original buffer, ignore it and use the original length. diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c --- a/Modules/socketmodule.c +++ b/Modules/socketmodule.c @@ -1027,13 +1027,22 @@ makebdaddr(bdaddr_t *bdaddr) /*ARGSUSED*/ static PyObject * -makesockaddr(int sockfd, struct sockaddr *addr, int addrlen, int proto) +makesockaddr(int sockfd, struct sockaddr *addr, socklen_t addrlen, + socklen_t buflen, int proto) { if (addrlen == 0) { /* No address -- may be recvfrom() from known socket */ Py_INCREF(Py_None); return Py_None; } + /* buflen is the length of the buffer containing the address, and + addrlen is either the same, or is the length returned by the OS + after writing an address into the buffer. Some systems return + the length they would have written if there had been space + (e.g. when an oversized AF_UNIX address has its sun_path + truncated). */ + if (addrlen > buflen) + addrlen = buflen; #ifdef __BEOS__ /* XXX: BeOS version of accept() doesn't set family correctly */ @@ -1058,19 +1067,27 @@ makesockaddr(int sockfd, struct sockaddr #if defined(AF_UNIX) case AF_UNIX: { + Py_ssize_t len, splen; struct sockaddr_un *a = (struct sockaddr_un *) addr; + + if (addrlen < offsetof(struct sockaddr_un, sun_path)) + Py_RETURN_NONE; + else + splen = addrlen - offsetof(struct sockaddr_un, sun_path); #ifdef linux - if (a->sun_path[0] == 0) { /* Linux abstract namespace */ - addrlen -= offsetof(struct sockaddr_un, sun_path); - return PyString_FromStringAndSize(a->sun_path, - addrlen); + if (splen > 0 && a->sun_path[0] == 0) { + /* Linux abstract namespace */ + len = splen; } else #endif /* linux */ { - /* regular NULL-terminated string */ - return PyString_FromString(a->sun_path); + /* Path text can occupy all of sun_path[], and therefore + lack null termination */ + for (len = 0; len < splen && a->sun_path[len] != 0; len++) + ; } + return PyString_FromStringAndSize(a->sun_path, len); } #endif /* AF_UNIX */ @@ -1689,6 +1706,7 @@ sock_accept(PySocketSockObject *s) sock_addr_t addrbuf; SOCKET_T newfd; socklen_t addrlen; + socklen_t buflen; PyObject *sock = NULL; PyObject *addr = NULL; PyObject *res = NULL; @@ -1696,6 +1714,7 @@ sock_accept(PySocketSockObject *s) if (!getsockaddrlen(s, &addrlen)) return NULL; + buflen = addrlen; memset(&addrbuf, 0, addrlen); newfd = INVALID_SOCKET; @@ -1731,7 +1750,7 @@ sock_accept(PySocketSockObject *s) goto finally; } addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf), - addrlen, s->sock_proto); + addrlen, buflen, s->sock_proto); if (addr == NULL) goto finally; @@ -2229,16 +2248,18 @@ sock_getsockname(PySocketSockObject *s) sock_addr_t addrbuf; int res; socklen_t addrlen; + socklen_t buflen; if (!getsockaddrlen(s, &addrlen)) return NULL; + buflen = addrlen; memset(&addrbuf, 0, addrlen); Py_BEGIN_ALLOW_THREADS res = getsockname(s->sock_fd, SAS2SA(&addrbuf), &addrlen); Py_END_ALLOW_THREADS if (res < 0) return s->errorhandler(); - return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, + return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, buflen, s->sock_proto); } @@ -2258,16 +2279,18 @@ sock_getpeername(PySocketSockObject *s) sock_addr_t addrbuf; int res; socklen_t addrlen; + socklen_t buflen; if (!getsockaddrlen(s, &addrlen)) return NULL; + buflen = addrlen; memset(&addrbuf, 0, addrlen); Py_BEGIN_ALLOW_THREADS res = getpeername(s->sock_fd, SAS2SA(&addrbuf), &addrlen); Py_END_ALLOW_THREADS if (res < 0) return s->errorhandler(); - return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, + return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, buflen, s->sock_proto); } @@ -2598,11 +2621,13 @@ sock_recvfrom_guts(PySocketSockObject *s int timeout; ssize_t n = -1; socklen_t addrlen; + socklen_t buflen; *addr = NULL; if (!getsockaddrlen(s, &addrlen)) return -1; + buflen = addrlen; if (!IS_SELECTABLE(s)) { select_error(); @@ -2640,7 +2665,7 @@ sock_recvfrom_guts(PySocketSockObject *s } if (!(*addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf), - addrlen, s->sock_proto))) + addrlen, buflen, s->sock_proto))) return -1; return n; @@ -4202,7 +4227,8 @@ socket_getaddrinfo(PyObject *self, PyObj goto err; for (res = res0; res; res = res->ai_next) { PyObject *addr = - makesockaddr(-1, res->ai_addr, res->ai_addrlen, protocol); + makesockaddr(-1, res->ai_addr, res->ai_addrlen, res->ai_addrlen, + protocol); if (addr == NULL) goto err; single = Py_BuildValue("iiisO", res->ai_family, -------------- next part -------------- # HG changeset patch # Parent 91096d27c802859992c11016864e3b22a0fbd141 Allow AF_UNIX pathnames up to the maximum 108 bytes on Linux, since it does not require sun_path to be null terminated. 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 @@ -1876,6 +1876,53 @@ class TestExceptions(unittest.TestCase): self.assertTrue(issubclass(socket.gaierror, socket.error)) self.assertTrue(issubclass(socket.timeout, socket.error)) +class TestLinuxPathLen(unittest.TestCase): + + # Test AF_UNIX path length limits on Linux. + + UNIX_PATH_MAX = 108 + + def setUp(self): + self.sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) + self.to_unlink = [] + + def tearDown(self): + self.sock.close() + for name in self.to_unlink: + support.unlink(name) + + def pathEncodingArgs(self): + # Return the encoding and error handler used to encode/decode + # pathnames. + encoding = sys.getfilesystemencoding() + if encoding is None: + encoding = sys.getdefaultencoding() + return encoding, "surrogateescape" + + def pathname(self, length): + # Return a bytes pathname of the given length. + path = os.path.abspath(support.TESTFN) + path_bytes = path.encode(*self.pathEncodingArgs()) + return path_bytes + b"a" * (length - len(path_bytes)) + + def testPathTooLong(self): + # Check we can't bind to a path longer than the assumed maximum. + path = self.pathname(self.UNIX_PATH_MAX + 1) + with self.assertRaisesRegexp(socket.error, "AF_UNIX path too long"): + self.sock.bind(path) + self.to_unlink.append(path) + + def testMaxPathLen(self): + # Test binding to a path of the maximum length and reading the + # address back. In this case, sun_path is not null terminated, + # and makesockaddr() used to read past the end of it. + path = self.pathname(self.UNIX_PATH_MAX) + self.sock.bind(path) + self.to_unlink.append(path) + self.assertEqual(self.sock.getsockname(), + path.decode(*self.pathEncodingArgs())) + os.stat(path) + class TestLinuxAbstractNamespace(unittest.TestCase): UNIX_PATH_MAX = 108 @@ -2194,6 +2241,7 @@ def test_main(): tests.append(BasicSocketPairTest) if sys.platform == 'linux2': tests.append(TestLinuxAbstractNamespace) + tests.append(TestLinuxPathLen) if isTipcAvailable(): tests.append(TIPCTest) tests.append(TIPCThreadableTest) diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c --- a/Modules/socketmodule.c +++ b/Modules/socketmodule.c @@ -1226,27 +1226,16 @@ getsockaddrarg(PySocketSockObject *s, Py addr = (struct sockaddr_un*)addr_ret; #ifdef linux - if (len > 0 && path[0] == 0) { - /* Linux abstract namespace extension */ - if (len > sizeof addr->sun_path) { - PyErr_SetString(socket_error, - "AF_UNIX path too long"); - return 0; - } - } - else -#endif /* linux */ - { - /* regular NULL-terminated string */ - if (len >= sizeof addr->sun_path) { - PyErr_SetString(socket_error, - "AF_UNIX path too long"); - return 0; - } - addr->sun_path[len] = 0; + if (len > sizeof(addr->sun_path)) { +#else + if (len >= sizeof(addr->sun_path)) { +#endif + PyErr_SetString(socket_error, "AF_UNIX path too long"); + return 0; } addr->sun_family = s->sock_family; memcpy(addr->sun_path, path, len); + memset(addr->sun_path + len, 0, sizeof(addr->sun_path) - len); #if defined(PYOS_OS2) *len_ret = sizeof(*addr); #else -------------- next part -------------- # HG changeset patch # Parent 9e29c3d6767ce72e5bc902c47f66e896dd0f402f When parsing addresses returned by accept(), etc., do not assume null termination of sun_path in AF_UNIX addresses: rely instead on the returned address length. If this is longer then the original buffer, ignore it and use the original length. diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c --- a/Modules/socketmodule.c +++ b/Modules/socketmodule.c @@ -1008,13 +1008,22 @@ makebdaddr(bdaddr_t *bdaddr) /*ARGSUSED*/ static PyObject * -makesockaddr(SOCKET_T sockfd, struct sockaddr *addr, size_t addrlen, int proto) +makesockaddr(SOCKET_T sockfd, struct sockaddr *addr, socklen_t addrlen, + socklen_t buflen, int proto) { if (addrlen == 0) { /* No address -- may be recvfrom() from known socket */ Py_INCREF(Py_None); return Py_None; } + /* buflen is the length of the buffer containing the address, and + addrlen is either the same, or is the length returned by the OS + after writing an address into the buffer. Some systems return + the length they would have written if there had been space + (e.g. when an oversized AF_UNIX address has its sun_path + truncated). */ + if (addrlen > buflen) + addrlen = buflen; switch (addr->sa_family) { @@ -1034,18 +1043,28 @@ makesockaddr(SOCKET_T sockfd, struct soc #if defined(AF_UNIX) case AF_UNIX: { + Py_ssize_t len, splen; struct sockaddr_un *a = (struct sockaddr_un *) addr; + + if (addrlen < offsetof(struct sockaddr_un, sun_path)) + Py_RETURN_NONE; + else + splen = addrlen - offsetof(struct sockaddr_un, sun_path); #ifdef linux - if (a->sun_path[0] == 0) { /* Linux abstract namespace */ - addrlen -= offsetof(struct sockaddr_un, sun_path); - return PyBytes_FromStringAndSize(a->sun_path, addrlen); + /* Backwards compatibility: return empty addresses as bytes */ + if (splen == 0 || (splen > 0 && a->sun_path[0] == 0)) { + /* Linux abstract namespace */ + return PyBytes_FromStringAndSize(a->sun_path, splen); } else #endif /* linux */ { - /* regular NULL-terminated string */ - return PyUnicode_FromString(a->sun_path); + /* Path text can occupy all of sun_path[], and therefore + lack null termination */ + for (len = 0; len < splen && a->sun_path[len] != 0; len++) + ; } + return PyUnicode_FromStringAndSize(a->sun_path, len); } #endif /* AF_UNIX */ @@ -1664,12 +1683,14 @@ sock_accept(PySocketSockObject *s) sock_addr_t addrbuf; SOCKET_T newfd = INVALID_SOCKET; socklen_t addrlen; + socklen_t buflen; PyObject *sock = NULL; PyObject *addr = NULL; PyObject *res = NULL; int timeout; if (!getsockaddrlen(s, &addrlen)) return NULL; + buflen = addrlen; memset(&addrbuf, 0, addrlen); if (!IS_SELECTABLE(s)) @@ -1699,7 +1720,7 @@ sock_accept(PySocketSockObject *s) } addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf), - addrlen, s->sock_proto); + addrlen, buflen, s->sock_proto); if (addr == NULL) goto finally; @@ -2149,16 +2170,18 @@ sock_getsockname(PySocketSockObject *s) sock_addr_t addrbuf; int res; socklen_t addrlen; + socklen_t buflen; if (!getsockaddrlen(s, &addrlen)) return NULL; + buflen = addrlen; memset(&addrbuf, 0, addrlen); Py_BEGIN_ALLOW_THREADS res = getsockname(s->sock_fd, SAS2SA(&addrbuf), &addrlen); Py_END_ALLOW_THREADS if (res < 0) return s->errorhandler(); - return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, + return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, buflen, s->sock_proto); } @@ -2178,16 +2201,18 @@ sock_getpeername(PySocketSockObject *s) sock_addr_t addrbuf; int res; socklen_t addrlen; + socklen_t buflen; if (!getsockaddrlen(s, &addrlen)) return NULL; + buflen = addrlen; memset(&addrbuf, 0, addrlen); Py_BEGIN_ALLOW_THREADS res = getpeername(s->sock_fd, SAS2SA(&addrbuf), &addrlen); Py_END_ALLOW_THREADS if (res < 0) return s->errorhandler(); - return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, + return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, buflen, s->sock_proto); } @@ -2456,11 +2481,13 @@ sock_recvfrom_guts(PySocketSockObject *s int timeout; Py_ssize_t n = -1; socklen_t addrlen; + socklen_t buflen; *addr = NULL; if (!getsockaddrlen(s, &addrlen)) return -1; + buflen = addrlen; if (!IS_SELECTABLE(s)) { select_error(); @@ -2498,7 +2525,7 @@ sock_recvfrom_guts(PySocketSockObject *s } if (!(*addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf), - addrlen, s->sock_proto))) + addrlen, buflen, s->sock_proto))) return -1; return n; @@ -4063,7 +4090,8 @@ socket_getaddrinfo(PyObject *self, PyObj for (res = res0; res; res = res->ai_next) { PyObject *single; PyObject *addr = - makesockaddr(-1, res->ai_addr, res->ai_addrlen, protocol); + makesockaddr(-1, res->ai_addr, res->ai_addrlen, res->ai_addrlen, + protocol); if (addr == NULL) goto err; single = Py_BuildValue("iiisO", res->ai_family, -------------- next part -------------- # HG changeset patch # Parent ffc1f9d1c8b374edc6d1d5de41d18f0d3631cbf7 Allow AF_UNIX pathnames up to the maximum 108 bytes on Linux, since it does not require sun_path to be null terminated. 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 @@ -4401,6 +4401,54 @@ class TestExceptions(unittest.TestCase): self.assertTrue(issubclass(socket.timeout, socket.error)) @unittest.skipUnless(sys.platform == 'linux', 'Linux specific test') +class TestLinuxPathLen(unittest.TestCase): + + # Test AF_UNIX path length limits on Linux. + + UNIX_PATH_MAX = 108 + + def setUp(self): + self.sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) + self.to_unlink = [] + + def tearDown(self): + self.sock.close() + for name in self.to_unlink: + support.unlink(name) + + def pathEncodingArgs(self): + # Return the encoding and error handler used to encode/decode + # pathnames. + encoding = sys.getfilesystemencoding() + if encoding is None: + encoding = sys.getdefaultencoding() + return encoding, "surrogateescape" + + def pathname(self, length): + # Return a bytes pathname of the given length. + path = os.path.abspath(support.TESTFN) + path_bytes = path.encode(*self.pathEncodingArgs()) + return path_bytes + b"a" * (length - len(path_bytes)) + + def testPathTooLong(self): + # Check we can't bind to a path longer than the assumed maximum. + path = self.pathname(self.UNIX_PATH_MAX + 1) + with self.assertRaisesRegexp(socket.error, "AF_UNIX path too long"): + self.sock.bind(path) + self.to_unlink.append(path) + + def testMaxPathLen(self): + # Test binding to a path of the maximum length and reading the + # address back. In this case, sun_path is not null terminated, + # and makesockaddr() used to read past the end of it. + path = self.pathname(self.UNIX_PATH_MAX) + self.sock.bind(path) + self.to_unlink.append(path) + self.assertEqual(self.sock.getsockname(), + path.decode(*self.pathEncodingArgs())) + os.stat(path) + + at unittest.skipUnless(sys.platform == 'linux', 'Linux specific test') class TestLinuxAbstractNamespace(unittest.TestCase): UNIX_PATH_MAX = 108 @@ -4896,6 +4944,7 @@ def test_main(): ]) tests.append(BasicSocketPairTest) tests.append(TestUnixDomain) + tests.append(TestLinuxPathLen) tests.append(TestLinuxAbstractNamespace) tests.extend([TIPCTest, TIPCThreadableTest]) tests.extend([BasicCANTest, CANTest]) diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c --- a/Modules/socketmodule.c +++ b/Modules/socketmodule.c @@ -1308,27 +1308,16 @@ getsockaddrarg(PySocketSockObject *s, Py addr = (struct sockaddr_un*)addr_ret; #ifdef linux - if (len > 0 && path[0] == 0) { - /* Linux abstract namespace extension */ - if (len > sizeof addr->sun_path) { - PyErr_SetString(PyExc_OSError, - "AF_UNIX path too long"); - goto unix_out; - } - } - else -#endif /* linux */ - { - /* regular NULL-terminated string */ - if (len >= sizeof addr->sun_path) { - PyErr_SetString(PyExc_OSError, - "AF_UNIX path too long"); - goto unix_out; - } - addr->sun_path[len] = 0; + if (len > sizeof(addr->sun_path)) { +#else + if (len >= sizeof(addr->sun_path)) { +#endif + PyErr_SetString(PyExc_OSError, "AF_UNIX path too long"); + goto unix_out; } addr->sun_family = s->sock_family; memcpy(addr->sun_path, path, len); + memset(addr->sun_path + len, 0, sizeof(addr->sun_path) - len); #if defined(PYOS_OS2) *len_ret = sizeof(*addr); #else -------------- next part -------------- # HG changeset patch # Parent 920816bbee6a0f9e0d2a3b86d08b7c61784818a7 When parsing addresses returned by accept(), etc., do not assume null termination of sun_path in AF_UNIX addresses: rely instead on the returned address length. If this is longer then the original buffer, ignore it and use the original length. diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c --- a/Modules/socketmodule.c +++ b/Modules/socketmodule.c @@ -1044,13 +1044,22 @@ makebdaddr(bdaddr_t *bdaddr) /*ARGSUSED*/ static PyObject * -makesockaddr(SOCKET_T sockfd, struct sockaddr *addr, size_t addrlen, int proto) +makesockaddr(SOCKET_T sockfd, struct sockaddr *addr, socklen_t addrlen, + socklen_t buflen, int proto) { if (addrlen == 0) { /* No address -- may be recvfrom() from known socket */ Py_INCREF(Py_None); return Py_None; } + /* buflen is the length of the buffer containing the address, and + addrlen is either the same, or is the length returned by the OS + after writing an address into the buffer. Some systems return + the length they would have written if there had been space + (e.g. when an oversized AF_UNIX address has its sun_path + truncated). */ + if (addrlen > buflen) + addrlen = buflen; switch (addr->sa_family) { @@ -1070,18 +1079,28 @@ makesockaddr(SOCKET_T sockfd, struct soc #if defined(AF_UNIX) case AF_UNIX: { + Py_ssize_t len, splen; struct sockaddr_un *a = (struct sockaddr_un *) addr; + + if (addrlen < offsetof(struct sockaddr_un, sun_path)) + Py_RETURN_NONE; + else + splen = addrlen - offsetof(struct sockaddr_un, sun_path); #ifdef linux - if (a->sun_path[0] == 0) { /* Linux abstract namespace */ - addrlen -= offsetof(struct sockaddr_un, sun_path); - return PyBytes_FromStringAndSize(a->sun_path, addrlen); + /* Backwards compatibility: return empty addresses as bytes */ + if (splen == 0 || (splen > 0 && a->sun_path[0] == 0)) { + /* Linux abstract namespace */ + return PyBytes_FromStringAndSize(a->sun_path, splen); } else #endif /* linux */ { - /* regular NULL-terminated string */ - return PyUnicode_DecodeFSDefault(a->sun_path); + /* Path text can occupy all of sun_path[], and therefore + lack null termination */ + for (len = 0; len < splen && a->sun_path[len] != 0; len++) + ; } + return PyUnicode_DecodeFSDefaultAndSize(a->sun_path, len); } #endif /* AF_UNIX */ @@ -2001,12 +2020,14 @@ sock_accept(PySocketSockObject *s) sock_addr_t addrbuf; SOCKET_T newfd = INVALID_SOCKET; socklen_t addrlen; + socklen_t buflen; PyObject *sock = NULL; PyObject *addr = NULL; PyObject *res = NULL; int timeout; if (!getsockaddrlen(s, &addrlen)) return NULL; + buflen = addrlen; memset(&addrbuf, 0, addrlen); if (!IS_SELECTABLE(s)) @@ -2036,7 +2057,7 @@ sock_accept(PySocketSockObject *s) } addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf), - addrlen, s->sock_proto); + addrlen, buflen, s->sock_proto); if (addr == NULL) goto finally; @@ -2486,16 +2507,18 @@ sock_getsockname(PySocketSockObject *s) sock_addr_t addrbuf; int res; socklen_t addrlen; + socklen_t buflen; if (!getsockaddrlen(s, &addrlen)) return NULL; + buflen = addrlen; memset(&addrbuf, 0, addrlen); Py_BEGIN_ALLOW_THREADS res = getsockname(s->sock_fd, SAS2SA(&addrbuf), &addrlen); Py_END_ALLOW_THREADS if (res < 0) return s->errorhandler(); - return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, + return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, buflen, s->sock_proto); } @@ -2515,16 +2538,18 @@ sock_getpeername(PySocketSockObject *s) sock_addr_t addrbuf; int res; socklen_t addrlen; + socklen_t buflen; if (!getsockaddrlen(s, &addrlen)) return NULL; + buflen = addrlen; memset(&addrbuf, 0, addrlen); Py_BEGIN_ALLOW_THREADS res = getpeername(s->sock_fd, SAS2SA(&addrbuf), &addrlen); Py_END_ALLOW_THREADS if (res < 0) return s->errorhandler(); - return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, + return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, buflen, s->sock_proto); } @@ -2793,11 +2818,13 @@ sock_recvfrom_guts(PySocketSockObject *s int timeout; Py_ssize_t n = -1; socklen_t addrlen; + socklen_t buflen; *addr = NULL; if (!getsockaddrlen(s, &addrlen)) return -1; + buflen = addrlen; if (!IS_SELECTABLE(s)) { select_error(); @@ -2835,7 +2862,7 @@ sock_recvfrom_guts(PySocketSockObject *s } if (!(*addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf), - addrlen, s->sock_proto))) + addrlen, buflen, s->sock_proto))) return -1; return n; @@ -3071,8 +3098,7 @@ sock_recvmsg_guts(PySocketSockObject *s, cmsg_list, (int)msg.msg_flags, makesockaddr(s->sock_fd, SAS2SA(&addrbuf), - ((msg.msg_namelen > addrbuflen) ? - addrbuflen : msg.msg_namelen), + msg.msg_namelen, addrbuflen, s->sock_proto)); if (retval == NULL) goto err_closefds; @@ -5066,7 +5092,8 @@ socket_getaddrinfo(PyObject *self, PyObj for (res = res0; res; res = res->ai_next) { PyObject *single; PyObject *addr = - makesockaddr(-1, res->ai_addr, res->ai_addrlen, protocol); + makesockaddr(-1, res->ai_addr, res->ai_addrlen, res->ai_addrlen, + protocol); if (addr == NULL) goto err; single = Py_BuildValue("iiisO", res->ai_family, -------------- next part -------------- # HG changeset patch # Parent 71ec881d834720532cb88af0c489e43f5f48bcf9 Allow AF_UNIX pathnames up to the maximum 108 bytes on Linux, since it does not require sun_path to be null terminated. 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 @@ -4585,6 +4585,54 @@ class TestExceptions(unittest.TestCase): self.assertTrue(issubclass(socket.timeout, OSError)) @unittest.skipUnless(sys.platform == 'linux', 'Linux specific test') +class TestLinuxPathLen(unittest.TestCase): + + # Test AF_UNIX path length limits on Linux. + + UNIX_PATH_MAX = 108 + + def setUp(self): + self.sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) + self.to_unlink = [] + + def tearDown(self): + self.sock.close() + for name in self.to_unlink: + support.unlink(name) + + def pathEncodingArgs(self): + # Return the encoding and error handler used to encode/decode + # pathnames. + encoding = sys.getfilesystemencoding() + if encoding is None: + encoding = sys.getdefaultencoding() + return encoding, "surrogateescape" + + def pathname(self, length): + # Return a bytes pathname of the given length. + path = os.path.abspath(support.TESTFN) + path_bytes = path.encode(*self.pathEncodingArgs()) + return path_bytes + b"a" * (length - len(path_bytes)) + + def testPathTooLong(self): + # Check we can't bind to a path longer than the assumed maximum. + path = self.pathname(self.UNIX_PATH_MAX + 1) + with self.assertRaisesRegexp(socket.error, "AF_UNIX path too long"): + self.sock.bind(path) + self.to_unlink.append(path) + + def testMaxPathLen(self): + # Test binding to a path of the maximum length and reading the + # address back. In this case, sun_path is not null terminated, + # and makesockaddr() used to read past the end of it. + path = self.pathname(self.UNIX_PATH_MAX) + self.sock.bind(path) + self.to_unlink.append(path) + self.assertEqual(self.sock.getsockname(), + path.decode(*self.pathEncodingArgs())) + os.stat(path) + + at unittest.skipUnless(sys.platform == 'linux', 'Linux specific test') class TestLinuxAbstractNamespace(unittest.TestCase): UNIX_PATH_MAX = 108 @@ -5137,6 +5185,7 @@ def test_main(): ]) tests.append(BasicSocketPairTest) tests.append(TestUnixDomain) + tests.append(TestLinuxPathLen) tests.append(TestLinuxAbstractNamespace) tests.extend([TIPCTest, TIPCThreadableTest]) tests.extend([BasicCANTest, CANTest]) diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c --- a/Modules/socketmodule.c +++ b/Modules/socketmodule.c @@ -1247,27 +1247,16 @@ getsockaddrarg(PySocketSockObject *s, Py addr = (struct sockaddr_un*)addr_ret; #ifdef linux - if (len > 0 && path[0] == 0) { - /* Linux abstract namespace extension */ - if (len > sizeof addr->sun_path) { - PyErr_SetString(PyExc_OSError, - "AF_UNIX path too long"); - goto unix_out; - } - } - else -#endif /* linux */ - { - /* regular NULL-terminated string */ - if (len >= sizeof addr->sun_path) { - PyErr_SetString(PyExc_OSError, - "AF_UNIX path too long"); - goto unix_out; - } - addr->sun_path[len] = 0; + if (len > sizeof(addr->sun_path)) { +#else + if (len >= sizeof(addr->sun_path)) { +#endif + PyErr_SetString(PyExc_OSError, "AF_UNIX path too long"); + goto unix_out; } addr->sun_family = s->sock_family; memcpy(addr->sun_path, path, len); + memset(addr->sun_path + len, 0, sizeof(addr->sun_path) - len); *len_ret = len + offsetof(struct sockaddr_un, sun_path); retval = 1; unix_out: -------------- next part -------------- # HG changeset patch # Parent b47c6fffbd04edcc55de5424d38e8bacba811f68 When parsing addresses returned by accept(), etc., do not assume null termination of sun_path in AF_UNIX addresses: rely instead on the returned address length. If this is longer then the original buffer, ignore it and use the original length. diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c --- a/Modules/socketmodule.c +++ b/Modules/socketmodule.c @@ -983,13 +983,22 @@ makebdaddr(bdaddr_t *bdaddr) /*ARGSUSED*/ static PyObject * -makesockaddr(SOCKET_T sockfd, struct sockaddr *addr, size_t addrlen, int proto) +makesockaddr(SOCKET_T sockfd, struct sockaddr *addr, socklen_t addrlen, + socklen_t buflen, int proto) { if (addrlen == 0) { /* No address -- may be recvfrom() from known socket */ Py_INCREF(Py_None); return Py_None; } + /* buflen is the length of the buffer containing the address, and + addrlen is either the same, or is the length returned by the OS + after writing an address into the buffer. Some systems return + the length they would have written if there had been space + (e.g. when an oversized AF_UNIX address has its sun_path + truncated). */ + if (addrlen > buflen) + addrlen = buflen; switch (addr->sa_family) { @@ -1009,18 +1018,28 @@ makesockaddr(SOCKET_T sockfd, struct soc #if defined(AF_UNIX) case AF_UNIX: { + Py_ssize_t len, splen; struct sockaddr_un *a = (struct sockaddr_un *) addr; + + if (addrlen < offsetof(struct sockaddr_un, sun_path)) + Py_RETURN_NONE; + else + splen = addrlen - offsetof(struct sockaddr_un, sun_path); #ifdef linux - if (a->sun_path[0] == 0) { /* Linux abstract namespace */ - addrlen -= offsetof(struct sockaddr_un, sun_path); - return PyBytes_FromStringAndSize(a->sun_path, addrlen); + /* Backwards compatibility: return empty addresses as bytes */ + if (splen == 0 || (splen > 0 && a->sun_path[0] == 0)) { + /* Linux abstract namespace */ + return PyBytes_FromStringAndSize(a->sun_path, splen); } else #endif /* linux */ { - /* regular NULL-terminated string */ - return PyUnicode_DecodeFSDefault(a->sun_path); + /* Path text can occupy all of sun_path[], and therefore + lack null termination */ + for (len = 0; len < splen && a->sun_path[len] != 0; len++) + ; } + return PyUnicode_DecodeFSDefaultAndSize(a->sun_path, len); } #endif /* AF_UNIX */ @@ -1952,6 +1971,7 @@ sock_accept(PySocketSockObject *s) sock_addr_t addrbuf; SOCKET_T newfd = INVALID_SOCKET; socklen_t addrlen; + socklen_t buflen; PyObject *sock = NULL; PyObject *addr = NULL; PyObject *res = NULL; @@ -1963,6 +1983,7 @@ sock_accept(PySocketSockObject *s) if (!getsockaddrlen(s, &addrlen)) return NULL; + buflen = addrlen; memset(&addrbuf, 0, addrlen); if (!IS_SELECTABLE(s)) @@ -2025,7 +2046,7 @@ sock_accept(PySocketSockObject *s) } addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf), - addrlen, s->sock_proto); + addrlen, buflen, s->sock_proto); if (addr == NULL) goto finally; @@ -2469,16 +2490,18 @@ sock_getsockname(PySocketSockObject *s) sock_addr_t addrbuf; int res; socklen_t addrlen; + socklen_t buflen; if (!getsockaddrlen(s, &addrlen)) return NULL; + buflen = addrlen; memset(&addrbuf, 0, addrlen); Py_BEGIN_ALLOW_THREADS res = getsockname(s->sock_fd, SAS2SA(&addrbuf), &addrlen); Py_END_ALLOW_THREADS if (res < 0) return s->errorhandler(); - return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, + return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, buflen, s->sock_proto); } @@ -2498,16 +2521,18 @@ sock_getpeername(PySocketSockObject *s) sock_addr_t addrbuf; int res; socklen_t addrlen; + socklen_t buflen; if (!getsockaddrlen(s, &addrlen)) return NULL; + buflen = addrlen; memset(&addrbuf, 0, addrlen); Py_BEGIN_ALLOW_THREADS res = getpeername(s->sock_fd, SAS2SA(&addrbuf), &addrlen); Py_END_ALLOW_THREADS if (res < 0) return s->errorhandler(); - return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, + return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, buflen, s->sock_proto); } @@ -2736,11 +2761,13 @@ sock_recvfrom_guts(PySocketSockObject *s int timeout; Py_ssize_t n = -1; socklen_t addrlen; + socklen_t buflen; *addr = NULL; if (!getsockaddrlen(s, &addrlen)) return -1; + buflen = addrlen; if (!IS_SELECTABLE(s)) { select_error(); @@ -2775,7 +2802,7 @@ sock_recvfrom_guts(PySocketSockObject *s } if (!(*addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf), - addrlen, s->sock_proto))) + addrlen, buflen, s->sock_proto))) return -1; return n; @@ -3011,8 +3038,7 @@ sock_recvmsg_guts(PySocketSockObject *s, cmsg_list, (int)msg.msg_flags, makesockaddr(s->sock_fd, SAS2SA(&addrbuf), - ((msg.msg_namelen > addrbuflen) ? - addrbuflen : msg.msg_namelen), + msg.msg_namelen, addrbuflen, s->sock_proto)); if (retval == NULL) goto err_closefds; @@ -5264,7 +5290,8 @@ socket_getaddrinfo(PyObject *self, PyObj for (res = res0; res; res = res->ai_next) { PyObject *single; PyObject *addr = - makesockaddr(-1, res->ai_addr, res->ai_addrlen, protocol); + makesockaddr(-1, res->ai_addr, res->ai_addrlen, res->ai_addrlen, + protocol); if (addr == NULL) goto err; single = Py_BuildValue("iiisO", res->ai_family, From report at bugs.python.org Wed May 6 00:27:32 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 May 2015 22:27:32 +0000 Subject: [issue21800] Implement RFC 6855 (IMAP Support for UTF-8) in imaplib. In-Reply-To: <1404175815.98.0.684783714649.issue21800@psf.upfronthosting.co.za> Message-ID: <1430864852.33.0.827814503854.issue21800@psf.upfronthosting.co.za> R. David Murray added the comment: Well, the problem with that is that we then have to parse the capability to see if it is utf8 that is being enabled. I don't like that as an API, it feels fragile. Since capabilities cannot later be disabled, there's no functional reason to keep it separate. However, it would solve the problem of values to use in the init flag, and would remove the caveat that you shouldn't use UTF8=ENABLE in an explicit enable call, so perhaps it is best after all. Do you have any interest in updating the patch? I won't be able to get back to it until this weekend. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 01:13:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 May 2015 23:13:44 +0000 Subject: [issue24122] Install fails after configure sets the extending/embedding install directory to NONE In-Reply-To: <1430682171.19.0.329693037889.issue24122@psf.upfronthosting.co.za> Message-ID: <20150505231341.84496.8582@psf.io> Roundup Robot added the comment: New changeset 29512e2015d9 by doko in branch '3.4': - Issue #24122, fix quoting for LIBPL https://hg.python.org/cpython/rev/29512e2015d9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 01:48:04 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 May 2015 23:48:04 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1430617941.05.0.870448306539.issue2292@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Yeah, but the docs don't need to be committed in time for beta 1. The source code should go in ASAP, especially since the PEP 492 changes will have to be merged in on top of them. @Thomas: which Monday were you shooting for? I had hoped yesterday... On Sat, May 2, 2015 at 6:52 PM, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > It certainly would be nice to have documentation. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 01:48:30 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 May 2015 23:48:30 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: Message-ID: Guido van Rossum added the comment: (To clarify, the PEP itself probably serves as enough documentation in the interim.) On Tue, May 5, 2015 at 4:47 PM, Guido van Rossum wrote: > Yeah, but the docs don't need to be committed in time for beta 1. The > source code should go in ASAP, especially since the PEP 492 changes will > have to be merged in on top of them. @Thomas: which Monday were you > shooting for? I had hoped yesterday... > > On Sat, May 2, 2015 at 6:52 PM, Benjamin Peterson > wrote: > >> >> Benjamin Peterson added the comment: >> >> It certainly would be nice to have documentation. >> >> ---------- >> >> _______________________________________ >> Python tracker >> >> _______________________________________ >> > > > > -- > --Guido van Rossum (python.org/~guido) > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 01:50:30 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 05 May 2015 23:50:30 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: Message-ID: <1430869827.1996149.263198657.218BCB56@webmail.messagingengine.com> Benjamin Peterson added the comment: On Tue, May 5, 2015, at 19:48, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > Yeah, but the docs don't need to be committed in time for beta 1. The > source code should go in ASAP, especially since the PEP 492 changes will > have to be merged in on top of them. @Thomas: which Monday were you > shooting for? I had hoped yesterday... I suppose I can just do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 02:05:26 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 06 May 2015 00:05:26 +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: <1430870726.01.0.00463588190518.issue24017@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- dependencies: +Missing *-unpacking generalizations _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 02:05:54 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 06 May 2015 00:05:54 +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: <1430870754.79.0.119246547851.issue24017@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 02:16:22 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 06 May 2015 00:16: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: <1430871382.08.0.194744686042.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: I'll upload the most recent patch soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 02:16:58 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 06 May 2015 00:16:58 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1430871418.51.0.401195473481.issue2292@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: twouters -> benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 02:17:23 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 06 May 2015 00:17:23 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1430871443.9.0.408530558633.issue2292@psf.upfronthosting.co.za> Benjamin Peterson added the comment: a65f685ba8c0 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 02:18:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 May 2015 00:18:39 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1430871519.82.0.866015043761.issue22906@psf.upfronthosting.co.za> STINNER Victor added the comment: Would it be possible to push the first part of the implementation (without __future__) just to unblock the implementation of the PEP 492 (issue #24017: async/await)? Later push the second part for __future__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 02:26:24 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 May 2015 00:26:24 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1430871443.9.0.408530558633.issue2292@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Thanks Benjamin! On May 5, 2015 5:17 PM, "Benjamin Peterson" wrote: > > Benjamin Peterson added the comment: > > a65f685ba8c0 > > ---------- > resolution: -> fixed > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 02:27:06 2015 From: report at bugs.python.org (Chris Angelico) Date: Wed, 06 May 2015 00:27:06 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1430872026.91.0.979827246717.issue22906@psf.upfronthosting.co.za> Chris Angelico added the comment: Stinner, not sure what you mean by first part / second part. Is there a way for me to withdraw the first two versions of the patch and just keep #37646? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 02:27:42 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 May 2015 00:27:42 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1430871519.82.0.866015043761.issue22906@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Well that would break a lot of code... On May 5, 2015 5:18 PM, "STINNER Victor" wrote: > > STINNER Victor added the comment: > > Would it be possible to push the first part of the implementation (without > __future__) just to unblock the implementation of the PEP 492 (issue > #24017: async/await)? > > Later push the second part for __future__. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 02:48:39 2015 From: report at bugs.python.org (gavstar) Date: Wed, 06 May 2015 00:48:39 +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: <1430873319.35.0.40877461923.issue24127@psf.upfronthosting.co.za> gavstar added the comment: Hi Tim.golden; py in its own command line gives.. " Microsoft Windows [Version 10.0.10074] (c) 2015 Microsoft Corporation. All rights reserved. C:\Users\Gav>py Job information querying failed C:\Users\Gav> " on platform windows 10 tech preview 64bit. as administrator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 03:00:20 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 06 May 2015 01:00:20 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430874020.14.0.22012326022.issue23911@psf.upfronthosting.co.za> Ned Deily added the comment: This checkin also breaks OS X framework builds. For some reason, framework builds are compiled with the gcc -fno-common option. The code in configure.ac to add that option dates back to the initial OS X framework support (c3c87ce4afdc from 2001). It's not clear to me why we use that option just in the case of framework builds (I suspect it may no longer be necessary) but the fact is that we have been and currently still do. And, in any case, the GCC description of -fno-common (https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html) suggests that there may be valid reasons to use it on some platforms or that other compilers might behave this way by default. A simple way to produce the error on Linux is: ./configure OPT="-fno-common" && make [...] gcc -pthread -o Programs/_freeze_importlib Programs/_freeze_importlib.o Modules/getbuildinfo.o Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/capsule.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/bltinmodule.o Python/ceval.o Python/compile.o Python/codecs.o Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/import.o Python/importdl.o Python/marshal.o Python/modsupport.o Python/mystrtoul.o Python/mysnprintf.o Python/peephole.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pyhash.o Python/pylifecycle.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/random.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/pystrhex.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload_shlib.o Python/thread.o Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o Modules/_threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/_weakref.o Modules/_functoolsmodule.o Modules/_operator.o Modules/_collectionsmodule.o Modules/itertoolsmodule.o Modules/atexitmodule.o Modules/_stat.o Modules/timemodule.o Modules/_localemodule.o Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o Modules/zipimport.o Modules/faulthandler.o Modules/_tracemalloc.o Modules/hashtable.o Modules/symtablemodule.o Modules/xxsubtype.o -lpthread -ldl -lutil -lm Python/pylifecycle.o:(.bss+0x20): multiple definition of `Py_FrozenFlag' Programs/_freeze_importlib.o:(.data+0x0): first defined here collect2: error: ld returned 1 exit status Makefile:710: recipe for target 'Programs/_freeze_importlib' failed make: *** [Programs/_freeze_importlib] Error 1 The OS X version of ld helpfully lists the modules: duplicate symbol _Py_FrozenFlag in: Programs/_freeze_importlib.o Python/pylifecycle.o I'm also not sure why the Py_FrozenFlag definition was added to _freeze_importlib.c in the first place. Reverting it with the following patch seems to solve the problem in the few configurations I tried (OS X framework, OS X non-shared, Linux non-shared, Linux shared). diff Programs/_freeze_importlib.c --- a/Programs/_freeze_importlib.c Tue May 05 12:04:35 2015 -0700 +++ b/Programs/_freeze_importlib.c Tue May 05 17:10:39 2015 -0700 @@ -12,8 +12,6 @@ #include #endif -int Py_FrozenFlag = 1; /* Suppress errors from getpath.c */ - /* To avoid a circular dependency on frozen.o, we create our own structure of frozen modules instead, left deliberately blank so as to avoid unintentional import of a stale version of _frozen_importlib. */ ---------- nosy: +ned.deily resolution: fixed -> stage: resolved -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 03:21:27 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 06 May 2015 01:21:27 +0000 Subject: [issue24130] Remove -fno-common compile option from OS X framework builds? Message-ID: <1430875287.46.0.873192743789.issue24130@psf.upfronthosting.co.za> New submission from Ned Deily: As noted in msg242635 of issue23911, for some reason configure.ac adds the gcc -fno-common option for OS X framework builds. Is this still necessary? I'm guessing it might be vestigial code left over from the Mac toolbox support in Python 2 that was removed in Python 3. diff configure.ac --- a/configure.ac Tue May 05 12:04:35 2015 -0700 +++ b/configure.ac Tue May 05 16:47:34 2015 -0700 @@ -2101,9 +2101,6 @@ AC_MSG_CHECKING(for --enable-framework) if test "$enable_framework" then - BASECFLAGS="$BASECFLAGS -fno-common -dynamic" - # -F. is needed to allow linking to the framework while - # in the build location. AC_DEFINE(WITH_NEXT_FRAMEWORK, 1, [Define if you want to produce an OpenStep/Rhapsody framework (shared library plus accessory files).]) Also, there seems to be a unused reference to $extra_undefs left over in configure.ac from the removed Mac toolbox support: --- a/configure.ac Tue May 05 12:04:35 2015 -0700 +++ b/configure.ac Tue May 05 18:20:21 2015 -0700 @@ -2346,8 +2346,6 @@ Linux*|GNU*) LINKFORSHARED="-Xlinker -export-dynamic";; # -u libsys_s pulls in all symbols in libsys Darwin/*) - LINKFORSHARED="$extra_undefs -framework CoreFoundation" - # Issue #18075: the default maximum stack size (8MBytes) is too # small for the default recursion limit. Increase the stack size # to ensure that tests don't crash ---------- assignee: ned.deily components: Build, Macintosh messages: 242636 nosy: ned.deily, ronaldoussoren priority: normal severity: normal stage: patch review status: open title: Remove -fno-common compile option from OS X framework builds? versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 03:24:38 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 06 May 2015 01:24:38 +0000 Subject: [issue24130] Remove -fno-common compile option from OS X framework builds? In-Reply-To: <1430875287.46.0.873192743789.issue24130@psf.upfronthosting.co.za> Message-ID: <1430875478.18.0.0756558783618.issue24130@psf.upfronthosting.co.za> Ned Deily added the comment: Sorry, that second patch should have been: diff -configure.ac --- a/configure.ac Tue May 05 12:04:35 2015 -0700 +++ b/configure.ac Tue May 05 18:22:39 2015 -0700 @@ -2346,7 +2346,7 @@ Linux*|GNU*) LINKFORSHARED="-Xlinker -export-dynamic";; # -u libsys_s pulls in all symbols in libsys Darwin/*) - LINKFORSHARED="$extra_undefs -framework CoreFoundation" + LINKFORSHARED="-framework CoreFoundation" # Issue #18075: the default maximum stack size (8MBytes) is too # small for the default recursion limit. Increase the stack size ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 04:00:03 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 06 May 2015 02:00:03 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1430877603.13.0.106272528525.issue2292@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 04:16:28 2015 From: report at bugs.python.org (Guilherme) Date: Wed, 06 May 2015 02:16:28 +0000 Subject: [issue24131] [configparser] Add section/option delimiter to ExtendedInterpolation Message-ID: <1430878588.06.0.66159234508.issue24131@psf.upfronthosting.co.za> New submission from Guilherme: Using configparser.ExtendedInterpolation one can interpolate ${section:option}. It would be nice to have a parameter on ExtendedInterpolation __init__ to change the delimiter, thus one can use ${section/option} instead (using '/' instead of ':', for example). ---------- components: Library (Lib) messages: 242638 nosy: giflw priority: normal severity: normal status: open title: [configparser] Add section/option delimiter to ExtendedInterpolation type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 04:17:32 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 06 May 2015 02:17:32 +0000 Subject: [issue24131] [configparser] Add section/option delimiter to ExtendedInterpolation In-Reply-To: <1430878588.06.0.66159234508.issue24131@psf.upfronthosting.co.za> Message-ID: <1430878652.04.0.658666981297.issue24131@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 05:28:53 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 06 May 2015 03:28:53 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430882933.81.0.630664077288.issue23911@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks for pointing this out, Ned. Early on I ran into a problem when running _freeze_importlib without the flag set. However, I expect that it was not necessary after a certain point (e.g. once I had a valid _importlib_external.h). I'll remove the flag as suggested. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 05:31:10 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 06 May 2015 03:31:10 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430883070.05.0.200013775949.issue23911@psf.upfronthosting.co.za> Eric Snow added the comment: changeset: 95887:3bea670c9830 user: Eric Snow date: Tue May 05 21:29:31 2015 -0600 summary: Remove an unnecessary flag. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 05:36:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 May 2015 03:36:54 +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: <20150506033651.76600.59731@psf.io> Roundup Robot added the comment: New changeset f65174aef9ea by Berker Peksag in branch 'default': Issue #9517: Move script_helper to the support package. https://hg.python.org/cpython/rev/f65174aef9ea ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 07:26:53 2015 From: report at bugs.python.org (Christophe BAL) Date: Wed, 06 May 2015 05:26:53 +0000 Subject: [issue24132] Direct sub-classing of pathless.Path Message-ID: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za> New submission from Christophe BAL: Hello. I have noticed a problem with the following code. from pathlib import Path class PPath(Path): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) test = PPath("dir", "test.txt") This gives the following error message. Traceback (most recent call last): File "/Users/projetmbc/test.py", line 14, in test = PPath("dir", "test.txt") File "/anaconda/lib/python3.4/pathlib.py", line 907, in __new__ self = cls._from_parts(args, init=False) File "/anaconda/lib/python3.4/pathlib.py", line 589, in _from_parts drv, root, parts = self._parse_args(args) File "/anaconda/lib/python3.4/pathlib.py", line 582, in _parse_args return cls._flavour.parse_parts(parts) AttributeError: type object 'PPath' has no attribute '_flavour' This breaks the sub-classing from Python point of view. There is an ugly hack to sub-class Path but it's a bit unpythonic. ---------- messages: 242643 nosy: projetmbc priority: normal severity: normal status: open title: Direct sub-classing of pathless.Path type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 07:54:35 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 06 May 2015 05:54:35 +0000 Subject: [issue24132] Direct sub-classing of pathless.Path In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za> Message-ID: <1430891675.22.0.410531956085.issue24132@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 08:27:02 2015 From: report at bugs.python.org (Christophe BAL) Date: Wed, 06 May 2015 06:27:02 +0000 Subject: [issue24132] Direct sub-classing of pathlib.Path In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za> Message-ID: <1430893622.4.0.29660327698.issue24132@psf.upfronthosting.co.za> Changes by Christophe BAL : ---------- title: Direct sub-classing of pathless.Path -> Direct sub-classing of pathlib.Path _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 08:54:24 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 May 2015 06:54:24 +0000 Subject: [issue24125] Fix for #23865 breaks docutils In-Reply-To: <1430771772.5.0.0533343511671.issue24125@psf.upfronthosting.co.za> Message-ID: <20150506065421.8964.42860@psf.io> Roundup Robot added the comment: New changeset fe340c2a220e by Serhiy Storchaka in branch '2.7': Issue #24125: Saved error's line and column numbers when an error is occured https://hg.python.org/cpython/rev/fe340c2a220e New changeset 7f8cd879687b by Serhiy Storchaka in branch '3.4': Issue #24125: Saved error's line and column numbers when an error is occured https://hg.python.org/cpython/rev/7f8cd879687b New changeset 1fb83fa2cdef by Serhiy Storchaka in branch 'default': Issue #24125: Saved error's line and column numbers when an error is occured https://hg.python.org/cpython/rev/1fb83fa2cdef ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 08:54:24 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 May 2015 06:54:24 +0000 Subject: [issue23865] Fix possible leaks in close methods In-Reply-To: <1428145980.2.0.463866688715.issue23865@psf.upfronthosting.co.za> Message-ID: <20150506065421.8964.16637@psf.io> Roundup Robot added the comment: New changeset fe340c2a220e by Serhiy Storchaka in branch '2.7': Issue #24125: Saved error's line and column numbers when an error is occured https://hg.python.org/cpython/rev/fe340c2a220e New changeset 7f8cd879687b by Serhiy Storchaka in branch '3.4': Issue #24125: Saved error's line and column numbers when an error is occured https://hg.python.org/cpython/rev/7f8cd879687b New changeset 1fb83fa2cdef by Serhiy Storchaka in branch 'default': Issue #24125: Saved error's line and column numbers when an error is occured https://hg.python.org/cpython/rev/1fb83fa2cdef ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 08:54:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 May 2015 06:54:26 +0000 Subject: [issue24009] Get rid of rare format units in PyArg_Parse* In-Reply-To: <1429470884.11.0.538472438707.issue24009@psf.upfronthosting.co.za> Message-ID: <20150506065421.8964.80164@psf.io> Roundup Robot added the comment: New changeset d65233f630e1 by Serhiy Storchaka in branch 'default': Issue #24009: Got rid of using rare "y#" format unit in TextIOWrapper.tell(). https://hg.python.org/cpython/rev/d65233f630e1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 09:10:37 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 06 May 2015 07:10:37 +0000 Subject: [issue12202] Check status returns in msilib.SummaryInformation.GetProperty() In-Reply-To: <1306591176.31.0.169874894705.issue12202@psf.upfronthosting.co.za> Message-ID: <1430896237.08.0.29633464622.issue12202@psf.upfronthosting.co.za> Mark Lawrence added the comment: The code change to _msi.c is minimal, the bulk of the patch is additional test code. I think we could still use this. Thoughts? See also #1104. ---------- components: +Windows nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 09:11:33 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 06 May 2015 07:11:33 +0000 Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za> Message-ID: <1430896293.43.0.606294001577.issue1104@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 09:14:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 May 2015 07:14:05 +0000 Subject: [issue24125] Fix for #23865 breaks docutils In-Reply-To: <1430771772.5.0.0533343511671.issue24125@psf.upfronthosting.co.za> Message-ID: <1430896445.17.0.224031274339.issue24125@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 Wed May 6 09:39:59 2015 From: report at bugs.python.org (Maciej Szulik) Date: Wed, 06 May 2015 07:39:59 +0000 Subject: [issue21800] Implement RFC 6855 (IMAP Support for UTF-8) in imaplib. In-Reply-To: <1404175815.98.0.684783714649.issue21800@psf.upfronthosting.co.za> Message-ID: <1430897999.53.0.986487293653.issue21800@psf.upfronthosting.co.za> Maciej Szulik added the comment: Yes, I can update that (that IMAP testing bug - http://bugs.python.org/issue22137, is taking me longer than I expected it ;)). I just want to make sure if I understand you correctly what's needs to be done is removing the utf8_enable code from init, we will enable ascii by default and only explicit call to enable method will enable it, am I missing something? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 09:56:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 May 2015 07:56:46 +0000 Subject: [issue20178] Derby #9: Convert 52 sites to Argument Clinic across 11 files In-Reply-To: <1389140078.91.0.720761635456.issue20178@psf.upfronthosting.co.za> Message-ID: <1430899006.44.0.576484731549.issue20178@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For Modules/_curses_panel.c there is special issue, #20171, with the patch. issue20178-sqlite-01.patch is applied almost clearly, but due to changes to Argument Clinic it should be updated. Perhaps more functions can be converted (functions that don't use PyArg_Parse* are worth to be converted too). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 10:01:24 2015 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 May 2015 08:01:24 +0000 Subject: [issue24124] Two versions of instructions for installing Python modules In-Reply-To: <1430744496.1.0.475235677565.issue24124@psf.upfronthosting.co.za> Message-ID: <1430899284.72.0.714287613711.issue24124@psf.upfronthosting.co.za> Nick Coghlan added the comment: As far as I'm aware, it's only confusing if you're poking around in the source tree, rather than using the built docs at docs.python.org (where the link to the legacy docs is now hidden away inside the distutils module docs). The legacy docs remain in place to preserve existing deep links and because they're the only current documentation of various distutils details that are needed to *implement* tools like pip and setuptools. In a more ideal world, we'd have a distutils expert with the time to go through the legacy docs, cull the outdated stuff, and lift the rest up into the distutils module documentation, but all the folks that might plausibly have the expertise to do that also have far more interesting things to do with their time :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 11:15:30 2015 From: report at bugs.python.org (Paul Moore) Date: Wed, 06 May 2015 09:15:30 +0000 Subject: [issue24132] Direct sub-classing of pathlib.Path In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za> Message-ID: <1430903730.39.0.476527730869.issue24132@psf.upfronthosting.co.za> Paul Moore added the comment: One issue with your code - what would you expect str(test) to produce? "dir/test.txt" or "dir\test.txt"? That's the point of the "flavour" - is it a Windows path or a Unix path? Agreed that an easier method of creating Path subclasses that handle this type of thing would be useful, but any solution needs to make sure that developers don't overlook the Windows vs Unix implications. Can you give an actual use case (as opposed to the toy example)? ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 12:14:20 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 06 May 2015 10:14:20 +0000 Subject: [issue24009] Get rid of rare format units in PyArg_Parse* In-Reply-To: <1429470884.11.0.538472438707.issue24009@psf.upfronthosting.co.za> Message-ID: <1430907260.7.0.108985127584.issue24009@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Note that these format characters can also be used outside of CPython. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 12:24:42 2015 From: report at bugs.python.org (levkivskyi) Date: Wed, 06 May 2015 10:24:42 +0000 Subject: [issue24133] Add 'composable' decorator to functools (with @ matrix multiplication syntax) Message-ID: <1430907882.79.0.781559925773.issue24133@psf.upfronthosting.co.za> New submission from levkivskyi: The matrix multiplication operator @ is going to be introduced in Python 3.5 and I am thinking about the following idea: The semantics of matrix multiplication is the composition of the corresponding linear transformations. A linear transformation is a particular example of a more general concept - functions. The latter are frequently composed with ("wrap") each other. For example: plot(real(sqrt(data))) However, it is not very readable in case of many wrapping layers. Therefore, it could be useful to employ the matrix multiplication operator @ for indication of function composition. This could be done by such (simplified) decorator: class composable: def __init__(self, func): self.func = func def __call__(self, arg): return self.func(arg) def __matmul__(self, other): def composition(*args, **kwargs): return self.func(other(*args, **kwargs)) return composable(composition) I think using such decorator with functions that are going to be deeply wrapped could improve readability. You could compare (note that only the outermost function should be decorated): plot(sorted(sqrt(real(data_array)))) vs. (plot @ sorted @ sqrt @ real) (data_array) I think the latter is more readable, also compare def sunique(lst): return sorted(list(set(lst))) vs. sunique = sorted @ list @ set Apart from readability, there are following pros of the proposed decorator: 1. Similar semantics as for matrix multiplication. 2. Same symbol for composition as for decorators. 3. The symbol @ resembles mathematical notation for function composition: ? I think it could be a good idea to add such a decorator to the stdlib functools module. ---------- components: Library (Lib) messages: 242653 nosy: levkivskyi priority: normal severity: normal status: open title: Add 'composable' decorator to functools (with @ matrix multiplication syntax) type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 13:00:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 May 2015 11:00:31 +0000 Subject: [issue23880] Tkinter: getint and getdouble should support Tcl_Obj In-Reply-To: <1428396064.01.0.00215215635093.issue23880@psf.upfronthosting.co.za> Message-ID: <20150506110026.76614.96256@psf.io> Roundup Robot added the comment: New changeset cb80dd82d3da by Serhiy Storchaka in branch 'default': Issue #23880: Tkinter's getint() and getdouble() now support Tcl_Obj. https://hg.python.org/cpython/rev/cb80dd82d3da ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 13:03:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 May 2015 11:03:09 +0000 Subject: [issue23880] Tkinter: getint and getdouble should support Tcl_Obj In-Reply-To: <1428396064.01.0.00215215635093.issue23880@psf.upfronthosting.co.za> Message-ID: <1430910189.18.0.72254972593.issue23880@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed in the default branch only. If other issues with Tcl/Tk 8.5 or 8.6 will be reported, we could apply general solution instead of particular workarounds in maintained branches too. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 13:05:57 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 May 2015 11:05:57 +0000 Subject: [issue24132] Direct sub-classing of pathlib.Path In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za> Message-ID: <1430910357.51.0.369754343322.issue24132@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The Path classes were not designed to be subclassable by the user. I'm not against making subclassing easier, but someone will have to propose a viable approach for that. ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 14:13:25 2015 From: report at bugs.python.org (Christophe BAL) Date: Wed, 06 May 2015 12:13:25 +0000 Subject: [issue24132] Direct sub-classing of pathlib.Path In-Reply-To: <1430910357.51.0.369754343322.issue24132@psf.upfronthosting.co.za> Message-ID: Christophe BAL added the comment: Hello. I will give a real example in 5 hours after my job. I will try tomorrow a solution to ease the subclassing using another dedicazted class PathPlus, sorry for the name. The idea would be to use this new class for customization, and also to define WindowsPath and PosixPath sub-classing this new class. By default PathPlus would be an empty class. I do not know if this works well. Maybe my idea is a bad one. *Christophe BAL* *Enseignant de math?matiques en Lyc?e **et d?veloppeur Python amateur* *---* *French math teacher in a "Lyc?e" **and **Python **amateur developer* 2015-05-06 13:05 GMT+02:00 Antoine Pitrou : > > Antoine Pitrou added the comment: > > The Path classes were not designed to be subclassable by the user. > I'm not against making subclassing easier, but someone will have to > propose a viable approach for that. > > ---------- > versions: +Python 3.5 -Python 3.4 > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 14:16:57 2015 From: report at bugs.python.org (Magnus Carlsson) Date: Wed, 06 May 2015 12:16:57 +0000 Subject: [issue24134] assertRaises can behave differently Message-ID: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> New submission from Magnus Carlsson: Hi I have a little issue with the current assertRaises implementation. It seems that it might produce a little different results depending on how you use it. self.assertRaises(IOError, None) will not produce the same result as: with self.assertRaises(IOError): None() In the first case everything will be fine due to the fact that assertRaises will actually return a context if the second callable parameters is None. The second case will throw a TypeError 'NoneType' object is not callable. I don't use None directly, but replace it with a variable of unknown state and you get a little hole where problems can creep in. In my case I was testing function decorators and that they should raise some exceptions on special cases. It turned our that I forgot to return the decorator and instead got the default None. But my tests didn't warn me about that. Bottom line is that if I use the first assertRaises(Exception, callable) I can't rely on it to check that the callable is actually something callable. I do see that there is a benefit of the context way, but in my opinion current implementation will allow problems to go undetected. My solution to this would be to rename the context variant into something different: with self.assertRaisesContext(Exception): do_something() A side note on this is that reverting back to the original behavior would allow you to reevaluate issue9587 for returning the actual exception. ---------- components: Library (Lib) messages: 242658 nosy: magnusc priority: normal severity: normal status: open title: assertRaises can behave differently type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 14:40:11 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 06 May 2015 12:40:11 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1430916011.5.0.982428776446.issue24134@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I don't think this is a bug. I think it is just a case that you have to be careful when calling functions, you actually do call the function. And that it returns what you think it does. I think the critical point is this: "It turned our that I forgot to return the decorator and instead got the default None. But my tests didn't warn me about that." The solution to that is to always have a test that your decorator actually returns a function. That's what I do. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 14:49:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 May 2015 12:49:16 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1430916556.97.0.115577371642.issue24134@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Possible solution is to use special sentinel instead of None. ---------- keywords: +patch nosy: +ezio.melotti, michael.foord, rbcollins, serhiy.storchaka stage: -> patch review versions: +Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39305/assert_raises_sentinel.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 14:57:47 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 May 2015 12:57:47 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1430917067.89.0.398274571376.issue24134@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The patch looks like a nice improvement. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 14:57:52 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 May 2015 12:57:52 +0000 Subject: [issue21800] Implement RFC 6855 (IMAP Support for UTF-8) in imaplib. In-Reply-To: <1404175815.98.0.684783714649.issue21800@psf.upfronthosting.co.za> Message-ID: <1430917072.1.0.878322589803.issue21800@psf.upfronthosting.co.za> R. David Murray added the comment: An explicit call to enable with an argument string that contains 'UTF8=ACCEPT'. I did not go far enough through the BNF to determine if enable can be passed more than one capability at a time, but I suspect it can. In which case we should factor out the capability parsing such that we can reuse it for parsing the enable argument. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 15:02:02 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 May 2015 13:02:02 +0000 Subject: [issue24133] Add 'composable' decorator to functools (with @ matrix multiplication syntax) In-Reply-To: <1430907882.79.0.781559925773.issue24133@psf.upfronthosting.co.za> Message-ID: <1430917322.64.0.16431242973.issue24133@psf.upfronthosting.co.za> R. David Murray added the comment: This should be taken to python-ideas (and probably pypi) first. You can reopen if there is agreement that this should be done. IMO it should not be done for 3.5 in any case. ---------- nosy: +r.david.murray resolution: -> later stage: -> resolved status: open -> closed versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 15:03:53 2015 From: report at bugs.python.org (=?utf-8?q?Thomas_G=C3=BCttler?=) Date: Wed, 06 May 2015 13:03:53 +0000 Subject: [issue24135] Policy for altering sys.path Message-ID: <1430917433.22.0.843755973522.issue24135@psf.upfronthosting.co.za> New submission from Thomas G?ttler: I am missing a policy how sys.path should be altered. We run a custom sub class of list in sys.path. We set it in sitecustomize.py This instance get replace by a common list in lines like this: sys.path = glob.glob(os.path.join(WHEEL_DIR, "*.whl")) + sys.path The above line is from pip, it similar things happen in a lot of packages. Before trying to solve this with code, I think the python community should agree an a policy for altering sys.path. What can I do to this done? We use Python 2.7. ---------- messages: 242664 nosy: Thomas G?ttler priority: normal severity: normal status: open title: Policy for altering sys.path _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 15:12:53 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 May 2015 13:12:53 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1430917973.41.0.199648186135.issue24134@psf.upfronthosting.co.za> R. David Murray added the comment: Why not sentinel = Object()? +1 for the patch, once tests are added. This may "break" code in maintenance releases, but presumably that will be finding real bugs. It is hard to imagine someone intentionally passing None to get the context manager behavior, even though it is documented in the doc strings (but not the main docs, I note). If anyone can find examples of that, though, we'd need to restrict this to 3.5. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 15:15:30 2015 From: report at bugs.python.org (Thomas Wouters) Date: Wed, 06 May 2015 13:15:30 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1430918130.17.0.638747902145.issue2292@psf.upfronthosting.co.za> Thomas Wouters added the comment: FYI, I meant last Monday, but I forgot it was May 4th (Dutch Memorial day) and May 5th (Dutch Liberation day), so that got in the way :P Should we keep this bug open for docs changes, or is there a separate issue for that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 15:17:32 2015 From: report at bugs.python.org (Matthias Klose) Date: Wed, 06 May 2015 13:17:32 +0000 Subject: [issue24122] Install fails after configure sets the extending/embedding install directory to NONE In-Reply-To: <1430682171.19.0.329693037889.issue24122@psf.upfronthosting.co.za> Message-ID: <1430918252.21.0.768472833376.issue24122@psf.upfronthosting.co.za> Matthias Klose added the comment: fixed for 3.4 and 3.5. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 15:18:47 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 06 May 2015 13:18:47 +0000 Subject: [issue24136] document PEP 448 Message-ID: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> New submission from Benjamin Peterson: PEP 448 has been implemented (#2292), but the documentation hasn't been updated. Updating the documentation will improve looking through Doc/reference/* and making sure the documentation (and grammar) for calls and assignments is updated for PEP 448's new syntax. I'm marking this as "easy" because it might be a good first bug. ---------- assignee: docs at python components: Documentation keywords: easy messages: 242668 nosy: benjamin.peterson, docs at python priority: high severity: normal stage: needs patch status: open title: document PEP 448 type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 15:20:18 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 06 May 2015 13:20:18 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1430918130.17.0.638747902145.issue2292@psf.upfronthosting.co.za> Message-ID: <1430918414.2180513.263444173.0C49DE89@webmail.messagingengine.com> Benjamin Peterson added the comment: On Wed, May 6, 2015, at 09:15, Thomas Wouters wrote: > > Thomas Wouters added the comment: > > FYI, I meant last Monday, but I forgot it was May 4th (Dutch Memorial > day) and May 5th (Dutch Liberation day), so that got in the way :P > > Should we keep this bug open for docs changes, or is there a separate > issue for that? #24136 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 15:21:19 2015 From: report at bugs.python.org (Henrik Heimbuerger) Date: Wed, 06 May 2015 13:21:19 +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: <1430918479.73.0.0286809743145.issue24127@psf.upfronthosting.co.za> Henrik Heimbuerger added the comment: I can confirm this issue for pip 6.1.1 on Windows 10.0.10074 for both Python 2.7.9 as well as 3.4.3. As a workaround, using "python -m pip" works fine (as suggested on http://stackoverflow.com/a/26428562/6278 for a different issue). ---------- nosy: +hheimbuerger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 15:22:15 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 May 2015 13:22:15 +0000 Subject: [issue24135] Policy for altering sys.path In-Reply-To: <1430917433.22.0.843755973522.issue24135@psf.upfronthosting.co.za> Message-ID: <1430918535.34.0.665566810129.issue24135@psf.upfronthosting.co.za> R. David Murray added the comment: My guess, unfortunately, is give up. There is too much code in the field that replaces sys.path with a regular list. What you propose is effectively an impossible social engineering problem. You may well also run into issues where the Python C code calls list methods directly even if sys.path is a subclass of list. (I don't know that that is true, but there are certainly places where the C code does that kind of thing). Could you get consensus to change stdlib and pip practice? That's at least conceivable. I guess python-ideas would be the place to start for that. I'm going to close the issue, since this would be a PEP level change if you are successful. (Frankly, I don't think you are likely to be successful, but I don't hang out on python-ideas so I might be wrong :) ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 15:50:47 2015 From: report at bugs.python.org (Paul Moore) Date: Wed, 06 May 2015 13:50:47 +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: <1430920247.64.0.546338333154.issue24127@psf.upfronthosting.co.za> Paul Moore added the comment: It looks like something in the QueryInformationJobObject API has changed with Windows 10. The code says: ok = QueryInformationJobObject(job, JobObjectExtendedLimitInformation, &info, sizeof(info), &rc); if (!ok || (rc != sizeof(info)) || !job) error(RC_CREATE_PROCESS, L"Job information querying failed"); This call looks right to me based on the MSDN documentation. Two possibilities I can think of: 1. Bug in Windows 10, which should be reported to Microsoft. 2. the size of the JOBOBJECT_EXTENDED_LIMIT_INFORMATION structure has changed in Windows 10, and the SDK used to build Python 2.7 doesn't have the new definition. Do you get the same problem with Python 3.4? If so, that might indicate a VS2008 issue. (I don't think this is likely as I checked sizeof(JOBOBJECT_EXTENDED_LIMIT_INFORMATION) in VS 2008 and VS 2010 and both said 144...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 15:54:58 2015 From: report at bugs.python.org (Magnus Carlsson) Date: Wed, 06 May 2015 13:54:58 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1430920498.84.0.578943655812.issue24134@psf.upfronthosting.co.za> Magnus Carlsson added the comment: "The solution to that is to always have a test that your decorator actually returns a function. That's what I do." Yes, I agree that with more tests I would have found the problem, but sometimes you forget things. And to me I want the tests to fail by default or for cases that are unspecified. I think the sentinel solution would come a long way of solving both the issue that I reported but still keep the context solution intact. Out of curiosity, would it be a solution to have the sentinel be a real function? def _sentinel(): pass ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 16:22:27 2015 From: report at bugs.python.org (ssh) Date: Wed, 06 May 2015 14:22:27 +0000 Subject: [issue23888] Fixing fractional expiry time bug in cookiejar In-Reply-To: <1428502659.33.0.324281998086.issue23888@psf.upfronthosting.co.za> Message-ID: <1430922147.51.0.312349019731.issue23888@psf.upfronthosting.co.za> ssh added the comment: Wouldn't int(float(expires) * 1e6) set the date much further in the future? I'm not sure why you'd do that unless the plan is to change the internal time unit to microseconds (which seems like a much bigger change, and overkill for handling this special case). Cookie strings operate at the second granularity, so I'm not sure if the sub-second precision is required. I took a quick look at curl's code and test cases, and they use a time_t structure which doesn't have subsecond precision. Fractional time is not a part of their test cases. https://github.com/bagder/curl/blob/6f8046f7a4bd3d6edcc53c2eec936105ec424d54/tests/libtest/lib517.c https://github.com/bagder/curl/blob/664b9baf67c2c22ebaf3606298ca9c4ce0b382d2/lib/parsedate.c#L331 Wget also appears to do something similar: http://bzr.savannah.gnu.org/lh/wget/trunk/annotate/head:/src/cookies.c#L387 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 16:29:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 May 2015 14:29:49 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1430922589.98.0.268782451821.issue24134@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch includes tests for the function is None. There were no tests for assertRaises(), the patch adds them, based on tests for assertWarns(). > Why not sentinel = Object()? Only for better repr in the case the sentinel is leaked. Other variants are to make it named object, such as a function or a class, as Magnus suggested. ---------- Added file: http://bugs.python.org/file39306/assert_raises_sentinel_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 16:42:37 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 06 May 2015 14:42:37 +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: <1430923357.33.0.256738561597.issue24127@psf.upfronthosting.co.za> Steve Dower added the comment: Null is a valid value for job here (indicates the current process's job), so that's probably the check that's failing. When I can sit down with a VM and a debugger I'll check, but that won't be until next week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 16:49:34 2015 From: report at bugs.python.org (Paul Moore) Date: Wed, 06 May 2015 14:49:34 +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: <1430923774.64.0.402007934182.issue24127@psf.upfronthosting.co.za> Paul Moore added the comment: Cheers. I missed a bit of code, job comes from "job = CreateJobObject(NULL, NULL)" so it shouldn't be NULL unless that call failed. Rather than speculate though, I'll leave it with you. Shout if I can help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 16:56:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 May 2015 14:56:16 +0000 Subject: [issue23815] Segmentation fault when create _tkinter objects In-Reply-To: <1427745415.01.0.962782500028.issue23815@psf.upfronthosting.co.za> Message-ID: <1430924176.52.0.955343735645.issue23815@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PyType_Ready() is called inside PyType_FromSpec(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 17:06:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 May 2015 15:06:46 +0000 Subject: [issue22334] test_tcl.test_split() fails on "x86 FreeBSD 7.2 3.x" buildbot In-Reply-To: <1409817164.01.0.942615937948.issue22334@psf.upfronthosting.co.za> Message-ID: <1430924806.37.0.974823087357.issue22334@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The test no longer failed since fixing full Tcl version parsing in cebe15821a0c/5bf0d9086cfc/9f13e9385186. It is now just skipped on non-final Tcl 8.6. In any case I suggest to upgrade Tcl/Tk on this buildbot. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 17:26:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 May 2015 15:26:17 +0000 Subject: [issue24137] Force not using _default_root in IDLE Message-ID: <1430925977.27.0.721479362057.issue24137@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Perhaps explicitly calling NoDefaultRoot() in IDLE will help to catch some possible bugs (in IDLE or in Tkinter). It should be called only when IDLE is ran in subprocess mode, so it will not affect user code that uses Tkinter. _default_root is used mainly for interactive experiments with Tkinter. It is worth also to call NoDefaultRoot() in IDLE tests (see Tkinter tests as a guide). ---------- components: IDLE, Tkinter messages: 242680 nosy: kbk, roger.serwy, serhiy.storchaka, terry.reedy priority: normal severity: normal status: open title: Force not using _default_root in IDLE type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 17:37:01 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 May 2015 15:37:01 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1430926621.09.0.988948520727.issue24134@psf.upfronthosting.co.za> R. David Murray added the comment: Made a couple of review comments on the English in the test comments. Patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 17:46:47 2015 From: report at bugs.python.org (Henrik Heimbuerger) Date: Wed, 06 May 2015 15:46:47 +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: <1430927207.59.0.974010165274.issue24127@psf.upfronthosting.co.za> Henrik Heimbuerger added the comment: To your earlier question: yes, I can reproduce this with Python 3.4.3. This is all on Windows 10.0.10074, 64-bit. I don't have a 32-bit system to test. UAC configuration is unmodified and on the default setting (third of the four steps on the slider). Python has been installed using the MSI installer without administrative rights. On Python 2, pip has been installed using the official 6.1.1 get-pip.py. For Python 3, it has been tested both with the preinstalled pip (I believe that was 6.0.8) as well as after upgrading it from PyPI (using the "python -m pip" workaround). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 18:15:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 May 2015 16:15:19 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <20150506161510.98673.55084@psf.io> Roundup Robot added the comment: New changeset 111ec3d5bf19 by Serhiy Storchaka in branch '2.7': Issue #24134: assertRaises() and assertRaisesRegexp() checks are not longer https://hg.python.org/cpython/rev/111ec3d5bf19 New changeset 5418ab3e5556 by Serhiy Storchaka in branch '3.4': Issue #24134: assertRaises(), assertRaisesRegex(), assertWarns() and https://hg.python.org/cpython/rev/5418ab3e5556 New changeset 679b5439b9a1 by Serhiy Storchaka in branch 'default': Issue #24134: assertRaises(), assertRaisesRegex(), assertWarns() and https://hg.python.org/cpython/rev/679b5439b9a1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 18:16:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 May 2015 16:16:05 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1430928965.03.0.394804872925.issue24134@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you David for your corrections. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 18:18:56 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 06 May 2015 16:18:56 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects Message-ID: <1430929136.04.0.0158927713933.issue24138@psf.upfronthosting.co.za> New submission from Larry Hastings: This probably shouldn't be checked in. But it was an interesting experiment, and I did get it to work. My brother forwarded me this question from Stack Overflow: http://stackoverflow.com/questions/23453133/is-there-a-reason-python-3-enumerates-slower-than-python-2 The debate brought up a good point: a lot of the overhead of range() is in creating and destroying the long objects. I wondered, could I get rid of that? Long story short, yes. rangeiterobject is a special-case range object for when you're iterating over integer values and the values all fit inside C longs. Otherwise it has to use the much slower general-purpose longrangeiterobject.) rangeiter_next is simple: it computes the new value then returns PyLong_FromLong of that value. First thought: cache a reference to the previous value. If its reference count is 1, we have the only reference. Overwrite its value and return it. But that doesn't help in the general case, because in "for x in range(1000)" x is holding a reference at the time __next__ is called on the iterator. The trick: cache *two* old yielded objects. In the general case, by the second iteration, everyone else has dropped their references to the older cached object and we can modify it safely. The second trick: if the value you're yielding is one of the interned "small ints", you *have* to return the interned small int. (Otherwise you break 0 == 0, I kid you not.) With this patch applied all regression tests pass. And, on my desktop machine, the benchmark they used in the above link: ./python -mtimeit -n 5 -r 2 -s"cnt = 0" "for i in range(10000000): cnt += 1" drops from 410ms to 318ms ("5 loops, best of 2: 318 msec per loop"). This implementation requires the rangeiterobject to have intimate knowledge of the implementation of the PyLongObject, including copy-and-pasting some information that isn't otherwise exposed (max small int essentially). At the very least that information would need to be exposed properly so rangeiterobject could use it correctly before this could be checked in. It might be cleaner for longobject.c to expose a private "set this long object to this value" function. It would fail if we can't do it safely: if the value was an interned (small) int, or if the long was of the wrong size (Py_SIZE(o) != 1). Is this interesting enough to pursue? I'm happy to drop it. ---------- assignee: larry components: Interpreter Core files: larry.range.hack.1.txt messages: 242685 nosy: larry, pitrou, rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Speed up range() by caching and modifying long objects type: performance versions: Python 3.5 Added file: http://bugs.python.org/file39307/larry.range.hack.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 18:28:20 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 06 May 2015 16:28:20 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects In-Reply-To: <1430929136.04.0.0158927713933.issue24138@psf.upfronthosting.co.za> Message-ID: <1430929700.82.0.87456284302.issue24138@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 18:38:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 May 2015 16:38:08 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects In-Reply-To: <1430929136.04.0.0158927713933.issue24138@psf.upfronthosting.co.za> Message-ID: <1430930288.34.0.386738233021.issue24138@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This regression was just discussed in issue24076. General suggestion about free list for small ints was proposed. It could speed up other integer computations, but comprehensive benchmarking results are needed. See also similar issue23507 for tuples. Perhaps we need general solution for fast specialized free lists. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 18:38:52 2015 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 06 May 2015 16:38:52 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects In-Reply-To: <1430929136.04.0.0158927713933.issue24138@psf.upfronthosting.co.za> Message-ID: <1430930332.82.0.70683434151.issue24138@psf.upfronthosting.co.za> Stefan Behnel added the comment: See issue 24076. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 18:49:30 2015 From: report at bugs.python.org (sumpfralle) Date: Wed, 06 May 2015 16:49:30 +0000 Subject: [issue23346] shutil.rmtree doesn't work correctly on FreeBSD. In-Reply-To: <1422507173.88.0.069796427202.issue23346@psf.upfronthosting.co.za> Message-ID: <1430930970.48.0.70832829269.issue23346@psf.upfronthosting.co.za> sumpfralle added the comment: I experience the same issue on a virtualized server (based on Virtuozzo) with Linux kernel 2.6.32. The following command fails: echo "import os; os.listdir(os.open('/tmp', os.O_RDONLY))" | python3 Traceback (most recent call last): File "", line 1, in OSError: [Errno 22] Invalid argument ---------- nosy: +sumpfralle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 18:50:43 2015 From: report at bugs.python.org (Christophe BAL) Date: Wed, 06 May 2015 16:50:43 +0000 Subject: [issue24132] Direct sub-classing of pathlib.Path In-Reply-To: Message-ID: Christophe BAL added the comment: Here are for example two extra methods that I have implemented. def __sub__(cls, path): """ This magic method allows to use ``onepath - anotherpath`` instead of the long version ``onepath.relative_to(anotherpath)`` given by ``pathlib.Path``. """ return cls.relative_to(path) def _ppath_common_with(cls, paths): """ This method returns the path of the smaller common "folder" of the current path and at least one paths. python:: from mistool import os_use path = os_use.PPath("/Users/projects/source/doc") path_1 = os_use.PPath("/Users/projects/README") path_2 = os_use.PPath("/Users/projects/source/misTool/os_use.py") print(path.common_with((path_1, path_2))) """ if not isinstance(paths, (list, tuple)): paths = [paths] commonparts = list(cls.parts) for onepath in paths: i = 0 for common, actual in zip(commonparts, onepath.parts): if common == actual: i += 1 else: break commonparts = commonparts[:i] if not commonparts: break commonpath = pathlib.Path("") for part in commonparts: commonpath /= part return commonpath *Christophe BAL* *Enseignant de math?matiques en Lyc?e **et d?veloppeur Python amateur* *---* *French math teacher in a "Lyc?e" **and **Python **amateur developer* 2015-05-06 14:13 GMT+02:00 Christophe BAL : > > Christophe BAL added the comment: > > Hello. > > I will give a real example in 5 hours after my job. I will try tomorrow a > solution to ease the subclassing using another dedicazted class PathPlus, > sorry for the name. The idea would be to use this new class for > customization, and also to define WindowsPath and PosixPath sub-classing > this new class. By default PathPlus would be an empty class. I do not know > if this works well. Maybe my idea is a bad one. > > *Christophe BAL* > *Enseignant de math?matiques en Lyc?e **et d?veloppeur Python amateur* > *---* > *French math teacher in a "Lyc?e" **and **Python **amateur developer* > > 2015-05-06 13:05 GMT+02:00 Antoine Pitrou : > > > > > Antoine Pitrou added the comment: > > > > The Path classes were not designed to be subclassable by the user. > > I'm not against making subclassing easier, but someone will have to > > propose a viable approach for that. > > > > ---------- > > versions: +Python 3.5 -Python 3.4 > > > > _______________________________________ > > Python tracker > > > > _______________________________________ > > > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 19:01:19 2015 From: report at bugs.python.org (Christie) Date: Wed, 06 May 2015 17:01:19 +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: <1430931679.59.0.435314051084.issue9517@psf.upfronthosting.co.za> Christie added the comment: Thanks very much @berker.peksag! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 19:37:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 May 2015 17:37:23 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects In-Reply-To: <1430929136.04.0.0158927713933.issue24138@psf.upfronthosting.co.za> Message-ID: <1430933843.12.0.175833701047.issue24138@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that adds a free list for 1-digit long objects. $ ./python -m timeit -s "r = range(10**3)" -- "for i in r: pass" Unpatched: 10000 loops, best of 3: 54.4 usec per loop With free list: 10000 loops, best of 3: 38 usec per loop With hacked range: 10000 loops, best of 3: 34.5 usec per loop Python 2.7: 10000 loops, best of 3: 37.1 usec per loop $ ./python -m timeit -s "r = list(range(10**3))" -- "for i in r: pass" 10000 loops, best of 3: 30.7 usec per loop In Python 2.7: $ ./python -m timeit -s "r = xrange(10**3)" -- "for i in r: pass" 10000 loops, best of 3: 41.4 usec per loop $ ./python -m timeit -s "r = range(10**3)" -- "for i in r: pass" 10000 loops, best of 3: 37.1 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 19:37:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 May 2015 17:37:42 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects In-Reply-To: <1430929136.04.0.0158927713933.issue24138@psf.upfronthosting.co.za> Message-ID: <1430933862.62.0.465201717612.issue24138@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file39308/long_free_list.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 19:39:00 2015 From: report at bugs.python.org (Roy Hyunjin Han) Date: Wed, 06 May 2015 17:39:00 +0000 Subject: [issue24070] Exceptions and arguments disappear when using argparse inside with statement In-Reply-To: <1430243845.68.0.464856289952.issue24070@psf.upfronthosting.co.za> Message-ID: <1430933940.26.0.918920419058.issue24070@psf.upfronthosting.co.za> Roy Hyunjin Han added the comment: The behavior may not be surprising from a technical perspective, but it is unintuitive. I think exceptions inside a with statement should trigger a traceback, unless you are saying that it is the responsibility of the author to catch and raise the exception inside __exit__, which feels to me like a workaround that is specific to parse_args. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 19:52:11 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 May 2015 17:52:11 +0000 Subject: [issue24070] Exceptions and arguments disappear when using argparse inside with statement In-Reply-To: <1430243845.68.0.464856289952.issue24070@psf.upfronthosting.co.za> Message-ID: <1430934731.35.0.698685915597.issue24070@psf.upfronthosting.co.za> R. David Murray added the comment: What is happening here is that the __exit__ method gets passed the exception, and then instead of returning and allowing the exception to propagate and be printed, it raises SystemExit (via parse_args), which causes Python to immediately shut down, *before* __exit__ returns and the exception is propagated. So yes, you'd have to do something specific for argparse (which raises a SystemExit exception if parsing fails) if you want to do something non-normal with SystemExit. That is, you'll need to catch SystemExit. This is really a duplicate of issue 9938. ---------- dependencies: +Documentation for argparse interactive use nosy: +r.david.murray resolution: not a bug -> duplicate stage: -> resolved versions: +Python 3.4, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 19:55:12 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 06 May 2015 17:55:12 +0000 Subject: [issue23888] Fixing fractional expiry time bug in cookiejar In-Reply-To: <1428502659.33.0.324281998086.issue23888@psf.upfronthosting.co.za> Message-ID: <1430934912.66.0.100372467871.issue23888@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks for the follow up on that. In light of your findings, I agree with the path you've taken in your patch (and yeah, you'd have to deal with conversions in the output if you were to take my suggestion). I've left a couple minor comments in Reitveld. Other than those, the patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 20:06:10 2015 From: report at bugs.python.org (David Watson) Date: Wed, 06 May 2015 18:06:10 +0000 Subject: [issue8372] socket: Buffer overrun while reading unterminated AF_UNIX addresses In-Reply-To: <20150505215404.GA6149@localhost.dbwats.plus.com> Message-ID: <20150506180601.GA9381@localhost.dbwats.plus.com> David Watson added the comment: Attaching patches for 3.5. ---------- Added file: http://bugs.python.org/file39309/enable-unterminated-3.5-2015-05-06.diff Added file: http://bugs.python.org/file39310/fix-overrun-3.5-2015-05-06.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- # HG changeset patch # Parent 5f2ae82157af71456c4837ff2838d1f0f01e759e Allow AF_UNIX pathnames up to the maximum 108 bytes on Linux, since it does not require sun_path to be null terminated. 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 @@ -4477,6 +4477,54 @@ class TestExceptions(unittest.TestCase): self.assertTrue(issubclass(socket.timeout, OSError)) @unittest.skipUnless(sys.platform == 'linux', 'Linux specific test') +class TestLinuxPathLen(unittest.TestCase): + + # Test AF_UNIX path length limits on Linux. + + UNIX_PATH_MAX = 108 + + def setUp(self): + self.sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) + self.to_unlink = [] + + def tearDown(self): + self.sock.close() + for name in self.to_unlink: + support.unlink(name) + + def pathEncodingArgs(self): + # Return the encoding and error handler used to encode/decode + # pathnames. + encoding = sys.getfilesystemencoding() + if encoding is None: + encoding = sys.getdefaultencoding() + return encoding, "surrogateescape" + + def pathname(self, length): + # Return a bytes pathname of the given length. + path = os.path.abspath(support.TESTFN) + path_bytes = path.encode(*self.pathEncodingArgs()) + return path_bytes + b"a" * (length - len(path_bytes)) + + def testPathTooLong(self): + # Check we can't bind to a path longer than the assumed maximum. + path = self.pathname(self.UNIX_PATH_MAX + 1) + with self.assertRaisesRegexp(socket.error, "AF_UNIX path too long"): + self.sock.bind(path) + self.to_unlink.append(path) + + def testMaxPathLen(self): + # Test binding to a path of the maximum length and reading the + # address back. In this case, sun_path is not null terminated, + # and makesockaddr() used to read past the end of it. + path = self.pathname(self.UNIX_PATH_MAX) + self.sock.bind(path) + self.to_unlink.append(path) + self.assertEqual(self.sock.getsockname(), + path.decode(*self.pathEncodingArgs())) + os.stat(path) + + at unittest.skipUnless(sys.platform == 'linux', 'Linux specific test') class TestLinuxAbstractNamespace(unittest.TestCase): UNIX_PATH_MAX = 108 @@ -5303,6 +5351,7 @@ def test_main(): ]) tests.append(BasicSocketPairTest) tests.append(TestUnixDomain) + tests.append(TestLinuxPathLen) tests.append(TestLinuxAbstractNamespace) tests.extend([TIPCTest, TIPCThreadableTest]) tests.extend([BasicCANTest, CANTest]) diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c --- a/Modules/socketmodule.c +++ b/Modules/socketmodule.c @@ -1460,27 +1460,17 @@ getsockaddrarg(PySocketSockObject *s, Py addr = (struct sockaddr_un*)addr_ret; #ifdef linux - if (path.len > 0 && *(const char *)path.buf == 0) { - /* Linux abstract namespace extension */ - if ((size_t)path.len > sizeof addr->sun_path) { - PyErr_SetString(PyExc_OSError, - "AF_UNIX path too long"); - goto unix_out; - } - } - else -#endif /* linux */ - { - /* regular NULL-terminated string */ - if ((size_t)path.len >= sizeof addr->sun_path) { - PyErr_SetString(PyExc_OSError, - "AF_UNIX path too long"); - goto unix_out; - } - addr->sun_path[path.len] = 0; + if ((size_t)path.len > sizeof(addr->sun_path)) { +#else + if ((size_t)path.len >= sizeof(addr->sun_path)) { +#endif + PyErr_SetString(PyExc_OSError, "AF_UNIX path too long"); + goto unix_out; } addr->sun_family = s->sock_family; memcpy(addr->sun_path, path.buf, path.len); + memset(addr->sun_path + path.len, 0, + sizeof(addr->sun_path) - path.len); *len_ret = path.len + offsetof(struct sockaddr_un, sun_path); retval = 1; unix_out: -------------- next part -------------- # HG changeset patch # Parent ac51dc99c1bd722e1b24b4bfa14520082e01f1a8 When parsing addresses returned by accept(), etc., do not assume null termination of sun_path in AF_UNIX addresses: rely instead on the returned address length. If this is longer then the original buffer, ignore it and use the original length. diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c --- a/Modules/socketmodule.c +++ b/Modules/socketmodule.c @@ -1129,13 +1129,22 @@ makebdaddr(bdaddr_t *bdaddr) /*ARGSUSED*/ static PyObject * -makesockaddr(SOCKET_T sockfd, struct sockaddr *addr, size_t addrlen, int proto) +makesockaddr(SOCKET_T sockfd, struct sockaddr *addr, socklen_t addrlen, + socklen_t buflen, int proto) { if (addrlen == 0) { /* No address -- may be recvfrom() from known socket */ Py_INCREF(Py_None); return Py_None; } + /* buflen is the length of the buffer containing the address, and + addrlen is either the same, or is the length returned by the OS + after writing an address into the buffer. Some systems return + the length they would have written if there had been space + (e.g. when an oversized AF_UNIX address has its sun_path + truncated). */ + if (addrlen > buflen) + addrlen = buflen; switch (addr->sa_family) { @@ -1155,18 +1164,28 @@ makesockaddr(SOCKET_T sockfd, struct soc #if defined(AF_UNIX) case AF_UNIX: { + Py_ssize_t len, splen; struct sockaddr_un *a = (struct sockaddr_un *) addr; + + if (addrlen < offsetof(struct sockaddr_un, sun_path)) + Py_RETURN_NONE; + else + splen = addrlen - offsetof(struct sockaddr_un, sun_path); #ifdef linux - if (a->sun_path[0] == 0) { /* Linux abstract namespace */ - addrlen -= offsetof(struct sockaddr_un, sun_path); - return PyBytes_FromStringAndSize(a->sun_path, addrlen); + /* Backwards compatibility: return empty addresses as bytes */ + if (splen == 0 || (splen > 0 && a->sun_path[0] == 0)) { + /* Linux abstract namespace */ + return PyBytes_FromStringAndSize(a->sun_path, splen); } else #endif /* linux */ { - /* regular NULL-terminated string */ - return PyUnicode_DecodeFSDefault(a->sun_path); + /* Path text can occupy all of sun_path[], and therefore + lack null termination */ + for (len = 0; len < splen && a->sun_path[len] != 0; len++) + ; } + return PyUnicode_DecodeFSDefaultAndSize(a->sun_path, len); } #endif /* AF_UNIX */ @@ -2212,6 +2231,7 @@ sock_accept(PySocketSockObject *s) sock_addr_t addrbuf; SOCKET_T newfd; socklen_t addrlen; + socklen_t buflen; PyObject *sock = NULL; PyObject *addr = NULL; PyObject *res = NULL; @@ -2219,6 +2239,7 @@ sock_accept(PySocketSockObject *s) if (!getsockaddrlen(s, &addrlen)) return NULL; + buflen = addrlen; memset(&addrbuf, 0, addrlen); if (!IS_SELECTABLE(s)) @@ -2256,7 +2277,7 @@ sock_accept(PySocketSockObject *s) } addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf), - addrlen, s->sock_proto); + addrlen, buflen, s->sock_proto); if (addr == NULL) goto finally; @@ -2720,16 +2741,18 @@ sock_getsockname(PySocketSockObject *s) sock_addr_t addrbuf; int res; socklen_t addrlen; + socklen_t buflen; if (!getsockaddrlen(s, &addrlen)) return NULL; + buflen = addrlen; memset(&addrbuf, 0, addrlen); Py_BEGIN_ALLOW_THREADS res = getsockname(s->sock_fd, SAS2SA(&addrbuf), &addrlen); Py_END_ALLOW_THREADS if (res < 0) return s->errorhandler(); - return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, + return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, buflen, s->sock_proto); } @@ -2749,16 +2772,18 @@ sock_getpeername(PySocketSockObject *s) sock_addr_t addrbuf; int res; socklen_t addrlen; + socklen_t buflen; if (!getsockaddrlen(s, &addrlen)) return NULL; + buflen = addrlen; memset(&addrbuf, 0, addrlen); Py_BEGIN_ALLOW_THREADS res = getpeername(s->sock_fd, SAS2SA(&addrbuf), &addrlen); Py_END_ALLOW_THREADS if (res < 0) return s->errorhandler(); - return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, + return makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, buflen, s->sock_proto); } @@ -3017,12 +3042,14 @@ sock_recvfrom_guts(PySocketSockObject *s { sock_addr_t addrbuf; socklen_t addrlen; + socklen_t buflen; struct sock_recvfrom ctx; *addr = NULL; if (!getsockaddrlen(s, &addrlen)) return -1; + buflen = addrlen; if (!IS_SELECTABLE(s)) { select_error(); @@ -3037,7 +3064,7 @@ sock_recvfrom_guts(PySocketSockObject *s if (sock_call(s, 0, sock_recvfrom_impl, &ctx) < 0) return -1; - *addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, + *addr = makesockaddr(s->sock_fd, SAS2SA(&addrbuf), addrlen, buflen, s->sock_proto); if (*addr == NULL) return -1; @@ -3277,8 +3304,7 @@ sock_recvmsg_guts(PySocketSockObject *s, cmsg_list, (int)msg.msg_flags, makesockaddr(s->sock_fd, SAS2SA(&addrbuf), - ((msg.msg_namelen > addrbuflen) ? - addrbuflen : msg.msg_namelen), + msg.msg_namelen, addrbuflen, s->sock_proto)); if (retval == NULL) goto err_closefds; @@ -5560,7 +5586,8 @@ socket_getaddrinfo(PyObject *self, PyObj for (res = res0; res; res = res->ai_next) { PyObject *single; PyObject *addr = - makesockaddr(-1, res->ai_addr, res->ai_addrlen, protocol); + makesockaddr(-1, res->ai_addr, res->ai_addrlen, res->ai_addrlen, + protocol); if (addr == NULL) goto err; single = Py_BuildValue("iiisO", res->ai_family, From report at bugs.python.org Wed May 6 20:21:59 2015 From: report at bugs.python.org (Paul Moore) Date: Wed, 06 May 2015 18:21:59 +0000 Subject: [issue24132] Direct sub-classing of pathlib.Path In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za> Message-ID: <1430936519.1.0.943827684681.issue24132@psf.upfronthosting.co.za> Paul Moore added the comment: For that type of function, I'd suggest you use a standalone function rather than subclassing and methods or operator overloading. You don't gain enough to be worth the complexity of having to subclass path objects. And duck typing means that your function works for any subclass of (Pure)Path without change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 20:26:47 2015 From: report at bugs.python.org (Paul Moore) Date: Wed, 06 May 2015 18:26:47 +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: <1430936807.94.0.846910413182.issue24127@psf.upfronthosting.co.za> Paul Moore added the comment: Adding Jason Coombs and Vinay Sajip, as if this needs a fix to the launcher code, then the launchers used by distlib and setuptools (for exe wrappers of console entry points) will need to be changed as well. It would be really useful if all 3 projects used a single codebase - having to duplicate fixes like this is annoying. ---------- nosy: +jason.coombs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 20:32:06 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 06 May 2015 18:32:06 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1430937126.3.0.234781074199.issue22906@psf.upfronthosting.co.za> Yury Selivanov added the comment: Hi Chris! Can I somehow help with the patch? ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 20:41:32 2015 From: report at bugs.python.org (Christophe BAL) Date: Wed, 06 May 2015 18:41:32 +0000 Subject: [issue24132] Direct sub-classing of pathlib.Path In-Reply-To: <1430936519.1.0.943827684681.issue24132@psf.upfronthosting.co.za> Message-ID: Christophe BAL added the comment: I don't agree with you. I prefer to add new functionalities to the paths I use. This is the power of OOP. It is easier and cleaner to use *mypath.common_with(otherpath)* than *common_with(**mypath, **other path)* . Python is highly OOP, so you can't say *"don't use subclassing in your case"*. As a user, I should have the possibility to use the method I want. Another example is the use of *onepath - anotherpath* instead of *onepath.relative_to(**another path)* . That's the power of the magic method to add this kind of feature. *Christophe BAL* *Enseignant de math?matiques en Lyc?e **et d?veloppeur Python amateur* *---* *French math teacher in a "Lyc?e" **and **Python **amateur developer* 2015-05-06 20:21 GMT+02:00 Paul Moore : > > Paul Moore added the comment: > > For that type of function, I'd suggest you use a standalone function > rather than subclassing and methods or operator overloading. You don't gain > enough to be worth the complexity of having to subclass path objects. And > duck typing means that your function works for any subclass of (Pure)Path > without change. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 21:01:32 2015 From: report at bugs.python.org (Paul Moore) Date: Wed, 06 May 2015 19:01:32 +0000 Subject: [issue24132] Direct sub-classing of pathlib.Path In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za> Message-ID: <1430938892.35.0.226280483559.issue24132@psf.upfronthosting.co.za> Paul Moore added the comment: I have no problem with that - it's a style choice certainly. As I said, I'd like to see simpler subclassing of pathlib objects. I just think it'll be quite hard to do (given the complexities of classes for Windows/Unix as well as pure and concrete paths). So if it's just about examples like this, I personally would take the easier route and just go with standalone functions. If someone else felt strongly enough to design and implement a subclassing solution, that's fine though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 21:06:30 2015 From: report at bugs.python.org (Christophe BAL) Date: Wed, 06 May 2015 19:06:30 +0000 Subject: [issue24132] Direct sub-classing of pathlib.Path In-Reply-To: <1430938892.35.0.226280483559.issue24132@psf.upfronthosting.co.za> Message-ID: Christophe BAL added the comment: Are you the author of path lib ? *Christophe BAL* *Enseignant de math?matiques en Lyc?e **et d?veloppeur Python amateur* *---* *French math teacher in a "Lyc?e" **and **Python **amateur developer* 2015-05-06 21:01 GMT+02:00 Paul Moore : > > Paul Moore added the comment: > > I have no problem with that - it's a style choice certainly. > > As I said, I'd like to see simpler subclassing of pathlib objects. I just > think it'll be quite hard to do (given the complexities of classes for > Windows/Unix as well as pure and concrete paths). So if it's just about > examples like this, I personally would take the easier route and just go > with standalone functions. If someone else felt strongly enough to design > and implement a subclassing solution, that's fine though. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 21:09:38 2015 From: report at bugs.python.org (Paul Moore) Date: Wed, 06 May 2015 19:09:38 +0000 Subject: [issue24132] Direct sub-classing of pathlib.Path In-Reply-To: Message-ID: Paul Moore added the comment: > Are you the author of path lib ? Nope, that's Antoine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 21:18:59 2015 From: report at bugs.python.org (Christophe BAL) Date: Wed, 06 May 2015 19:18:59 +0000 Subject: [issue24132] Direct sub-classing of pathlib.Path In-Reply-To: Message-ID: Christophe BAL added the comment: OK. I will try to find a way to achieve an easier and cleaner way to sub class pathlib.Path and co. What is the good way to propose a patch ? *Christophe BAL* *Enseignant de math?matiques en Lyc?e **et d?veloppeur Python amateur* *---* *French math teacher in a "Lyc?e" **and **Python **amateur developer* 2015-05-06 21:09 GMT+02:00 Paul Moore : > > Paul Moore added the comment: > > > Are you the author of path lib ? > > Nope, that's Antoine. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 21:55:59 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 06 May 2015 19:55:59 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects In-Reply-To: <1430929136.04.0.0158927713933.issue24138@psf.upfronthosting.co.za> Message-ID: <1430942159.56.0.789885424419.issue24138@psf.upfronthosting.co.za> Mark Lawrence added the comment: How does this apply where people like me scarcely if ever use range, it's standard for loops? There are plenty of recipes using itertools that show that you don't need range, is this really needed? No axe to grind, just curious. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 22:01:42 2015 From: report at bugs.python.org (Paul Moore) Date: Wed, 06 May 2015 20:01:42 +0000 Subject: [issue24132] Direct sub-classing of pathlib.Path In-Reply-To: Message-ID: Paul Moore added the comment: > What is the good way to propose a patch ? If you have a patch, attach it here, and it will get reviewed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 22:07:55 2015 From: report at bugs.python.org (Erik Hvatum) Date: Wed, 06 May 2015 20:07:55 +0000 Subject: [issue1222585] C++ compilation support for distutils Message-ID: <1430942875.11.0.868539368417.issue1222585@psf.upfronthosting.co.za> Erik Hvatum added the comment: The 2012-12-31 of this patch (currently the latest) has the surprising effect of causing distutils CFLAGS to be dropped. See for reference: https://bugs.gentoo.org/show_bug.cgi?id=548776 The issue I am experiencing is resolved by changing the section of the patch that reads: +- (cc, cxx, opt, cflags, ccshared, ldshared, shlib_suffix, ar, ar_flags) = \ +- get_config_vars('CC', 'CXX', 'OPT', 'CFLAGS', +- 'CCSHARED', 'LDSHARED', 'SHLIB_SUFFIX', 'AR', 'ARFLAGS') ++ (cc, cxx, ccshared, ldshared, ldcxxshared, shlib_suffix, ar, ar_flags) = \ ++ get_config_vars('CC', 'CXX', 'CCSHARED', 'LDSHARED', 'LDCXXSHARED', ++ 'SHLIB_SUFFIX', 'AR', 'ARFLAGS') ++ ++ cflags = '' ++ cxxflags = '' to: +- (cc, cxx, opt, cflags, ccshared, ldshared, shlib_suffix, ar, ar_flags) = \ +- get_config_vars('CC', 'CXX', 'OPT', 'CFLAGS', +- 'CCSHARED', 'LDSHARED', 'SHLIB_SUFFIX', 'AR', 'ARFLAGS') ++ (cc, cxx, cflags, ccshared, ldshared, ldcxxshared, shlib_suffix, ar, ar_flags) = \ ++ get_config_vars('CC', 'CXX', 'CFLAGS', 'CCSHARED', 'LDSHARED', 'LDCXXSHARED', ++ 'SHLIB_SUFFIX', 'AR', 'ARFLAGS') ++ ++ cxxflags = cflags This change causes the CFLAGS outputted by "python-config --cflags" to be used by distutils, as they are without the patch applied. To me, losing those CFLAGS, especially when building plain C python extensions, seems like a significant regression. ---------- nosy: +ehvatum versions: +Python 3.4 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 22:21:41 2015 From: report at bugs.python.org (Brian Curtin) Date: Wed, 06 May 2015 20:21:41 +0000 Subject: [issue1222585] C++ compilation support for distutils Message-ID: <1430943701.36.0.823898281783.issue1222585@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 6 22:47:57 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 06 May 2015 20:47:57 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects In-Reply-To: <1430929136.04.0.0158927713933.issue24138@psf.upfronthosting.co.za> Message-ID: <1430945277.23.0.404816130008.issue24138@psf.upfronthosting.co.za> Larry Hastings added the comment: 10**3 doesn't show off this hack as much as other numbers would; the hack only operates from 257 to the max in that will fit in a single long "digit" (32767 on 32-bit, 2**30 on 64-bit). Anyway, freelist for one-digit longs seems nearly as good, and it's a lot more general-purpose, so I'm much more interested in that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 04:12:17 2015 From: report at bugs.python.org (ssh) Date: Thu, 07 May 2015 02:12:17 +0000 Subject: [issue23888] Fixing fractional expiry time bug in cookiejar In-Reply-To: <1428502659.33.0.324281998086.issue23888@psf.upfronthosting.co.za> Message-ID: <1430964737.02.0.791100792986.issue23888@psf.upfronthosting.co.za> ssh added the comment: Attaching patch after addressing comments in code review. ---------- Added file: http://bugs.python.org/file39311/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 04:45:19 2015 From: report at bugs.python.org (Chris Angelico) Date: Thu, 07 May 2015 02:45:19 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1430966719.81.0.117475078995.issue22906@psf.upfronthosting.co.za> Chris Angelico added the comment: You sure can! Take it, deploy it, run the test suite, and then start writing real code that uses it. When you find a problem, that's what needs help! :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 11:19:35 2015 From: report at bugs.python.org (Dima Tisnek) Date: Thu, 07 May 2015 09:19:35 +0000 Subject: [issue24139] Use sqlite3 extended error codes Message-ID: <1430990375.51.0.367829317248.issue24139@psf.upfronthosting.co.za> New submission from Dima Tisnek: Let's fetch extended error codes from SQLite, information contained is not particularly interesting to the user, but may be invaluable in debugging! http://www.sqlite.org/rescode.html https://sqlite.org/c3ref/extended_result_codes.html http://www.sqlite.org/c3ref/errcode.html Current behaviour: For example, consider that extended error was SQLITE_READONLY_DBMOVED, it would be set in https://github.com/mackyle/sqlite/blob/1caed0ecc62583c4f8a509ff66ae99b6939fe727/src/pager.c#L4836 without explicit detail string. Python will call sqlite3_errcode() which will strip extended information via `& errMask` in https://github.com/mackyle/sqlite/blob/ebb27fe5bd5045d924d99cdd7dec9b7064c24768/src/main.c#L2176 Python will then call sqlite3_errmsg(), and the error message will be according to truncated (simple) error per: https://github.com/mackyle/sqlite/blob/ebb27fe5bd5045d924d99cdd7dec9b7064c24768/src/main.c#L1318 P.S. there are a few cases where sqlite3 internally sets both error code and message, in those cases, current Python module (presumably) reads out the error message correctly. For example https://github.com/mackyle/sqlite/blob/ebb27fe5bd5045d924d99cdd7dec9b7064c24768/src/main.c#L1584 ---------- components: Extension Modules messages: 242710 nosy: Dima.Tisnek priority: normal severity: normal status: open title: Use sqlite3 extended error codes type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 13:31:05 2015 From: report at bugs.python.org (vyktor) Date: Thu, 07 May 2015 11:31:05 +0000 Subject: [issue24140] In pdb using "until X" doesn't seem to have effect in commands Message-ID: <1430998265.01.0.0346920117937.issue24140@psf.upfronthosting.co.za> New submission from vyktor: When using pdb -m pdb test.py and entering: (Pdb) b A.f Breakpoint 1 at d:\tmp\stack\test.py:8 (Pdb) commands 2 (com) disable 2 (com) until 13 (com) end Until doesn't seem to have any effect. When statement is executed manually, everything works as expected (execution halts before implicit return from function). ---------- components: Library (Lib) messages: 242711 nosy: vyktor priority: normal severity: normal status: open title: In pdb using "until X" doesn't seem to have effect in commands type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 14:25:32 2015 From: report at bugs.python.org (Jens Timmerman) Date: Thu, 07 May 2015 12:25:32 +0000 Subject: [issue13492] ./configure --with-system-ffi=LIBFFI-PATH In-Reply-To: <1322472271.69.0.0807066602711.issue13492@psf.upfronthosting.co.za> Message-ID: <1431001532.75.0.624578781966.issue13492@psf.upfronthosting.co.za> Jens Timmerman added the comment: Wel, I can confirm that this is fixed in new libffi shipped with python now, and the problem no longer occurs on 3.4.3 (only version I checked) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 14:28:57 2015 From: report at bugs.python.org (Jens Timmerman) Date: Thu, 07 May 2015 12:28:57 +0000 Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za> Message-ID: <1431001737.71.0.2095700946.issue4130@psf.upfronthosting.co.za> Jens Timmerman added the comment: yep, newer versions of python with newer libffi do not longer have this issue, confirmed with python 3.4.3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 15:41:18 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 May 2015 13:41:18 +0000 Subject: [issue24139] Use sqlite3 extended error codes In-Reply-To: <1430990375.51.0.367829317248.issue24139@psf.upfronthosting.co.za> Message-ID: <1431006078.44.0.216008241151.issue24139@psf.upfronthosting.co.za> R. David Murray added the comment: It seems reasonable to provide as much error information as is available, one way or another. Would you like to work on a patch? ---------- nosy: +r.david.murray versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 16:37:18 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 07 May 2015 14:37:18 +0000 Subject: [issue2122] mmap.flush does not check for errors on windows In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za> Message-ID: <1431009438.98.0.354037644898.issue2122@psf.upfronthosting.co.za> Mark Lawrence added the comment: I think we should be properly handling errors. If people agree I'll provide a new patch to cover code and doc changes, but I've no idea how to provide any form of unit test for the change. ---------- nosy: +BreamoreBoy, paul.moore, steve.dower, zach.ware versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 16:45:54 2015 From: report at bugs.python.org (Brian Curtin) Date: Thu, 07 May 2015 14:45:54 +0000 Subject: [issue2122] mmap.flush does not check for errors on windows In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za> Message-ID: <1431009954.87.0.265661548945.issue2122@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 17:30:10 2015 From: report at bugs.python.org (Michael Ensslin) Date: Thu, 07 May 2015 15:30:10 +0000 Subject: [issue24141] Python 3 ships an outdated valgrind suppresison file. Message-ID: <1431012610.94.0.0884914526585.issue24141@psf.upfronthosting.co.za> New submission from Michael Ensslin: The suppression file that is shipped in Misc/valgrind-python.supp of the CPython 3(.x) source tarball only works with CPython 2. This was tested on Debian Sid, with Python 3.4.3 and Python 2.7.9, both presumably not compiled with "--valgrind". Since Debian does not ship valgrind-python.supp, I downloaded the source tarball for Python 3.4.3, and edited the suppression file (un-commenting the rules for Free and Realloc, as the documentation suggests for when running with a non-valgrind-aware version of CPython). The test results are as follows: $ uname -a Linux mic 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-2 (2015-04-13) x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux unstable (sid) Release: unstable Codename: sid $ valgrind --version valgrind-3.10.1 $ python3 --version Python 3.4.3 $ python2 --version Python 2.7.9 $ valgrind --tool=memcheck --suppressions=/tmp/Python-3.4.3/Misc/valgrind-python.supp python3 -c 'import sys; print(sys.version)' (...) ERROR SUMMARY: 666 errors from 61 contexts (suppressed: 0 from 0) $ valgrind --tool=memcheck --suppressions=/tmp/Python-3.4.3/Misc/valgrind-python.supp python2 -c 'import sys; print(sys.version)' (...) ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 486 from 28) ---------- messages: 242716 nosy: mic-e priority: normal severity: normal status: open title: Python 3 ships an outdated valgrind suppresison file. versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 17:31:10 2015 From: report at bugs.python.org (Michael Ensslin) Date: Thu, 07 May 2015 15:31:10 +0000 Subject: [issue24141] Python 3 ships an outdated valgrind suppressison file. In-Reply-To: <1431012610.94.0.0884914526585.issue24141@psf.upfronthosting.co.za> Message-ID: <1431012670.28.0.716783312863.issue24141@psf.upfronthosting.co.za> Changes by Michael Ensslin : ---------- title: Python 3 ships an outdated valgrind suppresison file. -> Python 3 ships an outdated valgrind suppressison file. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 17:37:40 2015 From: report at bugs.python.org (Michael Ensslin) Date: Thu, 07 May 2015 15:37:40 +0000 Subject: [issue24141] Python 3 ships an outdated valgrind suppressison file. In-Reply-To: <1431012610.94.0.0884914526585.issue24141@psf.upfronthosting.co.za> Message-ID: <1431013060.96.0.16650457595.issue24141@psf.upfronthosting.co.za> Michael Ensslin added the comment: Note: Additionally replacing PyObject_Free -> _PyObject_Free and PyObject_Realloc -> _PyObject_Realloc appears to fix the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 17:39:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 May 2015 15:39:34 +0000 Subject: [issue24141] Python 3 ships an outdated valgrind suppressison file. In-Reply-To: <1431012610.94.0.0884914526585.issue24141@psf.upfronthosting.co.za> Message-ID: <1431013174.22.0.10213766639.issue24141@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +christian.heimes, haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 17:54:46 2015 From: report at bugs.python.org (=?utf-8?q?Florian_H=C3=B6ch?=) Date: Thu, 07 May 2015 15:54:46 +0000 Subject: [issue24142] ConfigParser._read doesn't join multi-line values collected while reading if a ParsingError occured Message-ID: <1431014086.96.0.315028213592.issue24142@psf.upfronthosting.co.za> New submission from Florian H?ch: If a ParsingError occurs while reading a config file, the multi-line values collected while reading will never be joined because the error is raised before this can happen. This leads to very unexpected results, e.g. consider the following config.ini: [DEFAULT] test = test invalid >>> cfg = ConfigParser.ConfigParser() >>> cfg.read(['config.ini']) This will raise a ParsingError as expected. But the option values that were parsed without error are now all lists instead of strings: >>> cfg.get('DEFAULT', test') ['test'] Patch attached. ---------- components: Library (Lib) files: ConfigParser.py.patch keywords: patch messages: 242718 nosy: fhoech priority: normal severity: normal status: open title: ConfigParser._read doesn't join multi-line values collected while reading if a ParsingError occured type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file39312/ConfigParser.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 17:58:22 2015 From: report at bugs.python.org (=?utf-8?q?Florian_H=C3=B6ch?=) Date: Thu, 07 May 2015 15:58:22 +0000 Subject: [issue24142] ConfigParser._read doesn't join multi-line values collected while reading if a ParsingError occured In-Reply-To: <1431014086.96.0.315028213592.issue24142@psf.upfronthosting.co.za> Message-ID: <1431014302.74.0.582663905167.issue24142@psf.upfronthosting.co.za> Florian H?ch added the comment: [Btw, you might want to fix the contributor agreement form - I can't sign it because it shows no text, so I don't know what I'm supposed to enter in the fields (Firefox 37.0.2)] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 18:46:31 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 May 2015 16:46:31 +0000 Subject: [issue24142] ConfigParser._read doesn't join multi-line values collected while reading if a ParsingError occured In-Reply-To: <1431014086.96.0.315028213592.issue24142@psf.upfronthosting.co.za> Message-ID: <1431017191.56.0.0486782252564.issue24142@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 18:48:29 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 07 May 2015 16:48:29 +0000 Subject: [issue23888] Fixing fractional expiry time bug in cookiejar In-Reply-To: <1428502659.33.0.324281998086.issue23888@psf.upfronthosting.co.za> Message-ID: <1431017309.6.0.0909958025741.issue23888@psf.upfronthosting.co.za> Demian Brecht added the comment: I left a small comment around indentation in Rietveld. Also, for the sake of completeness (and for others taking part in this review/commit), I dug through the relevant RFCs and none of them seem to define time as having sub-section resolution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 20:29:14 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 07 May 2015 18:29:14 +0000 Subject: [issue24139] Use sqlite3 extended error codes In-Reply-To: <1430990375.51.0.367829317248.issue24139@psf.upfronthosting.co.za> Message-ID: <1431023354.1.0.739247420405.issue24139@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 20:33:28 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 07 May 2015 18:33:28 +0000 Subject: [issue24140] In pdb using "until X" doesn't seem to have effect in commands In-Reply-To: <1430998265.01.0.0346920117937.issue24140@psf.upfronthosting.co.za> Message-ID: <1431023608.25.0.110595885809.issue24140@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 20:34:03 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 07 May 2015 18:34:03 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1431023643.46.0.758398499777.issue2292@psf.upfronthosting.co.za> Stefan Behnel added the comment: I get a test failure in Cython's compatibility tests which seems to be attributable to this change: """ >>> def sideeffect(x): ... L.append(x) ... return x >>> def unhashable(x): ... L.append(x) ... return [x] >>> L = [] >>> {1:2, sideeffect(2): 3, 3: 4, unhashable(4): 5, sideeffect(5): 6} # doctest: +ELLIPSIS Traceback (most recent call last): TypeError: ...unhashable... >>> L [2, 4] """ Instead, L ends up being [2, 4, 5]. Is this intended? Or acceptable? ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 20:39:04 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 07 May 2015 18:39:04 +0000 Subject: [issue24141] Python 3 ships an outdated valgrind suppressison file. In-Reply-To: <1431012610.94.0.0884914526585.issue24141@psf.upfronthosting.co.za> Message-ID: <1431023944.81.0.531186549712.issue24141@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report. This problem and solution was just reported recently in Issue24111. ---------- nosy: +ned.deily resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Valgrind suppression file should be updated _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 20:40:23 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 07 May 2015 18:40:23 +0000 Subject: [issue24111] Valgrind suppression file should be updated In-Reply-To: <1430549990.4.0.860597056405.issue24111@psf.upfronthosting.co.za> Message-ID: <1431024023.69.0.918868500753.issue24111@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 20:40:31 2015 From: report at bugs.python.org (Joshua Landau) Date: Thu, 07 May 2015 18:40:31 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1431024031.26.0.676909132544.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: There is a change as part of this to make dict building more like list and set building, which both have this behaviour. The same changes have likely occurred before whenever BUILD_LIST and BUILD_SET were introduced, and this behaviour seems particularly undefined. That said, I did overlook the difference. Hopefully there's agreement that it doesn't matter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 20:43:25 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 07 May 2015 18:43:25 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1431024031.26.0.676909132544.issue2292@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I think it's fine. It collects all the keys and values and then calls BUILD_MAP (a new opcode), rather than calling STORE_MAP for each key/value pair. I think this is a reasonable strategy for compiling a dict display. On Thu, May 7, 2015 at 11:40 AM, Joshua Landau wrote: > > Joshua Landau added the comment: > > There is a change as part of this to make dict building more like list and > set building, which both have this behaviour. > > The same changes have likely occurred before whenever BUILD_LIST and > BUILD_SET were introduced, and this behaviour seems particularly undefined. > > That said, I did overlook the difference. Hopefully there's agreement that > it doesn't matter. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 20:53:09 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 07 May 2015 18:53:09 +0000 Subject: [issue24142] ConfigParser._read doesn't join multi-line values collected while reading if a ParsingError occured In-Reply-To: <1431014086.96.0.315028213592.issue24142@psf.upfronthosting.co.za> Message-ID: <1431024789.76.0.568000013291.issue24142@psf.upfronthosting.co.za> Ned Deily added the comment: [Thanks for the headsup about the contributor agreement form, now reported as https://github.com/python/pythondotorg/issues/747] ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 20:53:23 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 07 May 2015 18:53:23 +0000 Subject: [issue24142] ConfigParser._read doesn't join multi-line values collected while reading if a ParsingError occured In-Reply-To: <1431014086.96.0.315028213592.issue24142@psf.upfronthosting.co.za> Message-ID: <1431024803.83.0.414563153328.issue24142@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: -ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 20:55:53 2015 From: report at bugs.python.org (Karl Richter) Date: Thu, 07 May 2015 18:55:53 +0000 Subject: [issue24143] Makefile in tarball don't provide make uninstall target Message-ID: <1431024953.91.0.723046823463.issue24143@psf.upfronthosting.co.za> Changes by Karl Richter : ---------- components: Build nosy: krichter priority: normal severity: normal status: open title: Makefile in tarball don't provide make uninstall target versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 21:07:48 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 07 May 2015 19:07:48 +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: <1431025668.42.0.477915881369.issue7267@psf.upfronthosting.co.za> Mark Lawrence added the comment: What if any harm can be done by applying the patch with Victor's work around? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 21:10:59 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 07 May 2015 19:10:59 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1431025859.92.0.542603133781.issue24120@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 21:13:32 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 07 May 2015 19:13:32 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1431026012.34.0.66924053885.issue24120@psf.upfronthosting.co.za> Ethan Furman added the comment: >From Frank Woodall on python-ideas: ================================== How to reproduce: mkdir /tmp/path_test && cd /tmp/path_test && mkdir dir1 dir2 dir2/dir3 && touch dir1/file1 dir1/file2 dir2/file1 dir2/file2 dir2/dir3/file1 su chmod 700 dir2/dir3/ chown root:root dir2/dir3/ exit python 3.4.1 from pathlib import Path p = Path('/tmp/path_test') for x in p.rglob('*') : print(x) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 21:20:06 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 07 May 2015 19:20:06 +0000 Subject: [issue24143] Makefile in tarball don't provide make uninstall target Message-ID: <1431026406.49.0.875641108307.issue24143@psf.upfronthosting.co.za> New submission from Ned Deily: This has come up in the past (for example, Issue549764) but, AFAIK, no one has shown much interest in pursuing such a feature by providing a patch. Note that it would likely be very tricky to cover all the edge cases properly. As a practical matter, one reason this issue hasn't been addressed at the Makefile level is that most Python users do not install Python themselves from source but rather use one installed by some sort of package manager - e.g. an operating system release (e.g. Debian, OS X, etc), a third-party package manager (e.g. conda etc), or the python.org Windows installer - all of which have their own ways of managing installs, upgrades, and uninstalls. Unless you or someone else is willing to work on a patch with tests that does not add a significant new maintenance burden to the Makefile, it's likely to languish again. ---------- nosy: +ned.deily versions: +Python 3.6 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 21:22:40 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 07 May 2015 19:22:40 +0000 Subject: [issue24143] Makefile in tarball don't provide make uninstall target In-Reply-To: <1431026406.49.0.875641108307.issue24143@psf.upfronthosting.co.za> Message-ID: <1431026560.56.0.952083505225.issue24143@psf.upfronthosting.co.za> Ned Deily added the comment: [Note, this is in response to the opening of this issue by krichter; the opening did not generate a message itself] This has come up in the past (for example, Issue549764) but, AFAIK, no one has shown much interest in pursuing such a feature by providing a patch. Note that it would likely be very tricky to cover all the edge cases properly. As a practical matter, one reason this issue hasn't been addressed at the Makefile level is that most Python users do not install Python themselves from source but rather use one installed by some sort of package manager - e.g. an operating system release (e.g. Debian, OS X, etc), a third-party package manager (e.g. conda etc), or the python.org Windows installer - all of which have their own ways of managing installs, upgrades, and uninstalls. Unless you or someone else is willing to work on a patch with tests that does not add a significant new maintenance burden to the Makefile, it's likely to languish again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 21:23:00 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 07 May 2015 19:23:00 +0000 Subject: [issue24143] Makefile in tarball don't provide make uninstall target In-Reply-To: <1431026560.56.0.952083505225.issue24143@psf.upfronthosting.co.za> Message-ID: <1431026580.94.0.593897610603.issue24143@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- Removed message: http://bugs.python.org/msg242728 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 21:26:04 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 07 May 2015 19:26:04 +0000 Subject: [issue24143] Makefile in tarball don't provide make uninstall target In-Reply-To: <1431026560.56.0.952083505225.issue24143@psf.upfronthosting.co.za> Message-ID: <1431026764.74.0.29882463942.issue24143@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- priority: normal -> low stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 22:09:23 2015 From: report at bugs.python.org (Geoff Shannon) Date: Thu, 07 May 2015 20:09:23 +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: <1431029363.98.0.544658122152.issue22865@psf.upfronthosting.co.za> Geoff Shannon added the comment: Okay, I just found another way to achieve the same effect of letting the _read function ignore data but not inadvertantly close the stream. It relies on the fact that terminals will ignore null bytes fed to them. Now there are no code changes required, just an addition to the documentation. ---------- components: -Library (Lib) title: Allow pty.spawn to ignore data to copy -> Document how to make pty.spawn not copy data Added file: http://bugs.python.org/file39313/pty.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 22:13:29 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 07 May 2015 20:13:29 +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: <1431029609.53.0.505159164191.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: Third patch attached. Victor, it would be great if you can review it! ---------- Added file: http://bugs.python.org/file39314/await_03.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 22:16:17 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 07 May 2015 20:16:17 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431029777.86.0.159270030362.issue22906@psf.upfronthosting.co.za> Yury Selivanov added the comment: > You sure can! Take it, deploy it, run the test suite, and then start writing real code that uses it. When you find a problem, that's what needs help! :) Thank you for this generic answer, Chris. The reason I was asking is because issue #24017 depends on this one (also release blocker). And I was genuinely wondering if I can help (somehow) advancing your patch to be committed asap. Anyways, do you have any estimate when you finalize it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 22:18:01 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 07 May 2015 20:18:01 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1431029777.86.0.159270030362.issue22906@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I think you could help by (a) reviewing what's there, and (b) helping with the implementation of __future__. On Thu, May 7, 2015 at 1:16 PM, Yury Selivanov wrote: > > Yury Selivanov added the comment: > > > You sure can! Take it, deploy it, run the test suite, and then start > writing real code that uses it. When you find a problem, that's what needs > help! :) > > Thank you for this generic answer, Chris. > > The reason I was asking is because issue #24017 depends on this one (also > release blocker). And I was genuinely wondering if I can help (somehow) > advancing your patch to be committed asap. Anyways, do you have any > estimate when you finalize it? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 22:24:38 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 07 May 2015 20:24:38 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: Message-ID: Guido van Rossum added the comment: Or, if it's perfect (or good enough :-), just check it in. On Thu, May 7, 2015 at 1:18 PM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > I think you could help by (a) reviewing what's there, and (b) helping with > the implementation of __future__. > > On Thu, May 7, 2015 at 1:16 PM, Yury Selivanov > wrote: > > > > > Yury Selivanov added the comment: > > > > > You sure can! Take it, deploy it, run the test suite, and then start > > writing real code that uses it. When you find a problem, that's what > needs > > help! :) > > > > Thank you for this generic answer, Chris. > > > > The reason I was asking is because issue #24017 depends on this one (also > > release blocker). And I was genuinely wondering if I can help (somehow) > > advancing your patch to be committed asap. Anyways, do you have any > > estimate when you finalize it? > > > > ---------- > > > > _______________________________________ > > Python tracker > > > > _______________________________________ > > > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 22:48:43 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 07 May 2015 20:48:43 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects In-Reply-To: <1430929136.04.0.0158927713933.issue24138@psf.upfronthosting.co.za> Message-ID: <1431031723.91.0.176740092761.issue24138@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 23:24:00 2015 From: report at bugs.python.org (ssh) Date: Thu, 07 May 2015 21:24:00 +0000 Subject: [issue23888] Fixing fractional expiry time bug in cookiejar In-Reply-To: <1428502659.33.0.324281998086.issue23888@psf.upfronthosting.co.za> Message-ID: <1431033840.0.0.00853681510822.issue23888@psf.upfronthosting.co.za> ssh added the comment: Thanks for checking in the RFC. I had done that before I posted my StackOverflow question, but should have mentioned it here for completeness. I've addressed the comments. ---------- Added file: http://bugs.python.org/file39315/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 23:25:06 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 07 May 2015 21:25:06 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431033906.01.0.196864935653.issue22906@psf.upfronthosting.co.za> Yury Selivanov added the comment: Hi, Please find attached an updated patch. Summary of changes: 1. Most of feedback from Nick Coghlan and Serhiy Storchaka is applied; 2. Changes in difflib.py were reverted (unless we add the __future__ import there right now there is no need to fix it); 3. Chris' test is integrated to the patch. All in all I think it's in a good shape now, but I'd appreciate if someone looks at genobject.c changes one more time. ---------- Added file: http://bugs.python.org/file39316/pep0479.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 7 23:27:11 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 07 May 2015 21:27:11 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431034031.16.0.966512197132.issue22906@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- assignee: -> yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 00:10:35 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Thu, 07 May 2015 22:10:35 +0000 Subject: [issue24144] Docs discourage use of binascii.unhexlify etc. Message-ID: <1431036635.15.0.698772318331.issue24144@psf.upfronthosting.co.za> New submission from Devin Jeanpierre: Maybe the functions should be split up into those you shouldn't need to call directly, and those you should? I find it unlikely that you're supposed to use codecs.encode(..., 'hex') and codecs.decode(..., 'hex') instead of binascii (the only other thing, AFAIK, that works in both 2 and 3). Relevant quote starts with: "Normally, you will not use these functions directly" https://docs.python.org/2/library/binascii https://docs.python.org/3/library/binascii ---------- assignee: docs at python components: Documentation messages: 242737 nosy: Devin Jeanpierre, docs at python priority: normal severity: normal status: open title: Docs discourage use of binascii.unhexlify etc. 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 May 8 00:51:21 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 May 2015 22:51:21 +0000 Subject: [issue24144] Docs discourage use of binascii.unhexlify etc. In-Reply-To: <1431036635.15.0.698772318331.issue24144@psf.upfronthosting.co.za> Message-ID: <1431039081.3.0.401648322698.issue24144@psf.upfronthosting.co.za> R. David Murray added the comment: No, actually, using codecs would be the most straightforward way to achieve portability. The usual way to get hex in python2 was encode('hex'), which uses the codec. But if you want to use hexlify instead, I don't see any reason not to. There's no reason to change the binascii module description, though, since it is talking about normal code, not 2/3 shared source code (where you do sometimes have to jump through somewhat awkward hoops). (The One Obvious Way starting with 3.5 will be b'abcde'.hex(), but of course that isn't python2 compatible.) ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 01:04:11 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 07 May 2015 23:04:11 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: Message-ID: Nick Coghlan added the comment: This could likely stand to be clarified in the language reference, though (as well as in the 3.5 porting notes) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 01:13:04 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 07 May 2015 23:13:04 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1431034031.21.0.654791455135.issue22906@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Yury's patch mostly looks good to me, except: * the check in contextlib should be against __cause__ rather than __context__, and there should be a new test for this code handling path * there should be a new test for the __future__ flag itself (independently of the contextlib tests) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 02:14:38 2015 From: report at bugs.python.org (Aaron Meurer) Date: Fri, 08 May 2015 00:14:38 +0000 Subject: [issue17697] Incorrect stacktrace from pdb In-Reply-To: <1365692859.49.0.652230897549.issue17697@psf.upfronthosting.co.za> Message-ID: <1431044078.31.0.902550603071.issue17697@psf.upfronthosting.co.za> Changes by Aaron Meurer : ---------- nosy: +Aaron.Meurer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 02:33:19 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 08 May 2015 00:33:19 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431045199.34.0.161056371096.issue22906@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Yury's patch mostly looks good to me, except: Thanks! > * the check in contextlib should be against __cause__ rather than __context__, and there should be a new test for this code handling path Done. I've also added one test for correct handling of StopIteration without PEP 479. > * there should be a new test for the __future__ flag itself (independently of the contextlib tests) Forgot to attach it to the first patch! Nick, please take a look at the new patch (attached). ---------- Added file: http://bugs.python.org/file39317/pep0479.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 02:36:46 2015 From: report at bugs.python.org (Aaron Meurer) Date: Fri, 08 May 2015 00:36:46 +0000 Subject: [issue16482] pdb.set_trace() clobbering traceback on error In-Reply-To: <1353002125.56.0.265106335805.issue16482@psf.upfronthosting.co.za> Message-ID: <1431045406.67.0.052382527674.issue16482@psf.upfronthosting.co.za> Changes by Aaron Meurer : ---------- nosy: +Aaron.Meurer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 03:18:35 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 08 May 2015 01:18:35 +0000 Subject: [issue23796] BufferedReader.peek() crashes if closed In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za> Message-ID: <1431047915.25.0.197447386896.issue23796@psf.upfronthosting.co.za> Berker Peksag added the comment: 23796_fix_with_tests.patch LGTM. I'll apply it this weekend. Thanks for the patch, John. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 04:16:29 2015 From: report at bugs.python.org (Chris Angelico) Date: Fri, 08 May 2015 02:16:29 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431051389.59.0.535030602783.issue22906@psf.upfronthosting.co.za> Chris Angelico added the comment: The comment was general because I honestly had no idea what was needed still. All I knew was that the patch seemed to work for me, all tests passing (including the new one). Thanks for uploading the new patch; it compiles happily, and I'm running tests now, although that probably won't prove anything new. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 05:25:37 2015 From: report at bugs.python.org (Ma Lin) Date: Fri, 08 May 2015 03:25:37 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1431055537.91.0.211887539504.issue24117@psf.upfronthosting.co.za> Ma Lin added the comment: I examined all Chinese codecs, here are the patches, please review them, feel free to ask me your question. Thanks to Hye-Shik, your framework is very easy to understand :) ---------- Added file: http://bugs.python.org/file39318/forpy27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 05:25:58 2015 From: report at bugs.python.org (Ma Lin) Date: Fri, 08 May 2015 03:25:58 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1431055558.47.0.422675695293.issue24117@psf.upfronthosting.co.za> Changes by Ma Lin : Removed file: http://bugs.python.org/file39278/forpy3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 05:26:01 2015 From: report at bugs.python.org (Ma Lin) Date: Fri, 08 May 2015 03:26:01 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1431055561.05.0.259531720198.issue24117@psf.upfronthosting.co.za> Changes by Ma Lin : Removed file: http://bugs.python.org/file39277/forpy27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 05:27:17 2015 From: report at bugs.python.org (Ma Lin) Date: Fri, 08 May 2015 03:27:17 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1431055637.88.0.119640204417.issue24117@psf.upfronthosting.co.za> Changes by Ma Lin : Added file: http://bugs.python.org/file39319/forpy34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 05:27:50 2015 From: report at bugs.python.org (Ma Lin) Date: Fri, 08 May 2015 03:27:50 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1431055670.57.0.312923226025.issue24117@psf.upfronthosting.co.za> Changes by Ma Lin : Added file: http://bugs.python.org/file39320/forpy35.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 05:59:52 2015 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 08 May 2015 03:59:52 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1431057592.63.0.508715609993.issue24117@psf.upfronthosting.co.za> Ezio Melotti added the comment: Do you have authoritative links that describe these standards? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 06:45:51 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 08 May 2015 04:45:51 +0000 Subject: [issue23888] Fixing fractional expiry time bug in cookiejar In-Reply-To: <1428502659.33.0.324281998086.issue23888@psf.upfronthosting.co.za> Message-ID: <1431060351.82.0.874640918681.issue23888@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 07:06:30 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 08 May 2015 05:06:30 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431061590.2.0.435430007409.issue22906@psf.upfronthosting.co.za> Berker Peksag added the comment: A minor comment about the __future__ changes: 3.5.0a1 should probably be 3.5.0b1. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 07:38:46 2015 From: report at bugs.python.org (Ma Lin) Date: Fri, 08 May 2015 05:38:46 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1431063526.15.0.933418212089.issue24117@psf.upfronthosting.co.za> Ma Lin added the comment: Good question. GB2312: I tested those programming languages one by one. GBK/CP936/GB18030-2000: I gathered data via Internet as much as I can, then compare them to Python3's codecs. I check key points with authoritative source, and verify every appeared conflicts. The data come from ICU, Unicode.org, IBM, Chinese researchers, and data found by Google. I had spent about half-month to do this, not just started from several days ago. I hope those descriptions will help late comers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 08:30:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 May 2015 06:30:26 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <20150508063023.25443.32403@psf.io> Roundup Robot added the comment: New changeset 36d5e04b6cfa by Larry Hastings in branch 'default': Issue #24000: Improved Argument Clinic's mapping of converters to legacy https://hg.python.org/cpython/rev/36d5e04b6cfa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 08:31:50 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 May 2015 06:31:50 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1431066710.89.0.188639542057.issue24000@psf.upfronthosting.co.za> Larry Hastings added the comment: I think this is a definite improvement, so I've checked it in so I can move on. If you guys still want to talk about it, we can still change it before we hit beta. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 10:14:42 2015 From: report at bugs.python.org (paul) Date: Fri, 08 May 2015 08:14:42 +0000 Subject: [issue24098] Multiple use after frees in obj2ast_* methods In-Reply-To: <1430489429.65.0.587999729774.issue24098@psf.upfronthosting.co.za> Message-ID: <1431072882.24.0.657669695146.issue24098@psf.upfronthosting.co.za> paul added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 10:55:59 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 08 May 2015 08:55:59 +0000 Subject: [issue1322] Deprecate platform.dist() and platform.linux_distribution() functions In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> Message-ID: <1431075359.25.0.618039945078.issue1322@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Thanks, Berker, your patch looks fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 11:24:27 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 08 May 2015 09:24:27 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: Message-ID: Nick Coghlan added the comment: A couple of minor comments: * "self.fail" with an appropriate error message is a clearer way to indicate an incorrect logic path has been hit in a test case * the details of the exception chaining don't quite look right, as I believe "raise X from Y" sets both the cause and the context, with the suppress_context attribute set to turn off the display of the latter. I suggest checking that in Python code to confirm ny recollection, and then adjusting the test and implementation if necessary to match the Python level equivalent ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 12:33:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 08 May 2015 10:33:20 +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: <1431081200.81.0.848929109208.issue7267@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be just emit a warning in -3 mode? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 13:16:35 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 08 May 2015 11:16:35 +0000 Subject: [issue23042] ctypes module doesn't build on FreeBSD, RHEL (x86) - Undefined symbol "ffi_call_win32" In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za> Message-ID: <1431083795.62.0.423009685032.issue23042@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Here's a patch which I have tested on Linux, FreeBSD and Mac OS X. It solves the problem with compiling in Windows calls on non-Windows platforms and resynchronizes the ffi_raw_call() function with the ffi_call() implementation. Both functions had the same issue and the only difference between the two is the use of ffi_prep_args_raw instead of ffi_prep_args. As with davin's patch, this would need to be tested on Windows. ---------- Added file: http://bugs.python.org/file39321/ffi.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 13:28:05 2015 From: report at bugs.python.org (Omer Katz) Date: Fri, 08 May 2015 11:28:05 +0000 Subject: [issue16392] import crashes on circular imports in ext modules In-Reply-To: <1351946554.54.0.101006341814.issue16392@psf.upfronthosting.co.za> Message-ID: <1431084485.6.0.611318942802.issue16392@psf.upfronthosting.co.za> Omer Katz added the comment: Is this issue resolved in any way? Has there been a decision made on how to resolve it? What's the status here? ---------- nosy: +Omer.Katz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 14:33:12 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 May 2015 12:33:12 +0000 Subject: [issue24145] Support |= for parameters in converters Message-ID: <1431088392.11.0.874490778246.issue24145@psf.upfronthosting.co.za> New submission from Larry Hastings: Some "format units" provided by PyArg_ParseTuple() are exactly the same as others, except that they also accept the value None. For example, "s" and "z" are exactly the same, except "z" accepts None and "s" does not. The same goes for "s*" and "z*", or "s#" and "z#". To tell an Argument Clinic converter which types of objects it should accept, one would pass in the "accept" named parameter. We now use this facility for the "also accept None" format units. "z" is the same as "s", except that for "z" you add NoneType to the list of types passed in for "accept". Like so: str1: str() # format unit 's' str2: str(accept={str, NoneType}) # format unit 'z' The trick here is, the default value for the 'accept' parameter for the str() converter is {str}. But you have to know that in order to add NoneType to it. It'd be nice if there were some way of saying "take the existing default value for parameter X, and add value Y to it". Then for the "accept" parameter you could just add NoneType to it. You might say, "yeah, but Python doesn't have anything like that". To which I say, Argument Clinic isn't Python. It leverages Python syntax (using ast.parse) but we need not be bound by what Python does. We could maybe add a little syntax or play with the semantics to add this functionality. We discussed this on c.l.p-d a little, and some folks took the opportunity to play a little syntax golf with the idea. (Everybody who participated in the thread writ large got Cc'd on this bug, congratulations, you're welcome!) Ultimately there was only one syntax I liked, which (no surprise) was one I suggested: str2: str(accept|={NoneType}) accept's default value is a set, and sets use | as the union operator. And Python actually has a |= statement, although it doesn't work in function calls like that. But that means readers unfamiliar with Argument Clinic should be able to quickly intuit what the syntax means. It also meant I could use the tokenize module to do a proper job of the implementation. So I ask you: do we want this? Advantages and disadvantages as I see them: + : Don't Repeat Yourself. + : You don't have to look up the default types to add NoneType to it/them. - : Startling syntax, makes Clinic a little weirder Take a look at the diffs and decide whether the new syntax is an improvement. (You can look at the implementation too, of course, if you're curious. But IMO the implementation is fine, and ready to go in if we want it.) ---------- assignee: larry components: Argument Clinic files: larry.clinic.or.equals.for.parameters.1.txt messages: 242756 nosy: barry, gregory.p.smith, larry, ncoghlan, serhiy.storchaka, taleinat, zach.ware priority: normal severity: normal stage: patch review status: open title: Support |= for parameters in converters type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39322/larry.clinic.or.equals.for.parameters.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 14:35:17 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 May 2015 12:35:17 +0000 Subject: [issue23920] Should Clinic have "nullable" or types=NoneType? In-Reply-To: <1428812661.52.0.406302391077.issue23920@psf.upfronthosting.co.za> Message-ID: <1431088517.82.0.495015314075.issue23920@psf.upfronthosting.co.za> Larry Hastings added the comment: The final version of this has been implemented as part of 41fb7fd04b5d for issue #24001. However, I'll mention here for posterity's sakes: there's an additional discussion on #24145. (Everyone on the nosy list has already been invited to the party!) ---------- resolution: -> fixed stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 15:00:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 08 May 2015 13:00:21 +0000 Subject: [issue24145] Support |= for parameters in converters In-Reply-To: <1431088392.11.0.874490778246.issue24145@psf.upfronthosting.co.za> Message-ID: <1431090021.25.0.548882387342.issue24145@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For now str(accept={str, NoneType}) is used only 14 times in 6 files in 5 modules. The "z" format unit is used also in still not converted modules _codecs (a lot of sites), _locale, mmap, _multiprocessing, and _socket. Current syntax doesn't look so ugly for me. I would wait until we converted more modules and implemented more converters that don't match existing format units. Alternative syntax can be "str | NoneType" (without the accept parameter at all). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 15:00:41 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 08 May 2015 13:00:41 +0000 Subject: [issue24145] Support |= for parameters in converters In-Reply-To: <1431088392.11.0.874490778246.issue24145@psf.upfronthosting.co.za> Message-ID: <1431090041.48.0.549666594591.issue24145@psf.upfronthosting.co.za> Raymond Hettinger added the comment: To my eyes, the current set notation form more clearly expresses its intentions than the |= notation. Readability counts. I agree the |= is a startling syntax that looks weird enough to cause a mental hiccup when reading it. So, put me down for a -1. The mild benefit isn't worth it. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 15:22:43 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 May 2015 13:22:43 +0000 Subject: [issue24146] ast.literal_eval doesn't support the Python ternary operator Message-ID: <1431091363.36.0.664867447075.issue24146@psf.upfronthosting.co.za> New submission from Larry Hastings: ast.literal_eval() supports all Python operators, yes? No. It doesn't support "if/else", Python's ternary operator. Is there a reason it does not? I think it probably should. ---------- messages: 242760 nosy: benjamin.peterson, georg.brandl, larry priority: normal severity: normal stage: needs patch status: open title: ast.literal_eval doesn't support the Python ternary operator type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 15:38:19 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 08 May 2015 13:38:19 +0000 Subject: [issue16392] import crashes on circular imports in ext modules In-Reply-To: <1351946554.54.0.101006341814.issue16392@psf.upfronthosting.co.za> Message-ID: <1431092299.14.0.640092856372.issue16392@psf.upfronthosting.co.za> Brett Cannon added the comment: https://www.python.org/dev/peps/pep-0489/ is trying to come up with a redesign of extension module loading and no one has submitted a patch for the documentation (although Stefan has inlined proposed wording in a comment). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 15:59:34 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 May 2015 13:59:34 +0000 Subject: [issue21520] Erroneous zipfile test failure if the string 'bad' appears in pwd In-Reply-To: <1400395560.62.0.305002510991.issue21520@psf.upfronthosting.co.za> Message-ID: <20150508135931.8141.56016@psf.io> Roundup Robot added the comment: New changeset bff966aed6a3 by Larry Hastings in branch '3.4': Issue #21520: test_zipfile no longer fails if the word 'bad' appears https://hg.python.org/cpython/rev/bff966aed6a3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 16:00:43 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 May 2015 14:00:43 +0000 Subject: [issue21520] Erroneous zipfile test failure if the string 'bad' appears in pwd In-Reply-To: <1400395560.62.0.305002510991.issue21520@psf.upfronthosting.co.za> Message-ID: <1431093643.33.0.856364379874.issue21520@psf.upfronthosting.co.za> Larry Hastings added the comment: Checked in, with the filter function on a separate line, to 3.4. Also merged into 3.5. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 16:03:49 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 08 May 2015 14:03:49 +0000 Subject: [issue16392] import crashes on circular imports in ext modules In-Reply-To: <1351946554.54.0.101006341814.issue16392@psf.upfronthosting.co.za> Message-ID: <1431093829.53.0.159656063992.issue16392@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, the resolution of this issue will be to add documentation. Someone should turn Stefan's comment into a patch. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, r.david.murray stage: -> needs patch versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 16:16:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 08 May 2015 14:16:11 +0000 Subject: [issue24146] ast.literal_eval doesn't support the Python ternary operator In-Reply-To: <1431091363.36.0.664867447075.issue24146@psf.upfronthosting.co.za> Message-ID: <1431094571.22.0.305385123522.issue24146@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No it doesn't support all Python operators. >>> ast.literal_eval('2*3') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.4/ast.py", line 84, in literal_eval return _convert(node_or_string) File "/usr/lib/python3.4/ast.py", line 83, in _convert raise ValueError('malformed node or string: ' + repr(node)) ValueError: malformed node or string: <_ast.BinOp object at 0xb6f8446c> And shouldn't. It supports "+" and "-" only because they are needed for support of complex "literals". It is unintentional side effect, that ast.literal_eval() supports not only "2+3j", but "2+3" too. ---------- nosy: +mark.dickinson, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 16:25:22 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 May 2015 14:25:22 +0000 Subject: [issue20274] sqlite module has bad argument parsing code, including undefined behavior in C In-Reply-To: <1389817483.8.0.407525727046.issue20274@psf.upfronthosting.co.za> Message-ID: <1431095122.22.0.284108947425.issue20274@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm gonna fix this now. (I'm cleaning up some old issues I filed on the bug tracker this morning.) For 3.4, I'm just removing the PyObject *kwargs for those three functions that don't actually accept keyword arguments (METH_VARARGS) and aren't passed that parameter. That's a bug plain and simple, it's relying on undefined behavior, and it's better that we fix it. For 3.5. I'm adding a call to _PyArg_NoKeywords() to pysqlite_connection_call. Previously it simply ignored any/all keyword arguments; now it will complain if it is passed any. We don't need a deprecation cycle for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 16:25:28 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 08 May 2015 14:25:28 +0000 Subject: [issue24146] ast.literal_eval doesn't support the Python ternary operator In-Reply-To: <1431091363.36.0.664867447075.issue24146@psf.upfronthosting.co.za> Message-ID: <1431095128.78.0.576112553193.issue24146@psf.upfronthosting.co.za> R. David Murray added the comment: Right, this isn't a bug, it is that literal_eval is intended only to support *literals*, not expressions. See also issue 22525. ---------- nosy: +r.david.murray resolution: -> not a bug stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 16:45:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 May 2015 14:45:28 +0000 Subject: [issue20274] sqlite module has bad argument parsing code, including undefined behavior in C In-Reply-To: <1389817483.8.0.407525727046.issue20274@psf.upfronthosting.co.za> Message-ID: <20150508144524.84482.95857@psf.io> Roundup Robot added the comment: New changeset 4c860369b6c2 by Larry Hastings in branch '3.4': Issue #20274: Remove ignored and erroneous "kwargs" parameters from three https://hg.python.org/cpython/rev/4c860369b6c2 New changeset 3e9f4f3c7fa7 by Larry Hastings in branch 'default': Issue #20274: When calling a _sqlite.Connection, it now complains if passed https://hg.python.org/cpython/rev/3e9f4f3c7fa7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 16:47:17 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 May 2015 14:47:17 +0000 Subject: [issue20274] sqlite module has bad argument parsing code, including undefined behavior in C In-Reply-To: <1389817483.8.0.407525727046.issue20274@psf.upfronthosting.co.za> Message-ID: <1431096437.81.0.889049554516.issue20274@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- assignee: ghaering -> larry resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 16:47:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 08 May 2015 14:47:48 +0000 Subject: [issue20274] sqlite module has bad argument parsing code, including undefined behavior in C In-Reply-To: <1389817483.8.0.407525727046.issue20274@psf.upfronthosting.co.za> Message-ID: <1431096468.34.0.742843120799.issue20274@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is 2.7 affected? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 16:49:27 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 May 2015 14:49:27 +0000 Subject: [issue20274] sqlite module has bad argument parsing code, including undefined behavior in C In-Reply-To: <1389817483.8.0.407525727046.issue20274@psf.upfronthosting.co.za> Message-ID: <1431096567.35.0.14888732781.issue20274@psf.upfronthosting.co.za> Larry Hastings added the comment: Yes, all those bugs exist in 2.7. However, Benjamin hasn't responded to this bug, so I assume he doesn't care and I should leave 2.7 alone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 16:49:32 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 May 2015 14:49:32 +0000 Subject: [issue20274] sqlite module has bad argument parsing code, including undefined behavior in C In-Reply-To: <1389817483.8.0.407525727046.issue20274@psf.upfronthosting.co.za> Message-ID: <1431096572.54.0.932135102838.issue20274@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 17:01:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 08 May 2015 15:01:47 +0000 Subject: [issue20274] sqlite module has bad argument parsing code, including undefined behavior in C In-Reply-To: <1389817483.8.0.407525727046.issue20274@psf.upfronthosting.co.za> Message-ID: <1431097307.51.0.520035726528.issue20274@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think the bug should be fixed in 2.7 (but not in 3.3 unless we get a crasher). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 17:11:16 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 08 May 2015 15:11:16 +0000 Subject: [issue20274] sqlite module has bad argument parsing code, including undefined behavior in C In-Reply-To: <1389817483.8.0.407525727046.issue20274@psf.upfronthosting.co.za> Message-ID: <1431097876.62.0.805548868662.issue20274@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I don't mind if you fix it in 2.7, too. (Sorry, I get a lot of bug related emails...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 17:33:35 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 08 May 2015 15:33:35 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431099215.29.0.488348354661.issue22906@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, Berker, Please see the updated patch. ---------- Added file: http://bugs.python.org/file39323/pep0479.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 18:08:02 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 May 2015 16:08:02 +0000 Subject: [issue20274] sqlite module has bad argument parsing code, including undefined behavior in C In-Reply-To: <1389817483.8.0.407525727046.issue20274@psf.upfronthosting.co.za> Message-ID: <1431101282.98.0.0859702868668.issue20274@psf.upfronthosting.co.za> Larry Hastings added the comment: Benjamin: I assume you want the extraneous (and undefined behavior) kwargs parameters removed. Do you also want pysqlite_connection_call() to start calling _PyArg_NoKeywords()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 18:40:01 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 08 May 2015 16:40:01 +0000 Subject: [issue20274] sqlite module has bad argument parsing code, including undefined behavior in C In-Reply-To: <1431101282.98.0.0859702868668.issue20274@psf.upfronthosting.co.za> Message-ID: <1431103198.1273481.264537209.74F3874D@webmail.messagingengine.com> Benjamin Peterson added the comment: On Fri, May 8, 2015, at 12:08, Larry Hastings wrote: > > Larry Hastings added the comment: > > Benjamin: I assume you want the extraneous (and undefined behavior) > kwargs parameters removed. > > Do you also want pysqlite_connection_call() to start calling > _PyArg_NoKeywords()? Yes, please. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 18:56:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 May 2015 16:56:50 +0000 Subject: [issue20274] sqlite module has bad argument parsing code, including undefined behavior in C In-Reply-To: <1389817483.8.0.407525727046.issue20274@psf.upfronthosting.co.za> Message-ID: <20150508165647.7812.9825@psf.io> Roundup Robot added the comment: New changeset c91d135b0776 by Larry Hastings in branch '2.7': Issue #20274: When calling a _sqlite.Connection, it now complains if passed https://hg.python.org/cpython/rev/c91d135b0776 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 18:56:56 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 May 2015 16:56:56 +0000 Subject: [issue20274] sqlite module has bad argument parsing code, including undefined behavior in C In-Reply-To: <1389817483.8.0.407525727046.issue20274@psf.upfronthosting.co.za> Message-ID: <1431104216.53.0.084529516006.issue20274@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 19:27:42 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 08 May 2015 17:27:42 +0000 Subject: [issue23888] Fixing fractional expiry time bug in cookiejar In-Reply-To: <1428502659.33.0.324281998086.issue23888@psf.upfronthosting.co.za> Message-ID: <1431106062.15.0.584324398788.issue23888@psf.upfronthosting.co.za> Demian Brecht added the comment: LGTM, thanks for the patch! ---------- nosy: +r.david.murray stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 22:49:16 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 08 May 2015 20:49:16 +0000 Subject: [issue24078] inspect.getsourcelines ignores context and returns wrong line # In-Reply-To: <1430348672.59.0.934013457033.issue24078@psf.upfronthosting.co.za> Message-ID: <1431118156.64.0.895585920269.issue24078@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 22:51:20 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 08 May 2015 20:51:20 +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: <1431118280.64.0.447830643526.issue24129@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 23:01:58 2015 From: report at bugs.python.org (Maciej Szulik) Date: Fri, 08 May 2015 21:01:58 +0000 Subject: [issue21800] Implement RFC 6855 (IMAP Support for UTF-8) in imaplib. In-Reply-To: <1404175815.98.0.684783714649.issue21800@psf.upfronthosting.co.za> Message-ID: <1431118918.84.0.413196191225.issue21800@psf.upfronthosting.co.za> Maciej Szulik added the comment: David, I've changed according to your suggestion, appreciate review. ---------- Added file: http://bugs.python.org/file39324/issue21800.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 23:15:24 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 08 May 2015 21:15:24 +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: <1431119724.22.0.602300687334.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: Another iteration: - support of new syntax in lib2to3 - collections.abc.Awaitable ---------- Added file: http://bugs.python.org/file39325/await_04.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 23:31:18 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 08 May 2015 21:31:18 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1431120678.98.0.919232504339.issue23857@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Changing the title to reflect that the solution to how to configure Python is still up in the air. I also started a thread on python-dev to get some more feedback. ---------- title: Make default HTTPS certificate verification setting configurable via global ini file -> Make default HTTPS certificate verification setting configurable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 8 23:34:17 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 08 May 2015 21:34:17 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1431120857.83.0.124367439091.issue23857@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 00:14:38 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 08 May 2015 22:14:38 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1431123278.42.0.615455343741.issue23857@psf.upfronthosting.co.za> Christian Heimes added the comment: Please let me join the party. :) Like Antoine and Donald I'm against an option to disable certificate validation. I truly believe it's the wrong approach for the problem. Users don't *want* to disable security checks either. They disable the check because a SSL verification error is disruptive and they want to get on with their lives. Because with Python they have no other easy option they take the quick and easy path. *Yoda's voice* If you end SSL verification now - if you choose the quick and easy path as others did - you will become an agent of evil. I like to suggest a better way. Let's handle cert checks like Firefox or OpenSSH. Both give you the option to trust an unknown certificate for a specific host name and remember this trust, too. Let's add a feature to do the same with Python. Yes, it would require more work, additional features and careful engineering. But I strongly believe it's the better approach. Rough design idea: $ python ssl trustcert https://192.168.42.1 This command retrieves the cert from 192.168.42.1:443 and stores the mapping of 192.168.42.1 to SPKI sha512 hash in a file/directory relative sys.prefix. When a ssl._create_stdlib_context() context gets a verification error, then it checks the file for the hostname and SPKI hash of the leaf certificate. This features requires access to SPKI as DER and a proper verify_cb callback function. Disclaimer: I have code for the first feature and a plan for the second. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 00:20:19 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 08 May 2015 22:20:19 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1431123619.83.0.326467902643.issue23857@psf.upfronthosting.co.za> Christian Heimes added the comment: PS: It's also super easy to trust self-signed certificates. All you have to do is to grab the cert and set SSL_CERT_FILE env var: $ openssl s_client -connect host:443 | openssl x509 > /path/to/selfsigned.pem $ SSL_CERT_FILE=/path/to/selfsigned.pem python script.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 00:35:51 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 08 May 2015 22:35:51 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable In-Reply-To: <1431123619.83.0.326467902643.issue23857@psf.upfronthosting.co.za> Message-ID: <554D3A34.8090206@egenix.com> Marc-Andre Lemburg added the comment: Those are nice ideas, but you are forgetting two important points: * browsers are typically only being used by single users, applications by potentially hundreds or thousands of users * how should the poor sys admin who's task it is to keep Python up to date know which SSL certs to add to the trust store ? E.g. assume your application fetches user comments for sentiment analysis from a few thousand sites, or gathers status updates from a few hundred routers and switches you have installed at your site, or even more difficult: an application which tries to map your IT world of a few thousand network nodes, scanning port 443 for useful information. For eGenix PyRun we have now implemented an env var PYRUN_HTTPSVERIFY which can be set to 0 to disable the checks and revert back to Python 2.7.8 standards, if necessary, on a per process basis. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 01:05:42 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 08 May 2015 23:05:42 +0000 Subject: [issue24145] Support |= for parameters in converters In-Reply-To: <1431090041.48.0.549666594591.issue24145@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Aye, it occurs to me now that introducing the implicit form trades a "write time" lookup (where you have to override the converter defaults explicitly), for a "read time" lookup (where you need to mentally add the defaults to understand the modified accept clause) As a result, I think "explicit is better than implicit" wins, at least for now. If we decide after we have more experience that the repetition of the defaults when overriding them really is a problem, then it's possible to revisit that decision in the 3.6 time frame. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 01:13:26 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 08 May 2015 23:13:26 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1431099215.29.0.488348354661.issue22906@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Latest patch LGTM, although I believe the new chaining behaviour checks would be clearer with the 3 try/except blocks merged into a single block where all 3 behaviours are checked in the same except clause, and the else clause complains that StopIteration was suppressed. (I don't see a need to request a new review for that particular change, though) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 01:40:19 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 08 May 2015 23:40:19 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable In-Reply-To: <554D3A34.8090206@egenix.com> Message-ID: Nick Coghlan added the comment: Right, the key here is to think like a system administrator, not a developer. Most of those folks are downstream of redistributors (whether commercial ones or community Linux distributions) and relying on one of two things: * tools using the system cert store for certificate validation (so they can trust an internal CA automatically) * tools not verifying certificates properly The *right* answer on Linux is option one (which the system Python will be configured to use by default), but even with tools like DogTag available as open source, running your own internal CA properly is currently still a pain, especially once you start accounting for all the hardware devices out there with tragically bad certificate management. You can't just wave a magic wand and suddenly have all your physical gear catch up to the modern state of the art in SSL/TLS management as learned on the public internet - it's a staged upgrade project where the risks of insider threats and other perimeter compromises get traded off against the upgrade costs and infrastructure stability risks. This *is* work that needs to be done given the world we live in, but we also need to trust CIOs to appropriately manage the upgrade plans for their own intranets. It's not a coincidence that initiatives like Let's Encrypt are due to launch this year, nor that Red Hat's started hiring people like Christian to help integrate SSL certificate management directly into Linux identity & authentication management - this stuff currently gets done badly because it's *too hard* to do it right. But in the meantime, admins upgrading Python *2.7* need a way to say "let us decide what our highest priority infrastructure risks are, thank you very much". They don't need that for Python 3, as it doesn't have the same kind of large install base in environments where infrastructure modernisation represents a major ongoing investment. That means "your SSL/TLS certificate management must be in good order" can reasonably be a gating criterion for Python 3, but we need a better solution for redistributors and administrators when it comes to Python 2.7 upgrades. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 03:05:19 2015 From: report at bugs.python.org (Mik) Date: Sat, 09 May 2015 01:05:19 +0000 Subject: [issue24147] doublequote are not well recognized with Dialect class Message-ID: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za> New submission from Mik: Python 2.7.3 (default, Mar 13 2014, 11:03:55) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> class Mon(csv.Dialect): ... delimiter = ',' ... quotechar = '"' ... quoting = 0 ... lineterminator = '\n' ... >>> f = open('sans_headers.csv','r') >>> reader = csv.DictReader(f, fieldnames=('code', 'nom', 'texte'), dialect=Mon) >>> for l in reader: ... print l ... {'nom': 'line_1', 'code': '3', 'texte': 'one line\ntwo lines'} {'nom': 'line_2', 'code': '5', 'texte': 'one line\nand a quote "iop"";newline'} {'nom': None, 'code': 'I\'m not a cat"', 'texte': None} >>> f.seek(0) >>> reader = csv.DictReader(f, fieldnames=('code', 'nom', 'texte'), delimiter=',', quotechar='"', quoting=0, lineterminator='\n') >>> for l in reader: ... print l ... {'nom': 'line_1', 'code': '3', 'texte': 'one line\ntwo lines'} {'nom': 'line_2', 'code': '5', 'texte': 'one line\nand a quote "iop";newline\nI\'m not a cat'} >>> If I use a subclass of csv.Dialect with the same attribute that I should use with keywords in calling csv.DictReader I don't get the same behaviour. ---------- components: Library (Lib) messages: 242787 nosy: MiK priority: normal severity: normal status: open title: doublequote are not well recognized with Dialect class type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 03:22:47 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 09 May 2015 01:22:47 +0000 Subject: [issue22255] Multiprocessing freeze_support raises RuntimeError In-Reply-To: <1408754338.93.0.431000117242.issue22255@psf.upfronthosting.co.za> Message-ID: <1431134567.66.0.304136783334.issue22255@psf.upfronthosting.co.za> Davin Potts added the comment: The issue may already be addressed for the OP and without further information we don't know what or if anything needs pursuing. If new information surfaces, a new issue should be opened. ---------- resolution: -> out of date status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 03:27:55 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 09 May 2015 01:27:55 +0000 Subject: [issue21162] code in multiprocessing.pool freeze if inside some code from scikit-learn (and probably liblinear) executed on ubuntu 12.04 64 Bit In-Reply-To: <1396716060.12.0.828109902525.issue21162@psf.upfronthosting.co.za> Message-ID: <1431134875.18.0.213451186227.issue21162@psf.upfronthosting.co.za> Davin Potts added the comment: It is no longer possible to reproduce the described issue. Changes to the relevant libraries since this issue was originally opened appear to have addressed the cause. Going ahead with closing this issue as there have been no further reports from the OP or others suggesting otherwise. ---------- resolution: -> works for me status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 03:31:03 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 09 May 2015 01:31:03 +0000 Subject: [issue23042] ctypes module doesn't build on FreeBSD, RHEL (x86) - Undefined symbol "ffi_call_win32" In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za> Message-ID: <1431135063.62.0.759012219531.issue23042@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Let's see what the buildbots think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 03:31:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 May 2015 01:31:44 +0000 Subject: [issue23042] ctypes module doesn't build on FreeBSD, RHEL (x86) - Undefined symbol "ffi_call_win32" In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za> Message-ID: <20150509013141.8940.59020@psf.io> Roundup Robot added the comment: New changeset 96a7b401d5e4 by Benjamin Peterson in branch '2.7': fix libffi compilation on FreeBSD (#23042) https://hg.python.org/cpython/rev/96a7b401d5e4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 03:32:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 May 2015 01:32:50 +0000 Subject: [issue23042] ctypes module doesn't build on FreeBSD, RHEL (x86) - Undefined symbol "ffi_call_win32" In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za> Message-ID: <20150509013248.11950.96643@psf.io> Roundup Robot added the comment: New changeset a04b3de18c4c by Benjamin Peterson in branch '3.4': fix libffi compilation on FreeBSD (#23042) https://hg.python.org/cpython/rev/a04b3de18c4c New changeset 987b30a88653 by Benjamin Peterson in branch 'default': merge 3.4 (#23042) https://hg.python.org/cpython/rev/987b30a88653 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 04:20:52 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 09 May 2015 02:20:52 +0000 Subject: [issue13044] pdb throws AttributeError at end of debugging session In-Reply-To: <1316968582.76.0.94343164649.issue13044@psf.upfronthosting.co.za> Message-ID: <1431138052.54.0.00247141346815.issue13044@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 04:24:14 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 09 May 2015 02:24:14 +0000 Subject: [issue23042] ctypes module doesn't build on FreeBSD, RHEL (x86) - Undefined symbol "ffi_call_win32" In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za> Message-ID: <1431138254.66.0.856371376814.issue23042@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 05:29:49 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 09 May 2015 03:29:49 +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: <1431142189.63.0.244499861414.issue24017@psf.upfronthosting.co.za> Stefan Behnel added the comment: We also need a Coroutine ABC. Both the "GeneratorType" and "CO_COROUTINE" checks are too restrictive. Also see issue 24018, which this one should in fact depend on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 05:34:18 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 09 May 2015 03:34:18 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1431142458.37.0.228406120982.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: This is blocking issue 24017 (async/await syntax). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 05:46:43 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 09 May 2015 03:46:43 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431143203.75.0.400796974822.issue22906@psf.upfronthosting.co.za> Berker Peksag added the comment: In Lib/__future__.py: +generator_stop = _Feature((3, 5, 0, "alpha", 1), "alpha" needs to be changed to "beta". ---------- stage: test needed -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 05:47:38 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 09 May 2015 03:47:38 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1431142458.37.0.228406120982.issue24018@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Ask Yury if he'll commit it for you. It's ready. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 06:52:56 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 09 May 2015 04:52:56 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1431147176.51.0.288613104354.issue24018@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: lukasz.langa -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 07:07:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 May 2015 05:07:32 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <20150509050729.8159.53699@psf.io> Roundup Robot added the comment: New changeset ba5d7041e2f5 by Raymond Hettinger in branch 'default': Issue #24018: Add a collections.Generator abstract base class. https://hg.python.org/cpython/rev/ba5d7041e2f5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 07:08:15 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 09 May 2015 05:08:15 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1431148095.9.0.16415228741.issue24018@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 07:28:47 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 09 May 2015 05:28:47 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1431149327.26.0.784493155651.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: Thanks! Minor grouch: it should say "collections.*abc*.Generator" in the NEWS entry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 09:53:04 2015 From: report at bugs.python.org (Stephen J. Turnbull) Date: Sat, 09 May 2015 07:53:04 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za> Message-ID: <1431157984.91.0.636458618195.issue18814@psf.upfronthosting.co.za> Stephen J. Turnbull added the comment: Please do not add the "rehandle" functions to codecs. They do not change the (duck-typed) representation of data while maintaining the semantics, they change the semantics of data while retaining the representation. I suggest a "validation" submodule of the unicodedata package, or perhaps a new "unicodeutils" package, for these functions, as well as those that just detect the surrogates, etc. Because they change the semantics of data they should be documented as potentially dangerous because they can't be inverted back to bytes without knowledge of the history of transformations they perform (and not even then in the case of the "replace" error handler). This matters in applications where the input bytes may have been digitally signed, for example. ---------- nosy: +sjt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 10:48:25 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 09 May 2015 08:48:25 +0000 Subject: [issue24140] In pdb using "until X" doesn't seem to have effect in commands In-Reply-To: <1430998265.01.0.0346920117937.issue24140@psf.upfronthosting.co.za> Message-ID: <1431161305.48.0.724123164908.issue24140@psf.upfronthosting.co.za> Xavier de Gaye added the comment: test.py is missing. ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 11:01:50 2015 From: report at bugs.python.org (Tal Einat) Date: Sat, 09 May 2015 09:01:50 +0000 Subject: [issue24145] Support |= for parameters in converters In-Reply-To: <1431088392.11.0.874490778246.issue24145@psf.upfronthosting.co.za> Message-ID: <1431162110.7.0.575546717646.issue24145@psf.upfronthosting.co.za> Tal Einat added the comment: Well, the main reasons I'm +1 on the "|=" feature (regardless of specific syntax) are: 1) the intent is much clearer: e.g. also accept None, nothing else special going on 2) much easier maintenance if the default set of accepted types ever changes Also, this is one of the cases where I think that DRY defeats "explicit is better than implicit". As another example, in some hypothetical code, if there was a module constant "DEFAULT_FLAGS = A | B | C", I would prefer later to use "flags = DEFAULT_FLAGS | D" rather than "flags = A | B | C | D". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 11:27:51 2015 From: report at bugs.python.org (Ivan K) Date: Sat, 09 May 2015 09:27:51 +0000 Subject: [issue21162] code in multiprocessing.pool freeze if inside some code from scikit-learn (and probably liblinear) executed on ubuntu 12.04 64 Bit In-Reply-To: <1396716060.12.0.828109902525.issue21162@psf.upfronthosting.co.za> Message-ID: <1431163671.12.0.275424260616.issue21162@psf.upfronthosting.co.za> Ivan K added the comment: Sorry, forget to answer. I think I know the reason. Issue I think placed inside ATLAS library. Issue not reproducable on Mac OS X because it's have a bit different thread model. The only single platform is Linux (not tested on Windows btw). So main guess right now that this code fail if scikit-learn are compiled against a singlethread ATLAS. Then paralleling code brokes. However there is very few information regarding how to build it with Multithreaded ATLAS so I'm still not 100% confident. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 11:51:46 2015 From: report at bugs.python.org (Maciej Szulik) Date: Sat, 09 May 2015 09:51:46 +0000 Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime Message-ID: <1431165106.13.0.400585423822.issue1100942@psf.upfronthosting.co.za> Maciej Szulik added the comment: I've just double checked, this patch applies cleanly to latest tip. I wouldn't mind having this reviewed and merged. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 12:00:09 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 09 May 2015 10:00:09 +0000 Subject: [issue18551] child_exec() doesn't check return value of fcntl() In-Reply-To: <1374695138.31.0.553729401393.issue18551@psf.upfronthosting.co.za> Message-ID: <1431165609.05.0.157318714958.issue18551@psf.upfronthosting.co.za> Mark Lawrence added the comment: Calls to fcntl have been replaced by calls to _Py_set_inheritable so I'd assume that this can be closed as "out of date". ---------- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 12:55:04 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 09 May 2015 10:55:04 +0000 Subject: [issue18751] A manager's server never joins its threads In-Reply-To: <1376590396.18.0.712968689777.issue18751@psf.upfronthosting.co.za> Message-ID: <1431168904.76.0.774136708953.issue18751@psf.upfronthosting.co.za> Mark Lawrence added the comment: I've checked the code and this doesn't appear to have been implemented. I looked into providing a patch myself, but all the returns from calls to util.Finalize that I could find were assigned to different attribute names, so I'm not confident enough to proceed, sorry :( ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 13:02:33 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 09 May 2015 11:02:33 +0000 Subject: [issue18789] XML Vunerability Table Unclear In-Reply-To: <1377008574.91.0.12100936862.issue18789@psf.upfronthosting.co.za> Message-ID: <1431169353.99.0.998570717592.issue18789@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Joe The latest documentation has an additional sentence above the table "The following table gives an overview of the known attacks and whether the various modules are vulnerable to them." and the table has been changed to say Yes or No. Is this okay with you? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 14:00:09 2015 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 09 May 2015 12:00:09 +0000 Subject: [issue24147] doublequote are not well recognized with Dialect class In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za> Message-ID: <1431172809.62.0.742757955011.issue24147@psf.upfronthosting.co.za> Skip Montanaro added the comment: Can you attach your cab file so we don't need to reconstruct it (and possibly make a mistake) by reading your program's output? ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 14:19:10 2015 From: report at bugs.python.org (eryksun) Date: Sat, 09 May 2015 12:19:10 +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: <1431173950.11.0.358745821907.issue24127@psf.upfronthosting.co.za> eryksun added the comment: > 1. Bug in Windows 10, which should be reported to Microsoft. It appears to be a bug in the kernel. It's isn't updating the value of of the output parameter *lpReturnLength. C:\>ver Microsoft Windows [Version 10.0.10074] C:\>cdb -xi ld py Microsoft (R) Windows Debugger Version 10.0.10075.9 X86 Copyright (c) Microsoft Corporation. All rights reserved. CommandLine: py ************* Symbol Path validation summary ************** Response Time (ms) Location Deferred symsrv*symsrv.dll*C:\Symbols* http://msdl.microsoft.com/download/symbols Symbol search path is: symsrv*symsrv.dll* C:\Symbols*http://msdl.microsoft.com/download/symbols Executable search path is: (b5c.9cc): Break instruction exception - code 80000003 (first chance) eax=00000000 ebx=00000000 ecx=8ce20000 edx=00000000 esi=00d600e8 edi=7f9ea000 eip=776dfb65 esp=0056f980 ebp=0056f9ac iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 ntdll!LdrpDoDebuggerBreak+0x2b: 776dfb65 cc int 3 0:000> bp kernel32!QueryInformationJobObject 0:000> g Breakpoint 0 hit eax=0056f36c ebx=00d70c90 ecx=0056f370 edx=00000000 esi=00000184 edi=00db50cc eip=7759c4c0 esp=0056f2e8 ebp=0056f3e8 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 KERNEL32!QueryInformationJobObject: 7759c4c0 8bff mov edi,edi 0:000> dd esp l6 0056f2e8 00d619e5 00000184 00000009 0056f370 0056f2f8 00000070 0056f36c hJob == 0x184 JobObjectInfoClass == JobObjectExtendedLimitInformation cbJobObjectInfoLength == 0x70 (32-bit) *lpReturnLength (rc in run_child) is uninitialized: 0:000> dd 56f36c l1 0056f36c 77748600 Step to the system call, NtQueryInformationJobObject: 0:000> pc eax=0056f370 ebx=00000001 ecx=00000184 edx=0056f36c esi=0056f268 edi=00db50cc eip=7759c523 esp=0056f244 ebp=0056f2e4 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202 KERNEL32!QueryInformationJobObject+0x63: 7759c523 ff158c0e5d77 call dword ptr [KERNEL32!_imp__NtQueryInformationJobObject (775d0e8c)] ds:002b:775d0e8c={ntdll!NtQueryInformationJobObject (776a6c60)} 0:000> dd esp l5 0056f244 00000184 00000009 0056f268 00000070 0056f254 0056f36c 0:000> p eax=00000000 ebx=00000001 ecx=8ce20000 edx=0046e3e0 esi=0056f268 edi=00db50cc eip=7759c529 esp=0056f258 ebp=0056f2e4 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202 KERNEL32!QueryInformationJobObject+0x69: 7759c529 85c0 test eax,eax It returns STATUS_SUCCESS (register eax), but *lpReturnLength hasn't been updated: 0:000> dd 56f36c l1 0056f36c 77748600 Likewise the Win32 call is successful. 0:000> pt eax=00000001 ebx=00d70c90 ecx=541ed0d4 edx=00000000 esi=00000184 edi=00db50cc eip=7759c5c4 esp=0056f2e8 ebp=0056f3e8 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 KERNEL32!QueryInformationJobObject+0x104: 7759c5c4 c21400 ret 14h 0:000> dd 56f36c l1 0056f36c 77748600 ---------- nosy: +eryksun versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 14:33:45 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 09 May 2015 12:33:45 +0000 Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime Message-ID: <1431174824.99.0.526639719119.issue1100942@psf.upfronthosting.co.za> Berker Peksag added the comment: datetime.strptime is a classmethod, but the new date.strptime and time.strptime methods are staticmethods. I think we should make the new methods classmethods too. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 15:15:33 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 09 May 2015 13:15:33 +0000 Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate escaped strings In-Reply-To: <1431157984.91.0.636458618195.issue18814@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: surrogateescape and surrogateepass data *already* can't be inverted back to bytes reliably without knowing the original encoding - if you encode them as something else when they contain surrogates, you'll either get an exception (the default) or mojibake (if you use surrogateescape/surrogateepass as the output error handler). They only work as a transparent pass through if the input and output encodings match. I'd be fine with putting these data scrubbing functions somewhere other than in codecs, though (I'm not sure unicodedata is the right place, but a new module like "string.internals" might be, as these functions have more to do with Python's internal text representation than they do anything else. A module like the latter could also be a home for things like a chunking utility that splits a string up into substrings that use as little memory as possible for feeding into a StringIO instance before throwing the original away). I also don't think they're urgent - the introduction of /etc/locale.conf makes modern Linux far more consistent in getting locale settings right, and even older platforms tend to get the locale right for user processes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 15:19:10 2015 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 09 May 2015 13:19:10 +0000 Subject: [issue24147] doublequote are not well recognized with Dialect class In-Reply-To: <1431172809.62.0.742757955011.issue24147@psf.upfronthosting.co.za> Message-ID: Skip Montanaro added the comment: Sorry, failed to override my phone's spell correction. "cab" should be "csv". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 17:19:17 2015 From: report at bugs.python.org (ramiro) Date: Sat, 09 May 2015 15:19:17 +0000 Subject: [issue24148] 'cum' not a valid sort key for pstats.Stats.sort_stats Message-ID: <1431184757.15.0.93515789631.issue24148@psf.upfronthosting.co.za> New submission from ramiro: On the documentation page "The Python Profilers" https://docs.python.org/3.4/library/profile.html#instant-user-s-manual the following example is given: p.sort_stats('time', 'cum').print_stats(.5, 'init') This raises a KeyError, because 'cum' is not available as a sort key to pstats.Stats.sort_stats. As per the documentation of this method (https://docs.python.org/3.4/library/profile.html#the-stats-class) you can either use 'cumulative' or 'cumtime', which both work as expected. Since 'cumulative' is used a few examples earlier I suggest to use that for consistency. Tested with the following Python version: Python 3.4.3 on Ubuntu 15.04 ---------- assignee: docs at python components: Documentation messages: 242812 nosy: docs at python, ramiro priority: normal severity: normal status: open title: 'cum' not a valid sort key for pstats.Stats.sort_stats type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 17:40:33 2015 From: report at bugs.python.org (vyktor) Date: Sat, 09 May 2015 15:40:33 +0000 Subject: [issue24140] In pdb using "until X" doesn't seem to have effect in commands In-Reply-To: <1430998265.01.0.0346920117937.issue24140@psf.upfronthosting.co.za> Message-ID: <1431186033.42.0.598516565996.issue24140@psf.upfronthosting.co.za> vyktor added the comment: Adding test.py, but according to docs https://docs.python.org/3.2/library/pdb.html#pdbcommand-commands "Specifying any command resuming execution (currently continue, step, next, return, jump, quit and their abbreviations) terminates the command list (as if that command was immediately followed by end). " This is probably expected behavior. ---------- Added file: http://bugs.python.org/file39326/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 17:44:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 May 2015 15:44:39 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <20150509154436.25433.13344@psf.io> Roundup Robot added the comment: New changeset 36a8d935c322 by Yury Selivanov in branch 'default': PEP 479: Change StopIteration handling inside generators. https://hg.python.org/cpython/rev/36a8d935c322 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 17:45:49 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 09 May 2015 15:45:49 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431186349.83.0.271840804441.issue22906@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks Nick and Berker for the reviews! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 17:49:21 2015 From: report at bugs.python.org (vyktor) Date: Sat, 09 May 2015 15:49:21 +0000 Subject: [issue24140] In pdb using "until X" doesn't seem to have effect in commands In-Reply-To: <1430998265.01.0.0346920117937.issue24140@psf.upfronthosting.co.za> Message-ID: <1431186561.14.0.449032187194.issue24140@psf.upfronthosting.co.za> vyktor added the comment: In here: > /home/vyktor/src/error/minimal.py(1)() -> print('1') (Pdb) break 2 Breakpoint 1 at /home/vyktor/src/error/minimal.py:2 (Pdb) commands 1 (com) print('Triggered bp 1') (com) until 4 (com) end (Pdb) cont 1 Triggered bp 1 > /home/vyktor/src/error/minimal.py(2)() -> print('2') (Pdb) until has no effect. Expected behavior would be executing print 2 and 3. ---------- Added file: http://bugs.python.org/file39327/minimal.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 18:07:07 2015 From: report at bugs.python.org (Chris Angelico) Date: Sat, 09 May 2015 16:07:07 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431187627.17.0.320762210649.issue22906@psf.upfronthosting.co.za> Chris Angelico added the comment: Thanks everyone for all the help getting this to land! This is going to be a part of my active python3 binary from now on :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 18:08:12 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 09 May 2015 16:08:12 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431187692.5.0.66611705756.issue22906@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 18:29:21 2015 From: report at bugs.python.org (Mik) Date: Sat, 09 May 2015 16:29:21 +0000 Subject: [issue24147] doublequote are not well recognized with Dialect class In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za> Message-ID: <1431188961.32.0.396017983026.issue24147@psf.upfronthosting.co.za> Mik added the comment: Hi, This is the file used for my test. Thank you, regard, Mik ---------- Added file: http://bugs.python.org/file39328/sans_headers.csv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 18:38:09 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 09 May 2015 16:38:09 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431189489.42.0.245451539469.issue22906@psf.upfronthosting.co.za> Berker Peksag added the comment: Buildbots are not happy: [ 63/393] test_contextlib Fatal Python error: Objects/frameobject.c:429 object at 0x200041abc28 has negative ref count -2604246222170760230 Current thread 0x00000200002c2500 (most recent call first): File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/unittest/case.py", line 579 in run File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/unittest/case.py", line 627 in __call__ File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/unittest/suite.py", line 122 in run File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/unittest/suite.py", line 84 in __call__ File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/unittest/suite.py", line 122 in run File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/unittest/suite.py", line 84 in __call__ File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/unittest/suite.py", line 122 in run File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/unittest/suite.py", line 84 in __call__ File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/unittest/runner.py", line 176 in run File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/support/__init__.py", line 1775 in _run_suite File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/support/__init__.py", line 1809 in run_unittest File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/regrtest.py", line 1279 in test_runner File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/regrtest.py", line 1280 in runtest_inner File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/regrtest.py", line 967 in runtest File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/regrtest.py", line 763 in main File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/regrtest.py", line 1564 in main_in_temp_cwd File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/__main__.py", line 3 in File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/runpy.py", line 85 in _run_code File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/runpy.py", line 170 in _run_module_as_main make: *** [buildbottest] Aborted http://buildbot.python.org/all/builders/System%20Z%20Linux%203.x/builds/3162/steps/test/logs/stdio http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/11643/steps/test/logs/stdio ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 18:45:01 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 09 May 2015 16:45:01 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1431189489.42.0.245451539469.issue22906@psf.upfronthosting.co.za> Message-ID: <8CC86FC5-3FD0-4971-9051-40ABC34FED9A@gmail.com> Yury Selivanov added the comment: Strange, the test suite was running just fine on my machine. I'll take a closer look later today. ---------- nosy: +Yury.Selivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 18:47:53 2015 From: report at bugs.python.org (Chris Angelico) Date: Sat, 09 May 2015 16:47:53 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431190073.63.0.57313866259.issue22906@psf.upfronthosting.co.za> Chris Angelico added the comment: Weird. Tests ran fine on my machine too. Interestingly, that number is 0xdbdbdbdbdbdbdbda - does that mean anything? (It's negative 0x2424242424242426, for what that's worth.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 19:02:32 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 09 May 2015 17:02:32 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1431190073.63.0.57313866259.issue22906@psf.upfronthosting.co.za> Message-ID: <937442A8-6F30-4B32-87EF-87E8E5FD8C38@gmail.com> Yury Selivanov added the comment: I think it crashes in debug mode or something. Somewhere we did too many decrefs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 19:54:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 May 2015 17:54:04 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <20150509175401.76592.14189@psf.io> Roundup Robot added the comment: New changeset d15c26085591 by Yury Selivanov in branch 'default': Issue 22906: Add test file. https://hg.python.org/cpython/rev/d15c26085591 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 20:09:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 May 2015 18:09:16 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <20150509180913.76596.75415@psf.io> Roundup Robot added the comment: New changeset 5d8bc813d270 by Yury Selivanov in branch 'default': Issue 22906: Increment refcount after PyException_SetContext https://hg.python.org/cpython/rev/5d8bc813d270 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 20:10:04 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 09 May 2015 18:10:04 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431195004.59.0.170593469454.issue22906@psf.upfronthosting.co.za> Yury Selivanov added the comment: Berker, buildbots should be happy now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 20:37:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 May 2015 18:37:45 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <20150509183742.25445.56288@psf.io> Roundup Robot added the comment: New changeset f7cc54086cd2 by Guido van Rossum in branch 'default': Fix news entry for issue 24018. https://hg.python.org/cpython/rev/f7cc54086cd2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 20:38:11 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 09 May 2015 18:38:11 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1431149327.26.0.784493155651.issue24018@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Fixed. On Fri, May 8, 2015 at 10:28 PM, Stefan Behnel wrote: > > Stefan Behnel added the comment: > > Thanks! Minor grouch: it should say "collections.*abc*.Generator" in the > NEWS entry. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 20:45:53 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 09 May 2015 18:45:53 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431197153.0.0.331393922847.issue22906@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 21:01:50 2015 From: report at bugs.python.org (Becklin Haston) Date: Sat, 09 May 2015 19:01:50 +0000 Subject: [issue24149] Issue with unit tests Message-ID: <1431198110.31.0.593961870852.issue24149@psf.upfronthosting.co.za> New submission from Becklin Haston: Hello. Having issue when running unit tests for Python v3.5. Encountering failure when doing test 75/393. File attached is relevant traceback. ---------- components: Tests files: traceback.txt messages: 242829 nosy: hastonb priority: normal severity: normal status: open title: Issue with unit tests versions: Python 3.5 Added file: http://bugs.python.org/file39329/traceback.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 21:04:23 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 09 May 2015 19:04:23 +0000 Subject: [issue24149] Issue with unit tests In-Reply-To: <1431198110.31.0.593961870852.issue24149@psf.upfronthosting.co.za> Message-ID: <1431198263.85.0.973094290641.issue24149@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report. This problem was just introduced and just fixed an hour ago: see issue22906. Try updating to the very latest tip and try again. ---------- nosy: +ned.deily resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 21:07:18 2015 From: report at bugs.python.org (rainier) Date: Sat, 09 May 2015 19:07:18 +0000 Subject: [issue24150] text_contextlib fails on Mac OSX 10.10.3 Message-ID: <1431198438.47.0.0907649941057.issue24150@psf.upfronthosting.co.za> New submission from rainier: Test 75 test_contextlib fails. Fatal Python error: Objects/frameobject.c:429 object at 0x10fa32178 has negative ref count -2604246222170760230 Exception: Child error on test_contextlib: Exit code -6 Thread hangs and must be force exited on Mac OSX 10.10.3 Problem with threading. Stack trace: [ 75/393] test_contextlib Fatal Python error: Objects/frameobject.c:429 object at 0x10fa32178 has negative ref count -2604246222170760230 Current thread 0x00007fff73b07300 (most recent call first): File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/unittest/case.py", line 579 in run File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/unittest/case.py", line 627 in __call__ File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/unittest/suite.py", line 122 in run File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/unittest/suite.py", line 122 in run File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/unittest/suite.py", line 122 in run File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/test/support/__init__.py", line 1674 in run File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/test/support/__init__.py", line 1775 in _run_suite File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/test/support/__init__.py", line 1809 in run_unittest File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/test/regrtest.py", line 1279 in test_runner File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/test/regrtest.py", line 1280 in runtest_inner File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/test/regrtest.py", line 978 in runtest File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/test/regrtest.py", line 532 in main File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/test/regrtest.py", line 1564 in main_in_temp_cwd File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/test/regrtest.py", line 1589 in File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/runpy.py", line 85 in _run_code File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/runpy.py", line 170 in _run_module_as_main Traceback (most recent call last): File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/test/__main__.py", line 3, in regrtest.main_in_temp_cwd() File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/test/regrtest.py", line 1564, in main_in_temp_cwd main() File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/test/regrtest.py", line 738, in main raise Exception("Child error on {}: {}".format(test, result[1])) Exception: Child error on test_contextlib: Exit code -6 ^CException ignored in: Traceback (most recent call last): File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/threading.py", line 1297, in _shutdown t.join() File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/threading.py", line 1063, in join self._wait_for_tstate_lock() File "/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/threading.py", line 1079, in _wait_for_tstate_lock elif lock.acquire(block, timeout): ---------- components: Tests messages: 242831 nosy: rainier priority: normal severity: normal status: open title: text_contextlib fails on Mac OSX 10.10.3 type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 21:07:43 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 09 May 2015 19:07:43 +0000 Subject: [issue21162] code in multiprocessing.pool freeze if inside some code from scikit-learn (and probably liblinear) executed on ubuntu 12.04 64 Bit In-Reply-To: <1396716060.12.0.828109902525.issue21162@psf.upfronthosting.co.za> Message-ID: <1431198463.14.0.26388192688.issue21162@psf.upfronthosting.co.za> Davin Potts added the comment: @Ivan.K: Can you be more specific about which linux platform you are using? To reproduce, should I use Ubuntu, Fedora, OpenSUSE, ... and which version of that linux distro? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 21:10:18 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 09 May 2015 19:10:18 +0000 Subject: [issue24150] text_contextlib fails on Mac OSX 10.10.3 In-Reply-To: <1431198438.47.0.0907649941057.issue24150@psf.upfronthosting.co.za> Message-ID: <1431198618.75.0.768259129313.issue24150@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report. This problem has just been fixed. Please update and try again. ---------- nosy: +ned.deily resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 21:11:23 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 09 May 2015 19:11:23 +0000 Subject: [issue24150] text_contextlib fails on Mac OSX 10.10.3 In-Reply-To: <1431198438.47.0.0907649941057.issue24150@psf.upfronthosting.co.za> Message-ID: <1431198683.47.0.50134505015.issue24150@psf.upfronthosting.co.za> Ned Deily added the comment: (See Issue22906 for details.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 21:41:21 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 09 May 2015 19:41:21 +0000 Subject: [issue24140] In pdb using "until X" doesn't seem to have effect in commands In-Reply-To: <1430998265.01.0.0346920117937.issue24140@psf.upfronthosting.co.za> Message-ID: <1431200481.08.0.878158818255.issue24140@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The bug occurs also on the default branch: '3.5.0a4+ (default:8bac00eadfda, May 6 2015, 17:40:12) \n[GCC 4.9.2 20150304 (prerelease)]' The reason is that 'do_until' is missing from the Pdb.commands_resuming list, which causes the Pdb.bp_commands() method to invoke the interaction function _cmdloop() after having processed all the breakpoint commands instead of returning from the trace function, so that the settings made by set_until() are lost. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 21:46:52 2015 From: report at bugs.python.org (Rebecca Hsieh) Date: Sat, 09 May 2015 19:46:52 +0000 Subject: [issue24151] test_pydoc fails Message-ID: <1431200812.83.0.50914922757.issue24151@psf.upfronthosting.co.za> New submission from Rebecca Hsieh: While running this command: ./python -m test.test_pydoc -j3 the error underneath was produced. The AssertionError of 'walkpkg' was not found. Fails around the test_apropos_empty_doc (_main_.PydocImportTest). The following is the stack trace that was produced after running the test: test_allmethods (__main__.PydocDocTest) ... ok test_getpager_with_stdin_none (__main__.PydocDocTest) ... ok test_help_output_redirect (__main__.PydocDocTest) ... ok test_html_doc (__main__.PydocDocTest) ... ok test_input_strip (__main__.PydocDocTest) ... ok test_is_object_or_method (__main__.PydocDocTest) ... ok test_is_package_when_is_package (__main__.PydocDocTest) ... ok test_is_package_when_not_package (__main__.PydocDocTest) ... ok test_issue8225 (__main__.PydocDocTest) ... ok test_namedtuple_public_underscore (__main__.PydocDocTest) ... ok test_non_str_name (__main__.PydocDocTest) ... ok test_not_ascii (__main__.PydocDocTest) ... ok test_not_here (__main__.PydocDocTest) ... ok test_splitdoc_with_description (__main__.PydocDocTest) ... ok test_stripid (__main__.PydocDocTest) ... ok test_synopsis (__main__.PydocDocTest) ... ok test_synopsis_sourceless (__main__.PydocDocTest) ... ok test_synopsis_sourceless_empty_doc (__main__.PydocDocTest) ... ok test_text_doc (__main__.PydocDocTest) ... ok test_text_enum_member_with_value_zero (__main__.PydocDocTest) ... ok test_apropos_empty_doc (__main__.PydocImportTest) ... FAIL test_apropos_with_bad_package (__main__.PydocImportTest) ... ok test_apropos_with_unreadable_dir (__main__.PydocImportTest) ... ok test_badimport (__main__.PydocImportTest) ... ok test_importfile (__main__.PydocImportTest) ... ok test_modules (__main__.PydocImportTest) ... skipped 'causes undesireable side-ef test_modules_search (__main__.PydocImportTest) ... skipped 'causes undesireable test_modules_search_builtin (__main__.PydocImportTest) ... skipped 'some buildbo test_bound_builtin_method (__main__.TestDescriptions) ... ok test_bound_python_method (__main__.TestDescriptions) ... ok test_builtin (__main__.TestDescriptions) ... ok test_class (__main__.TestDescriptions) ... ok test_module (__main__.TestDescriptions) ... ok test_module_level_callable (__main__.TestDescriptions) ... ok test_unbound_builtin_method (__main__.TestDescriptions) ... ok test_unbound_python_method (__main__.TestDescriptions) ... ok test_server (__main__.PydocServerTest) ... ok test_content_type_err (__main__.PydocUrlHandlerTest) ... ok test_url_requests (__main__.PydocUrlHandlerTest) ... ok test_keywords (__main__.TestHelper) ... ok test_DynamicClassAttribute (__main__.PydocWithMetaClasses) ... ok test_buggy_dir (__main__.PydocWithMetaClasses) ... ok test_resolve_false (__main__.PydocWithMetaClasses) ... ok test_virtualClassAttributeWithOneMeta (__main__.PydocWithMetaClasses) ... ok test_virtualClassAttributeWithTwoMeta (__main__.PydocWithMetaClasses) ... ok ====================================================================== FAIL: test_apropos_empty_doc (__main__.PydocImportTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/hsiehr/Documents/OpenSource/cpython/Lib/test/test_pydoc.py", line self.assertIn('walkpkg', stdout.getvalue()) AssertionError: 'walkpkg' not found in '_ast \n_codecs \n_collections - High per that operate on functions.\n_imp - (Extremely) low-level import machinery bits odule provides the Python interfaces to stream handling. The\n_locale - Support rface.\n_signal - This module provides mechanisms to use signal handlers in Pyth_string - string helper module\n_symtable \n_thread - This module provides primiams.\n_tracemalloc - Debug module to trace memory blocks allocated by Python.\n_iltering support.\n_weakref - Weak-reference support module.\natexit - allow probe executedupon normal program termination.\nbuiltins - Built-in functions, excele makes available standard errno system symbols.\nfaulthandler - faulthandler mhe garbage collector for reference cycles.\nitertools - Functional tools for credule contains functions that can read and write Python values in\nposix - This mctionality that is\npwd - This module provides access to the Unix password databme objects used or maintained by the\ntime - This module provides various functixsubtype is an example module showing how to subtype builtin types from C.\nzipiing Python modules from Zip archives.\n' ---------------------------------------------------------------------- Ran 45 tests in 3.309s FAILED (failures=1, skipped=3) Traceback (most recent call last): File "/home/hsiehr/Documents/OpenSource/cpython/Lib/runpy.py", line 170, in _r "__main__", mod_spec) File "/home/hsiehr/Documents/OpenSource/cpython/Lib/runpy.py", line 85, in _ru exec(code, run_globals) File "/home/hsiehr/Documents/OpenSource/cpython/Lib/test/test_pydoc.py", line test_main() File "/home/hsiehr/Documents/OpenSource/cpython/Lib/test/support/__init__.py", return func(*args) File "/home/hsiehr/Documents/OpenSource/cpython/Lib/test/test_pydoc.py", line PydocWithMetaClasses, File "/home/hsiehr/Documents/OpenSource/cpython/Lib/test/support/__init__.py", _run_suite(suite) File "/home/hsiehr/Documents/OpenSource/cpython/Lib/test/support/__init__.py", raise TestFailed(err) test.support.TestFailed: Traceback (most recent call last): File "/home/hsiehr/Documents/OpenSource/cpython/Lib/test/test_pydoc.py", line self.assertIn('walkpkg', stdout.getvalue()) AssertionError: 'walkpkg' not found in '_ast \n_codecs \n_collections - High per that operate on functions.\n_imp - (Extremely) low-level import machinery bits odule provides the Python interfaces to stream handling. The\n_locale - Support rface.\n_signal - This module provides mechanisms to use signal handlers in Pyth_string - string helper module\n_symtable \n_thread - This module provides primiams.\n_tracemalloc - Debug module to trace memory blocks allocated by Python.\n_iltering support.\n_weakref - Weak-reference support module.\natexit - allow probe executedupon normal program termination.\nbuiltins - Built-in functions, excele makes available standard errno system symbols.\nfaulthandler - faulthandler mhe garbage collector for reference cycles.\nitertools - Functional tools for credule contains functions that can read and write Python values in\nposix - This mctionality that is\npwd - This module provides access to the Unix password databme objects used or maintained by the\ntime - This module provides various functixsubtype is an example module showing how to subtype builtin types from C.\nzipiing Python modules from Zip archives.\n' ---------- components: Tests messages: 242838 nosy: hsiehr priority: normal severity: normal status: open title: test_pydoc fails type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 22:37:25 2015 From: report at bugs.python.org (Alex Lord) Date: Sat, 09 May 2015 20:37:25 +0000 Subject: [issue24104] Use after free in xmlparser_setevents (2) In-Reply-To: <1430489742.91.0.610954411273.issue24104@psf.upfronthosting.co.za> Message-ID: <1431203845.17.0.523314876101.issue24104@psf.upfronthosting.co.za> Alex Lord added the comment: ../cpython/python.exe test_xmlparser_setevents.py __del__ 1 __del__ 3 Segmentation fault: 11 Confirmation on 3.5.0a4 Python 3.5.0a4+ ---------- nosy: +Alex.Lord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 22:45:44 2015 From: report at bugs.python.org (ryan) Date: Sat, 09 May 2015 20:45:44 +0000 Subject: [issue24152] test_mailcap fails Message-ID: <1431204344.46.0.744313326923.issue24152@psf.upfronthosting.co.za> New submission from ryan: UnicodeDecodeError ---------- components: Tests files: results hgrepos: 308 messages: 242840 nosy: petrosr2 priority: normal severity: normal status: open title: test_mailcap fails type: crash versions: Python 2.7 Added file: http://bugs.python.org/file39330/results _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 23:02:33 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 09 May 2015 21:02:33 +0000 Subject: [issue24151] test_pydoc fails In-Reply-To: <1431200812.83.0.50914922757.issue24151@psf.upfronthosting.co.za> Message-ID: <1431205353.05.0.17349919263.issue24151@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report. I'm not able to reproduce the failure myself. Can you give more information on what platform this was run on (OS version) and at what changeset the build was with (hg summary)? Perhaps you could try debugging the execution of that test case with some prints? Also, since there was a major break in the default branch earlier today that caused tests to fail, it might be worthwhile to first ensure you have a good build by doing a total rebuild (make clean && make). ---------- nosy: +ned.deily type: crash -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 23:12:22 2015 From: report at bugs.python.org (ryan) Date: Sat, 09 May 2015 21:12:22 +0000 Subject: [issue24152] test_mailcap fails In-Reply-To: <1431204344.46.0.744313326923.issue24152@psf.upfronthosting.co.za> Message-ID: <1431205942.86.0.239848725863.issue24152@psf.upfronthosting.co.za> ryan added the comment: running command over PuTTY on Ubuntu 3.13, python 2.7.6 $ ./python -m test test_mailcap [1/1] test_mailcap test test_mailcap failed -- Traceback (most recent call last): File "/home/petrosr2/Documents/opensource/cpy/Lib/test/test_mailcap.py", line 126, in test_system_mailcap caps = mailcap.getcaps() File "/home/petrosr2/Documents/opensource/cpy/Lib/mailcap.py", line 26, in getcaps morecaps = readmailcapfile(fp) File "/home/petrosr2/Documents/opensource/cpy/Lib/mailcap.py", line 64, in readmailcapfile line = fp.readline() File "/home/petrosr2/Documents/opensource/cpy/Lib/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3820: ordinal not in range(128) 1 test failed: test_mailcap ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 9 23:42:06 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 09 May 2015 21:42:06 +0000 Subject: [issue24152] test_mailcap fails if a mailcap file contains a non-decodable character In-Reply-To: <1431204344.46.0.744313326923.issue24152@psf.upfronthosting.co.za> Message-ID: <1431207726.47.0.905480320163.issue24152@psf.upfronthosting.co.za> Ned Deily added the comment: I can reproduce the failure by arbitrarily adding a non-ascii character to one of the mailcap files searched for by the mailcap module (https://docs.python.org/3/library/mailcap.html#mailcap.getcaps), like $HOME/.mailcap, and by setting the process to an ascii-only locale (export LANG=C). While this might be a somewhat unusual combination in practice, mailcap should be able to handle it. By the way, this is a Python 3 problem since test_mailcap does not exist in Python 2. 2.7.6 might be the version of the system-supplied Python, but you appeared to be running with a Python you built. Try ./python -V to show the version of the Python you are using. ---------- components: +Library (Lib) -Tests nosy: +ned.deily stage: -> needs patch title: test_mailcap fails -> test_mailcap fails if a mailcap file contains a non-decodable character type: crash -> versions: +Python 3.4, Python 3.5 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 01:06:51 2015 From: report at bugs.python.org (Ryan Shupe) Date: Sat, 09 May 2015 23:06:51 +0000 Subject: [issue24153] threading/multiprocessing tests fail on chromebook under crouton generated chroots Message-ID: <1431212811.34.0.300169078652.issue24153@psf.upfronthosting.co.za> New submission from Ryan Shupe: I set up my Asus chromebook c200 with crouton and installed two chroot environments under the trusty release. In one I built and ran the tests for Python 3.5.0a4+ See stacktrace of resulting error: [209/394/2] test_multiprocessing_fork [210/394/3] test_multiprocessing_forkserver Process Process-243: Traceback (most recent call last): File "/home/shuper/Downloads/src/cpython/Lib/multiprocessing/process.py", line 254, in _bootstrap self.run() File "/home/shuper/Downloads/src/cpython/Lib/multiprocessing/process.py", line 93, in run self._target(*self._args, **self._kwargs) File "/home/shuper/Downloads/src/cpython/Lib/test/_test_multiprocessing.py", line 458, in _test_stderr_flush sys.stderr = open(testfn, 'w') OSError: [Errno 28] No space left on device: '@test_4624_tmp' Process Process-245: Traceback (most recent call last): File "/home/shuper/Downloads/src/cpython/Lib/multiprocessing/process.py", line 254, in _bootstrap self.run() File "/home/shuper/Downloads/src/cpython/Lib/multiprocessing/process.py", line 93, in run self._target(*self._args, **self._kwargs) File "/home/shuper/Downloads/src/cpython/Lib/test/_test_multiprocessing.py", line 464, in _test_sys_exit sys.stderr = open(testfn, 'w') OSError: [Errno 28] No space left on device: '@test_4624_tmp' Dangling processes: {} Dangling threads: {} Warning -- multiprocessing.process._dangling was modified by test_multiprocessing_forkserver Warning -- threading._dangling was modified by test_multiprocessing_forkserver test test_multiprocessing_forkserver failed -- multiple errors occurred; run in verbose mode for details [211/394/3] test_multiprocessing_main_handling /home/shuper/Downloads/src/cpython/Lib/test/support/__init__.py:946: RuntimeWarning: tests may fail, unable to create temp dir: /home/shuper/Downloads/src/cpython/build/test_python_6460 with temp_dir(path=name, quiet=quiet) as temp_path: /home/shuper/Downloads/src/cpython/Lib/test/support/__init__.py:947: RuntimeWarning: tests may fail, unable to change CWD to: /home/shuper/Downloads/src/cpython/build/test_python_6460 with change_cwd(temp_path, quiet=quiet) as cwd_dir: ^C^T^CTraceback (most recent call last): File "/home/shuper/Downloads/src/cpython/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/home/shuper/Downloads/src/cpython/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/shuper/Downloads/src/cpython/Lib/test/__main__.py", line 3, in regrtest.main_in_temp_cwd() File "/home/shuper/Downloads/src/cpython/Lib/test/regrtest.py", line 1564, in main_in_temp_cwd main() File "/home/shuper/Downloads/src/cpython/Lib/test/regrtest.py", line 744, in main worker.join() File "/home/shuper/Downloads/src/cpython/Lib/threading.py", line 1063, in join self._wait_for_tstate_lock() File "/home/shuper/Downloads/src/cpython/Lib/threading.py", line 1079, in _wait_for_tstate_lock elif lock.acquire(block, timeout): KeyboardInterrupt ---------- components: Tests messages: 242844 nosy: shiprex priority: normal severity: normal status: open title: threading/multiprocessing tests fail on chromebook under crouton generated chroots versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 01:22:47 2015 From: report at bugs.python.org (Tim Graham) Date: Sat, 09 May 2015 23:22:47 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1431213767.46.0.453051188993.issue24134@psf.upfronthosting.co.za> Tim Graham added the comment: I noticed this is backwards incompatible for a small feature in Django. If you want to leave this feature in Python 2.7 and 3.4, it'll break things unless we push out a patch for Django; see https://github.com/django/django/pull/4637. ---------- nosy: +Tim.Graham _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 01:23:46 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 09 May 2015 23:23:46 +0000 Subject: [issue24153] threading/multiprocessing tests fail on chromebook under crouton generated chroots In-Reply-To: <1431212811.34.0.300169078652.issue24153@psf.upfronthosting.co.za> Message-ID: <1431213826.72.0.193218946682.issue24153@psf.upfronthosting.co.za> Ned Deily added the comment: The failures seem pretty clear: OSError: [Errno 28] No space left on device Are you allocating enough disk space in the chrooted environments? The amount of free space needed to run all the tests varies by platform, by architecture, by test options selected, etc, and by file system type (see, for example, Issue23953). I don't know that we have any rough guidelines for free space; you may have to experiment and you could try excluding largefile tests: ./python -m test -uall,-largefile [...] ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 03:37:48 2015 From: report at bugs.python.org (Yuri Teixeira) Date: Sun, 10 May 2015 01:37:48 +0000 Subject: [issue24154] pathlib.Path.rename moves file to Path.cwd() when argument is a string Message-ID: <1431221868.46.0.281125917567.issue24154@psf.upfronthosting.co.za> New submission from Yuri Teixeira: from pathlib import Path p = Path('/any/folder') f = p / 'oldname' f.rename('newname') The above will rename the file 'oldname' to 'newname' but will also move it to Path.cwd() I thought that pathlib.Path.rename() when fed with a string would change f.name only. I certainly did not expect the file to move. My hypothesis is that a new Path('newname') is being created and used to move the file so it that goes to Path.cwd() with the new name but I don't know anything. Please disregard if this is working as intended. The docs do not mention this behavior: https://docs.python.org/3/library/pathlib.html#pathlib.Path.rename I'm using Python 3.4.3 on Debian testing. ---------- components: Library (Lib) messages: 242847 nosy: yurit priority: normal severity: normal status: open title: pathlib.Path.rename moves file to Path.cwd() when argument is a string type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 05:34:08 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 10 May 2015 03:34: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: <1431228848.8.0.9239103174.issue24017@psf.upfronthosting.co.za> Nick Coghlan added the comment: Review sent - very nice work on this Yury. Highlights: * I concur with Stefan that we should have a full PyCoroutineMethods struct at the C level, with a "tp_as_coroutine" pointer to that replacing the current tp_reserved slot * I also concur with Stefan about adding a Coroutine ABC * PyType_FromSpec (and typeslots.h) will need updating once we agree on a slot structure (with my recommendation being "define C level slots for all of the new PEP 492 methods") * I found CO_COROUTINE/CO_NATIVE_COROUTINE confusing as a reader of the implementation, as they only told me how the objects were defined, rather than telling me why I should care. Based on what I gleaned of their intended purpose from reading the implementation, I suggest switching this to instead use CO_COROUTINE (set for all coroutines, regardless of how they were defined) and CO_ITERABLE_COROUTINE (set only for those coroutines that also support iteration), and adjusting the naming of other APIs accordingly. * I found the names of the WITH_CLEANUP_ENTER and WITH_CLEANUP_EXIT bytecodes misleading, as they don't refer to the corresponding context management phases - they're both related to the "exit" phase. WITH_CLEANUP_START and WITH_CLEANUP_FINISH should be clearer for readers (both of the implementation and of the disassembled bytecode). ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 05:40:46 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 10 May 2015 03:40:46 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1431229246.92.0.00770129146818.issue22906@psf.upfronthosting.co.za> Nick Coghlan added the comment: Since it took me a moment to figure out why the extra incref was needed: * both PyException_SetCause and PyException_SetContext steal a reference to their second argument * hence we need the second incref, rather than relying solely on the reference received from PyErr_NormalizeException This does suggest the new incref is conceptually in the wrong spot - it should be before the call to PyException_SetCause, such that this block of code *always* possesses a valid reference while accessing "val". At the moment, we technically still don't have an active reference when passing "val" to PyException_SetContext. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 06:52:28 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 10 May 2015 04:52:28 +0000 Subject: [issue24155] Optimize heapify for better cache utililzation Message-ID: <1431233548.51.0.135942153976.issue24155@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Heapify() is implemented with a series of siftup() operations that aggregate small heaps into bigger heaps. The current algorithm builds all the smallest heaps first, then makes all of the next largest size, and so on. This is not cache friendly because the aggregation step operates on smaller heaps built long before. The new algorithm performs the aggregation step immediately after its child heaps are built (while they are still likely to be in cache). The overall algorithm is the same (children built before parents). The number of comparisons is the same. And the resulting heap is identical. The only difference is performing work while the inputs are still in cache rather than waiting until all heaps at the current size have been built. For small heaps that already fit entirely in L1 cache, there is no benefit, so we stick with the current version which has less branching. For larger heaps, we switch to the new order. The timings and benefits depend on the number and sizes of the objects being heapified as well as the relative speed of L1 to L2 to L3 to DRAM. ------------------------------------------------------------------ For those who are interested, here timings for heapifying shuffled lists of various sizes. The elements are tuples of length 1 that contain distinct integers. The first row has the time to copy to the data. It should be substracted from the timings on the next two rows which time the new algorithm versus the old algorithm. The benefits don't start to show up until after N is over 1000 (depending on the input type, the breakeven point seems to fall somewhere between 1200 and 2500 on my machine). N = 100 [2.9262970201671124e-05, 2.9265997000038624e-05, 2.9325950890779495e-05] tupledata[:] [0.0006274560000747442, 0.0006340609397739172, 0.0006361680570989847] heapify(tupledata[:]) [0.0006139189936220646, 0.0006186790997162461, 0.000632670009508729] heapify_old(tupledata[:]) [2.8867041692137718e-05, 2.8883921913802624e-05, 2.896797377616167e-05] tupledata[:] [0.000608008005656302, 0.0006171419518068433, 0.0006187589606270194] heapify(tupledata[:]) [0.0006224410608410835, 0.000638791942037642, 0.0006388520123437047] heapify_old(tupledata[:]) [2.89019662886858e-05, 2.8969021514058113e-05, 2.8973910957574844e-05] tupledata[:] [0.0006031119264662266, 0.0006048450013622642, 0.0006136660231277347] heapify(tupledata[:]) [0.000612352043390274, 0.0006144039798527956, 0.0006217029877007008] heapify_old(tupledata[:]) N = 1000 [0.0002854769118130207, 0.0002856890205293894, 0.00028590403962880373] tupledata[:] [0.006836145068518817, 0.006866019102744758, 0.006885501905344427] heapify(tupledata[:]) [0.0067316299537196755, 0.006792359985411167, 0.0067987809889018536] heapify_old(tupledata[:]) [0.00028532894793897867, 0.0002853329060599208, 0.00028538203332573175] tupledata[:] [0.006822419003583491, 0.0068415619898587465, 0.006888034055009484] heapify(tupledata[:]) [0.006734892027452588, 0.006814536056481302, 0.0068227669689804316] heapify_old(tupledata[:]) [0.00028527993708848953, 0.0002854960039258003, 0.0002858199877664447] tupledata[:] [0.006787727936170995, 0.0067988099763169885, 0.006827510078437626] heapify(tupledata[:]) [0.0067258820636197925, 0.006815586006268859, 0.006871008081361651] heapify_old(tupledata[:]) N = 10000 [0.004415847011841834, 0.004417525022290647, 0.0044295149855315685] tupledata[:] [0.07748138904571533, 0.07753941905684769, 0.07756883592810482] heapify(tupledata[:]) [0.08400217199232429, 0.08420385408680886, 0.08428021904546767] heapify_old(tupledata[:]) [0.004418709082528949, 0.004422315978445113, 0.004425868042744696] tupledata[:] [0.07753065403085202, 0.0775474050315097, 0.07755298691336066] heapify(tupledata[:]) [0.08406145800836384, 0.08412359503563493, 0.08419332408811897] heapify_old(tupledata[:]) [0.0044234748929739, 0.0044267530320212245, 0.0044296300038695335] tupledata[:] [0.07729987089987844, 0.07750388595741242, 0.07770221296232194] heapify(tupledata[:]) [0.08401058206800371, 0.0840839499142021, 0.08423375408165157] heapify_old(tupledata[:]) N = 100000 [0.055330604896880686, 0.05594596697483212, 0.056045167963020504] tupledata[:] [1.2075877389870584, 1.207723677973263, 1.2084980909712613] heapify(tupledata[:]) [1.56127171497792, 1.5691186729818583, 1.575164051959291] heapify_old(tupledata[:]) [0.0558202009415254, 0.05597207904793322, 0.0560223578941077] tupledata[:] [1.2101711059221998, 1.211772706010379, 1.2120026310440153] heapify(tupledata[:]) [1.5360360990744084, 1.5435883220052347, 1.5501357419416308] heapify_old(tupledata[:]) [0.05999936908483505, 0.06000674597453326, 0.06018067698460072] tupledata[:] [1.209613809012808, 1.2116600699955598, 1.2144729839637876] heapify(tupledata[:]) [1.5371010650414973, 1.5499007020844147, 1.5706949040759355] heapify_old(tupledata[:]) N = 1000000 [0.8224946830887347, 0.8234598189592361, 0.8247971039963886] tupledata[:] [18.152570085017942, 18.340327466023155, 18.413799613015726] heapify(tupledata[:]) [19.786154965986498, 19.91440916794818, 19.952165015041828] heapify_old(tupledata[:]) [0.8147928019752726, 0.8154206149047241, 0.8169217950198799] tupledata[:] [18.227028850931674, 18.265947047038935, 18.36190685792826] heapify(tupledata[:]) [19.587209751014598, 19.62119024794083, 19.85366743709892] heapify_old(tupledata[:]) [0.8098425359930843, 0.8100302360253409, 0.8104055189760402] tupledata[:] [18.16859135404229, 18.207948053022847, 18.350174001068808] heapify(tupledata[:]) [19.6270396419568, 19.85634774295613, 20.017801710986532] heapify_old(tupledata[:]) N = 10000000 [16.074914730968885, 16.084022041060962, 16.150474293972366] tupledata[:] [205.83624146296643, 205.94496312504634, 205.96075649105478] heapify(tupledata[:]) [349.2653319039382, 349.8653641429264, 351.06795906298794] heapify_old(tupledata[:]) [16.07795425108634, 16.091183452052064, 16.10310253489297] tupledata[:] [205.1686675120145, 206.0234369279351, 206.10121345799416] heapify(tupledata[:]) [348.308155576, 348.6673470499227, 348.7512100059539] heapify_old(tupledata[:]) [16.074230056954548, 16.098330755950883, 16.106685669976287] tupledata[:] [205.18946332705673, 205.4753301080782, 205.5993042109767] heapify(tupledata[:]) [349.5718760070158, 349.6067797210999, 351.29123334004544] heapify_old(tupledata[:]) ---------- assignee: rhettinger components: Extension Modules files: draft_heapq.diff keywords: patch messages: 242850 nosy: rhettinger priority: normal severity: normal status: open title: Optimize heapify for better cache utililzation type: performance versions: Python 3.5 Added file: http://bugs.python.org/file39331/draft_heapq.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 06:58:21 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 10 May 2015 04:58:21 +0000 Subject: [issue24155] Optimize heapify for better cache utililzation In-Reply-To: <1431233548.51.0.135942153976.issue24155@psf.upfronthosting.co.za> Message-ID: <1431233901.18.0.211670232831.issue24155@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file39332/wordy_explanation.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 07:03:54 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 10 May 2015 05:03:54 +0000 Subject: [issue24155] Optimize heapify for better cache utililzation In-Reply-To: <1431233548.51.0.135942153976.issue24155@psf.upfronthosting.co.za> Message-ID: <1431234234.85.0.865007150434.issue24155@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Removed file: http://bugs.python.org/file39331/draft_heapq.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 07:04:45 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 10 May 2015 05:04:45 +0000 Subject: [issue24155] Optimize heapify for better cache utililzation In-Reply-To: <1431233548.51.0.135942153976.issue24155@psf.upfronthosting.co.za> Message-ID: <1431234285.35.0.637056171351.issue24155@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file39333/better_heapify.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 07:36:04 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 10 May 2015 05:36:04 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1431236164.52.0.246674232349.issue23857@psf.upfronthosting.co.za> Nick Coghlan added the comment: First draft of a recommendations PEP: https://hg.python.org/peps/rev/85bc7f13b295 (PEP 493) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 09:54:33 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 May 2015 07:54:33 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1431244473.76.0.886711585095.issue24134@psf.upfronthosting.co.za> R. David Murray added the comment: Given one failure there are probably more. So we should probably back this out of 2.7 and 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 10:53:03 2015 From: report at bugs.python.org (Ivan K) Date: Sun, 10 May 2015 08:53:03 +0000 Subject: [issue21162] code in multiprocessing.pool freeze if inside some code from scikit-learn (and probably liblinear) executed on ubuntu 12.04 64 Bit In-Reply-To: <1396716060.12.0.828109902525.issue21162@psf.upfronthosting.co.za> Message-ID: <1431247983.65.0.349547646669.issue21162@psf.upfronthosting.co.za> Ivan K added the comment: This behaviour was reproduced on Ubuntu 12.04 and on Centos 7 (centos image running on vagrant) so I don't expect this is ddistro specific ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 12:19:33 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 10 May 2015 10:19:33 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1431253173.25.0.225535449705.issue24134@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 13:04:06 2015 From: report at bugs.python.org (Roman Rader) Date: Sun, 10 May 2015 11:04:06 +0000 Subject: [issue24156] unit test Message-ID: <1431255846.39.0.865425621117.issue24156@psf.upfronthosting.co.za> Changes by Roman Rader : ---------- nosy: Roman.Rader priority: normal severity: normal status: open title: unit test _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 13:05:39 2015 From: report at bugs.python.org (Roman Rader) Date: Sun, 10 May 2015 11:05:39 +0000 Subject: [issue24156] test.test_ssl.ThreadedTests unit test failed Message-ID: <1431255939.47.0.583767548174.issue24156@psf.upfronthosting.co.za> New submission from Roman Rader: ====================================================================== FAIL: test_server_accept (test.test_ssl.ThreadedTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/roma/Documents/MY/cpython/Lib/test/test_ssl.py", line 2904, in test_server_accept self.assertEqual(peer, client_addr) AssertionError: Tuples differ: ('192.168.1.103', 43446) != ('127.0.0.1', 43446) ---------- components: +Tests title: unit test -> test.test_ssl.ThreadedTests unit test failed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 14:42:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 May 2015 12:42:46 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1431261766.26.0.501621622174.issue24134@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Agree, this change breaks general wrappers around assertRaises, and this breakage is unavoidable. Likely we should rollback changes in maintained releases. The fix in Django doesn't LGTM. It depends on internal detail. More correct fix should look like: def assertRaisesMessage(self, expected_exception, expected_message, *args, **kwargs): return six.assertRaisesRegex(self, expected_exception, re.escape(expected_message), *args, **kwargs) I used special sentinel because it is simple solution, but we should discourage to use this detail outside the module. Proposed patch (for 3.5) uses a little more complex approach, that doesn't attract to use implementation details. In additional, added more strict argument checking, only the msg keyword parameter now is acceptable in context manager mode. Please check changed docstrings. It is possible also to make transition softer. Accept None as a callable and emit the deprecation warning. ---------- resolution: fixed -> stage: resolved -> patch review status: closed -> open Added file: http://bugs.python.org/file39334/assert_raises_args.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 15:03:36 2015 From: report at bugs.python.org (Davin Potts) Date: Sun, 10 May 2015 13:03:36 +0000 Subject: [issue24153] threading/multiprocessing tests fail on chromebook under crouton generated chroots In-Reply-To: <1431212811.34.0.300169078652.issue24153@psf.upfronthosting.co.za> Message-ID: <1431263016.3.0.298043270402.issue24153@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 16:10:25 2015 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 10 May 2015 14:10:25 +0000 Subject: [issue24157] test_urandom_fd_reopened failure on Mac OS X Message-ID: <1431267025.82.0.688433219235.issue24157@psf.upfronthosting.co.za> New submission from Skip Montanaro: Got this reproducibly on the cpython branch on my Mac (Yosemite 10.10.3). It succeeds on my 3.4 branch, both updated a few minutes ago. Didn't see it already reported: % ./python.exe Lib/test/test_os.py ....s..............................sss.............s....s...........s.......................sssss.sss.s.........ss....................................s........F.......ssssssssssssssssssssss ====================================================================== FAIL: test_urandom_fd_reopened (__main__.URandomFDTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_os.py", line 1273, in test_urandom_fd_reopened self.assertEqual(len(out), 8) AssertionError: 66 != 8 ---------------------------------------------------------------------- Ran 189 tests in 1.352s FAILED (failures=1, skipped=41) ---------- components: Tests messages: 242856 nosy: skip.montanaro priority: normal severity: normal status: open title: test_urandom_fd_reopened failure on Mac OS X versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 16:15:53 2015 From: report at bugs.python.org (Codetrainee) Date: Sun, 10 May 2015 14:15:53 +0000 Subject: [issue24158] Error of the hint of upgrading pip Message-ID: <1431267353.89.0.367147566325.issue24158@psf.upfronthosting.co.za> New submission from Codetrainee: When first running pip built in python 3.4.3 on windows, it will notify you that you should upgrade to 6.1.1 The recommended command is 'pip install --upgrade pip' However, if you run this command, it will uninstall pip as well as fail to upgrade pip. On the official site of pip, it gives the command on windows - 'python -m pip install -U pip', which runs perfectly. ---------- components: Installation messages: 242857 nosy: codetrainee priority: normal severity: normal status: open title: Error of the hint of upgrading pip type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 16:22:25 2015 From: report at bugs.python.org (Alex Gaynor) Date: Sun, 10 May 2015 14:22:25 +0000 Subject: [issue24158] Error of the hint of upgrading pip In-Reply-To: <1431267353.89.0.367147566325.issue24158@psf.upfronthosting.co.za> Message-ID: <1431267745.3.0.714476225263.issue24158@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +dstufft, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 16:34:20 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 10 May 2015 14:34:20 +0000 Subject: [issue24159] Misleading TypeError when pickling bytes to a file opened as text Message-ID: <1431268460.0.0.240754621807.issue24159@psf.upfronthosting.co.za> New submission from Jason R. Coombs: I had a piece of code which I distilled to this: import pickle with open('out.pickle', 'w') as out: pickle.dump(out, b'data') Running that code raises this error: TypeError: must be str, not bytes The error is raised at the dump call with no additional context. Based on the error, my reaction is to think that pickled doesn't support bytes objects in pickles. On further examination, it's not actually that the bytes cannot be pickled, but that the 'dump' call requires that the file be opened in binary mode ('wb'), but because of the error message essentially says "expecting a text string" and because it's unclear that the error is raised during the write to the stream and because the JSON library expects an output stream to be opened in text mode, the error message is misleading. At least [two other people think the behavior could be clearer](http://stackoverflow.com/questions/13906623/using-pickle-dump-typeerror-must-be-str-not-bytes#comment43761528_13906715). Would it be possible and reasonable to trap a TypeError at the call to `.write` and replace or augment the message with something like "file must be opened in binary mode"? On second thought, perhaps the culprit isn't pickle here, but the stream writer. Perhaps the `.write` method should provide a clearer message indicating the context at which it's expecting str and not bytes. ---------- components: IO messages: 242858 nosy: jason.coombs priority: low severity: normal status: open title: Misleading TypeError when pickling bytes to a file opened as text type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 16:48:39 2015 From: report at bugs.python.org (Paul Moore) Date: Sun, 10 May 2015 14:48:39 +0000 Subject: [issue17620] Python interactive console doesn't use sys.stdin for input In-Reply-To: <1364921954.86.0.527255608282.issue17620@psf.upfronthosting.co.za> Message-ID: <1431269319.43.0.263556254653.issue17620@psf.upfronthosting.co.za> Changes by Paul Moore : ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 17:21:43 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 10 May 2015 15:21:43 +0000 Subject: [issue19873] There is a duplicate function in Lib/test/test_pathlib.py In-Reply-To: <1386059449.85.0.979457911898.issue19873@psf.upfronthosting.co.za> Message-ID: <1431271303.27.0.122863045949.issue19873@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can we have a formal commit review please as Jessica's comment in msg212966 that the patch looked good was over one year ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 18:21:44 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 10 May 2015 16:21:44 +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: <1431274904.9.0.651865353913.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Review sent - very nice work on this Yury. Thanks a lot, Nick! Highlights: > * I concur with Stefan that we should have a full PyCoroutineMethods struct at the C level, with a "tp_as_coroutine" pointer to that replacing the current tp_reserved slot Do you think that tp_as_async is a better name? (I explained my point of view in code review comments) Also, do we need slots for __aenter__ and __aexit__? We don't have slots for regular context manager protocol, fwiw. > * I also concur with Stefan about adding a Coroutine ABC I will. We definitely need it. > * PyType_FromSpec (and typeslots.h) will need updating once we agree on a slot structure (with my recommendation being "define C level slots for all of the new PEP 492 methods") > * I found CO_COROUTINE/CO_NATIVE_COROUTINE confusing as a reader of the implementation, as they only told me how the objects were defined, rather than telling me why I should care. Based on what I gleaned of their intended purpose from reading the implementation, I suggest switching this to instead use CO_COROUTINE (set for all coroutines, regardless of how they were defined) and CO_ITERABLE_COROUTINE (set only for those coroutines that also support iteration), and adjusting the naming of other APIs accordingly. I agree that CO_COROUTINE is something that we should use for 'async def' functions (instead of CO_NATIVE_COROUTINE). However, CO_ITERABLE_COROUTINE sounds a bit odd to me, as generator-based coroutines (at least in asyncio) aren't supposed to be iterated over. How about CO_GENBASED_COROUTINE flag? > * I found the names of the WITH_CLEANUP_ENTER and WITH_CLEANUP_EXIT bytecodes misleading, as they don't refer to the corresponding context management phases - they're both related to the "exit" phase. WITH_CLEANUP_START and WITH_CLEANUP_FINISH should be clearer for readers (both of the implementation and of the disassembled bytecode). Big +1. Your names are much better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 18:30:17 2015 From: report at bugs.python.org (ppperry) Date: Sun, 10 May 2015 16:30:17 +0000 Subject: [issue24160] Pdb sometimes crashes when trying to remove a breakpoint defined in a different debugger sessoon Message-ID: <1431275416.99.0.134014878289.issue24160@psf.upfronthosting.co.za> New submission from ppperry: >>> import pdb, test3 >>> pdb.run("reload(test3)") > (1)() (Pdb) s --Call-- > c:\documents and settings\perry\desktop\coding_projects\python\test3.py(1)() -> foo = 7789 (Pdb) b 2 Breakpoint 1 at c:\documents and settings\perry\desktop\coding_projects\python\test3.py:2 (Pdb) c > c:\documents and settings\perry\desktop\coding_projects\python\test3.py(2)() -> bar = 7788 (Pdb) c >>> pdb.run("reload(test3)") > (1)() (Pdb) s --Call-- > c:\documents and settings\perry\desktop\coding_projects\python\test3.py(1)() -> foo = 7789 (Pdb) b 1 Breakpoint 2 at c:\documents and settings\perry\desktop\coding_projects\python\test3.py:1 (Pdb) cl 1 Traceback (most recent call last): File "", line 1, in pdb.run("reload(test3)") File "C:\Python27\lib\pdb.py", line 1238, in run Pdb().run(statement, globals, locals) File "C:\Python27\lib\bdb.py", line 400, in run exec cmd in globals, locals File "", line 1, in File "test3.py", line 1, in foo = 7789 File "C:\Python27\lib\bdb.py", line 51, in trace_dispatch return self.dispatch_call(frame, arg) File "C:\Python27\lib\bdb.py", line 80, in dispatch_call self.user_call(frame, arg) File "C:\Python27\lib\pdb.py", line 148, in user_call self.interaction(frame, None) File "C:\Python27\lib\pdb.py", line 210, in interaction self.cmdloop() File "C:\Python27\lib\cmd.py", line 142, in cmdloop stop = self.onecmd(line) File "C:\Python27\lib\pdb.py", line 279, in onecmd return cmd.Cmd.onecmd(self, line) File "C:\Python27\lib\cmd.py", line 221, in onecmd return func(arg) File "C:\Python27\lib\pdb.py", line 622, in do_clear err = self.clear_bpbynumber(i) File "C:\Python27\lib\bdb.py", line 297, in clear_bpbynumber self._prune_breaks(bp.file, bp.line) File "C:\Python27\lib\bdb.py", line 268, in _prune_breaks self.breaks[filename].remove(lineno) ValueError: list.remove(x): x not in list Running the same code without first defining a breakpoint (in the second debugger instance) raises KeyError: [path to test3.py] on the same lien The contents of test3.py are irrelevant, as long as it is at least two lines long and syntactically correct. ---------- components: Library (Lib) messages: 242861 nosy: georg.brandl, ppperry priority: normal severity: normal status: open title: Pdb sometimes crashes when trying to remove a breakpoint defined in a different debugger sessoon type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 19:08:15 2015 From: report at bugs.python.org (Jon Clements) Date: Sun, 10 May 2015 17:08:15 +0000 Subject: [issue24159] Misleading TypeError when pickling bytes to a file opened as text In-Reply-To: <1431268460.0.0.240754621807.issue24159@psf.upfronthosting.co.za> Message-ID: <1431277695.84.0.55308825329.issue24159@psf.upfronthosting.co.za> Changes by Jon Clements : ---------- nosy: +joncle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 19:40:40 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 10 May 2015 17:40:40 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1431274904.9.0.651865353913.issue24017@psf.upfronthosting.co.za> Message-ID: Andrew Svetlov added the comment: On Sun, May 10, 2015 at 7:21 PM, Yury Selivanov wrote: > > Yury Selivanov added the comment: > >> Review sent - very nice work on this Yury. > > Thanks a lot, Nick! > > Highlights: > >> * I concur with Stefan that we should have a full PyCoroutineMethods struct at the C level, with a "tp_as_coroutine" pointer to that replacing the current tp_reserved slot > > Do you think that tp_as_async is a better name? (I explained my point of view in code review comments) > > Also, do we need slots for __aenter__ and __aexit__? We don't have slots for regular context manager protocol, fwiw. > >> * I also concur with Stefan about adding a Coroutine ABC > > I will. We definitely need it. > >> * PyType_FromSpec (and typeslots.h) will need updating once we agree on a slot structure (with my recommendation being "define C level slots for all of the new PEP 492 methods") > >> * I found CO_COROUTINE/CO_NATIVE_COROUTINE confusing as a reader of the implementation, as they only told me how the objects were defined, rather than telling me why I should care. Based on what I gleaned of their intended purpose from reading the implementation, I suggest switching this to instead use CO_COROUTINE (set for all coroutines, regardless of how they were defined) and CO_ITERABLE_COROUTINE (set only for those coroutines that also support iteration), and adjusting the naming of other APIs accordingly. > > I agree that CO_COROUTINE is something that we should use for 'async def' functions (instead of CO_NATIVE_COROUTINE). However, CO_ITERABLE_COROUTINE sounds a bit odd to me, as generator-based coroutines (at least in asyncio) aren't supposed to be iterated over. How about CO_GENBASED_COROUTINE flag? > Maybe CO_ASYNC_COROUTINE and CO_OLDSTYLE_COROUTINE? This is wild proposal, feel free to ignore it. > >> * I found the names of the WITH_CLEANUP_ENTER and WITH_CLEANUP_EXIT bytecodes misleading, as they don't refer to the corresponding context management phases - they're both related to the "exit" phase. WITH_CLEANUP_START and WITH_CLEANUP_FINISH should be clearer for readers (both of the implementation and of the disassembled bytecode). > > Big +1. Your names are much better. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 21:10:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 May 2015 19:10:28 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <20150510191025.8141.46561@psf.io> Roundup Robot added the comment: New changeset 787cc3d1d3af by Yury Selivanov in branch 'default': Issue #22906: Do incref before SetCause/SetContext https://hg.python.org/cpython/rev/787cc3d1d3af ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 22:45:39 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 10 May 2015 20:45:39 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <1431290739.01.0.228657201778.issue23970@psf.upfronthosting.co.za> Steve Dower added the comment: Any further comments on this? I'd like to get it in for beta (though I don't believe it's covered by feature freeze). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 22:48:08 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 10 May 2015 20:48:08 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1431290888.74.0.487944247288.issue23955@psf.upfronthosting.co.za> Steve Dower added the comment: Any further comments/bikeshedding on the applocal parameter? I still need to do some docs, but I want the basic design agreed upon first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 22:55:34 2015 From: report at bugs.python.org (behzad nouri) Date: Sun, 10 May 2015 20:55:34 +0000 Subject: [issue24161] PyIter_Check returns false positive for objects of type instance Message-ID: <1431291334.61.0.842611161748.issue24161@psf.upfronthosting.co.za> New submission from behzad nouri: - python 2 only, not reproducible on python 3 Attached file makes an extension module which just returns PyIter_Check value on passed object. Calling the function with an object of type "instance" returns true, even though the object is not iterator: >>> import spam >>> class Foo: ... pass ... >>> foo = Foo() >>> type(foo) >>> spam.isiter(foo) # <<<< ?! 1 >>> next(foo) TypeError: instance has no next() method ---------- components: Interpreter Core files: spammodule.c messages: 242866 nosy: behzad.nouri priority: normal severity: normal status: open title: PyIter_Check returns false positive for objects of type instance type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file39335/spammodule.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 23:03:51 2015 From: report at bugs.python.org (Alex Lord) Date: Sun, 10 May 2015 21:03:51 +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: <1431291831.15.0.636249224449.issue16864@psf.upfronthosting.co.za> Alex Lord added the comment: Updated the patch to have a versionchanged for lastrowid in Doc/Library/sqlite3.rst and Doc/whatsnew/3.5.rst One thing of note is that I wasn't able to get the indentation to be on the same level for sqlite3.rst (it would either intent the description text or the versionchange text). Now that I'm actually starting to understand the dbapi and sqlite3 I've come to the conclusion that the lastrowid method should update the lastrowid for the INSERT OR ROLLBACK, INSERT OR ABORT, INSERT OR FAIL, INSERT OR IGNORE statements as well as the INSERT and INSERT OR REPLACE statements. I'm unsure how hard or simple supporting those statements will be The code in question is 704 Py_DECREF(self->lastrowid);$ 705 if (!multiple && statement_type == STATEMENT_INSERT) {$ 706 sqlite_int64 lastrowid;$ 707 Py_BEGIN_ALLOW_THREADS$ 708 lastrowid = sqlite3_last_insert_rowid(self->connection->db);$ 709 Py_END_ALLOW_THREADS$ 710 self->lastrowid = _pysqlite_long_from_int64(lastrowid); And the difficulty will be if sqlite3_last_insert_rowid (line 708) does or doesn't return a row id if the OR STATEMENT portion of those inserts are triggered. The Problem I'm having is that when I tried to find sqlite3_last_insert_rowid in the Modules/_sqlite directory I got nothing $ grep -r "sqlite3_last_insert_rowid" Modules/_sqlite/ Modules/_sqlite//cursor.c: lastrowid = sqlite3_last_insert_rowid(self->connection->db); When I pulled the grep out to the entire cpython repository $ grep -r "sqlite3_last_insert_rowid" . Binary file ./build/lib.macosx-10.10-x86_64-3.5-pydebug/_sqlite3.cpython-35dm-darwin.so matches Binary file ./build/lib.macosx-10.10-x86_64-3.5-pydebug/_sqlite3.so matches Binary file ./build/temp.macosx-10.10-x86_64-3.5-pydebug/Users/alexlord/mercurial/cpython/Modules/_sqlite/cursor.o matches ./Modules/_sqlite/cursor.c: lastrowid = sqlite3_last_insert_rowid(self->connection->db); I still didn't find anything and I'm not sure where to go from here. ---------- Added file: http://bugs.python.org/file39336/sqlite_lastrowid_35.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 23:16:58 2015 From: report at bugs.python.org (Alex Lord) Date: Sun, 10 May 2015 21:16:58 +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: <1431292618.69.0.9172957477.issue16864@psf.upfronthosting.co.za> Alex Lord added the comment: Thanks for Alex_gayner and lifeless. They pointed out the sqlite3_last_row_id is part of the sqlite3 module itself (not cpython). https://www.sqlite.org/c3ref/last_insert_rowid.html According the documentation we can expect that if a constraint stops an insertion then the lostrowid is not modified. As such the changes required to add full INSERT OR CONDITION support for last row id is unit tests for each statement and changing the conditional to recognize all insert cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 10 23:25:37 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 10 May 2015 21:25:37 +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: <1431293137.41.0.020664608738.issue24017@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- dependencies: +add a Generator ABC _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 00:36:02 2015 From: report at bugs.python.org (Donald Stufft) Date: Sun, 10 May 2015 22:36:02 +0000 Subject: [issue24158] Error of the hint of upgrading pip In-Reply-To: <1431267353.89.0.367147566325.issue24158@psf.upfronthosting.co.za> Message-ID: <1431297362.72.0.601932131675.issue24158@psf.upfronthosting.co.za> Donald Stufft added the comment: Hey, This is actually a message that comes from a third party component, pip in this case. I've opened up https://github.com/pypa/pip/issues/2773 with the pip project and suggest that further discussion/tracking happen there. It will be picked up by Python automatically when it gets fixed in pip and released and updated in Python. ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 00:50:11 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 10 May 2015 22:50:11 +0000 Subject: [issue24161] PyIter_Check returns false positive for objects of type instance In-Reply-To: <1431291334.61.0.842611161748.issue24161@psf.upfronthosting.co.za> Message-ID: <1431298211.46.0.806715938742.issue24161@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The PyIter_Check() macro in Include/abstract.h does a quick test to see whether the tp_iternext slot is null or marked as not implemented. That works for builtin types but not for user defined classes (heap types). Old-style instances, see Objects/classobject.c::instance_iternext(), all define iternext with code that attempts lookup and call to the next() method, and if not it is not found, raises the TypeError you are seeing. The conflict is that PyIter_Check() aims to be a fast check of a static slot entry while instance_iternext() aims for a dynamic call-it-and-see-if-it-works check much like PyObject_HasAttr() does. Since this code is very old (back to Python 2.2) and has been mostly harmless (as far as we know), one resolution would be to just document this as a known limitation of PyIter_Check(). Rather than using PyIter_Check(), extensions should just call next() on object and see whether it succeeds. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 01:21:30 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 10 May 2015 23:21:30 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <1431300090.72.0.193282310667.issue15027@psf.upfronthosting.co.za> Mark Lawrence added the comment: As this appears to be a performance improvement only can it go into 3.5 or do we wait for 3.x? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 01:23:56 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 May 2015 23:23:56 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1431300236.62.0.609189760996.issue24134@psf.upfronthosting.co.za> R. David Murray added the comment: Yeah, the general case of wrappers is something I hadn't considered. Probably we should go the deprecation route. Robert, what's your opinion? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 01:24:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 May 2015 23:24:51 +0000 Subject: [issue21800] Implement RFC 6855 (IMAP Support for UTF-8) in imaplib. In-Reply-To: <1404175815.98.0.684783714649.issue21800@psf.upfronthosting.co.za> Message-ID: <20150510232448.14368.79327@psf.io> Roundup Robot added the comment: New changeset 195343b5e64f by R David Murray in branch 'default': #21800: Add RFC 6855 support to imaplib. https://hg.python.org/cpython/rev/195343b5e64f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 01:29:26 2015 From: report at bugs.python.org (behzad nouri) Date: Sun, 10 May 2015 23:29:26 +0000 Subject: [issue24161] PyIter_Check returns false positive for objects of type instance In-Reply-To: <1431291334.61.0.842611161748.issue24161@psf.upfronthosting.co.za> Message-ID: <1431300566.37.0.270341851913.issue24161@psf.upfronthosting.co.za> behzad nouri added the comment: > That works for builtin types but not for user defined classes > Rather than using PyIter_Check(), extensions should just call next() on object and see whether it succeeds but then, what would be the use case of PyIter_Check outside of python core? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 02:14:00 2015 From: report at bugs.python.org (Matthias Klose) Date: Mon, 11 May 2015 00:14:00 +0000 Subject: [issue24162] [2.7 regression] test_asynchat test failure on i586-linux-gnu Message-ID: <1431303240.23.0.685308735341.issue24162@psf.upfronthosting.co.za> New submission from Matthias Klose: I see this on i586-linux-gnu and i686-linux-gnu. Reverting the 95844:fb6c2fbbde34 commit makes the problem go away. python: ../Modules/_collectionsmodule.c:711: deque_del_item: Assertion `i >= 0 && i < (((PyVarObject*)(deque))->ob_size)' failed. Makefile:818: recipe for target 'test' failed make[1]: *** [test] Aborted (core dumped) ---------- components: Library (Lib) messages: 242875 nosy: benjamin.peterson, doko, rhettinger priority: release blocker severity: normal status: open title: [2.7 regression] test_asynchat test failure on i586-linux-gnu type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 02:56:40 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 11 May 2015 00:56:40 +0000 Subject: [issue21800] Implement RFC 6855 (IMAP Support for UTF-8) in imaplib. In-Reply-To: <1404175815.98.0.684783714649.issue21800@psf.upfronthosting.co.za> Message-ID: <1431305800.56.0.0949461353489.issue21800@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Maciek (and Milan). I tweaked your patch slightly (mostly doc changes...I moved the discussion of the utf8 RFC into the enable method only, and added back the docs for utf8_enabled). I made some review comments about the changes other than that doc reorg that I made before commit, just FYI. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 03:33:02 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 May 2015 01:33:02 +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: <1431307982.56.0.0737430586349.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: New patch is attached. Nick, I think that all of your feedback should be addressed in this patch. Major changes: 1. There are two code flags now: CO_COROUTINE and CO_GENBASED_COROUTINE (I'm OK to use another name, see my older comments). CO_COROUTINE is assigned to all 'async def' code objects. CO_GENBASED_COROUTINE is assigned to generator-based coroutines decorated with types.coroutine(). 2. tp_await renamed to tp_as_async. (I'm OK to use another name, please see my older comment first) PyAsyncMethods struct holds three slots: am_await, am_aiter, am_anext. Implementing am_exit would be tricky, because of how SETUP_WITH opcode is engineered. I'd really prefer to not to add it. 3. collections.abc.Coroutine. 4. etc (all other feedback from you). ---------- Added file: http://bugs.python.org/file39337/await_05.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 03:33:30 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 May 2015 01:33:30 +0000 Subject: [issue24161] PyIter_Check returns false positive for objects of type instance In-Reply-To: <1431291334.61.0.842611161748.issue24161@psf.upfronthosting.co.za> Message-ID: <1431308010.41.0.831246479822.issue24161@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > but then, what would be the use case of PyIter_Check > outside of python core? You could still use it anywhere. It will give a correct result in the cases of extension modules, builtin types, and new-style classes. It will give a false positive in the case of old-style classes. The latter case doesn't seem to be of much consequence (there is a still a TypeError raised when next() is called), so you just find out a bit later than you otherwise would (I believe that is why this is why we haven't gotten a bug report in the 13+ years this code has existed). The feature is imperfect, incomplete and not as useful as it could be. But this ship sailed a long time ago. It is far too late for redesign (and risking unintended breakage). FWIW, PyIter_Check() is used several times in the Python core: sqlite, cPickle, and iter(). In those examples, there seem to be no adverse consequences for the false positive because we still get a TypeError downstream when the actual call is made to next(). ---------- assignee: -> docs at python components: +Documentation -Interpreter Core nosy: +docs at python priority: normal -> low stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 04:00:23 2015 From: report at bugs.python.org (Ilia Kurenkov) Date: Mon, 11 May 2015 02:00:23 +0000 Subject: [issue1818] Add named tuple reader to CSV module In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za> Message-ID: <1431309623.92.0.246685821456.issue1818@psf.upfronthosting.co.za> Ilia Kurenkov added the comment: Friendly reminder that this exists. I know everyone's busy and this is marked as low-priority, but I'm gonna keep bumping this till we add a solution :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 04:01:22 2015 From: report at bugs.python.org (Ilia Kurenkov) Date: Mon, 11 May 2015 02:01:22 +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: <1431309682.18.0.122839792157.issue20362@psf.upfronthosting.co.za> Ilia Kurenkov added the comment: Hi there! I was wondering if anyone had a chance to take a look at this :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 04:25:42 2015 From: report at bugs.python.org (Spencer Stirling) Date: Mon, 11 May 2015 02:25:42 +0000 Subject: [issue24163] shutil.copystat pukes when attribute security.selinux is present Message-ID: <1431311142.46.0.816679575818.issue24163@psf.upfronthosting.co.za> New submission from Spencer Stirling: Using shutil.copytree to copy a directory tree. The source dir lives on a Windows 7 host, however is being accessed from inside a VirtualBox VM as a "shared folder" (using vagrant to manage this whole thing). The destination directory is just a regular linux directory inside the VM. The guest OS is CentOS 5. shutil.copystat dies on this copy. I have tracked the problem down to line 154 in shutil.py: os.setxattr(dst, name, value, follow_symlinks=follow_symlinks) The issue is that the src directory apparently defines the attribute security.selinux, however setxattr doesn't see this attribute in the destination and throws an exception. ---------- components: IO messages: 242881 nosy: sstirlin priority: normal severity: normal status: open title: shutil.copystat pukes when attribute security.selinux is present type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 05:01:29 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 May 2015 03:01:29 +0000 Subject: [issue24163] shutil.copystat fails when attribute security.selinux is present In-Reply-To: <1431311142.46.0.816679575818.issue24163@psf.upfronthosting.co.za> Message-ID: <1431313289.83.0.640133476189.issue24163@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- title: shutil.copystat pukes when attribute security.selinux is present -> shutil.copystat fails when attribute security.selinux is present _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 05:11:00 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 May 2015 03:11:00 +0000 Subject: [issue24161] PyIter_Check returns false positive for objects of type instance In-Reply-To: <1431291334.61.0.842611161748.issue24161@psf.upfronthosting.co.za> Message-ID: <1431313860.65.0.653511093938.issue24161@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +patch Added file: http://bugs.python.org/file39338/doc_iter_check.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 06:04:48 2015 From: report at bugs.python.org (Alex Lord) Date: Mon, 11 May 2015 04:04:48 +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: <1431317088.34.0.714767587832.issue16864@psf.upfronthosting.co.za> Alex Lord added the comment: Went back to test to see if the other statements are covered already. Unit tests show that lastrowid is set properly no matter what form of sqlite insert statement is used. sqlite_lastrowid_35_v2.patch contains the doc changes, unit test changes, and code change. I believe that the latest version of this patch is ready for a code review by a core dev. ---------- Added file: http://bugs.python.org/file39339/sqlite_lastrowid_35_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 06:08:31 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 May 2015 04:08:31 +0000 Subject: [issue18789] XML Vunerability Table Unclear In-Reply-To: <1377008574.91.0.12100936862.issue18789@psf.upfronthosting.co.za> Message-ID: <1431317311.33.0.51037256638.issue18789@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The table would still be more clear with "safe" and "vulnerable" entries. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 08:25:01 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 May 2015 06:25:01 +0000 Subject: [issue24068] statistics module - incorrect results with boolean input In-Reply-To: <1430211206.61.0.689765465928.issue24068@psf.upfronthosting.co.za> Message-ID: <1431325501.75.0.754224354612.issue24068@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 09:47:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 May 2015 07:47:01 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1431330421.42.0.426196564828.issue24134@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file39340/assert_raises_args_deprecation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 09:54:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 May 2015 07:54:17 +0000 Subject: [issue20014] Makes array.array constructor accepts ascii-unicode typecode In-Reply-To: <1387360195.98.0.786950742842.issue20014@psf.upfronthosting.co.za> Message-ID: <1431330857.14.0.294876829023.issue20014@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 09:54:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 May 2015 07:54:27 +0000 Subject: [issue13566] Array objects pickled in 3.x with protocol <=2 are unpickled incorrectly in 2.x In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za> Message-ID: <1431330867.19.0.0169478763928.issue13566@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 10:07:25 2015 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 11 May 2015 08:07:25 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1431331645.14.0.0967952543975.issue1602@psf.upfronthosting.co.za> Nick Coghlan added the comment: It sounds like fixing this properly requires fixing issue 17620 first (so the interactive interpreter actually uses sys.stdin), so I've flagged that as a dependency. ---------- dependencies: +Python interactive console doesn't use sys.stdin for input _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 10:57:43 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 11 May 2015 08:57:43 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects In-Reply-To: <1430929136.04.0.0158927713933.issue24138@psf.upfronthosting.co.za> Message-ID: <1431334663.98.0.820600496674.issue24138@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I like the idea of adding a free list of longs in Python 3, but I think we should extend this somewhat to cover more ground, e.g. by pre-allocating a block of 1 digit long objects, like we did for Python 2 ints, and perhaps allocate up to 4k (= 1 memory page) towards such a free list. The added cache locality of having the data in a pre-allocated block should provide some more performance. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 11:42:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 May 2015 09:42:21 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects In-Reply-To: <1430929136.04.0.0158927713933.issue24138@psf.upfronthosting.co.za> Message-ID: <1431337341.22.0.889973395013.issue24138@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: According to my and Larry's measurements [1] the distribution of created int's by size during running Python tests is: On 32-bit Linux: int 42828741 13.40% 0 425353 0.99% 0.99% 1 21399290 49.96% 50.96% 2 10496856 24.51% 75.47% 3 4873346 11.38% 86.85% 4 1021563 2.39% 89.23% 5 1246444 2.91% 92.14% 6 733676 1.71% 93.85% 7 123074 0.29% 94.14% 8 139203 0.33% 94.47% ... On 64-bit Linux: int 47600237 13.53% 0 294964 0.62% 0.62% 1 36135772 75.92% 76.53% 2 4504046 9.46% 86.00% 3 2109837 4.43% 90.43% 4 1277995 2.68% 93.11% 5 542775 1.14% 94.25% 6 485451 1.02% 95.27% ... 86% of ints have size <= 3 on 32-bit and <= 2 on 64-bit. This is enough to represent 32-bit integers (as in Python 2 int). I think we should support free list not only for 1-digit ints, but at least up to 3 digit on 32-bit build and up to 2 digits on 64-bit build. Other natural limit is 3 digit on 64-bit build (enough to represent 64-bit C long on Linux or pointer on all platforms). Larger integers perhaps are encountered mainly in tests. Pre-allocating a block has a disadvantage. It is hard to free allocated block. The program can create a lot of integers, then drop most of them, and request the memory for other needs, but blocks once allocated for integers would not freed. This is not trivial design decision and should be discussed on Python-Dev and accepted by BDFL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 11:43:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 May 2015 09:43:06 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects In-Reply-To: <1430929136.04.0.0158927713933.issue24138@psf.upfronthosting.co.za> Message-ID: <1431337386.19.0.0621785649283.issue24138@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: [1] http://comments.gmane.org/gmane.comp.python.devel/153078 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 11:59:40 2015 From: report at bugs.python.org (Paul Moore) Date: Mon, 11 May 2015 09:59:40 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1431338380.17.0.112117374972.issue1602@psf.upfronthosting.co.za> Changes by Paul Moore : ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 12:09:17 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 11 May 2015 10:09:17 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects In-Reply-To: <1430929136.04.0.0158927713933.issue24138@psf.upfronthosting.co.za> Message-ID: <1431338957.18.0.392861906509.issue24138@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'd rather stick to the simple freelist approach. People interested in (allegedly) more ambitious designs can open new issues, together with patches to evaluate their efficiency. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 12:10:56 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 11 May 2015 10:10:56 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects In-Reply-To: <1430929136.04.0.0158927713933.issue24138@psf.upfronthosting.co.za> Message-ID: <1431339056.1.0.870616763746.issue24138@psf.upfronthosting.co.za> Larry Hastings added the comment: I'd rather have the general-purpose freelist for ints too. How about we close this issue now, and assuming the freelist for ints goes in we can abandon this approach entirely. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 12:49:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 May 2015 10:49:50 +0000 Subject: [issue24164] Support pickling objects with __new__ with keyword arguments with protocol 2+ Message-ID: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Pickling of objects of classes whose __new__ mandates the use of keyword-only arguments is supported with protocol 4 (using a new opcode NEWOBJ_EX). But it is possible to implement this feature with protocol 2+ (less efficiently than with NEWOBJ_EX). __new_ex__ is pickled as partial(cls.__new__, cls, *args, **kwargs). Pickled data is compatible with older Python releases up to 2.7 (issue5228). Proposed patch adds support of __new__ with keyword arguments with protocols 2 and 3. ---------- components: Extension Modules, Interpreter Core, Library (Lib) files: pickle_new_ex_protocol_2.patch keywords: patch messages: 242890 nosy: alexandre.vassalotti, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Support pickling objects with __new__ with keyword arguments with protocol 2+ type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39341/pickle_new_ex_protocol_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 13:05:13 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 11 May 2015 11:05:13 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects In-Reply-To: <1431337341.22.0.889973395013.issue24138@psf.upfronthosting.co.za> Message-ID: <55508CE5.3070007@egenix.com> Marc-Andre Lemburg added the comment: On 11.05.2015 11:42, Serhiy Storchaka wrote: > > Pre-allocating a block has a disadvantage. It is hard to free allocated block. The program can create a lot of integers, then drop most of them, and request the memory for other needs, but blocks once allocated for integers would not freed. This is not trivial design decision and should be discussed on Python-Dev and accepted by BDFL. True, but if it's only 1-4k RAM, I don't think anyone would mind :-) Python 2 is doing exactly that with 1k RAM for the integer free list. I think it was one of the first free lists ever added to Python, so done in a time when RAM was expensive ;-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 14:36:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 May 2015 12:36:52 +0000 Subject: [issue24138] Speed up range() by caching and modifying long objects In-Reply-To: <1430929136.04.0.0158927713933.issue24138@psf.upfronthosting.co.za> Message-ID: <1431347812.3.0.395914927278.issue24138@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Well, 1-4k RAM can be consumed just after the start up (it's only 100-300 integers) and never freed. What next? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 15:56:54 2015 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 11 May 2015 13:56:54 +0000 Subject: [issue1818] Add named tuple reader to CSV module In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za> Message-ID: <1431352614.29.0.0621929231491.issue1818@psf.upfronthosting.co.za> Skip Montanaro added the comment: I looked at this six years ago. I still haven't found a situation where I pined for a NamedTupleReader. That said, I have no objection to committing it if others, more well-versed in current Python code and NamedTuples than I gives it a pass. Note that I added a couple comments to the csv.py diff, but nobody either updated the code or explained why I was out in the weeds in my comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 15:59:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 May 2015 13:59:29 +0000 Subject: [issue24165] Free list for single-digits ints Message-ID: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch adds free list for single-digit PyLong objects. In Python tests 7% of created objects are ints. 50% of them are 15-bit (single-digit on 32-bit build), 75% of them are 30-bit (single-digit on 64-bit build). See the start of the discussion in issue24138. ---------- components: Interpreter Core files: int_free_list_2.patch keywords: patch messages: 242894 nosy: BreamoreBoy, ethan.furman, larry, lemburg, mark.dickinson, pitrou, rhettinger, scoder, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Free list for single-digits ints type: performance versions: Python 3.5 Added file: http://bugs.python.org/file39342/int_free_list_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 16:15:33 2015 From: report at bugs.python.org (Benjamin Schubert) Date: Mon, 11 May 2015 14:15:33 +0000 Subject: [issue24166] ArgumentParser behavior does not match generated help Message-ID: <1431353733.91.0.614025540349.issue24166@psf.upfronthosting.co.za> New submission from Benjamin Schubert: When creating a ArgumentParser on which we attach a subparser with different options and then add a nargs="+" argument to the initial parser, the command format string generated does not match the behavior. for example it would generate : argparse_error.py [-h] {ls,du} ... vm [vm ...] but only accept one vm. I would suspect a bug when parsing the arguments (as the help meets the desired behavior). Attached is a little script to reproduce the error. Thank you ! ---------- components: Library (Lib) files: argparse_error.py messages: 242895 nosy: tellendil priority: normal severity: normal status: open title: ArgumentParser behavior does not match generated help type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file39343/argparse_error.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 16:16:43 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 11 May 2015 14:16:43 +0000 Subject: [issue24165] Free list for single-digits ints In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za> Message-ID: <1431353803.55.0.991586267695.issue24165@psf.upfronthosting.co.za> Brett Cannon added the comment: Any chance of running hg.python.org/benchmarks to see what kind of performance this would get us? ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 17:23:11 2015 From: report at bugs.python.org (Paul Baker) Date: Mon, 11 May 2015 15:23:11 +0000 Subject: [issue24167] 2.4.X links on www.python.org/downloads/windows point to the wrong files Message-ID: <1431357791.66.0.890349214354.issue24167@psf.upfronthosting.co.za> New submission from Paul Baker: On the "www.python.org/downloads/windows" page, the "Windows x86 MSI installer" links for versions 2.4.4, 2.4.3, 2.4.2 and 2.4.0 point to the IA64 versions of the installers rather than the x86 versions. For example, the 2.4.4 link points to "python-2.4.4.ia64.msi" rather than "python-2.4.4.msi". ---------- components: Installation, Windows messages: 242897 nosy: paul.baker, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: 2.4.X links on www.python.org/downloads/windows point to the wrong files _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 17:28:34 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 May 2015 15:28:34 +0000 Subject: [issue24167] 2.4.X links on www.python.org/downloads/windows point to the wrong files In-Reply-To: <1431357791.66.0.890349214354.issue24167@psf.upfronthosting.co.za> Message-ID: <1431358114.01.0.511543748569.issue24167@psf.upfronthosting.co.za> STINNER Victor added the comment: You should report bugs of the website to https://github.com/python/pythondotorg/issues ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 17:46:20 2015 From: report at bugs.python.org (Paul Baker) Date: Mon, 11 May 2015 15:46:20 +0000 Subject: [issue24167] 2.4.X links on www.python.org/downloads/windows point to the wrong files In-Reply-To: <1431357791.66.0.890349214354.issue24167@psf.upfronthosting.co.za> Message-ID: <1431359180.15.0.409038598578.issue24167@psf.upfronthosting.co.za> Paul Baker added the comment: Done: https://github.com/python/pythondotorg/issues/751 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 18:12:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 May 2015 16:12:08 +0000 Subject: [issue21795] smtpd.SMTPServer should announce 8BITMIME when supported and accept SMTPUTF8 without it In-Reply-To: <1403033401.43.0.395080659803.issue21795@psf.upfronthosting.co.za> Message-ID: <20150511161204.76619.98384@psf.io> Roundup Robot added the comment: New changeset e34ed02738bf by R David Murray in branch 'default': #21795: advertise 8BITMIME if decode_data is False. https://hg.python.org/cpython/rev/e34ed02738bf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 18:13:11 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 11 May 2015 16:13:11 +0000 Subject: [issue21795] smtpd.SMTPServer should announce 8BITMIME when supported and accept SMTPUTF8 without it In-Reply-To: <1403033401.43.0.395080659803.issue21795@psf.upfronthosting.co.za> Message-ID: <1431360791.61.0.613947188772.issue21795@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Milan. I tweaked some things and tried to sort out the docs for all the changes we have made to smtpd. If you see anything I screwed up let me know. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 18:20:04 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 11 May 2015 16:20:04 +0000 Subject: [issue24167] 2.4.X links on www.python.org/downloads/windows point to the wrong files In-Reply-To: <1431357791.66.0.890349214354.issue24167@psf.upfronthosting.co.za> Message-ID: <1431361204.59.0.137799277595.issue24167@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 19:06:32 2015 From: report at bugs.python.org (paul j3) Date: Mon, 11 May 2015 17:06:32 +0000 Subject: [issue24166] ArgumentParser behavior does not match generated help In-Reply-To: <1431353733.91.0.614025540349.issue24166@psf.upfronthosting.co.za> Message-ID: <1431363992.05.0.573743703632.issue24166@psf.upfronthosting.co.za> paul j3 added the comment: I wouldn't describe this as bug, just a nuance on how parsers and subparsers play together. To the main parser, the subparser argument looks like another positional. It allocates strings to it and any following positionals based on their respective 'nargs'. The nargs for a subparser is 'A...' (argparse.PARSER), which is similar to '+' (it takes one or more strings) parser2=ArgumentParser() parser2.add_argument('arg1',nargs='A...') parser2.add_argument('arg2',nargs='+') parser2.parse_args(['create','test','test2']) produces Namespace(arg1=['create', 'test'], arg2=['test2']) Notice how 2 of the strings are allocated to arg1, and only 1 to arg2. arg2 is happy with just 1, so arg1 gets the rest. In your example it's the subparser that is issuing the 'unrecognized arguments' message, because it doesn't have a positional argument that would take it. Having more than one positional that takes are variable number of arguments is tricky. I find it helpful to think in terms of how `re` would handle a pattern like `(A+)(A*)(A)`. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 19:19:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 May 2015 17:19:15 +0000 Subject: [issue24155] Optimize heapify for better cache utililzation In-Reply-To: <1431233548.51.0.135942153976.issue24155@psf.upfronthosting.co.za> Message-ID: <20150511171912.8936.93644@psf.io> Roundup Robot added the comment: New changeset db87591fce01 by Raymond Hettinger in branch 'default': Issue #24155: Optimize heapify for better cache utililzation. https://hg.python.org/cpython/rev/db87591fce01 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 19:19:28 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 May 2015 17:19:28 +0000 Subject: [issue24155] Optimize heapify for better cache utililzation In-Reply-To: <1431233548.51.0.135942153976.issue24155@psf.upfronthosting.co.za> Message-ID: <1431364768.89.0.880223899348.issue24155@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 19:22:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 May 2015 17:22:35 +0000 Subject: [issue24161] PyIter_Check returns false positive for objects of type instance In-Reply-To: <1431291334.61.0.842611161748.issue24161@psf.upfronthosting.co.za> Message-ID: <20150511172231.76621.59091@psf.io> Roundup Robot added the comment: New changeset 0f7795edca65 by Raymond Hettinger in branch '2.7': Issue #24161: Document that PyIter_Check() returns false positives for old-style instances. https://hg.python.org/cpython/rev/0f7795edca65 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 19:24:49 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 May 2015 17:24:49 +0000 Subject: [issue24161] PyIter_Check returns false positive for objects of type instance In-Reply-To: <1431291334.61.0.842611161748.issue24161@psf.upfronthosting.co.za> Message-ID: <1431365089.01.0.794549091973.issue24161@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 19:26:42 2015 From: report at bugs.python.org (paul j3) Date: Mon, 11 May 2015 17:26:42 +0000 Subject: [issue24166] ArgumentParser behavior does not match generated help In-Reply-To: <1431353733.91.0.614025540349.issue24166@psf.upfronthosting.co.za> Message-ID: <1431365202.56.0.423660443602.issue24166@psf.upfronthosting.co.za> paul j3 added the comment: And the behavior does match the help {ls,du} ... vm [vm ...] It's just that one of the strings is allocated to the first `...`, whereas you expected it to be put in the second. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 19:48:12 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 11 May 2015 17:48:12 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <1431366492.37.0.569543886621.issue23970@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Why are you removing the mcvs9compiler.py file when at the same time your are referencing it in the msvccompiler.py doc string ? --- a/Lib/distutils/msvccompiler.py +++ b/Lib/distutils/msvccompiler.py @@ -1,201 +1,120 @@ """distutils.msvccompiler Contains MSVCCompiler, an implementation of the abstract CCompiler class -for the Microsoft Visual Studio. +for Microsoft Visual Studio 2015. + +The module is compatible with VS 2015 and later. You can find legacy support +for older versions in distutils.msvc9compiler and distutils.msvccompiler. """ IMO, it would be better and more in line with the b/w aspects of distutils, to move the VS15 support into a new msvc14compiler.py which is then imported by msvccompiler.py at the end (much like this was done for msvc9compiler.py. That way we can maintain compatibility with existing code which uses stuff from those legacy modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 20:25:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 May 2015 18:25:03 +0000 Subject: [issue24165] Free list for single-digits ints In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za> Message-ID: <1431368703.56.0.724122560352.issue24165@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Report on Linux xarax 3.13.0-52-generic #86-Ubuntu SMP Mon May 4 04:32:15 UTC 2015 i686 athlon Total CPU cores: 2 ### 2to3 ### 15.796000 -> 15.652000: 1.01x faster ### etree_generate ### Min: 0.687270 -> 0.715218: 1.04x slower Avg: 0.698458 -> 0.722657: 1.03x slower Significant (t=-9.02) Stddev: 0.01846 -> 0.00431: 4.2808x smaller ### etree_iterparse ### Min: 1.145829 -> 1.117311: 1.03x faster Avg: 1.159865 -> 1.129438: 1.03x faster Significant (t=21.95) Stddev: 0.00835 -> 0.00513: 1.6297x smaller ### etree_parse ### Min: 0.816515 -> 0.867189: 1.06x slower Avg: 0.825879 -> 0.877618: 1.06x slower Significant (t=-48.87) Stddev: 0.00405 -> 0.00630: 1.5556x larger ### etree_process ### Min: 0.542221 -> 0.565161: 1.04x slower Avg: 0.548276 -> 0.569324: 1.04x slower Significant (t=-28.38) Stddev: 0.00380 -> 0.00361: 1.0540x smaller ### json_load ### Min: 1.020657 -> 0.995001: 1.03x faster Avg: 1.025593 -> 0.998038: 1.03x faster Significant (t=28.37) Stddev: 0.00503 -> 0.00468: 1.0738x smaller ### nbody ### Min: 0.577393 -> 0.588626: 1.02x slower Avg: 0.578246 -> 0.590917: 1.02x slower Significant (t=-43.51) Stddev: 0.00037 -> 0.00203: 5.4513x larger ### regex_v8 ### Min: 0.123794 -> 0.119950: 1.03x faster Avg: 0.124631 -> 0.121131: 1.03x faster Significant (t=4.92) Stddev: 0.00340 -> 0.00371: 1.0917x larger The following not significant results are hidden, use -v to show them: django_v2, fastpickle, fastunpickle, json_dump_v2, tornado_http. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 21:03:35 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 11 May 2015 19:03:35 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <1431371015.89.0.144384373429.issue23970@psf.upfronthosting.co.za> Steve Dower added the comment: Simply because I didn't update the doc string :) I don't really want to put a version number on this file, since it isn't MSVC 14.0 specific - it's MSVC 14 and all future versions. We don't check the build version anymore, though get_build_version() is still there (hardcoded to 14.0) As you say, the existing modules are legacy, so I wonder what would be useful from them? They refer to compilers that aren't available and won't be useful for Python 3.5 to the extent that I'd really like to discourage using them. The modules themselves are undocumented and were not available on other platforms, so any code using them should be protecting themselves against ImportError already, and they're going to be broken anyway so they may as well break early. But my main question is why would you still need the old versions around, given that compatibility is already broken? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 21:16:31 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 11 May 2015 19:16:31 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1431371015.89.0.144384373429.issue23970@psf.upfronthosting.co.za> Message-ID: <5551000A.5030505@egenix.com> Marc-Andre Lemburg added the comment: On 11.05.2015 21:03, Steve Dower wrote: > > Steve Dower added the comment: > > Simply because I didn't update the doc string :) > > I don't really want to put a version number on this file, since it isn't MSVC 14.0 specific - it's MSVC 14 and all future versions. We don't check the build version anymore, though get_build_version() is still there (hardcoded to 14.0) > > As you say, the existing modules are legacy, so I wonder what would be useful from them? They refer to compilers that aren't available and won't be useful for Python 3.5 to the extent that I'd really like to discourage using them. The modules themselves are undocumented and were not available on other platforms, so any code using them should be protecting themselves against ImportError already, and they're going to be broken anyway so they may as well break early. > > But my main question is why would you still need the old versions around, given that compatibility is already broken? In Python 2, distutils could be easily be used on earlier Python versions, simplifying the amount of work you'd need to do in your setup.py to address differences between the various Python versions you wanted to support. I don't know what the deal is for Python 3. Apart from that, it may be necessary to compile some parts of C extensions with older compilers. Probably a rare case, but then again: what do we gain by removing the old code ? Note that VC9 was handled in the same way: it was added to the set rather than replacing it. That was done in the Python 2 series, though, where the above guarantee was used as basis, so things may be different for Python 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 21:57:07 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 11 May 2015 19:57:07 +0000 Subject: [issue24165] Free list for single-digits ints In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za> Message-ID: <1431374227.63.0.323029074394.issue24165@psf.upfronthosting.co.za> Stefan Behnel added the comment: I got similar results on 64bits for my original patch (very similar to what Serhiy used now). The numbers are not really conclusive. Report on Linux leppy 3.13.0-46-generic #77-Ubuntu SMP Mon Mar 2 18:23:39 UTC 2015 x86_64 x86_64 Total CPU cores: 4 ### 2to3 ### 6.885334 -> 6.829016: 1.01x faster ### etree_process ### Min: 0.249504 -> 0.253876: 1.02x slower Med: 0.252730 -> 0.258274: 1.02x slower Avg: 0.254332 -> 0.261100: 1.03x slower Significant (t=-5.99) Stddev: 0.00478 -> 0.00640: 1.3391x larger ### fastpickle ### Min: 0.402085 -> 0.416765: 1.04x slower Med: 0.405595 -> 0.424729: 1.05x slower Avg: 0.405882 -> 0.429707: 1.06x slower Significant (t=-12.45) Stddev: 0.00228 -> 0.01334: 5.8585x larger ### json_dump_v2 ### Min: 2.611031 -> 2.522507: 1.04x faster Med: 2.678369 -> 2.544085: 1.05x faster Avg: 2.706089 -> 2.552111: 1.06x faster Significant (t=10.40) Stddev: 0.09551 -> 0.04290: 2.2265x smaller ### nbody ### Min: 0.217901 -> 0.214968: 1.01x faster Med: 0.224340 -> 0.216781: 1.03x faster Avg: 0.226012 -> 0.216981: 1.04x faster Significant (t=6.03) Stddev: 0.01049 -> 0.00142: 7.4102x smaller ### regex_v8 ### Min: 0.040856 -> 0.039377: 1.04x faster Med: 0.041847 -> 0.040082: 1.04x faster Avg: 0.042468 -> 0.040726: 1.04x faster Significant (t=3.20) Stddev: 0.00291 -> 0.00252: 1.1549x smaller The following not significant results are hidden, use -v to show them: etree_generate, etree_iterparse, etree_parse, fastunpickle, json_load. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 21:59:06 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 11 May 2015 19:59:06 +0000 Subject: [issue24165] Free list for single-digits ints In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za> Message-ID: <1431374346.05.0.29103633544.issue24165@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You probably need a workload that uses integers quite heavily to see a difference. And even then, it would also depend on the allocation pattern. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 21:59:43 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 May 2015 19:59:43 +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: <1431374383.16.0.0111450013548.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, Guido, Updated patch attached. ---------- Added file: http://bugs.python.org/file39344/await_06.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 22:06:25 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 11 May 2015 20:06:25 +0000 Subject: [issue24165] Free list for single-digits ints In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za> Message-ID: <1431374785.33.0.926833556173.issue24165@psf.upfronthosting.co.za> Stefan Behnel added the comment: Well, as I've shown in issue 24076 (I'm copying the numbers here), even simple arithmetic expressions can benefit from a free-list. Basically anything that uses temporary integer results. Original: $ ./python -m timeit 'sum(range(1, 100000))' 1000 loops, best of 3: 1.86 msec per loop $ ./python -m timeit -s 'l = list(range(1000, 10000))' '[(i*2+5) // 7 for i in l]' 1000 loops, best of 3: 1.05 msec per loop With freelist: $ ./python -m timeit 'sum(range(1, 100000))' 1000 loops, best of 3: 1.52 msec per loop $ ./python -m timeit -s 'l = list(range(1000, 10000))' '[(i*2+5) // 7 for i in l]' 1000 loops, best of 3: 931 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 22:08:55 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 11 May 2015 20:08:55 +0000 Subject: [issue24076] sum() several times slower on Python 3 In-Reply-To: <1430332618.4.0.236828536627.issue24076@psf.upfronthosting.co.za> Message-ID: <1431374935.52.0.622731768263.issue24076@psf.upfronthosting.co.za> Stefan Behnel added the comment: Issue 24165 was created to pursue the path of a free-list for PyLong objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 22:22:10 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 11 May 2015 20:22:10 +0000 Subject: [issue24165] Free list for single-digits ints In-Reply-To: <1431374785.33.0.926833556173.issue24165@psf.upfronthosting.co.za> Message-ID: <55510F70.80900@free.fr> Antoine Pitrou added the comment: Yes, but I meant a realistic workload, not a micro-benchmark. There are tons of ways to make Python look faster on micro-benchmarks but that have no relevant impact on actual applications. (note that I'm still sympathetic to the freelist approach) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 23:20:52 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 11 May 2015 21:20:52 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <1431379252.35.0.9121195899.issue23970@psf.upfronthosting.co.za> Steve Dower added the comment: I guess we need a third opinion. For me, the subclasses of CCompiler are undocumented and not a guaranteed interface (people using them directly are consenting adults). They're also an eyesore, so if I can clean them up without breaking the CCompiler interface (or minor version upgrades) then I should. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 23:23:04 2015 From: report at bugs.python.org (Maciej Szulik) Date: Mon, 11 May 2015 21:23:04 +0000 Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime Message-ID: <1431379384.81.0.913736288723.issue1100942@psf.upfronthosting.co.za> Maciej Szulik added the comment: Berker per your comment updated patch changing those two new methods (namely date.strptime and time.strptime) to be classmethod and not staticmethods. ---------- Added file: http://bugs.python.org/file39345/issue1100942.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 23:31:19 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 11 May 2015 21:31:19 +0000 Subject: [issue24157] test_urandom_fd_reopened failure on Mac OS X In-Reply-To: <1431267025.82.0.688433219235.issue24157@psf.upfronthosting.co.za> Message-ID: <1431379879.27.0.764732433694.issue24157@psf.upfronthosting.co.za> Ned Deily added the comment: Skip, looking at the test, it seems likely that there is unexpected writing to stdout in the subprocess. Can you add a print(out) in the test (around test_os.py:1273) to see what is actually being written on your machine? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 23:34:10 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 11 May 2015 21:34:10 +0000 Subject: [issue24159] Misleading TypeError when pickling bytes to a file opened as text In-Reply-To: <1431268460.0.0.240754621807.issue24159@psf.upfronthosting.co.za> Message-ID: <1431380050.71.0.147340286533.issue24159@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +alexandre.vassalotti, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 23:39:36 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 11 May 2015 21:39:36 +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: <1431380376.44.0.572297136463.issue16864@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ghaering stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 23:43:38 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 11 May 2015 21:43:38 +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: <1431380618.13.0.166584763805.issue20362@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 23:43:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 May 2015 21:43:57 +0000 Subject: [issue24165] Free list for single-digits ints In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za> Message-ID: <1431380637.13.0.126024517509.issue24165@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, sorry, Stefan, I didn't noticed your patch. I wouldn't write my patch if noticed your patch. int_free_list_2.patch adds free list only for single-digits ints. Following patch adds free list for multi-digit ints (3 on 32-bit build, 2 on 64-bit build) enough to represent 32-bit integers. Unfortunately it makes allocating/deallocating of single-digit ints slower. Microbenchmarks: $ ./python -m timeit -s "r = range(10**4)" -- "for i in r: pass" Unpatched: 1000 loops, best of 3: 603 usec per loop 1-digit free list: 1000 loops, best of 3: 390 usec per loop Multi-digit free list: 1000 loops, best of 3: 428 usec per loop $ ./python -m timeit -s "r = range(10**5)" -- "for i in r: pass" Unpatched: 100 loops, best of 3: 6.12 msec per loop 1-digit free list: 100 loops, best of 3: 5.69 msec per loop Multi-digit free list: 100 loops, best of 3: 4.36 msec per loop $ ./python -m timeit -s "a = list(range(10**4))" -- "for i, x in enumerate(a): pass" Unpatched: 1000 loops, best of 3: 1.25 msec per loop 1-digit free list: 1000 loops, best of 3: 929 usec per loop Multi-digit free list: 1000 loops, best of 3: 968 usec per loop $ ./python -m timeit -s "a = list(range(10**5))" -- "for i, x in enumerate(a): pass" Unpatched: 100 loops, best of 3: 11.7 msec per loop 1-digit free list: 100 loops, best of 3: 10.9 msec per loop Multi-digit free list: 100 loops, best of 3: 9.99 msec per loop As for more realistic cases, base85 encoding is 5% faster with multi-digit free list. $ ./python -m timeit -s "from base64 import b85encode; a = bytes(range(256))*100" -- "b85encode(a)" Unpatched: 100 loops, best of 3: 10 msec per loop 1-digit free list: 100 loops, best of 3: 9.85 msec per loop Multi-digit free list: 100 loops, best of 3: 9.48 msec per loop ---------- Added file: http://bugs.python.org/file39346/int_free_list_multidigit.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 23:48:10 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 11 May 2015 21:48:10 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1431379252.35.0.9121195899.issue23970@psf.upfronthosting.co.za> Message-ID: <55512395.9080004@egenix.com> Marc-Andre Lemburg added the comment: On 11.05.2015 23:20, Steve Dower wrote: > > I guess we need a third opinion. > > For me, the subclasses of CCompiler are undocumented and not a guaranteed interface (people using them directly are consenting adults). They're also an eyesore, so if I can clean them up without breaking the CCompiler interface (or minor version upgrades) then I should. The distutils interface isn't documented in all details, so the rule of thumb by which everybody operates is that any non-private symbol is part of the public API. FWIW: I don't see a problem with keeping implementations around for older MS VC versions. It's well possible that someone might want to use them for creating a Python version compiled with an older version of MS VC, e.g. in an embedding scenario. And you can still have your new cleaned up version override the default msvccompiler class. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 23:50:12 2015 From: report at bugs.python.org (Paul Moore) Date: Mon, 11 May 2015 21:50:12 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <1431381012.59.0.354225035786.issue23970@psf.upfronthosting.co.za> Paul Moore added the comment: I agree with Steve, we shouldn't be constrained to preserve all the undocumented internals of distutils - doing that in the past is what has made distutils essentially unmaintainable. I don't think there's a concrete example of real code that will be broken by this change - if I follow the comments correctly, MAL's code will still work ("I guess we'll then just continue to override the .initialize() call"). Without a specific breakage that can't be fixed to work with the new code, I don't think this patch should be blocked just because people might be using the old internals. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 23:51:58 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 11 May 2015 21:51:58 +0000 Subject: [issue24163] shutil.copystat fails when attribute security.selinux is present In-Reply-To: <1431311142.46.0.816679575818.issue24163@psf.upfronthosting.co.za> Message-ID: <1431381118.22.0.0306834682352.issue24163@psf.upfronthosting.co.za> Ned Deily added the comment: Possibly related: Issue15238 (msg165591 re root) ---------- nosy: +hynek, ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 11 23:56:26 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 11 May 2015 21:56:26 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1431381012.59.0.354225035786.issue23970@psf.upfronthosting.co.za> Message-ID: <55512585.1090003@egenix.com> Marc-Andre Lemburg added the comment: On 11.05.2015 23:50, Paul Moore wrote: > > I agree with Steve, we shouldn't be constrained to preserve all the undocumented internals of distutils - doing that in the past is what has made distutils essentially unmaintainable. > > I don't think there's a concrete example of real code that will be broken by this change - if I follow the comments correctly, MAL's code will still work ("I guess we'll then just continue to override the .initialize() call"). Without a specific breakage that can't be fixed to work with the new code, I don't think this patch should be blocked just because people might be using the old internals. This is not about our code. We can work around all this. The point is that in general, we don't break things in Python just because we can, even if we don't need to. In this case, I don't see a need to break things to add support for a new compiler version, which is why I don't follow Steve's arguments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 00:41:16 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 11 May 2015 22:41:16 +0000 Subject: [issue24156] test.test_ssl.ThreadedTests unit test failed In-Reply-To: <1431255939.47.0.583767548174.issue24156@psf.upfronthosting.co.za> Message-ID: <1431384076.61.0.622445731557.issue24156@psf.upfronthosting.co.za> Ned Deily added the comment: There are places in the test suite that assume 127.0.0.1 is the standard loopback address and will fail if the system under test doesn't follow that convention; see, for example, the discussion in Issue22753. I suspect that, in your case, the system's host configuration (/etc/hosts, DNS configuration, or similar) is such that the loopback address (127.0.0.1) is "round-tripped" as the actual address (192.168.1.103) of the interface. What platform are you running this on? Can you check what the addresses association with "localhost" and the names associated with the two IP addresses? For example, on many POSIX-y platforms, the following might work: dig localhost dig -x 127.0.0.1 dig -x 192.168.1.103 ifconfig ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 01:30:27 2015 From: report at bugs.python.org (=?utf-8?q?Radek_Hol=C3=BD?=) Date: Mon, 11 May 2015 23:30:27 +0000 Subject: [issue6057] sqlite3 error classes should be documented In-Reply-To: <1242673346.43.0.948670169284.issue6057@psf.upfronthosting.co.za> Message-ID: <1431387027.89.0.702047407365.issue6057@psf.upfronthosting.co.za> Radek Hol? added the comment: One reason why I would like to have it mentioned in the documentation is that the fact that it is not documented there causes "sqlite3.Error" to be missing in the "objects.inv" file generated by Sphinx so that enabling the "nitpicky" mode with "intersphinx" extension when generating my documentation using Sphinx results in many "WARNING: py:exc reference target not found: sqlite3.Error" false positives. (I'd also like to have it backported to Python 2.6 but I know that it's impossible) ---------- nosy: +PyDeq _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 01:41:57 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 11 May 2015 23:41:57 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <1431387717.65.0.533092416869.issue23970@psf.upfronthosting.co.za> Steve Dower added the comment: Things are already 'broken' for the new compiler version, so Python won't build properly with older versions of VC anymore (there are a few more changes, like removing _PyVerify_fd, that will make this even less likely - the new CRT is for too incompatible with the old one, though it's much more compatible with other OSs). If it's a big deal, I'll add the new compiler class as _msvccompiler.py and leave the old ones there as legacy code. That will save us from this discussion next time and avoid breaking people immediately (though there's almost certainly going to be subtle issues for them...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 02:03:04 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 May 2015 00:03:04 +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: <1431388984.78.0.444072262315.issue24017@psf.upfronthosting.co.za> Nick Coghlan added the comment: Latest version looks good to me (aside from a quibble about whether StopAsyncIteration should inherit from BaseException instead of Exception - see my review for details). Based on Guido's explanation in the review, I also suggested adding the following example method to the PEP as part of the rationale for StopAsyncIteration: def __anext__(self): try: data = await self._get_data() except EOFError: raise StopAsyncIteration return data The trick is that when __anext__ is itself a coroutine, we really do have 3 exit paths: * suspension to wait for events (await) * returning the next value (return) * terminating iteration (raise StopAsyncIteration) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 02:16:54 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 May 2015 00:16:54 +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: <1431389814.26.0.484282122305.issue24017@psf.upfronthosting.co.za> Nick Coghlan added the comment: Guido convinced me that having StopAsyncIteration inherit from Exception was the right approach, as it means errors are more likely to be of the "we caught it when we shouldn't have" variety, rather than the harder to debug "an exception escaped when it shouldn't have" variety. This isn't like SystemExit, KeyboardInterrupt or GeneratorExit where they're specifically designed to reliably terminate a thread of execution. That means I can offer an unreserved +1 on the current patch (#6) for beta 1 :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 03:14:38 2015 From: report at bugs.python.org (Toshishige Hagihara) Date: Tue, 12 May 2015 01:14:38 +0000 Subject: [issue24168] Unittest discover fails with namespace package if the path contains the string same as the module name Message-ID: <1431393278.14.0.705809016524.issue24168@psf.upfronthosting.co.za> New submission from Toshishige Hagihara: There is a problem with unittest discovering with namespace packages. Given the following directory structure, the following command fails with the errors. # Directory Structure ``` /home/hagihara/test.cybozu/infra/forest/lib/python3/ cybozu/ # <- namespace package cmdb/ __init__.py test.py ``` # Commands ``` # setup module path echo /home/hagihara/test.cybozu/infra/forest/lib/python3 > sudo dd of=/usr/lib/python3/dist-packages/cybozu.pth cd /home/hagihara/test.cybozu/infra python3 -m unittest discover -s cybozu ``` # Errors ``` $ python3 -m unittest discover -s cybozu Traceback (most recent call last): File "/usr/lib/python3.4/unittest/loader.py", line 221, in discover os.path.dirname((the_module.__file__))) AttributeError: 'module' object has no attribute '__file__' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.4/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.4/runpy.py", line 85, in _run_code exec(code, run_globals) File "/usr/lib/python3.4/unittest/__main__.py", line 18, in main(module=None) File "/usr/lib/python3.4/unittest/main.py", line 92, in __init__ self.parseArgs(argv) File "/usr/lib/python3.4/unittest/main.py", line 116, in parseArgs self._do_discovery(argv[2:]) File "/usr/lib/python3.4/unittest/main.py", line 225, in _do_discovery self.test = loader.discover(self.start, self.pattern, self.top) File "/usr/lib/python3.4/unittest/loader.py", line 242, in discover namespace=True)) File "/usr/lib/python3.4/unittest/loader.py", line 349, in _find_tests namespace=namespace) File "/usr/lib/python3.4/unittest/loader.py", line 310, in _find_tests name = self._get_name_from_path(full_path) File "/usr/lib/python3.4/unittest/loader.py", line 284, in _get_name_from_path assert not _relpath.startswith('..'), "Path must be within the project" AssertionError: Path must be within the project ``` # Cause of the error This error happens because TestLoader.discover does not set `self._top_level_dir` properly. `/usr/lib/python3.4/unittest/loader.py` ``` class TestLoader(object): ... def discover(self, start_dir, pattern='test*.py', top_level_dir=None): ... if os.path.isdir(os.path.abspath(start_dir)): ... else: # support for discovery from dotted module names try: __import__(start_dir) except ImportError: is_not_importable = True else: try: start_dir = os.path.abspath( os.path.dirname((the_module.__file__))) except AttributeError: # look for namespace packages ... if spec and spec.loader is None: if spec.submodule_search_locations is not None: is_namespace = True for path in the_module.__path__: if (not set_implicit_top and not path.startswith(top_level_dir)): continue self._top_level_dir = \ <--- cause of the error. (path.split(the_module.__name__ .replace(".", os.path.sep))[0]) ``` If path of the module contains the string same as the module name, the path is split at incorrect position and invalid value is set to `self._top_level_dir`. ``` path.split(the_module.__name__.replace(".", os.path.sep))[0] ``` the_module -> cybozu cybozu.__path__ -> ['/home/hagihara/test.cybozu/infra/forest/lib/python3/cybozu'] path.split('cybozu')[0] -> '/home/hagihara/test.' ---------- components: Tests messages: 242929 nosy: toshishige hagihara priority: normal severity: normal status: open title: Unittest discover fails with namespace package if the path contains the string same as the module name type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 04:06:50 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 May 2015 02:06:50 +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: <1431396410.01.0.731595720561.issue24168@psf.upfronthosting.co.za> Eric Snow added the comment: Just in case, please take a look at issues #17457 and #23882 to see if they already cover the bug. ---------- nosy: +eric.snow, rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 04:31:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 02:31:32 +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: <20150512023129.1941.23635@psf.io> Roundup Robot added the comment: New changeset 957478e95b26 by Yury Selivanov in branch '3.4': asyncio: Support PEP 492. Issue #24017. https://hg.python.org/cpython/rev/957478e95b26 New changeset 44c1db190525 by Yury Selivanov in branch 'default': asyncio: Merge 3.4 -- Support PEP 492. Issue #24017. https://hg.python.org/cpython/rev/44c1db190525 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 04:39:54 2015 From: report at bugs.python.org (Toshishige Hagihara) Date: Tue, 12 May 2015 02:39:54 +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: <1431398394.06.0.260080951461.issue24168@psf.upfronthosting.co.za> Toshishige Hagihara added the comment: Thanks for suggestion. I checked both issues and found that this bug is created in #17457 and #23882 does not fix it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 04:45:54 2015 From: report at bugs.python.org (Christie) Date: Tue, 12 May 2015 02:45:54 +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: <1431398754.39.0.342650316563.issue24033@psf.upfronthosting.co.za> Christie added the comment: Updated both tests in _test_mulitprocessing.py which were using sys.exectuable and Popen to use script_helpers instead, refactored script_helpers a bit to make this work. ---------- keywords: +patch Added file: http://bugs.python.org/file39347/issue24033_script_helper_multi_both.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 04:47:15 2015 From: report at bugs.python.org (Christie) Date: Tue, 12 May 2015 02:47:15 +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: <1431398835.64.0.443228007262.issue9517@psf.upfronthosting.co.za> Christie added the comment: Hey @berker.peksag, @r.david.murray, @serhiy.storchaka, If you get a chance I've got some changes up for review at: * http://bugs.python.org/issue24033 * http://bugs.python.org/issue23981 Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 05:03:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 03:03: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: <20150512030320.7792.87224@psf.io> Roundup Robot added the comment: New changeset eeeb666a5365 by Yury Selivanov in branch 'default': PEP 0492 -- Coroutines with async and await syntax. Issue #24017. https://hg.python.org/cpython/rev/eeeb666a5365 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 05:06:30 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 12 May 2015 03:06:30 +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: <1431399990.78.0.487485566329.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: Guido, Nick, Victor, Thanks for your reviews and guidance! The patch has been committed to the default branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 05:23:40 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 12 May 2015 03:23:40 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1431399990.78.0.487485566329.issue24017@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Thank you Yury! You are a coding machine. On Mon, May 11, 2015 at 8:06 PM, Yury Selivanov wrote: > > Yury Selivanov added the comment: > > Guido, Nick, Victor, > Thanks for your reviews and guidance! The patch has been committed to the > default branch. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 06:06:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 04:06:39 +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: <20150512040635.102425.96795@psf.io> Roundup Robot added the comment: New changeset 3a3cc2b9a1b2 by Yury Selivanov in branch 'default': Issue 24017: Update NEWS file. https://hg.python.org/cpython/rev/3a3cc2b9a1b2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 06:54:00 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 May 2015 04:54: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: <1431406440.1.0.902774644202.issue18814@psf.upfronthosting.co.za> Nick Coghlan added the comment: I suggest we defer this one to 3.6 - I still think it's worth doing, but I don't think it's a major barrier to migration, and it would be good to get some real world experience with the new sys.stdin behaviour of defaulting to using surrogateescape in the POSIX locale in 3.5 before committing to a particular design for the surrogate cleaning API. I do like the idea of a "string.internals" submodule as a possible home for exposing the Python level API. ---------- title: Add codecs.convert_surrogateescape to "clean" surrogate escaped strings -> Add utilities to "clean" surrogate code points from strings versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 06:57:35 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 May 2015 04:57:35 +0000 Subject: [issue22264] Add wsgiref.util.dump_wsgistr & load_wsgistr In-Reply-To: <1408884341.89.0.273491669506.issue22264@psf.upfronthosting.co.za> Message-ID: <1431406655.65.0.714394878118.issue22264@psf.upfronthosting.co.za> Nick Coghlan added the comment: Reviewing the items I had flagged as dependencies of issue 22555 for personal tracking purposes, I suggest we defer further consideration of this idea to 3.6 and/or the creation of a WSGI 2.0 specification. ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 07:00:00 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 May 2015 05:00:00 +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: <1431406800.4.0.831429875088.issue22385@psf.upfronthosting.co.za> Nick Coghlan added the comment: Reviewing the items I had flagged as dependencies of issue 22555 for personal tracking purposes, I suggest we defer further consideration of this idea to 3.6 after folks have had a chance to get some experience with the basic bytes.hex() method. ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 07:08:31 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 May 2015 05:08:31 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1431407311.13.0.669065813511.issue15216@psf.upfronthosting.co.za> Nick Coghlan added the comment: Reviewing the items I had flagged as dependencies of issue 22555 for personal tracking purposes, I suggest we defer further consideration of this idea to 3.6 after folks have had a chance to get some experience with the interpreter defaulting to using "surrogateescape" on the standard streams when an underlying *nix operating system (other than Mac OS X) claims that the system encoding is ASCII. ---------- priority: high -> normal versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 07:09:39 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 May 2015 05:09:39 +0000 Subject: [issue22555] Tracking issue for adjustments to binary/text boundary handling In-Reply-To: <1412481703.35.0.528069461639.issue22555@psf.upfronthosting.co.za> Message-ID: <1431407379.62.0.892634178241.issue22555@psf.upfronthosting.co.za> Nick Coghlan added the comment: I just went through the still-open issues referenced from here, and recommended deferring further consideration of all of the remaining items to 3.6: * utilities for clearing out surrogates from strings: issue 18814 * treating "wsgistr" as a serialisation format: issue 22264 * defining a formatting mini-language for hex output: issue 22385 * providing a way to change the encoding of an existing stream: issue 15216 I also added two new dependencies to this tracking issue: * Improved Unicode handling in the Windows console: issue 17620 * Using sys.stdin consistently at the default interactive prompt: issue 1602 ---------- dependencies: +Python interactive console doesn't use sys.stdin for input, windows console doesn't print or input Unicode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 08:16:57 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 12 May 2015 06:16:57 +0000 Subject: [issue22555] Tracking issue for adjustments to binary/text boundary handling In-Reply-To: <1412481703.35.0.528069461639.issue22555@psf.upfronthosting.co.za> Message-ID: <1431411417.52.0.53490420682.issue22555@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 08:31:59 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 May 2015 06:31:59 +0000 Subject: [issue18576] Document test.support.script_helper In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za> Message-ID: <1431412319.59.0.927953500342.issue18576@psf.upfronthosting.co.za> Nick Coghlan added the comment: script_helper was moved to the test.support package in issue 9517, so this issue is just about adding the docs now. ---------- dependencies: +Make test.script_helper more comprehensive, and use it in the test suite -Refactor the test_runpy walk_package support code into a common location title: Rename and document test.script_helper as test.support.script_helper -> Document test.support.script_helper versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 08:33:32 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 May 2015 06:33:32 +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: <1431412412.27.0.144133435704.issue9517@psf.upfronthosting.co.za> Nick Coghlan added the comment: Just noting that issue 18576 has a draft patch for test.support.script_helper documentation (the "move to the support module" part of the current patch there is obsolete) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 08:34:27 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 May 2015 06:34:27 +0000 Subject: [issue18576] Document test.support.script_helper In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za> Message-ID: <1431412467.38.0.861121954069.issue18576@psf.upfronthosting.co.za> Nick Coghlan added the comment: Also noting that my draft docs are over a year old now, so they need to be reviewed against the current state of the helper module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 09:29:34 2015 From: report at bugs.python.org (Benjamin Schubert) Date: Tue, 12 May 2015 07:29:34 +0000 Subject: [issue24166] ArgumentParser behavior does not match generated help In-Reply-To: <1431353733.91.0.614025540349.issue24166@psf.upfronthosting.co.za> Message-ID: <1431415774.71.0.330108804727.issue24166@psf.upfronthosting.co.za> Benjamin Schubert added the comment: Thanks a lot for this explanation ! It is more clear now for why it is not working. However, I would suggest that the ArgumentParser should still try to match anything the subparser could not, or would this be too complicated ? Moreover, if this scheme is not feasible, I would suggest modifying the documentation, or having a warning, or something to let people know. If this is possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 10:19:21 2015 From: report at bugs.python.org (Benjamin Schubert) Date: Tue, 12 May 2015 08:19:21 +0000 Subject: [issue24166] ArgumentParser behavior does not match generated help In-Reply-To: <1431353733.91.0.614025540349.issue24166@psf.upfronthosting.co.za> Message-ID: <1431418761.21.0.782828969175.issue24166@psf.upfronthosting.co.za> Benjamin Schubert added the comment: I solved my problem by subclassing the ArgumentParser and redefining parse_args as follow : class MultipleArgumentParser(ArgumentParser): def parse_args(self, args=None, namespace=None): args, argv = self.parse_known_args(args, namespace) if not argv: return args # save old actions, before rerunning the parser without the _SubParsersActions self._old_actions = self._actions.copy() self._actions = [action for action in self._old_actions if not isinstance(action, _SubParsersAction)] # parse the remaining command line args2, argv2 = self.parse_known_args(argv, None) self._actions = self._old_actions.copy() if argv2: msg = _('unrecognized arguments: %s') self.error(msg % ' '.join(argv2)) for key, value in vars(args2).items(): if isinstance(value, collections.Iterable): setattr(args, key, [value for value in itertools.chain(getattr(args, key), value)]) return args I know this is not generic enough and not cleanly done. However, would this be an interesting addition to the argumentparser ? If so, I can try to make a generic implementation, which would allow having multiple arguments after a subparser which did not match them ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 11:17:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 09:17:43 +0000 Subject: [issue13566] Increase pickle compatibility In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za> Message-ID: <1431422263.94.0.0239375468438.issue13566@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch pickles all ascii strings with protocols < 3 and fix_import=True with compatible opcodes (STRING, BINSTRING and SHORT_BINSTRING). Pickled strings are unpickled as str in Python 2 and Python 3 (unless encoding="bytes"). As a side effect, short ascii strings (length < 256) are pickled more compact with protocols < 3. ---------- keywords: +patch stage: needs patch -> patch review title: Array objects pickled in 3.x with protocol <=2 are unpickled incorrectly in 2.x -> Increase pickle compatibility type: behavior -> enhancement versions: +Python 3.5 -Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file39348/pickle_old_strings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 11:40:38 2015 From: report at bugs.python.org (Andrew Stormont) Date: Tue, 12 May 2015 09:40:38 +0000 Subject: [issue23895] PATCH: 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: <1431423638.16.0.149734566303.issue23895@psf.upfronthosting.co.za> Andrew Stormont added the comment: Bump. Would be nice to get this included in python 2.7.11. I also have a similar fix for the multiprocessing module but I won't bother submitting it if it will get ignored. ---------- status: open -> languishing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 11:47:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 09:47:24 +0000 Subject: [issue24009] Get rid of rare format units in PyArg_Parse* In-Reply-To: <1429470884.11.0.538472438707.issue24009@psf.upfronthosting.co.za> Message-ID: <1431424044.02.0.712813710414.issue24009@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, of course, I think we shouldn't drop support of these format units. But using them likely is a sign of outdated or transitional code. It should be discouraged in new code, and every case should be analyzed and cleaned. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 12:18:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 10:18:08 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <20150512101805.7804.64532@psf.io> Roundup Robot added the comment: New changeset 031df83dffb4 by Serhiy Storchaka in branch 'default': Issue #20173: Converted the _codecs module to Argument Clinic. https://hg.python.org/cpython/rev/031df83dffb4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 12:18:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 10:18:59 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1431425939.92.0.00936398306853.issue20173@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated to the tip and committed. Included Larry's suggestion about sys.getdefaultencoding(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 12:22:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 10:22:08 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <1431426128.25.0.212667942194.issue15027@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can I commit the patch now Larry? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 12:30:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 10:30:46 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1431426646.88.0.835855762209.issue23290@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please pay a little attention to this issue Raymond? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 12:36:29 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 10:36:29 +0000 Subject: [issue23870] pprint collections classes In-Reply-To: <1428167976.78.0.301380656754.issue23870@psf.upfronthosting.co.za> Message-ID: <20150512103626.1945.64357@psf.io> Roundup Robot added the comment: New changeset 73c01323cb9b by Serhiy Storchaka in branch 'default': Issue #23870: The pprint module now supports all standard collections https://hg.python.org/cpython/rev/73c01323cb9b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 12:37:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 10:37:32 +0000 Subject: [issue23870] pprint collections classes In-Reply-To: <1428167976.78.0.301380656754.issue23870@psf.upfronthosting.co.za> Message-ID: <1431427052.92.0.4920797044.issue23870@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 May 12 12:52:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 10:52:01 +0000 Subject: [issue24037] Argument Clinic: add the boolint converter In-Reply-To: <1429785188.86.0.806042190219.issue24037@psf.upfronthosting.co.za> Message-ID: <1431427921.14.0.266551160056.issue24037@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated to the tip. Used new converter in recently converted _tkinter and _codecs modules. Now it is used 30 times. ---------- Added file: http://bugs.python.org/file39349/clinic_boolint_converter_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 12:53:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 10:53:47 +0000 Subject: [issue24042] Convert os._getfullpathname() and os._isdir() to Argument Clinic In-Reply-To: <1429815662.86.0.935887508266.issue24042@psf.upfronthosting.co.za> Message-ID: <1431428027.15.0.61826172939.issue24042@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could anyone please test the patch on Windows? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 13:01:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 11:01:02 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <20150512110058.111992.16895@psf.io> Roundup Robot added the comment: New changeset 39df27d97901 by Serhiy Storchaka in branch 'default': Fixed compilation on Windows for issue #20173. https://hg.python.org/cpython/rev/39df27d97901 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 13:02:38 2015 From: report at bugs.python.org (Clement Rouault) Date: Tue, 12 May 2015 11:02:38 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1431428558.39.0.163519528739.issue22939@psf.upfronthosting.co.za> Clement Rouault added the comment: After a few months, I am back to you on this issue. What should be the next step of the process ? ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 13:06:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 11:06:09 +0000 Subject: [issue21859] Add Python implementation of FileIO In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za> Message-ID: <1431428769.09.0.0467859801881.issue21859@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Both issues are fixed. ---------- assignee: -> serhiy.storchaka dependencies: -Check path arguments of os functions for null character resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 13:17:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 11:17:46 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1431429466.49.0.563938479451.issue22995@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 13:20:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 11:20:24 +0000 Subject: [issue22682] Add support of KZ1048 (RK1048) encoding In-Reply-To: <1413836476.72.0.167337994722.issue22682@psf.upfronthosting.co.za> Message-ID: <1431429624.62.0.677099465932.issue22682@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 13:20:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 11:20:33 +0000 Subject: [issue22681] Add support of KOI8-T encoding In-Reply-To: <1413827370.97.0.876918138857.issue22681@psf.upfronthosting.co.za> Message-ID: <1431429633.65.0.99646622306.issue22681@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 13:47:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 11:47:44 +0000 Subject: [issue21708] Deprecate nonstandard behavior of a dumbdbm database In-Reply-To: <1402425082.25.0.679069092867.issue21708@psf.upfronthosting.co.za> Message-ID: <1431431264.24.0.602776370592.issue21708@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Warnings are not raised by default. They are raised only when the database is opened with the 'r' mode and then modified. The earlier we start deprecation period, the earlier we could add true "read-only" and "update existing" modes to dbm.dumb. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 14:55:46 2015 From: report at bugs.python.org (Alex Shkop) Date: Tue, 12 May 2015 12:55:46 +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: <1431435346.9.0.0721098537638.issue18383@psf.upfronthosting.co.za> Alex Shkop added the comment: Please, review the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 14:57:41 2015 From: report at bugs.python.org (Alex Shkop) Date: Tue, 12 May 2015 12:57:41 +0000 Subject: [issue23882] unittest discovery doesn't detect namespace packages when given no parameters In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za> Message-ID: <1431435461.7.0.950572754462.issue23882@psf.upfronthosting.co.za> Alex Shkop added the comment: Please, review the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 15:10:54 2015 From: report at bugs.python.org (Petr Viktorin) Date: Tue, 12 May 2015 13:10:54 +0000 Subject: [issue1322] Deprecate platform.dist() and platform.linux_distribution() functions In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> Message-ID: <1431436254.36.0.81618923984.issue1322@psf.upfronthosting.co.za> Changes by Petr Viktorin : ---------- nosy: +encukou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 15:15:14 2015 From: report at bugs.python.org (Petr Viktorin) Date: Tue, 12 May 2015 13:15:14 +0000 Subject: [issue17762] platform.linux_distribution() should honor /etc/os-release In-Reply-To: <1366124468.64.0.40642643299.issue17762@psf.upfronthosting.co.za> Message-ID: <1431436514.75.0.86055340015.issue17762@psf.upfronthosting.co.za> Changes by Petr Viktorin : ---------- nosy: +encukou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 15:27:49 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 12 May 2015 13:27:49 +0000 Subject: [issue1322] Deprecate platform.dist() and platform.linux_distribution() functions In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> Message-ID: <1431437269.02.0.720339208317.issue1322@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- assignee: lemburg -> berker.peksag stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 15:32:23 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 May 2015 13:32:23 +0000 Subject: [issue23895] PATCH: 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: <1431437543.76.0.239510010651.issue23895@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> patch review status: languishing -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 15:49:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 13:49:57 +0000 Subject: [issue23034] Dynamically control debugging output In-Reply-To: <1418332173.89.0.386427809737.issue23034@psf.upfronthosting.co.za> Message-ID: <1431438597.7.0.223175238747.issue23034@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch adds the "-X showalloccount" option, that turn on the output of allocated objects counts if COUNT_ALLOCS, SHOW_ALLOC_COUNT, or SHOW_TRACK_COUNT are defined. The output of COUNT_ALLOCS is now written to stderr. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file39350/show_alloc_counts.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 15:51:07 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 May 2015 13:51:07 +0000 Subject: [issue23895] PATCH: 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: <1431438667.17.0.512364017706.issue23895@psf.upfronthosting.co.za> R. David Murray added the comment: Do you know anyone else using solaris who could do a review (ie: confirm that your patch makes sense and works for them)? It looks like jcea, who is our only current committer who uses Solaris as far as I know (well, OpenIndiana), hasn't had time to look at this. On the other hand, it isn't 100% clear to me that this is appropriate. I'm not (yet) experienced enough with the internals of our build system to be the one to make the call, but it seems to me that you can support -z ignore by modifying your Modules/Setup file, so it may not be appropriate to inject solaris specific support in setup.py for an option that isn't normally used. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 15:53:33 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 May 2015 13:53:33 +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: <1431438813.55.0.959778751903.issue23895@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: PATCH: python socket module fails to build on Solaris when -zignore is in LDFLAGS -> python socket module fails to build on Solaris when -zignore is in LDFLAGS _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 16:00:55 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 14:00:55 +0000 Subject: [issue23796] BufferedReader.peek() crashes if closed In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za> Message-ID: <20150512140050.63246.14912@psf.io> Roundup Robot added the comment: New changeset 41e9d324f10d by Berker Peksag in branch 'default': Issue #23796: peak and read1 methods of BufferedReader now raise ValueError https://hg.python.org/cpython/rev/41e9d324f10d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 16:15:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 14:15:18 +0000 Subject: [issue23796] BufferedReader.peek() crashes if closed In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za> Message-ID: <20150512141505.11415.53977@psf.io> Roundup Robot added the comment: New changeset 7d722c9049ff by Berker Peksag in branch '3.4': Issue #23796: peak and read1 methods of BufferedReader now raise ValueError https://hg.python.org/cpython/rev/7d722c9049ff New changeset be7636fd6438 by Berker Peksag in branch 'default': Issue #23796: Null merge. https://hg.python.org/cpython/rev/be7636fd6438 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 16:16:35 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 12 May 2015 14:16:35 +0000 Subject: [issue23796] BufferedReader.peek() crashes if closed In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za> Message-ID: <1431440195.6.0.088499000583.issue23796@psf.upfronthosting.co.za> Berker Peksag added the comment: Fixed. Thanks for the patch, John. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 16:25:30 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 14:25:30 +0000 Subject: [issue23983] Update example in the pty documentation In-Reply-To: <1429233448.23.0.72580455628.issue23983@psf.upfronthosting.co.za> Message-ID: <20150512142527.66039.34952@psf.io> Roundup Robot added the comment: New changeset e656bece13fa by Berker Peksag in branch '3.4': Issue #23983: Update the pty module example. https://hg.python.org/cpython/rev/e656bece13fa New changeset 0be7c8f46378 by Berker Peksag in branch 'default': Issue #23983: Update the pty module example. https://hg.python.org/cpython/rev/0be7c8f46378 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 16:26:14 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 12 May 2015 14:26:14 +0000 Subject: [issue23983] Update example in the pty documentation In-Reply-To: <1429233448.23.0.72580455628.issue23983@psf.upfronthosting.co.za> Message-ID: <1431440774.98.0.99017355818.issue23983@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 16:28:08 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 12 May 2015 14:28:08 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1431440888.35.0.935012084573.issue19610@psf.upfronthosting.co.za> Berker Peksag added the comment: ?ric, could you please take a look at issue19610_v4.diff? I'd like to commit the patch this weekend. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 16:43:55 2015 From: report at bugs.python.org (John Hergenroeder) Date: Tue, 12 May 2015 14:43:55 +0000 Subject: [issue23796] BufferedReader.peek() crashes if closed In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za> Message-ID: <1431441835.0.0.873051112445.issue23796@psf.upfronthosting.co.za> John Hergenroeder added the comment: Wonderful! Thanks for your help, Berker! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 16:59:46 2015 From: report at bugs.python.org (Roman Rader) Date: Tue, 12 May 2015 14:59:46 +0000 Subject: [issue24156] test.test_ssl.ThreadedTests unit test failed In-Reply-To: <1431255939.47.0.583767548174.issue24156@psf.upfronthosting.co.za> Message-ID: <1431442786.62.0.658769337849.issue24156@psf.upfronthosting.co.za> Roman Rader added the comment: You're right, it does not reproduces on any machine. I'm using Arch Linux, still trying to figure out the repro steps. My hosts file doesn't contain such entries for localhost, it's pretty standard. If I disable my external network interface, it retrieves my second IP from virtual interface. And only when I disable all interfaces, I can get 127.0.0.1 on source in IP packet. The problem is, even if I enforce client to bind to "127.0.0.1", it substitutes as well (see https://gist.github.com/rrader/3e575cde56827b1f74a1). strace is clean, Python calls all kernel functions with 127.0.0.1 IP. So, I suppose, the problem not in the Python code itself, but somewhere deeper (however it can be lack of some flags?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 17:10:35 2015 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 12 May 2015 15:10:35 +0000 Subject: [issue22682] Add support of KZ1048 (RK1048) encoding In-Reply-To: <1413836476.72.0.167337994722.issue22682@psf.upfronthosting.co.za> Message-ID: <1431443435.25.0.372530985421.issue22682@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Please go ahead! Or do you expect someone else to review the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 17:22:45 2015 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 12 May 2015 15:22:45 +0000 Subject: [issue22681] Add support of KOI8-T encoding In-Reply-To: <1413827370.97.0.876918138857.issue22681@psf.upfronthosting.co.za> Message-ID: <1431444165.73.0.0731979694308.issue22681@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Looks good to me. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 17:30:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 15:30:46 +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: <20150512153034.11419.53037@psf.io> Roundup Robot added the comment: New changeset 0dc3b61f1dfa by Yury Selivanov in branch 'default': Issue #24017: Plug ref leak. https://hg.python.org/cpython/rev/0dc3b61f1dfa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 17:42:17 2015 From: report at bugs.python.org (paul) Date: Tue, 12 May 2015 15:42:17 +0000 Subject: [issue24098] Multiple use after frees in obj2ast_* methods In-Reply-To: <1430489429.65.0.587999729774.issue24098@psf.upfronthosting.co.za> Message-ID: <1431445337.47.0.0998774293191.issue24098@psf.upfronthosting.co.za> paul added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 17:43:59 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 12 May 2015 15:43:59 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <1431445439.63.0.305753630142.issue15027@psf.upfronthosting.co.za> Larry Hastings added the comment: We're still in alpha, so it's fine for 3.5 right now. The cutoff for new features for 3.5 will be May 23. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 17:46:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 15:46:02 +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: <20150512154556.66013.66047@psf.io> Roundup Robot added the comment: New changeset ee7d2c9c70ab by Yury Selivanov in branch '3.4': asyncio: Make sure sys.set_coroutine_wrapper is called *only* when loop is running. https://hg.python.org/cpython/rev/ee7d2c9c70ab New changeset 874edaa34b54 by Yury Selivanov in branch 'default': asyncio: Make sure sys.set_coroutine_wrapper is called *only* when loop is running. https://hg.python.org/cpython/rev/874edaa34b54 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 20:02:07 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 12 May 2015 18:02:07 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1431453727.19.0.277633026593.issue23290@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't like the patch as-is (comment change is wrong, test in the inner-loop making the common case pay for a short-cut for the uncommon case). As I said before, the basic idea is good and I will very likely include some variant of this for Python3.5. I marked this as low priority so I can work on other things (such as deque slicing) before the feature freeze and will come back to this after beta 1. Please remain calm. My development time is limited but this is something I do want to get done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 20:28:40 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 18:28:40 +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: <20150512182831.56719.94529@psf.io> Roundup Robot added the comment: New changeset 9d2c4d887c19 by Yury Selivanov in branch 'default': Issue #24017: Unset asyncio event loop after test. https://hg.python.org/cpython/rev/9d2c4d887c19 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 20:37:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 18:37:04 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1431455824.38.0.986986708862.issue23290@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Doesn't the feature freeze start from beta 1? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 20:48:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 18:48:00 +0000 Subject: [issue22682] Add support of KZ1048 (RK1048) encoding In-Reply-To: <1413836476.72.0.167337994722.issue22682@psf.upfronthosting.co.za> Message-ID: <1431456480.15.0.54839215016.issue22682@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be nice if somebody of the encoding package maintainers (Martin, Marc-Andre) will approve (or reject) the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 20:50:58 2015 From: report at bugs.python.org (Kurt Rose) Date: Tue, 12 May 2015 18:50:58 +0000 Subject: [issue24169] sockets convert out-of-range port numbers % 2**16 Message-ID: <1431456658.59.0.16323204969.issue24169@psf.upfronthosting.co.za> New submission from Kurt Rose: This appears to affect all versions of Python. In a behavior inherited from C, TCP ports that are > 2 bytes are silently truncated. Here is a simple reproduction: >>> socket.create_connection( ('google.com', 2**16 + 80) ) Needs more investigation, but one likely place to make the fix is here: https://hg.python.org/cpython/file/9d2c4d887c19/Modules/socketmodule.c#l1535 if (!PyArg_ParseTuple(args, "O&i:getsockaddrarg", idna_converter, &host, &port)) Instead of parsing port with i, use H. This is a deep change to the behavior, but I think it is very unlikely that users intentionally mean to pass a TCP port > 2**16. More likely, this is silently swallowing errors. There no indication that the passed port parameter is not being used for the actual TCP communication (which is physically impossible because TCP only has a 2 byte port field). In fact, the socket will continue to "lie" to the user and obfuscate the actual port being used if getsockname() is called: >>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname() ('10.225.89.86', 54899) ---------- messages: 242987 nosy: Kurt.Rose priority: normal severity: normal status: open title: sockets convert out-of-range port numbers % 2**16 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 Tue May 12 20:55:02 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 12 May 2015 18:55:02 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1431456902.7.0.504353472618.issue23290@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Optimizations aren't new features. We can still tweak the implementation through-out the betas. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 20:55:10 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 12 May 2015 18:55:10 +0000 Subject: [issue22682] Add support of KZ1048 (RK1048) encoding In-Reply-To: <1413836476.72.0.167337994722.issue22682@psf.upfronthosting.co.za> Message-ID: <1431456910.58.0.135191577957.issue22682@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Looks good. Thanks, Serhiy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 21:05:39 2015 From: report at bugs.python.org (magnus.forsberg) Date: Tue, 12 May 2015 19:05:39 +0000 Subject: [issue24170] IDLE crashes when I press ^ key Message-ID: <1431457539.55.0.53127301555.issue24170@psf.upfronthosting.co.za> New submission from magnus.forsberg: Every time I press the ^ key, IDLE crashes. I've tried this with two different keyboards with the same result. I use IDLE 3.4.3 with Mac OS X 10.10.3. ---------- components: IDLE messages: 242990 nosy: magnus.forsberg priority: normal severity: normal status: open title: IDLE crashes when I press ^ key type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 21:11:47 2015 From: report at bugs.python.org (Sean Wolfe) Date: Tue, 12 May 2015 19:11:47 +0000 Subject: [issue2704] IDLE: Patch to make PyShell behave more like a Terminal interface In-Reply-To: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za> Message-ID: <1431457907.61.0.408292776141.issue2704@psf.upfronthosting.co.za> Sean Wolfe added the comment: Windows 7 patch test successful: https://bugs.python.org/issue2704 * install python 2.7.8 fresh on W7 * check idle terminal functionality --> should not show terminal changes from 2704: - up arrows move cursor - typing out of focus has no effect - clicking above the prompt, then typing, does not move cursor to the prompt and begin typing * install Terminal.py in idlelib * apply PyShell.py.patch * click out of focus and type --> cursor returns to prompt + text appears * backspace --> backspace deletes text on prompt line * press up arrow --> cursor does not move up --> bell sounds as there are no previous commands * enter a few commands, then use up/down keys to navigate history --> up and down browse through history There seems to be a bell command in the history as I cycle through commands when I cross from earliest to latest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 21:12:14 2015 From: report at bugs.python.org (Kurt Rose) Date: Tue, 12 May 2015 19:12:14 +0000 Subject: [issue24169] sockets convert out-of-range port numbers % 2**16 In-Reply-To: <1431456658.59.0.16323204969.issue24169@psf.upfronthosting.co.za> Message-ID: <1431457934.06.0.574007981289.issue24169@psf.upfronthosting.co.za> Kurt Rose added the comment: I was incorrect -- the result of getsockname() appears to be some garbage port: >>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname() ('10.225.89.86', 56446) >>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname() ('10.225.89.86', 56447) >>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname() ('10.225.89.86', 56448) >>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname() ('10.225.89.86', 56449) >>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname() ('10.225.89.86', 56450) >>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname() ('10.225.89.86', 56451) >>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname() ('10.225.89.86', 56452) Java's stdlib gives a proper error message: >>> java.net.Socket("google.com", 2**16 + 80) Traceback (most recent call last): File "", line 1, in at java.net.InetSocketAddress.(Unknown Source) at java.net.Socket.(Unknown Source) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Sou rce) at java.lang.reflect.Constructor.newInstance(Unknown Source) at org.python.core.PyReflectedConstructor.constructProxy(PyReflectedCons tructor.java:210) java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: port out of range:65616 The .NET runtime also rejects invalid ports: >>> System.Net.IPEndPoint(0x7F000001, 2**16 + 80) Traceback (most recent call last): File "", line 1, in ValueError: Specified argument was out of the range of valid values. Parameter name: port IronPython by extension rejects the invalid port: >>> socket.create_connection( ('google.com', 2**16 + 80) ) Traceback (most recent call last): File "", line 1, in ValueError: Specified argument was out of the range of valid values. Parameter name: port However, Jython recreates the behavior of CPython: >>> socket.create_connection( ('google.com', 2**16 + 80) ).getsockname() (u'10.225.89.86', 63071) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 21:13:53 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 12 May 2015 19:13:53 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1431458033.21.0.0555199771064.issue23290@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I looked at the patch again and it is in pretty good shape. Please hoist the conditionals out of the loop (for intelligibility and to let the compiler in-line more effectively). Also, let's remove the "dump" and "clear" variable names in favor of comments that explain the conditionals (to introducing new terminology to the module). If you want, I'll take a crack at it in the next couple of days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 21:14:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 19:14:52 +0000 Subject: [issue24170] IDLE crashes when I press ^ key In-Reply-To: <1431457539.55.0.53127301555.issue24170@psf.upfronthosting.co.za> Message-ID: <1431458092.71.0.440749859048.issue24170@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +kbk, ned.deily, roger.serwy, ronaldoussoren, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 21:15:43 2015 From: report at bugs.python.org (Sean Wolfe) Date: Tue, 12 May 2015 19:15:43 +0000 Subject: [issue2704] IDLE: Patch to make PyShell behave more like a Terminal interface In-Reply-To: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za> Message-ID: <1431458143.43.0.333240177111.issue2704@psf.upfronthosting.co.za> Sean Wolfe added the comment: successfully tested on Linux in 2014 Hello folks, FYI I also installed this patch on Lubuntu linux in 2014 on a series of computers at a lab where I mentor. I don't have the documentation for those specific tests, but I did follow the outline above, and it was done. So, IMO we can call this tested on W7, Linux and OSX 10.9.3, for Python 2.7 . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 21:18:16 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 12 May 2015 19:18:16 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1431456902.7.0.504353472618.issue23290@psf.upfronthosting.co.za> Message-ID: <555251F6.6060302@free.fr> Antoine Pitrou added the comment: Le 12/05/2015 20:55, Raymond Hettinger a ?crit : > > Optimizations aren't new features. We can still tweak the implementation through-out the betas. Not really. The period after the first beta is for fixing bugs, not for risking introducing new bugs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 21:21:19 2015 From: report at bugs.python.org (Tim Graham) Date: Tue, 12 May 2015 19:21:19 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1431458479.03.0.0204200351038.issue24134@psf.upfronthosting.co.za> Tim Graham added the comment: I didn't find any problems while testing your proposed new patch for cpython and your proposed patch for Django together. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 21:22:21 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 12 May 2015 19:22:21 +0000 Subject: [issue24170] IDLE crashes when I press ^ key In-Reply-To: <1431457539.55.0.53127301555.issue24170@psf.upfronthosting.co.za> Message-ID: <1431458541.84.0.853163142842.issue24170@psf.upfronthosting.co.za> Ned Deily added the comment: If you are using a Python 3.4.3 from a python.org installer for OS X or have built your own, have you installed the latest ActiveTcl 8.5.x as described here? https://www.python.org/download/mac/tcltk/ If not, you should have received a warning when you launched IDLE. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 21:23:59 2015 From: report at bugs.python.org (JitterMan) Date: Tue, 12 May 2015 19:23:59 +0000 Subject: [issue24171] httplib Message-ID: <1431458639.62.0.956641186382.issue24171@psf.upfronthosting.co.za> New submission from JitterMan: In python2.7.9, httplib.py, on line 780, makes a call to: line = response.fp.readline(_MAXLINE + 1) This ends up calling a function defined on line 1362 in the same file: def readline(self): Notice the argument mismatch. The call passes two arguments, but the function defines only one. This can be 'fixed' by changing the definition to: def readline(self, size=None): ---------- messages: 242998 nosy: jitterman priority: normal severity: normal status: open title: httplib type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 21:30:51 2015 From: report at bugs.python.org (Kurt Rose) Date: Tue, 12 May 2015 19:30:51 +0000 Subject: [issue24169] sockets convert out-of-range port numbers % 2**16 In-Reply-To: <1431456658.59.0.16323204969.issue24169@psf.upfronthosting.co.za> Message-ID: <1431459051.52.0.540672093774.issue24169@psf.upfronthosting.co.za> Kurt Rose added the comment: Sorry, dumb mistake on my part. I should have been calling getpeername(), not getsockname() In that case the result is 80: >>> socket.create_connection( ('google.com', 2**16 + 80) ).getpeername() ('74.125.239.41', 80) The "random" ports were the client-side ephemeral ports. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 21:41:37 2015 From: report at bugs.python.org (Christie) Date: Tue, 12 May 2015 19:41:37 +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: <1431459697.13.0.585143809999.issue9517@psf.upfronthosting.co.za> Christie added the comment: Cool, thanks @ncoghlan! Would you like someone to take on the work of updating the latest patch on issue 18576? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 21:57:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 19:57:53 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1431460673.97.0.422490010399.issue23290@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is the patch with hoisted the conditionals out of the loop. New microbenchmarking results: $ ./python -m timeit -s "s = set(range(10**4))" -- "frozenset(s)" Unpatched: 1000 loops, best of 3: 407 usec per loop With patch #4: 1000 loops, best of 3: 325 usec per loop (speed up 25%) With patch #5: 1000 loops, best of 3: 272 usec per loop (speed up 50%) $ ./python -m timeit -s "s = {i+(j<<64) for i in range(10**4//2) for j in range(2)}" -- "frozenset(s)" Unpatched: 1000 loops, best of 3: 995 usec per loop With patch #4: 1000 loops, best of 3: 447 usec per loop (speed up 123%) With patch #5: 1000 loops, best of 3: 417 usec per loop (speed up 139%) $ ./python -m timeit -s "s = set(range(10**4)); s.add(-1); s.discard(-1)" -- "frozenset(s)" Unpatched: 1000 loops, best of 3: 411 usec per loop With patch #4: 1000 loops, best of 3: 355 usec per loop (speed up 16%) With patch #5: 1000 loops, best of 3: 406 usec per loop (equal) $ ./python -m timeit -s "s = {i+(j<<64) for i in range(10**4//2) for j in range(2)}; s.add(-1); s.discard(-1)" -- "frozenset(s)" Unpatched: 1000 loops, best of 3: 1.01 msec per loop With patch #4: 1000 loops, best of 3: 572 usec per loop (speed up 77%) With patch #5: 1000 loops, best of 3: 609 usec per loop (speed up 66%) ---------- Added file: http://bugs.python.org/file39351/set_faster_copy_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 21:58:25 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 May 2015 19:58:25 +0000 Subject: [issue24169] sockets convert out-of-range port numbers % 2**16 In-Reply-To: <1431456658.59.0.16323204969.issue24169@psf.upfronthosting.co.za> Message-ID: <1431460705.51.0.622639331146.issue24169@psf.upfronthosting.co.za> R. David Murray added the comment: You pegged it when you said the behavior is inherited from C. Technically this isn't a bug in Python, since the socket module is a set of (mostly) thin wrappers around the C. Enhancing CPython to do the check is not a bad suggestion, especially since it seems that other languages and implementations do so. We won't fix this in a maintenance release, though, since it would pointlessly break working code (even if that code is technically buggy). ---------- nosy: +r.david.murray stage: -> needs patch type: behavior -> enhancement versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 22:03:59 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 12 May 2015 20:03:59 +0000 Subject: [issue24156] test.test_ssl.ThreadedTests unit test failed In-Reply-To: <1431255939.47.0.583767548174.issue24156@psf.upfronthosting.co.za> Message-ID: <1431461039.66.0.29232652128.issue24156@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the additional info. I don't know what possible configuration options might affect this other than that I would expect to see 127.0.0.1 as the primary IPv4 address on the loopback interface, like: # ifconfig [...] lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 [...] Since this does seem to be unique to your configuration, I'm going to close this issue for now. If you do discover the root cause and it appears to be something that might be seen by other users and, thus, should be handled in the test suite, please re-open. ---------- resolution: -> works for me stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 22:06:04 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 May 2015 20:06:04 +0000 Subject: [issue24171] httplib In-Reply-To: <1431458639.62.0.956641186382.issue24171@psf.upfronthosting.co.za> Message-ID: <1431461164.33.0.434057221562.issue24171@psf.upfronthosting.co.za> R. David Murray added the comment: This is a duplicate of issue 17849. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Missing size argument in readline() method for httplib's class LineAndFileWrapper type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 22:06:29 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 May 2015 20:06:29 +0000 Subject: [issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper In-Reply-To: <1366979224.14.0.876475494511.issue17849@psf.upfronthosting.co.za> Message-ID: <1431461189.36.0.0350380618394.issue17849@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +jitterman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 22:10:50 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 12 May 2015 20:10:50 +0000 Subject: [issue23882] unittest discovery doesn't detect namespace packages when given no parameters In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za> Message-ID: <1431461450.35.0.0805243423035.issue23882@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 22:12:58 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 12 May 2015 20:12:58 +0000 Subject: [issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper In-Reply-To: <1366979224.14.0.876475494511.issue17849@psf.upfronthosting.co.za> Message-ID: <1431461578.21.0.750054090871.issue17849@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 22:13:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 20:13:08 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <20150512201305.8151.88098@psf.io> Roundup Robot added the comment: New changeset 80cf7723c4cf by Serhiy Storchaka in branch 'default': Issue #15027: The UTF-32 encoder is now 3x to 7x faster. https://hg.python.org/cpython/rev/80cf7723c4cf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 22:24:40 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 20:24:40 +0000 Subject: [issue22681] Add support of KOI8-T encoding In-Reply-To: <1413827370.97.0.876918138857.issue22681@psf.upfronthosting.co.za> Message-ID: <20150512202436.45098.18795@psf.io> Roundup Robot added the comment: New changeset 78de5d040492 by Serhiy Storchaka in branch 'default': Issue #22681: Added support for the koi8_t encoding. https://hg.python.org/cpython/rev/78de5d040492 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 22:24:40 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 20:24:40 +0000 Subject: [issue22682] Add support of KZ1048 (RK1048) encoding In-Reply-To: <1413836476.72.0.167337994722.issue22682@psf.upfronthosting.co.za> Message-ID: <20150512202435.45098.83683@psf.io> Roundup Robot added the comment: New changeset 6e1fe5bfba48 by Serhiy Storchaka in branch 'default': Issue #22682: Added support for the kz1048 encoding. https://hg.python.org/cpython/rev/6e1fe5bfba48 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 22:26:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 20:26:46 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <1431462406.8.0.11893222829.issue15027@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And that's not all... ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 22:28:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 20:28:05 +0000 Subject: [issue22682] Add support of KZ1048 (RK1048) encoding In-Reply-To: <1413836476.72.0.167337994722.issue22682@psf.upfronthosting.co.za> Message-ID: <1431462485.2.0.307690426848.issue22682@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your reviews Amaury and Marc-Andre. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 22:28:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 20:28:32 +0000 Subject: [issue22681] Add support of KOI8-T encoding In-Reply-To: <1413827370.97.0.876918138857.issue22681@psf.upfronthosting.co.za> Message-ID: <1431462512.83.0.731940280391.issue22681@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 22:29:56 2015 From: report at bugs.python.org (JitterMan) Date: Tue, 12 May 2015 20:29:56 +0000 Subject: [issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper In-Reply-To: <1366979224.14.0.876475494511.issue17849@psf.upfronthosting.co.za> Message-ID: <1431462596.84.0.161060842281.issue17849@psf.upfronthosting.co.za> JitterMan added the comment: I ran into this problem when I gave https_proxy an invalid value: export https_proxy=http://foo.com No divine intervention required. I was just trying to determine what message was printed with the proxy environment variable was set incorrectly. Perhaps that will help you develop a more reasonable testcase. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 22:55:12 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 12 May 2015 20:55:12 +0000 Subject: [issue24170] IDLE crashes when I press ^ key In-Reply-To: <1431457539.55.0.53127301555.issue24170@psf.upfronthosting.co.za> Message-ID: <1431464112.12.0.810394237912.issue24170@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Does not happen on Windows. Please start Idle with "python -m idlelib" in a console and report any error traceback you see. Replace 'python' with 'python3' or 'py -3' as needed to start 3.x. (I am not familiar with osx incantation.) ---------- components: +Macintosh type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 22:59:28 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 12 May 2015 20:59:28 +0000 Subject: [issue24170] IDLE crashes when I press ^ key In-Reply-To: <1431457539.55.0.53127301555.issue24170@psf.upfronthosting.co.za> Message-ID: <1431464368.57.0.236321606853.issue24170@psf.upfronthosting.co.za> Ned Deily added the comment: This is undoubtedly a crash in Tk, not in Python itself, so there won't be any Python traceback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 23:05:00 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 12 May 2015 21:05:00 +0000 Subject: [issue24170] IDLE crashes when I press ^ key In-Reply-To: <1431457539.55.0.53127301555.issue24170@psf.upfronthosting.co.za> Message-ID: <1431464700.12.0.4748694768.issue24170@psf.upfronthosting.co.za> Terry J. Reedy added the comment: At least on Windows, tk errors usually result in TclError with a message that is sometimes helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 23:11:24 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 12 May 2015 21:11:24 +0000 Subject: [issue24170] IDLE crashes when I press ^ key In-Reply-To: <1431457539.55.0.53127301555.issue24170@psf.upfronthosting.co.za> Message-ID: <1431465084.57.0.443158181314.issue24170@psf.upfronthosting.co.za> Ned Deily added the comment: Unless I'm very much mistaken, this is another instance of the old Cocoa Tk problem documented here (http://sourceforge.net/p/tktoolkit/bugs/2722/) and referred to in https://www.python.org/download/mac/tcltk/. It's not like a normal TclError in that it causes the embedded Tcl interpreter used by Python to hard crash with no chance of recovery. This is why we strongly recommend people not use older versions of Cocoa Tk as, unfortunately, are still shipped by Apple with the latest versions of OS X. The problem has been fixed in more recent versions of Cocoa Tk such as those shipped by ActiveState and which the python.org installer will use if installed (and will warn about if not installed). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 23:20:24 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 21:20:24 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <20150512212022.1931.85548@psf.io> Roundup Robot added the comment: New changeset 34648ce02bd4 by Serhiy Storchaka in branch 'default': Issue #22486: Added the math.gcd() function. The fractions.gcd() function now is https://hg.python.org/cpython/rev/34648ce02bd4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 23:21:15 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 12 May 2015 21:21:15 +0000 Subject: [issue22681] Add support of KOI8-T encoding In-Reply-To: <1413827370.97.0.876918138857.issue22681@psf.upfronthosting.co.za> Message-ID: <1431465675.38.0.112159668726.issue22681@psf.upfronthosting.co.za> Ned Deily added the comment: Lots of "LookupError: unknown encoding: koi8_t" test failures (on OS X 10.10) after this commit, for example, in test_codecs: ====================================================================== ERROR: test_basics (test.test_codecs.BasicUnicodeTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/3x/source/Lib/test/test_codecs.py", line 1869, in test_basics name = codecs.lookup(encoding).name LookupError: unknown encoding: koi8_t ====================================================================== ERROR: test_decoder_state (test.test_codecs.BasicUnicodeTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/3x/source/Lib/test/test_codecs.py", line 2024, in test_decoder_state self.check_state_handling_decode(encoding, u, u.encode(encoding)) LookupError: unknown encoding: koi8_t ====================================================================== ERROR: test_seek (test.test_codecs.BasicUnicodeTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/3x/source/Lib/test/test_codecs.py", line 1992, in test_seek reader = codecs.getreader(encoding)(io.BytesIO(s.encode(encoding))) File "/py/dev/3x/blds/uxd/../../source/Lib/codecs.py", line 998, in getreader return lookup(encoding).streamreader LookupError: unknown encoding: koi8_t ---------------------------------------------------------------------- Ran 211 tests in 5.970s FAILED (errors=5, skipped=17) ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 23:22:47 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 12 May 2015 21:22:47 +0000 Subject: [issue22681] Add support of KOI8-T encoding In-Reply-To: <1413827370.97.0.876918138857.issue22681@psf.upfronthosting.co.za> Message-ID: <1431465767.31.0.349371540521.issue22681@psf.upfronthosting.co.za> Ned Deily added the comment: Also the 10.6 (Snow Leopard) buildbot: http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/3125/steps/test/logs/stdio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 23:23:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 21:23:57 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <1431465837.53.0.0592353481233.issue23509@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please look at the patch Raymond? There are only few days are left to the feature freeze. ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 23:35:20 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 21:35:20 +0000 Subject: [issue22682] Add support of KZ1048 (RK1048) encoding In-Reply-To: <1413836476.72.0.167337994722.issue22682@psf.upfronthosting.co.za> Message-ID: <20150512213514.120069.72000@psf.io> Roundup Robot added the comment: New changeset def3bab79c8f by Serhiy Storchaka in branch 'default': Added forgotten new files for issues #22681 and #22682. https://hg.python.org/cpython/rev/def3bab79c8f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 23:35:20 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 May 2015 21:35:20 +0000 Subject: [issue22681] Add support of KOI8-T encoding In-Reply-To: <1413827370.97.0.876918138857.issue22681@psf.upfronthosting.co.za> Message-ID: <20150512213514.120069.94460@psf.io> Roundup Robot added the comment: New changeset def3bab79c8f by Serhiy Storchaka in branch 'default': Added forgotten new files for issues #22681 and #22682. https://hg.python.org/cpython/rev/def3bab79c8f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 23:36:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 May 2015 21:36:53 +0000 Subject: [issue22681] Add support of KOI8-T encoding In-Reply-To: <1413827370.97.0.876918138857.issue22681@psf.upfronthosting.co.za> Message-ID: <1431466613.04.0.647299670069.issue22681@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Ned. I just forgive to add new encoding files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 23:39:02 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 12 May 2015 21:39:02 +0000 Subject: [issue24042] Convert os._getfullpathname() and os._isdir() to Argument Clinic In-Reply-To: <1429815662.86.0.935887508266.issue24042@psf.upfronthosting.co.za> Message-ID: <1431466742.37.0.792280282676.issue24042@psf.upfronthosting.co.za> Mark Lawrence added the comment: I've tested the patch on Windows 8.1, 32 and 64 bit release and debug builds with no problems. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 12 23:59:11 2015 From: report at bugs.python.org (magnus.forsberg) Date: Tue, 12 May 2015 21:59:11 +0000 Subject: [issue24170] IDLE crashes when I press ^ key In-Reply-To: <1431457539.55.0.53127301555.issue24170@psf.upfronthosting.co.za> Message-ID: <1431467951.22.0.880635372767.issue24170@psf.upfronthosting.co.za> magnus.forsberg added the comment: Thanks for your replies! There is a warning about Tcl/Tk: ">>> WARNING: The version of Tcl/Tk (8.5.9) in use may be unstable. Visit http://www.python.org/download/mac/tcltk/ for current information." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 00:10:33 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 12 May 2015 22:10:33 +0000 Subject: [issue24170] IDLE crashes when I press ^ key In-Reply-To: <1431457539.55.0.53127301555.issue24170@psf.upfronthosting.co.za> Message-ID: <1431468633.88.0.332843578711.issue24170@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks! I'm going to assume then that installing a current ActiveTcl 8.5.x will fix the problem for you. ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 00:12:04 2015 From: report at bugs.python.org (paul j3) Date: Tue, 12 May 2015 22:12:04 +0000 Subject: [issue24166] ArgumentParser behavior does not match generated help In-Reply-To: <1431353733.91.0.614025540349.issue24166@psf.upfronthosting.co.za> Message-ID: <1431468724.07.0.91123441767.issue24166@psf.upfronthosting.co.za> paul j3 added the comment: Look at http://bugs.python.org/issue9338 argparse optionals with nargs='?', '*' or '+' can't be followed by positionals That has a proposed patch that wraps the main argument consumption loop in another loop. The current loop alternatively consumes optionals and positionals until the argv list is done. The `consume_loop` method in that patch tries various allocations of argv strings between optionals and positionals. It performs 'dry' runs until it finds something that consumes most of the strings, and then does the actual parsing with changes to the namespace. The idea might be adapted to work with subparsers, paying attention, as you do, to the 'extras' from parse_known_args. But it might be hard to reliably perform a 'dry' run when subparsers are involved. I suspect that any change along this line will be too complex to ever be the default behavior. The chances of messing with backward compatibility are just too great. It might pass as an alternative parsing call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 00:13:32 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 12 May 2015 22:13:32 +0000 Subject: [issue22681] Add support of KOI8-T encoding In-Reply-To: <1413827370.97.0.876918138857.issue22681@psf.upfronthosting.co.za> Message-ID: <1431468812.32.0.500435222819.issue22681@psf.upfronthosting.co.za> Ned Deily added the comment: All better, thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 00:39:47 2015 From: report at bugs.python.org (Kurt Rose) Date: Tue, 12 May 2015 22:39:47 +0000 Subject: [issue24169] sockets convert out-of-range port numbers % 2**16 In-Reply-To: <1431456658.59.0.16323204969.issue24169@psf.upfronthosting.co.za> Message-ID: <1431470387.55.0.790296542001.issue24169@psf.upfronthosting.co.za> Kurt Rose added the comment: Totally agree this needs to be managed carefully. My goal here was just to raise awareness and see if there is consensus that the behavior should be changed. I came across this because an upstream process had a bug which led to impossible TCP ports being specified. So, for my use case it would have been better if create_connection() had rejected the invalid data. If we are talking about enhancements to the socket module, it would also be nice if errors included the address :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 00:55:52 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 12 May 2015 22:55:52 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1431471352.66.0.671884988107.issue23290@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Attaching a variant with several fix-ups (mostly minor): * Changed the order of the three sections to go from most-restricted-most-optimized to the general-fall-through case. The downside is that we test so->fill==0 twice. The upside is that it corresponds to my way of thinking about the logic. * Put the fill/used increments in the same order as the rest of the file. * Loop over other_entry++ instead of using indexing. This corresponds to my way of thinking about the entries and gives the compiler a stronger hint that it can avoid the indexing overhead. * Removed the unnecessary dummy check from the direct_pointer_copy case. * Switch the order of the same size and no dummies tests in the insert_clean case. * Revise the comments to be clearer about the requirements for each case. * Move the sometimes unnecessary hash variable assignments inside the conditional. ---------- Added file: http://bugs.python.org/file39352/set_faster_copy_6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 00:58:15 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 12 May 2015 22:58:15 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1431471495.8.0.0167223155255.issue23290@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Removed file: http://bugs.python.org/file39352/set_faster_copy_6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 00:59:24 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 12 May 2015 22:59:24 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1431471564.87.0.184349253529.issue23290@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file39353/set_faster_copy_6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 01:26:09 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 12 May 2015 23:26:09 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1431473169.91.0.0559430965366.issue22486@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 02:57:29 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 13 May 2015 00:57:29 +0000 Subject: [issue17394] Add slicing support to collections.deque In-Reply-To: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za> Message-ID: <1431478649.02.0.0472667151164.issue17394@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 03:01:41 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 13 May 2015 01:01:41 +0000 Subject: [issue17394] Add slicing support to collections.deque In-Reply-To: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za> Message-ID: <1431478901.44.0.0947137739948.issue17394@psf.upfronthosting.co.za> Larry Hastings added the comment: For the record, Raymond asked for permission to check this in (a new feature) for 3.5 beta 2, as he won't have time to finish it before beta 1. As 3.5 release manager I've given him permission. Go Raymond! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 03:46:56 2015 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 13 May 2015 01:46:56 +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: <1431481616.47.0.538028787595.issue9517@psf.upfronthosting.co.za> Nick Coghlan added the comment: Sure, that would be great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 05:36:03 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 May 2015 03:36: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: <1431488163.37.0.65142555224.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, Guido, Attached is a patch that fixes a refleak in 'async with' implementation. The problem is related to WITH_CLEANUP_START/WITH_CLEANUP_FINISH opcodes. For regular 'with' statements, these opcodes go one after another (essentially, it was one opcode before 'async with'). For 'async with' statements, we have a GET_AWAITABLE/YIELD_FROM pair between them. Now, if an error occurred during running a GET_AWAITABLE or a YIELD_FROM opcode, WITH_CLEANUP_FINISH was unreachable. All blocks were correctly unwound by the eval loop, but exception object got too many DECREFS. My solution is to continue using WITH_CLEANUP_START/WITH_CLEANUP_FINISH opcodes, but use SETUP_EXCEPT to guard them and nested YIELD_FROM and GET_AWAITABLE. In case of an exception, I propose to use another new opcode -- ASYNC_WITH_CLEANUP_EXCEPT. It unwinds the block set up by SETUP_EXCEPT, restores exception, NULLifies a copy of exception in the stack and does 'goto error', letting eval loop do the rest. "./python.exe -m test -R3:3 test_coroutines" with this patch reports no refleaks. I also updates test_coroutines with a lot of new 'async with' tests, I think that I got all usecases covered. Please take a look at the patch, I want to commit it as soon as possible. ---------- Added file: http://bugs.python.org/file39354/with.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 06:06:07 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 13 May 2015 04:06:07 +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: <1431489967.71.0.728294946612.issue24079@psf.upfronthosting.co.za> Martin Panter added the comment: Another problem with tostring() is that it seems you have to call it with encoding="unicode". Perhaps it would be better to suggest code like "".join(element.itertext())? I would also improve on J?r?me?s version by making the None case more explicit. And perhaps both attributes can be defined together, rather than giving a half-hearted definition linking between them: .. attribute:: text .. attribute:: tail The *text* attribute holds any text between the element's begin tag and the next tag. The *tail* attribute holds any text between the element's end tag and the next tag. These attributes are set to ``None`` if there is no text. For example, in the XML data ``1234``, the *a* element has ``None`` for both *text* and *tail* attributes, the *b* element has *text* ``"1"`` and *tail* ``"4"``, the *c* element has *text* ``"2"`` and *tail* ``None``, the *d* element has *text* ``None`` and *tail* ``"3"``. To collect the inner text of an element, use :meth:`itertext`, for example ``"".join(element.itertext())``. Applications may store arbitrary objects in these attributes. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 06:30:33 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 13 May 2015 04:30:33 +0000 Subject: [issue24086] Configparser interpolation is unexpected In-Reply-To: <1430421130.2.0.837084015548.issue24086@psf.upfronthosting.co.za> Message-ID: <1431491433.51.0.515679677665.issue24086@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 06:44:43 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 13 May 2015 04:44:43 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1431492283.02.0.607040721122.issue24053@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 07:00:58 2015 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 13 May 2015 05:00:58 +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: <1431493258.24.0.326818780244.issue24017@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm bothered by the remarkable proliferation of new opcodes for the PEP 492 handling. Is there are a specific reason this implicit exception handler can't be decomposed and implemented using the same opcodes as are used to implement explicit exception handlers? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 07:02:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 05:02:00 +0000 Subject: [issue23193] Please support "numeric_owner" in tarfile In-Reply-To: <1420728144.57.0.872420723687.issue23193@psf.upfronthosting.co.za> Message-ID: <20150513050157.88740.2705@psf.io> Roundup Robot added the comment: New changeset e5a53d75dc19 by Zachary Ware in branch 'default': Issue #23193: Skip numeric_owner tests on platforms where they don't make sense https://hg.python.org/cpython/rev/e5a53d75dc19 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 07:10:44 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 May 2015 05:10:44 +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: <1431493843.97.0.101515267068.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Is there are a specific reason this implicit exception handler can't be decomposed and implemented using the same opcodes as are used to implement explicit exception handlers? I don't think it's possible to replace ASYNC_WITH_CLEANUP_EXCEPT opcode with some combination of existing opcodes. What might be possible is to implement 'async with' without using WITH_CLEANUP_* opcodes at all. Let me try that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 07:15:50 2015 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 13 May 2015 05:15:50 +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: <1431494150.46.0.577358866753.issue24017@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm going to dig into this one locally, as it sounds to me like something may be going wrong with the refcounts in the complex stack manipulation involved in WITH_CLEANUP. It seems plausible that there's a genuinely missing incref/decref pair somewhere in the non-exceptional path, which the proposed new opcode is working around. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 07:19:39 2015 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 13 May 2015 05:19:39 +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: <1431494379.92.0.63132768774.issue24017@psf.upfronthosting.co.za> Nick Coghlan added the comment: Avoiding WITH_CLEANUP entirely in the async case also sounds like a plausible approach. Either way, I'm also on IRC now if you want to thrash this out there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 07:19:52 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 May 2015 05:19:52 +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: <1431494392.04.0.544746717261.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: I'd suggest you to look at ceval.c before PEP 492 patch then (where there is just one WITH_CLEANUP opcode). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 07:28:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 05:28:01 +0000 Subject: [issue23731] Implement PEP 488 In-Reply-To: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za> Message-ID: <20150513052758.122016.91803@psf.io> Roundup Robot added the comment: New changeset bbdbc4399b52 by Zachary Ware in branch 'default': Issue #23731: Fix tracemalloc test on Windows. https://hg.python.org/cpython/rev/bbdbc4399b52 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 07:35:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 05:35:07 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <20150513053504.8145.19131@psf.io> Roundup Robot added the comment: New changeset cc2e52878393 by Zachary Ware in branch 'default': Issue #23911: Fix ctypes test on Windows. https://hg.python.org/cpython/rev/cc2e52878393 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 07:54:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 05:54:16 +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: <20150513055413.122028.90069@psf.io> Roundup Robot added the comment: New changeset e39fd5a8501a by Nick Coghlan in branch 'default': Issue 24017: fix for "async with" refcounting https://hg.python.org/cpython/rev/e39fd5a8501a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 08:06:46 2015 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 13 May 2015 06:06:46 +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: <1431497206.0.0.747143749738.issue24017@psf.upfronthosting.co.za> Nick Coghlan added the comment: A bit more detail on the patch-as-merged: it has all of Yury's new tests, but the actual bug turned out to just be a missing INCREF/DECREF pair in WITH_CLEANUP_START and WITH_CLEANUP_FINISH. In the success case the reference counting errors cancelled each other out without causing a problem, as there was always a second live reference to the exception object on the stack. However, in the case where the awaitable threw an exception the standard exception handling machinery took care of removing the saved exception from the stack, and correctly decremented the reference count, which then caused problems due to the missing INCREF in WITH_CLEANUP_START. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 08:21:32 2015 From: report at bugs.python.org (Mahmoud Hashemi) Date: Wed, 13 May 2015 06:21:32 +0000 Subject: [issue24172] Errors in resource.getpagesize module documentation Message-ID: <1431498092.42.0.745658320728.issue24172@psf.upfronthosting.co.za> New submission from Mahmoud Hashemi: The resource module's description of resource.getpagesize is woefully misguiding. Reproduced in full for convenience: resource.getpagesize() Returns the number of bytes in a system page. (This need not be the same as the hardware page size.) This function is useful for determining the number of bytes of memory a process is using. The third element of the tuple returned by getrusage() describes memory usage in pages; multiplying by page size produces number of bytes. Besides being vague by not referring to the third element as ru_maxrss, the peak RSS for the process (i.e., not the current memory usage), tests on Linux, Darwin, and FreeBSD show the following: * Linux: ru_maxrss is in kilobytes * Darwin (OS X): ru_maxrss is in bytes * FreeBSD: ru_maxrss is in kilobytes (same as Linux) Knowing the page size is probably useful to someone, but the misinformation has definitely sent more than one person down the wrong path here. Additionally, the correct information should be up in the getrusage() method documentation, closer to relevant field descriptions. Mahmoud ---------- assignee: docs at python components: Documentation messages: 243043 nosy: docs at python, mahmoud priority: normal severity: normal status: open title: Errors in resource.getpagesize module documentation 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 Wed May 13 08:32:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 06:32:31 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <20150513063228.82433.53776@psf.io> Roundup Robot added the comment: New changeset d3582826d24c by Zachary Ware in branch 'default': Issue #20172: Convert the winsound module to Argument Clinic. https://hg.python.org/cpython/rev/d3582826d24c New changeset 6e613ecd70f0 by Zachary Ware in branch 'default': Issue #20172: Convert the winreg module to Argument Clinic. https://hg.python.org/cpython/rev/6e613ecd70f0 New changeset c190cf615eb2 by Zachary Ware in branch 'default': Issue #20172: Convert the msvcrt module to Argument Clinic. https://hg.python.org/cpython/rev/c190cf615eb2 New changeset 4cf37a50d91a by Zachary Ware in branch 'default': Issue #20172: Convert the _winapi module to Argument Clinic. https://hg.python.org/cpython/rev/4cf37a50d91a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 08:34:00 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 13 May 2015 06:34:00 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1431498840.77.0.436759433165.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: Committed, thanks for the reviews, guidance, and patience! ---------- assignee: -> zach.ware resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 08:46:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 06:46:10 +0000 Subject: [issue24042] Convert os._getfullpathname() and os._isdir() to Argument Clinic In-Reply-To: <1429815662.86.0.935887508266.issue24042@psf.upfronthosting.co.za> Message-ID: <1431499570.21.0.90593331922.issue24042@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed in 4d7175af607e. Thank you Mark for the testing. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 08:52:44 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 13 May 2015 06:52:44 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1431499964.54.0.098317039789.issue22486@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 08:54:08 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 13 May 2015 06:54:08 +0000 Subject: [issue24032] urlparse.urljoin does not add query part In-Reply-To: <1429737423.73.0.596485063186.issue24032@psf.upfronthosting.co.za> Message-ID: <1431500048.13.0.44705978678.issue24032@psf.upfronthosting.co.za> Martin Panter added the comment: This is not how URL joining is meant to work. For example if the base URL ?. . ./foo.php?param=10? produces a HTML file with a relative link to ?bar.php?, the parent path should be joined on, but not the query part. I understand the Python implementation is meant to more or less follow the RFC. See the second example at which is the same form as your case, and shows the query part being removed: Base URI: http://a/b/c/d;p?q Relative reference: "g" Target URL: "http://a/b/c/g" There are occasionally cases where keeping the base query, or even joining two sets of query parameters together, is desirable. But these cases are rare and urljoin() is not meant to handle them. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 08:58:20 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 May 2015 06:58:20 +0000 Subject: [issue24064] Make the property doctstring writeable In-Reply-To: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> Message-ID: <1431500300.02.0.580773556729.issue24064@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > If make docstrings writable, it would be good to ensure > that they exactly are strings. I don't see a need for this restriction. Even regular classes don't enforce this. ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 09:07:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 07:07:07 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1431500827.89.0.440771287718.issue23290@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Except one error (the declaration after the code), the patch LGTM. It is shame to me that I left so much non-optimized code in specialized loops. The result of my microbenchmarks is the speed up 51%, 153%, 23% and 96% respectively. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 09:12:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 07:12:16 +0000 Subject: [issue24064] Make the property doctstring writeable In-Reply-To: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> Message-ID: <1431501136.5.0.473502193334.issue24064@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Perhaps the property class now need set the tp_clear slot? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 09:13:11 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 13 May 2015 07:13:11 +0000 Subject: [issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper In-Reply-To: <1366979224.14.0.876475494511.issue17849@psf.upfronthosting.co.za> Message-ID: <1431501191.88.0.464063215612.issue17849@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 09:19:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 07:19:09 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1431501549.52.0.331683080053.issue23488@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 09:42:20 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 13 May 2015 07:42:20 +0000 Subject: [issue24136] document PEP 448 In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1431502940.57.0.725951878712.issue24136@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 09:57:39 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 May 2015 07:57:39 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1431503859.87.0.598170558905.issue23488@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You should fix the comment as mentioned in the review, otherwise looks good to me. ---------- assignee: rhettinger -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 10:07:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 08:07:26 +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: <1431504446.04.0.506465117797.issue19543@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What would you say about this Benjamin? ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 10:10:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 08:10:25 +0000 Subject: [issue24064] Make the property doctstring writeable In-Reply-To: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> Message-ID: <20150513081022.122026.58929@psf.io> Roundup Robot added the comment: New changeset 1e8a768fa0a5 by Raymond Hettinger in branch 'default': Issue #24064: Property() docstrings are now writeable. https://hg.python.org/cpython/rev/1e8a768fa0a5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 10:12:42 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 May 2015 08:12:42 +0000 Subject: [issue16669] Docstrings for namedtuple In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za> Message-ID: <1431504762.54.0.97000447287.issue16669@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: rejected -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 10:20:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 08:20:31 +0000 Subject: [issue11145] '%o' % user-defined instance In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za> Message-ID: <1431505231.9.0.713006450802.issue11145@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I there are no objection's, I'll commit the last patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 10:26:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 08:26:22 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <20150513082619.7820.59988@psf.io> Roundup Robot added the comment: New changeset 79c884cc9625 by Raymond Hettinger in branch 'default': Issue #23290: Optimize set_merge() for cases where the target is empty. https://hg.python.org/cpython/rev/79c884cc9625 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 10:31:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 08:31:37 +0000 Subject: [issue23637] Warnings error with non-ascii chars. In-Reply-To: <1426062904.63.0.0951614232281.issue23637@psf.upfronthosting.co.za> Message-ID: <1431505897.35.0.213192642124.issue23637@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: One of the worst things in Python 2 is that all can work on author's machine in ASCII-only environment, but then unhelpfully fail on user machine with non-ASCII data. Especially when needed a combination of few conditions for the fail. This issue is about one of such cases. And even worse, it makes the program fail with unfriendly error message during an attempt to output possible helpful warning. It is very desirable to me to solve it. What would you say about this Benjamin? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 10:42:10 2015 From: report at bugs.python.org (White_Rabbit) Date: Wed, 13 May 2015 08:42:10 +0000 Subject: [issue24173] curses HOWTO/implementation disagreement Message-ID: <1431506529.99.0.82682445605.issue24173@psf.upfronthosting.co.za> New submission from White_Rabbit: Similarly to issue 6771?, the curses HOWTO? talks about the curses.wrapper module and its curses.wrapper.wrapper function, but with python 2.7.5-ubuntu3 I already have the curses.wrapper function. ? https://bugs.python.org/issue6771 ? https://docs.python.org/2/howto/curses.html ---------- assignee: docs at python components: Documentation messages: 243058 nosy: White_Rabbit, docs at python priority: normal severity: normal status: open title: curses HOWTO/implementation disagreement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 10:46:16 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 May 2015 08:46:16 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1431506776.52.0.00519563507235.issue23290@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: later -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 11:02:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 09:02:11 +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: <1431507731.34.0.82972225751.issue7267@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a modification of Victor's patch, that just emits Py3k warning. Both ways, with OverflowError and Py3k DeprecationWarning, are good to me. What would you say about this Benjamin? ---------- Added file: http://bugs.python.org/file39355/int_format_c_warn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 11:07:30 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 May 2015 09:07:30 +0000 Subject: [issue24064] Make the property doctstring writeable In-Reply-To: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> Message-ID: <1431508050.6.0.123924196854.issue24064@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> serhiy.storchaka Added file: http://bugs.python.org/file39356/property_clear.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 11:08:42 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 May 2015 09:08:42 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1431508122.14.0.22153954656.issue23488@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This is good to go. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 11:09:49 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 May 2015 09:09:49 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1431508189.18.0.345987359192.issue23488@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This would have gone quicker if the size bug-fix hadn't been commingled with the optimization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 11:16:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 09:16:12 +0000 Subject: [issue24064] Make the property doctstring writeable In-Reply-To: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> Message-ID: <20150513091610.11922.69811@psf.io> Roundup Robot added the comment: New changeset bde652ae05fd by Berker Peksag in branch 'default': Issue #24064: Add __doc__ to the example in collections.rst. https://hg.python.org/cpython/rev/bde652ae05fd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 11:32:06 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 09:32:06 +0000 Subject: [issue1322] Deprecate platform.dist() and platform.linux_distribution() functions In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> Message-ID: <20150513093202.108350.12019@psf.io> Roundup Robot added the comment: New changeset 9c606c573ec0 by Berker Peksag in branch 'default': Issue #1322: platform.dist() and platform.linux_distribution() functions are now deprecated. https://hg.python.org/cpython/rev/9c606c573ec0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 11:33:20 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 13 May 2015 09:33:20 +0000 Subject: [issue1322] Deprecate platform.dist() and platform.linux_distribution() functions In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> Message-ID: <1431509600.89.0.525879085687.issue1322@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 11:34:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 09:34:48 +0000 Subject: [issue23695] idiom for clustering a data series into n-length groups In-Reply-To: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za> Message-ID: <20150513093444.82453.77245@psf.io> Roundup Robot added the comment: New changeset f7d82e40e472 by Raymond Hettinger in branch 'default': Issue #23695: Explain the zip() example for clustering a data series into n-length groups. https://hg.python.org/cpython/rev/f7d82e40e472 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 11:35:03 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 May 2015 09:35:03 +0000 Subject: [issue23695] idiom for clustering a data series into n-length groups In-Reply-To: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za> Message-ID: <1431509703.78.0.510035202577.issue23695@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 11:48:30 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 09:48:30 +0000 Subject: [issue19934] collections.Counter.most_common does not document `None` as acceptable input. In-Reply-To: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za> Message-ID: <20150513094827.11928.58828@psf.io> Roundup Robot added the comment: New changeset 8440dda28ffe by Raymond Hettinger in branch '3.4': Issue #19934: Document *None* as an acceptable input to Counter.most_common([n]) https://hg.python.org/cpython/rev/8440dda28ffe ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 11:51:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 09:51:07 +0000 Subject: [issue19934] collections.Counter.most_common does not document `None` as acceptable input. In-Reply-To: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za> Message-ID: <20150513095104.11950.23886@psf.io> Roundup Robot added the comment: New changeset df708898f27b by Raymond Hettinger in branch '2.7': Issue #19934: Document *None* as an acceptable input to Counter.most_common([n]) https://hg.python.org/cpython/rev/df708898f27b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 11:51:38 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 May 2015 09:51:38 +0000 Subject: [issue19934] collections.Counter.most_common does not document `None` as acceptable input. In-Reply-To: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za> Message-ID: <1431510698.0.0.827634230782.issue19934@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for pointing out the omission. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 12:13:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 10:13:37 +0000 Subject: [issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio In-Reply-To: <1429140944.27.0.450320519696.issue23971@psf.upfronthosting.co.za> Message-ID: <20150513101334.8141.61345@psf.io> Roundup Robot added the comment: New changeset cd0706499812 by Raymond Hettinger in branch '2.7': Issue #23971: Fix underestimated presizing in dict.fromkeys() https://hg.python.org/cpython/rev/cd0706499812 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 12:29:24 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 May 2015 10:29:24 +0000 Subject: [issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio In-Reply-To: <1429140944.27.0.450320519696.issue23971@psf.upfronthosting.co.za> Message-ID: <1431512964.84.0.410250956464.issue23971@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Fixed fromkeys() in Py2.7. Stills needs to be forward ported to 3.4/3.5. ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 12:39:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 10:39:57 +0000 Subject: [issue22064] Misleading message from 2to3 when skipping optional fixers In-Reply-To: <1406269222.0.0.185162448191.issue22064@psf.upfronthosting.co.za> Message-ID: <20150513103955.8145.45447@psf.io> Roundup Robot added the comment: New changeset 571c82d8f4c9 by Berker Peksag in branch '3.4': Issue #22064: Improve the misleading message from 2to3 when skipping optional fixers. https://hg.python.org/cpython/rev/571c82d8f4c9 New changeset 11fefeb7e941 by Berker Peksag in branch 'default': Issue #22064: Improve the misleading message from 2to3 when skipping optional fixers. https://hg.python.org/cpython/rev/11fefeb7e941 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 12:42:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 10:42:12 +0000 Subject: [issue22064] Misleading message from 2to3 when skipping optional fixers In-Reply-To: <1406269222.0.0.185162448191.issue22064@psf.upfronthosting.co.za> Message-ID: <20150513104211.1931.14525@psf.io> Roundup Robot added the comment: New changeset f6e297e698ff by Berker Peksag in branch '2.7': Issue #22064: Improve the misleading message from 2to3 when skipping optional fixers. https://hg.python.org/cpython/rev/f6e297e698ff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 12:42:57 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 13 May 2015 10:42:57 +0000 Subject: [issue22064] Misleading message from 2to3 when skipping optional fixers In-Reply-To: <1406269222.0.0.185162448191.issue22064@psf.upfronthosting.co.za> Message-ID: <1431513777.24.0.747833589111.issue22064@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Vinod. ---------- nosy: +berker.peksag resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 12:49:14 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 13 May 2015 10:49:14 +0000 Subject: [issue24065] Outdated *_RESTRICTED flags in structmember.h In-Reply-To: <1430156419.01.0.516849484938.issue24065@psf.upfronthosting.co.za> Message-ID: <1431514154.4.0.521632248994.issue24065@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 13:34:00 2015 From: report at bugs.python.org (Stuart Bishop) Date: Wed, 13 May 2015 11:34:00 +0000 Subject: [issue23757] tuple function gives wrong answer when called on list subclass with custom __iter__ In-Reply-To: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za> Message-ID: <1431516840.95.0.596171160387.issue23757@psf.upfronthosting.co.za> Stuart Bishop added the comment: Can we get this reopened? As David MacIver points out, this seems entirely a wart in tuple's constructor (compared to all the other builtin types), whereas 10977 is worrying about how 3rd party code using the C API can corrupt subclasses of builtin types (a much larger scope, and much less likely to be resolved in a good way). Does it make sense to require python code wishing to case a tuple or tuple subclass do so using tuple(list(o)), or should tuple(o) work as expected? The primary use is of course converting a mutable sequence to an immutable representation to use as a dict key. ---------- nosy: +stub _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 13:50:23 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Bellegarde?=) Date: Wed, 13 May 2015 11:50:23 +0000 Subject: [issue24174] Python crash on exit Message-ID: <1431517823.23.0.704050374474.issue24174@psf.upfronthosting.co.za> New submission from C?dric Bellegarde: Hello, i'm lollypop dev: https://github.com/gnumdk/lollypop Sometimes, when lollypop quits, i get a segfault... Here bracktrace: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff6b3b528 in _int_free (av=0x7ffff6e65620 , p=, have_lock=0) at malloc.c:3996 3996 malloc.c: Aucun fichier ou dossier de ce type. (gdb) backtrace #0 0x00007ffff6b3b528 in _int_free (av=0x7ffff6e65620 , p=, have_lock=0) at malloc.c:3996 #1 0x00000000005eae0f in code_dealloc (co=0x7ffff68be150) at ../Objects/codeobject.c:364 #2 0x00000000005f57f7 in func_dealloc (op=0x7ffff4dc4488) at ../Objects/funcobject.c:555 #3 0x00000000005f531f in sm_dealloc (sm=0x7ffff4dbd8d0) at ../Objects/funcobject.c:908 #4 0x0000000000459acf in free_keys_object (keys=0xb462e0) at ../Objects/dictobject.c:369 #5 PyDict_Clear (op=) at ../Objects/dictobject.c:1282 #6 0x000000000045c102 in PyDict_Clear (op=) at ../Objects/dictobject.c:1260 #7 0x000000000047b8d8 in type_clear (type=0xb46f28) at ../Objects/typeobject.c:3228 #8 0x000000000052bb3a in delete_garbage (old=, collectable=) at ../Modules/gcmodule.c:866 #9 collect (generation=generation at entry=2, n_collected=n_collected at entry=0x0, n_uncollectable=n_uncollectable at entry=0x0, nofail=nofail at entry=1) at ../Modules/gcmodule.c:1032 #10 0x000000000052c651 in _PyGC_CollectNoFail () at ../Modules/gcmodule.c:1638 #11 0x00000000004fbf1d in PyImport_Cleanup () at ../Python/import.c:540 #12 0x000000000050ecb9 in Py_Finalize () at ../Python/pythonrun.c:616 #13 0x000000000051125c in Py_Finalize () at ../Python/pythonrun.c:2795 #14 Py_Exit (sts=sts at entry=0) at ../Python/pythonrun.c:2793 #15 0x000000000041e409 in handle_system_exit () at ../Python/pythonrun.c:1812 #16 0x00000000005115b4 in handle_system_exit () at ../Python/pythonrun.c:1881 #17 PyErr_PrintEx (set_sys_last_vars=) at ../Python/pythonrun.c:1822 #18 0x00000000005123cf in PyErr_Print () at ../Python/pythonrun.c:1718 #19 PyRun_SimpleFileExFlags (fp=0x7ffff6e65620 , filename=0xffffffff , closeit=1, flags=0xffff800008d504d0) at ../Python/pythonrun.c:1611 #20 0x0000000000422cbc in run_file (p_cf=, filename=, fp=) at ../Modules/main.c:319 #21 Py_Main (argc=-157933448, argv=0x7ffff6a24180) at ../Modules/main.c:751 #22 0x000000000041f06c in main (argc=2, argv=) at ../Modules/python.c:69 ---------- components: Interpreter Core messages: 243074 nosy: gnumdk priority: normal severity: normal status: open title: Python crash on exit type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 14:04:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 12:04:52 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <20150513120448.82447.41188@psf.io> Roundup Robot added the comment: New changeset 4b5461dcd190 by Serhiy Storchaka in branch 'default': Issue #23488: Random generator objects now consume 2x less memory on 64-bit. https://hg.python.org/cpython/rev/4b5461dcd190 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 14:06:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 12:06:17 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1431518777.23.0.742777577098.issue23488@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 Wed May 13 14:08:49 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 13 May 2015 12:08:49 +0000 Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a null-terminated string In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za> Message-ID: <1431518929.29.0.406110315832.issue23088@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for looking at this David. I am posting utf8-null.v5.patch, which tweaks some of the wording. ---------- Added file: http://bugs.python.org/file39357/utf8-null.v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 14:17:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 12:17:49 +0000 Subject: [issue24064] Make the property doctstring writeable In-Reply-To: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> Message-ID: <1431519469.31.0.405510754651.issue24064@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- assignee: serhiy.storchaka -> rhettinger stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 14:22:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 12:22:09 +0000 Subject: [issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio In-Reply-To: <1429140944.27.0.450320519696.issue23971@psf.upfronthosting.co.za> Message-ID: <1431519729.12.0.456747854569.issue23971@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: An example of uncollectable loop if tp_clear is not implemented: class A: @property def f(self): pass A.f.__doc__ = (A.f,) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 14:23:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 12:23:20 +0000 Subject: [issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio In-Reply-To: <1429140944.27.0.450320519696.issue23971@psf.upfronthosting.co.za> Message-ID: <1431519800.87.0.541853562117.issue23971@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- Removed message: http://bugs.python.org/msg243078 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 14:23:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 12:23:37 +0000 Subject: [issue24064] Make the property doctstring writeable In-Reply-To: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> Message-ID: <1431519817.17.0.379144772345.issue24064@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: An example of uncollectable loop if tp_clear is not implemented: class A: @property def f(self): pass A.f.__doc__ = (A.f,) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 14:28:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 12:28:09 +0000 Subject: [issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio In-Reply-To: <1429140944.27.0.450320519696.issue23971@psf.upfronthosting.co.za> Message-ID: <1431520089.17.0.223198303338.issue23971@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: - if (dictresize(mp, Py_SIZE(seq))) { + if (dictresize(mp, Py_SIZE(seq) / 2 * 3)) { If Py_SIZE(seq) is 1, dictresize argument is 0. Why not wryte the expression as Py_SIZE(seq) * 3 / 2? It never overflows, because Py_SIZE(seq) is the size of allocated array of pointers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 14:31:30 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 May 2015 12:31:30 +0000 Subject: [issue24172] Errors in resource.getpagesize module documentation In-Reply-To: <1431498092.42.0.745658320728.issue24172@psf.upfronthosting.co.za> Message-ID: <1431520290.23.0.53339533218.issue24172@psf.upfronthosting.co.za> R. David Murray added the comment: Indeed, we should probably be referring people to their system's man pages for the authoritative definition of most of these fields. According to the man pages project getpagesize is no longer a POSIX API, and that should probably be noted as well (ie: it isn't present on all systems, and furthermore it is isn't accurate on all systems where it is present...apparently older GCCs got it wrong). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 14:31:51 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 May 2015 12:31:51 +0000 Subject: [issue24172] Errors in resource.getpagesize module documentation In-Reply-To: <1431498092.42.0.745658320728.issue24172@psf.upfronthosting.co.za> Message-ID: <1431520311.45.0.79947451716.issue24172@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> needs patch versions: -Python 3.2, Python 3.3, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 14:34:41 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 May 2015 12:34:41 +0000 Subject: [issue24032] urlparse.urljoin does not add query part In-Reply-To: <1429737423.73.0.596485063186.issue24032@psf.upfronthosting.co.za> Message-ID: <1431520481.24.0.102898419962.issue24032@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 14:42:56 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 13 May 2015 12:42:56 +0000 Subject: [issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio In-Reply-To: <1429140944.27.0.450320519696.issue23971@psf.upfronthosting.co.za> Message-ID: <1431520976.71.0.977156721835.issue23971@psf.upfronthosting.co.za> Mark Dickinson added the comment: >From the patch: - if (dictresize(mp, Py_SIZE(seq))) { + if (dictresize(mp, Py_SIZE(seq) / 2 * 3)) { Isn't there a risk of signed overflow here? The dictresize function has an `assert(minused >= 0)`, which is going to fail for values of `Py_SIZE(seq)` that are close to `PY_SSIZE_T_MAX` in the common case where signed overflow just wraps modulo the appropriate power of 2 (though it's undefined behaviour, so in theory it *could* do anything). ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 14:45:00 2015 From: report at bugs.python.org (koobs) Date: Wed, 13 May 2015 12:45:00 +0000 Subject: [issue24175] Test failure in test_utime on FreeBSD Message-ID: <1431521100.95.0.772714139961.issue24175@psf.upfronthosting.co.za> New submission from koobs: The following test failure is observable in koobs-freebsd9 and koobs-freebsd10 buildbots, on the 3.4 and 3.x branches. ====================================================================== FAIL: test_utime (test.test_os.StatAttributeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_os.py", line 418, in test_utime self._test_utime(self.fname, getattr, utime, 10) File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_os.py", line 405, in _test_utime self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime")) AssertionError: 1431519042.77718 != 1431519042.777179 The regression was introduced recently, with the last successful build on koobs-freebsd10 being: 3.4: revision 69951573cb0ecd264d14648b6854c2dce3974186 3.x: revision c031fa8e6884808667e4e5b800c4f2184d46279c ---------- components: Tests keywords: 3.4regression messages: 243083 nosy: koobs priority: normal severity: normal status: open title: Test failure in test_utime on FreeBSD versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 14:45:44 2015 From: report at bugs.python.org (koobs) Date: Wed, 13 May 2015 12:45:44 +0000 Subject: [issue24175] Test failure in test_utime on FreeBSD In-Reply-To: <1431521100.95.0.772714139961.issue24175@psf.upfronthosting.co.za> Message-ID: <1431521144.32.0.559236121686.issue24175@psf.upfronthosting.co.za> koobs added the comment: After running the latest builds, it appears 3.x is now green, leaving 3.4 failing ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 14:45:49 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 13 May 2015 12:45:49 +0000 Subject: [issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio In-Reply-To: <1429140944.27.0.450320519696.issue23971@psf.upfronthosting.co.za> Message-ID: <1431521149.42.0.905832580982.issue23971@psf.upfronthosting.co.za> Mark Dickinson added the comment: > It never overflows, because Py_SIZE(seq) is the size of allocated array of pointers. Ah, good point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 14:47:51 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 May 2015 12:47:51 +0000 Subject: [issue23757] tuple function gives wrong answer when called on list subclass with custom __iter__ In-Reply-To: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za> Message-ID: <1431521271.3.0.955142653086.issue23757@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: duplicate -> stage: resolved -> needs patch status: closed -> open type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 15:44:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 13:44:48 +0000 Subject: [issue5633] fix for timeit when the statement is a string and the setup is not (and tests) In-Reply-To: <1238533299.21.0.751134071386.issue5633@psf.upfronthosting.co.za> Message-ID: <1431524688.93.0.485945867939.issue5633@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Definitely there is a bug. The code of timeit is written to support string stmt and callable setup. Expected that locals available when the function is created, would be available when the function is executed. But this doesn't work. May be it worked in the earlier Python, I don't know. Due to the lack of tests this was unnoticed. Here is simpler patch that fixes the support of callable setup with string stmt. But I like Tim's approach (compile testing function using the single template), it makes the implementation simpler. I'll try to adapt it for current sources. ---------- nosy: +serhiy.storchaka stage: -> patch review versions: +Python 2.7, Python 3.4, Python 3.5 -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 15:45:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 13:45:03 +0000 Subject: [issue5633] fix for timeit when the statement is a string and the setup is not (and tests) In-Reply-To: <1238533299.21.0.751134071386.issue5633@psf.upfronthosting.co.za> Message-ID: <1431524703.5.0.734167654739.issue5633@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file39358/timeit_callable_setup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 16:07:25 2015 From: report at bugs.python.org (Thomas Caswell) Date: Wed, 13 May 2015 14:07:25 +0000 Subject: [issue24176] Incorrect parsing of unpacked expressions in call Message-ID: <1431526045.58.0.199670957567.issue24176@psf.upfronthosting.co.za> New submission from Thomas Caswell: On the current tip (changeset: 96023:4b5461dcd190) the following results in a syntax error def test(a='a', b='b'): print(a, b) opta = dict() optb = dict(a=1, b=2) test(**(opta or {})) # <- works on all python test(**optb or {}) # <- fails on current hg tip This is suspected to be a result of https://hg.python.org/cpython/rev/a65f685ba8c0 This was reported as an issue against sphinx (https://github.com/sphinx-doc/sphinx/pull/1889) and I was redirected here. As suggested by Robert Lehmann suggests the issue is https://hg.python.org/cpython/rev/a65f685ba8c0#l1.33 which should be `** test`. Making this change prevents the syntax error (patch attached). ---------- components: Interpreter Core files: unpack_grammar.patch keywords: patch messages: 243087 nosy: tcaswell priority: normal severity: normal status: open title: Incorrect parsing of unpacked expressions in call type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file39359/unpack_grammar.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 16:15:27 2015 From: report at bugs.python.org (Petr Viktorin) Date: Wed, 13 May 2015 14:15:27 +0000 Subject: [issue17762] platform.linux_distribution() should honor /etc/os-release In-Reply-To: <1366124468.64.0.40642643299.issue17762@psf.upfronthosting.co.za> Message-ID: <1431526527.02.0.528135672225.issue17762@psf.upfronthosting.co.za> Petr Viktorin added the comment: The functions have been deprecated in #1322, is it time to close this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 16:18:26 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 13 May 2015 14:18:26 +0000 Subject: [issue11145] '%o' % user-defined instance In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za> Message-ID: <1431526706.07.0.580410136827.issue11145@psf.upfronthosting.co.za> Ethan Furman added the comment: Armin indicated in his last comment that the patch still has multiple issues. Are there tests to catch the issues he previously found? That seems the best method to verify that the current (and future) patches don't break 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 16:18:38 2015 From: report at bugs.python.org (Petr Viktorin) Date: Wed, 13 May 2015 14:18:38 +0000 Subject: [issue1322] Deprecate platform.dist() and platform.linux_distribution() functions In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> Message-ID: <1431526718.97.0.42393735152.issue1322@psf.upfronthosting.co.za> Petr Viktorin added the comment: Issues #17762 and #9514 had patches to improve these functions. Time to close them? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 16:19:56 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 13 May 2015 14:19:56 +0000 Subject: [issue17762] platform.linux_distribution() should honor /etc/os-release In-Reply-To: <1366124468.64.0.40642643299.issue17762@psf.upfronthosting.co.za> Message-ID: <1431526796.58.0.509516514629.issue17762@psf.upfronthosting.co.za> Changes by Marc-Andre Lemburg : ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 16:20:47 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 13 May 2015 14:20:47 +0000 Subject: [issue9514] platform.linux_distribution() under Ubuntu returns ('debian', 'squeeze/sid', '') In-Reply-To: <1280944069.64.0.760525549047.issue9514@psf.upfronthosting.co.za> Message-ID: <1431526847.75.0.767809293419.issue9514@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: See issue1322 ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 16:21:06 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 13 May 2015 14:21:06 +0000 Subject: [issue17762] platform.linux_distribution() should honor /etc/os-release In-Reply-To: <1366124468.64.0.40642643299.issue17762@psf.upfronthosting.co.za> Message-ID: <1431526866.56.0.467353806416.issue17762@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: See issue1322 for why we're closing this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 16:21:42 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 13 May 2015 14:21:42 +0000 Subject: [issue1322] Deprecate platform.dist() and platform.linux_distribution() functions In-Reply-To: <1431526718.97.0.42393735152.issue1322@psf.upfronthosting.co.za> Message-ID: <55535DEF.3090608@egenix.com> Marc-Andre Lemburg added the comment: On 13.05.2015 16:18, Petr Viktorin wrote: > > Issues #17762 and #9514 had patches to improve these functions. Time to close them? Yes. I just did. Thanks for the reminder. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 16:21:43 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 May 2015 14:21:43 +0000 Subject: [issue24176] Incorrect parsing of unpacked expressions in call In-Reply-To: <1431526045.58.0.199670957567.issue24176@psf.upfronthosting.co.za> Message-ID: <1431526903.92.0.937302814871.issue24176@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +benjamin.peterson, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 16:36:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 14:36:36 +0000 Subject: [issue5633] fix for timeit when the statement is a string and the setup is not (and tests) In-Reply-To: <1238533299.21.0.751134071386.issue5633@psf.upfronthosting.co.za> Message-ID: <1431527796.75.0.714941147979.issue5633@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is more complicated patch, that not only fixes handling of callable setup, but also simplifies the implementation of timeit constructor. ---------- Added file: http://bugs.python.org/file39360/timeit_callable_setup_refactor.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 16:48:57 2015 From: report at bugs.python.org (Petr Viktorin) Date: Wed, 13 May 2015 14:48:57 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1431528537.69.0.9854561202.issue23699@psf.upfronthosting.co.za> Petr Viktorin added the comment: >From the discussion on the list: - It needs to be a macro, not function, to support various types (unsigned long long, float; possibly C++ stuff with overriden operators) - Another suggestion to change the order of arguments; I still think being the same as richcmp and PyObject_RichCompareBool is best. I believe all the issues raised here and on the list are handled. Could anyone re-review the patch? If the usage changes are too much, it's possible to only change Include/object.h and Doc/c-api/typeobj.rst, and leave the rest. Should I trim the patch that way? Anything else I can do to help this get merged? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 17:07:49 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 May 2015 15:07:49 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1431529669.2.0.45814160357.issue16991@psf.upfronthosting.co.za> Yury Selivanov added the comment: Eric, is there any chance this can land in 3.5? OrderedDict is a heavily used thing, everyone will benefit from a fast implementation. It's OK if we have an imperfect (but fully compatible with existing OrderedDict) implementation in 3.5. We can optimize it in 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 17:25:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 15:25:51 +0000 Subject: [issue19934] collections.Counter.most_common does not document `None` as acceptable input. In-Reply-To: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za> Message-ID: <20150513152548.25445.9402@psf.io> Roundup Robot added the comment: New changeset 68d653f9a2c9 by Andrew Kuchling in branch '2.7': #19934: fix mangled wording https://hg.python.org/cpython/rev/68d653f9a2c9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 17:34:12 2015 From: report at bugs.python.org (Kain) Date: Wed, 13 May 2015 15:34:12 +0000 Subject: [issue23995] msvcrt could not be imported In-Reply-To: <1429382716.1.0.015048526051.issue23995@psf.upfronthosting.co.za> Message-ID: <1431531252.0.0.280452706881.issue23995@psf.upfronthosting.co.za> Kain added the comment: Had the same problem but was able to fix this by rewriting the win_getpass method in getpass.py: def win_getpass(prompt='Password: ', stream=None): """Prompt for password with echo off, using Windows getch().""" if sys.stdin is not sys.__stdin__: return fallback_getpass(prompt, stream) import msvcrt for c in prompt: msvcrt.putch(c.encode('utf-8')) pw = "" while 1: c = msvcrt.getch() if c == '\r'.encode('utf-8') or c == '\n'.encode('utf-8'): break if c == '\003'.encode('utf-8'): raise KeyboardInterrupt if c == '\b'.encode('utf-8'): pw = pw[:-1] else: pw = pw + c.decode('utf-8') msvcrt.putch('\r'.encode('utf-8')) msvcrt.putch('\n'.encode('utf-8')) return pw ---------- nosy: +Kain _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 17:43:01 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 May 2015 15:43:01 +0000 Subject: [issue23995] msvcrt could not be imported In-Reply-To: <1429382716.1.0.015048526051.issue23995@psf.upfronthosting.co.za> Message-ID: <1431531781.62.0.697626559889.issue23995@psf.upfronthosting.co.za> R. David Murray added the comment: I'm setting this to release blocker because it sounds like a simple fix and I don't think we should release with these basic windows functions missing. If you (Steve) don't think it is important for the beta you could set it to deferred blocker. ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 17:58:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 15:58:54 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <20150513155849.88744.63700@psf.io> Roundup Robot added the comment: New changeset c8adc2c13c8b by Zachary Ware in branch 'default': Issue #20172: Update clinicizations to current clinic. https://hg.python.org/cpython/rev/c8adc2c13c8b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 18:04:25 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 13 May 2015 16:04:25 +0000 Subject: [issue24177] Add https?_proxy support to http.client Message-ID: <1431533065.95.0.88567271375.issue24177@psf.upfronthosting.co.za> New submission from Demian Brecht: http_proxy and https_proxy are common environment variables used cross platform. Currently, urllib.request has support for it, but http.client does not. It probably should. If support is added to http.client, the handling of proxy environment variables in urllib.request should be factored out and made to be reliant on the changes in http.client (which shouldn't require any new code, only removal). Given the common usage of the environment variables (as observed by other utilities such as wget and curl), it seems odd to require a user to know about and use the higher level urllib.request API rather than have support for it baked into the lower level http.client API. ---------- components: Library (Lib) messages: 243101 nosy: demian.brecht, orsenthil, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Add https?_proxy support to http.client type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 18:27:58 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 13 May 2015 16:27:58 +0000 Subject: [issue1683368] object.__init__ shouldn't allow args/kwds Message-ID: <1431534478.96.0.359616604119.issue1683368@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> resolved type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 18:30:54 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 May 2015 16:30:54 +0000 Subject: [issue24178] asyncio: support 'async with' for locks Message-ID: <1431534654.64.0.286846605598.issue24178@psf.upfronthosting.co.za> New submission from Yury Selivanov: The attached patch makes Locks, Conditions, Semaphores, and BoundedSemaphores support new 'async with' syntax. Because the patch contains a file that will only be checked in to the CPython repo (test_pep492.py), I decided to create the issue on bugs.python.org instead of asyncio GH repo. Please review. ---------- assignee: yselivanov components: asyncio files: alock.patch keywords: patch messages: 243102 nosy: asvetlov, gvanrossum, haypo, yselivanov priority: normal severity: normal stage: patch review status: open title: asyncio: support 'async with' for locks type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39361/alock.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 18:57:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 16:57:21 +0000 Subject: [issue11145] '%o' % user-defined instance In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za> Message-ID: <1431536241.01.0.638613323948.issue11145@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is easy to find a bug than reproduce it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 19:02:35 2015 From: report at bugs.python.org (Eric Radman) Date: Wed, 13 May 2015 17:02:35 +0000 Subject: [issue21791] Proper return status of os.WNOHANG is not always (0, 0) In-Reply-To: <1403022188.82.0.702725813338.issue21791@psf.upfronthosting.co.za> Message-ID: <1431536555.56.0.162968839129.issue21791@psf.upfronthosting.co.za> Eric Radman added the comment: Thanks for posting some simple examples. Here is the commit that I wrote to solve this problem when I encountered it in the wild: https://bitbucket.org/tk0miya/testing.postgresql/commits/3f145860cfd91e3f03f24b87c4b3b41c3a974037 Closing since I am also not able to reproduce this using a simple example. ---------- resolution: -> works for me status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 19:04:08 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 May 2015 17:04:08 +0000 Subject: [issue24179] asyncio: support 'async for' for StreamReader Message-ID: <1431536648.59.0.847721042337.issue24179@psf.upfronthosting.co.za> New submission from Yury Selivanov: This patch adds support for 'async for' syntax for StreamReader. The issue is opened on bugs.python.org instead of asyncio GH (same as issue #24178) ---------- assignee: yselivanov components: asyncio files: aread.patch keywords: patch messages: 243105 nosy: asvetlov, gvanrossum, haypo, yselivanov priority: normal severity: normal stage: patch review status: open title: asyncio: support 'async for' for StreamReader type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39362/aread.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 19:25:17 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 13 May 2015 17:25:17 +0000 Subject: [issue22555] Tracking issue for adjustments to binary/text boundary handling In-Reply-To: <1412481703.35.0.528069461639.issue22555@psf.upfronthosting.co.za> Message-ID: <1431537917.33.0.82892195166.issue22555@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 19:49:28 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 May 2015 17:49:28 +0000 Subject: [issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio In-Reply-To: <1429140944.27.0.450320519696.issue23971@psf.upfronthosting.co.za> Message-ID: <1431539368.76.0.698150665014.issue23971@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > If Py_SIZE(seq) is 1, dictresize argument is 0. That doesn't matter. The minimum dict size is 8. > Why not write Py_SIZE(seq) * 3 / 2? Because I prefer the / 2 * 3 style so I don't have to think about whether seq can overflow. Do you really feel like bike-shedding this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 19:51:12 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 May 2015 17:51:12 +0000 Subject: [issue24178] asyncio: support 'async with' for locks In-Reply-To: <1431534654.64.0.286846605598.issue24178@psf.upfronthosting.co.za> Message-ID: <1431539471.99.0.101296045001.issue24178@psf.upfronthosting.co.za> Yury Selivanov added the comment: Updated patch is attached: - '__aenter__' returns None - "with await lock" is now supported. ---------- Added file: http://bugs.python.org/file39363/alock_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 19:52:12 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 May 2015 17:52:12 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1431539532.01.0.343264790739.issue23699@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I prefer the current form so that I don't have to constantly lookup to see exactly what the macro does. If this has been around from the beginning, it might have "eased" the writing by a minute or so. But now, it will just be a barrier to maintenance. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 19:53:31 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 13 May 2015 17:53:31 +0000 Subject: [issue24162] [2.7 regression] test_asynchat test failure on i586-linux-gnu In-Reply-To: <1431303240.23.0.685308735341.issue24162@psf.upfronthosting.co.za> Message-ID: <1431539611.6.0.269898974196.issue24162@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 20:01:42 2015 From: report at bugs.python.org (Kurt Rose) Date: Wed, 13 May 2015 18:01:42 +0000 Subject: [issue24169] sockets convert out-of-range port numbers % 2**16 In-Reply-To: <1431456658.59.0.16323204969.issue24169@psf.upfronthosting.co.za> Message-ID: <1431540102.66.0.456403843618.issue24169@psf.upfronthosting.co.za> Kurt Rose added the comment: I think this may in fact be a bug. There are other places in the socket module where port is checked, create_connection() just seems to have been missed. create_connection() and socket.connect() have different behavior: >>> socket.create_connection( ('google.com', 0x10000 + 80) ) >>> socket.socket().connect( ('google.com', 0x10000 + 80) ) Traceback (most recent call last): File "", line 1, in File "C:\Python27\lib\socket.py", line 224, in meth return getattr(self._sock,name)(*args) OverflowError: getsockaddrarg: port must be 0-65535. https://hg.python.org/cpython/file/712f246da49b/Modules/socketmodule.c#l1395 if (port < 0 || port > 0xffff) { PyErr_SetString( PyExc_OverflowError, "getsockaddrarg: port must be 0-65535."); return 0; } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 20:10:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 18:10:45 +0000 Subject: [issue24178] asyncio: support 'async with' for locks In-Reply-To: <1431534654.64.0.286846605598.issue24178@psf.upfronthosting.co.za> Message-ID: <20150513181042.7800.48691@psf.io> Roundup Robot added the comment: New changeset 616f15f05530 by Yury Selivanov in branch 'default': Issue 24178: support 'async with' for asyncio locks. https://hg.python.org/cpython/rev/616f15f05530 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 20:12:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 18:12:46 +0000 Subject: [issue24064] Make the property doctstring writeable In-Reply-To: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> Message-ID: <20150513181245.11950.61552@psf.io> Roundup Robot added the comment: New changeset 2ddadd0e736d by Raymond Hettinger in branch 'default': Issue #24064: Help property() support GC https://hg.python.org/cpython/rev/2ddadd0e736d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 20:13:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 18:13:01 +0000 Subject: [issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio In-Reply-To: <1429140944.27.0.450320519696.issue23971@psf.upfronthosting.co.za> Message-ID: <1431540781.76.0.732469134516.issue23971@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, I just asking. If the minimum dict size is 8 and there is no special case for empty dicts, all is good to me. But note, that x / 2 * 3 overflows as well as x * 3 / 2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 20:14:33 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 May 2015 18:14:33 +0000 Subject: [issue24064] Make the property doctstring writeable In-Reply-To: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> Message-ID: <1431540873.14.0.570217071548.issue24064@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 20:22:34 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 13 May 2015 18:22:34 +0000 Subject: [issue24064] Make the property doctstring writeable In-Reply-To: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> Message-ID: <1431541354.76.0.28705150435.issue24064@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 20:24:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 18:24:12 +0000 Subject: [issue24179] asyncio: support 'async for' for StreamReader In-Reply-To: <1431536648.59.0.847721042337.issue24179@psf.upfronthosting.co.za> Message-ID: <20150513182407.7816.24878@psf.io> Roundup Robot added the comment: New changeset 4f6978343ef6 by Yury Selivanov in branch 'default': Issue 24179: Support 'async for' for asyncio.StreamReader. https://hg.python.org/cpython/rev/4f6978343ef6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 20:39:41 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 May 2015 18:39:41 +0000 Subject: [issue24179] asyncio: support 'async for' for StreamReader In-Reply-To: <1431536648.59.0.847721042337.issue24179@psf.upfronthosting.co.za> Message-ID: <1431542381.94.0.912066072715.issue24179@psf.upfronthosting.co.za> Yury Selivanov added the comment: Guido, thanks for review. Closing the issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 20:40:08 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 May 2015 18:40:08 +0000 Subject: [issue24178] asyncio: support 'async with' for locks In-Reply-To: <1431534654.64.0.286846605598.issue24178@psf.upfronthosting.co.za> Message-ID: <1431542408.38.0.270142534351.issue24178@psf.upfronthosting.co.za> Yury Selivanov added the comment: Guido, thanks for review. Closing the issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 20:43:20 2015 From: report at bugs.python.org (Drekin) Date: Wed, 13 May 2015 18:43:20 +0000 Subject: [issue22555] Tracking issue for adjustments to binary/text boundary handling In-Reply-To: <1412481703.35.0.528069461639.issue22555@psf.upfronthosting.co.za> Message-ID: <1431542600.79.0.451203708303.issue22555@psf.upfronthosting.co.za> Changes by Drekin : ---------- nosy: +Drekin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 21:02:22 2015 From: report at bugs.python.org (Petr Viktorin) Date: Wed, 13 May 2015 19:02:22 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1431543742.72.0.776992420741.issue23699@psf.upfronthosting.co.za> Petr Viktorin added the comment: Is it really not better to give the operation a name, rather than repeating the same ten lines every time? (Well, not the same -- all the modules code it a bit differently, but with the same meaning.) I might be true that the types in Python itself are "done", but this is intended as part of the C API. There are still modules unported to Python 3, for which *now* is the beginning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 21:46:15 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 May 2015 19:46:15 +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: <1431546375.32.0.336287032521.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: Closing the issue. I'll open a new one for missing documentation. Thanks! ---------- components: +Interpreter Core resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 21:47:27 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 May 2015 19:47:27 +0000 Subject: [issue24180] PEP 492: Documentation Message-ID: <1431546447.0.0.742432302216.issue24180@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: asvetlov, gvanrossum, haypo, ncoghlan, yselivanov priority: deferred blocker severity: normal stage: needs patch status: open title: PEP 492: Documentation type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 21:47:52 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 May 2015 19:47:52 +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: <1431546472.27.0.981696568857.issue24017@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- dependencies: +PEP 492: Documentation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 21:49:27 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 13 May 2015 19:49: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: <1431546567.83.0.149864795853.issue24017@psf.upfronthosting.co.za> Guido van Rossum added the comment: BTW, a shout out to Nick for doing most of the review for this monster patch. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 22:49:55 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 May 2015 20:49:55 +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: <20150513204952.25439.6681@psf.io> Roundup Robot added the comment: New changeset 0d80d46adfdb by Yury Selivanov in branch 'default': Issue 24017: More tests for 'async for' and 'async with'. https://hg.python.org/cpython/rev/0d80d46adfdb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 23:23:55 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 13 May 2015 21:23:55 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1431552235.65.0.0254328710293.issue23699@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'm -1 on this whole concept and I don't believe that it will make porting easier. It takes longer to learn the macro, see what it does, write tests for it, etc than it takes to model ten lines of boilerplate code. The macros make it harder for me and others to understand and maintain the code. In this regard, Python has been getting worse (harder for new maintainers to look at code and know what it is doing). Saving ten lines of clear code isn't a good motivation for going down this path. C macros are infamous for a reason. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 23:36:24 2015 From: report at bugs.python.org (ppperry) Date: Wed, 13 May 2015 21:36:24 +0000 Subject: [issue10977] Concrete obect C API considered harmful to subclasses of builtin typesje In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za> Message-ID: <1431552984.48.0.913495049571.issue10977@psf.upfronthosting.co.za> Changes by ppperry : ---------- title: Concrete object C API considered harmful to subclasses of builtin types -> Concrete obect C API considered harmful to subclasses of builtin typesje _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 23:36:45 2015 From: report at bugs.python.org (ppperry) Date: Wed, 13 May 2015 21:36:45 +0000 Subject: [issue10977] Concrete object C API considered harmful to subclasses of builtin typesje In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za> Message-ID: <1431553005.61.0.737835136997.issue10977@psf.upfronthosting.co.za> Changes by ppperry : ---------- title: Concrete obect C API considered harmful to subclasses of builtin typesje -> Concrete object C API considered harmful to subclasses of builtin typesje _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 23:37:51 2015 From: report at bugs.python.org (ppperry) Date: Wed, 13 May 2015 21:37:51 +0000 Subject: [issue10977] Concrete object C API considered harmful to subclasses of builtin types In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za> Message-ID: <1431553071.28.0.553488701198.issue10977@psf.upfronthosting.co.za> Changes by ppperry : ---------- title: Concrete object C API considered harmful to subclasses of builtin typesje -> Concrete object C API considered harmful to subclasses of builtin types _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 23:47:26 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 13 May 2015 21:47:26 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1431553646.34.0.269180043384.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: @Yury, I'm mostly just waiting for Raymond to give it at least a quick sanity-check. I know there is at least 1 ref leak, but that can be sorted out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 23:47:50 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 13 May 2015 21:47:50 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 Message-ID: <1431553670.83.0.456032288115.issue24181@psf.upfronthosting.co.za> New submission from Terry J. Reedy: In console: pcbuild/win32/python_d.exe -m test -j6 ... [393/395/1] test_fileio Traceback (most recent call last): File "F:\Python\dev\35\lib\runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "F:\Python\dev\35\lib\runpy.py", line 85, in _run_code exec(code, run_globals) File "F:\Python\dev\35\lib\test\__main__.py", line 3, in regrtest.main_in_temp_cwd() File "F:\Python\dev\35\lib\test\regrtest.py", line 1564, in main_in_temp_cwd main() File "F:\Python\dev\35\lib\test\regrtest.py", line 738, in main raise Exception("Child error on {}: {}".format(test, result[1])) Exception: Child error on test_fileio: Exit code 2147483651 In crash box: Debug assertion failed /dd/vctools/crt_bld/self_x86/crt/src/chsize.c line 56 _osfile(desfile) & FOPEN By leaving box alone, all but about 4 tests finished. When clicked on button, fileio message appeared. On previous run, click as soon as box appeared, and console window frooze much sooner, with just half of tests run. There were also 'Python_d.exe has stopped working' messages, but same true with 3.4 tests, which finished. ---------- components: Tests, Windows messages: 243122 nosy: steve.dower, terry.reedy, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: test_fileio crash, 3.5, Win 7 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 23:48:57 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 May 2015 21:48:57 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1431553737.48.0.926400118586.issue16991@psf.upfronthosting.co.za> Yury Selivanov added the comment: @Eric, can you set priority to "release blocker"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 23:49:42 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 13 May 2015 21:49:42 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1431553782.86.0.0452029899786.issue16991@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 23:49:56 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 13 May 2015 21:49:56 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 In-Reply-To: <1431553670.83.0.456032288115.issue24181@psf.upfronthosting.co.za> Message-ID: <1431553796.54.0.297222525379.issue24181@psf.upfronthosting.co.za> Zachary Ware added the comment: Which version of MSVC are you using? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 13 23:58:07 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 13 May 2015 21:58:07 +0000 Subject: [issue24182] test_tcl assertion failure, 2.7, Win 7 Message-ID: <1431554287.05.0.384397214911.issue24182@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Win 7, fresh build, only on 2.7 File "F:\Python\dev\27\lib\test\test_tcl.py", line 225, in test_evalfile_null_in_result self.assertEqual(tcl.eval('set a'), 'a\xc0\x80b') Fails ---------- messages: 243125 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal stage: needs patch status: open title: test_tcl assertion failure, 2.7, Win 7 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 00:00:32 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 13 May 2015 22:00:32 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 In-Reply-To: <1431553670.83.0.456032288115.issue24181@psf.upfronthosting.co.za> Message-ID: <1431554432.7.0.415741733832.issue24181@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The same '2010' used for 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 00:12:38 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 13 May 2015 22:12:38 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 In-Reply-To: <1431554432.7.0.415741733832.issue24181@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: That may be the problem; it may be time for you to upgrade to VS 2015, which is now in RC. As recently as this morning, I've had a clean test run with 2015 Community Edition on Windows 8.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 00:45:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 May 2015 22:45:13 +0000 Subject: [issue24182] test_tcl assertion failure, 2.7, Win 7 In-Reply-To: <1431554287.05.0.384397214911.issue24182@psf.upfronthosting.co.za> Message-ID: <1431557113.25.0.372649014334.issue24182@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is error message? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 01:00:19 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 13 May 2015 23:00:19 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 In-Reply-To: <1431553670.83.0.456032288115.issue24181@psf.upfronthosting.co.za> Message-ID: <1431558019.89.0.0793520441678.issue24181@psf.upfronthosting.co.za> Steve Dower added the comment: It's entirely possible that I missed a _PyVerify_fd call around the ftruncate implementation, since that function is now a no-op for VS 2015 builds. The only reason I didn't remove them all when adding the new handling for was because there was no trustworthy version of VC14 around then (it was still Preview). VS 2015 RC is trustworthy, so it is time to upgrade, but I'm still not quite ready to aggressively break everyone who hasn't. Maybe we should? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 01:46:32 2015 From: report at bugs.python.org (Timothy Cardenas) Date: Wed, 13 May 2015 23:46:32 +0000 Subject: [issue24183] ABCMeta classes do not support the **kwargs standard class interface Message-ID: <1431560792.95.0.495596888848.issue24183@psf.upfronthosting.co.za> New submission from Timothy Cardenas: Summary: Any class that derives from the ABCMeta class doesn't support keyword variable arguments as defined here :https://www.python.org/dev/peps/pep-3115/. Expected: If i define a simple class that derives from ABCMeta that has a kwarg the class should be created (see below from collections import UserDict class MyDict(UserDict, bar='baz'): pass dictionary = MyDict() # Expect this to create a new instance of MyDict. Actual: from collections import UserDict class MyDict(UserDict, bar='baz'): pass dictionary = MyDict() # This call fails because UserDict inherits from ABCMeta Traceback (most recent call last): File "abc_meta.py", line 4, in class MyDict(UserDict, bar='baz'): ---------- components: Library (Lib) files: abc_meta.py messages: 243130 nosy: trcarden priority: normal severity: normal status: open title: ABCMeta classes do not support the **kwargs standard class interface type: behavior versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39364/abc_meta.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 01:56:39 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 May 2015 23:56:39 +0000 Subject: [issue24183] ABCMeta classes do not support the **kwargs standard class interface In-Reply-To: <1431560792.95.0.495596888848.issue24183@psf.upfronthosting.co.za> Message-ID: <1431561399.02.0.243723541649.issue24183@psf.upfronthosting.co.za> R. David Murray added the comment: ABCMeta does not support arbitrary keyword arguments, that is correct. If you want keyword arguments to be handled, you need to write your own metaclass that does so. (I'm pretty sure I'm reading the PEP correctly...if not I'm sure one of the other core devs will re-open this ;) ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 02:24:29 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 14 May 2015 00:24:29 +0000 Subject: [issue23757] tuple function gives wrong answer when called on list subclass with custom __iter__ In-Reply-To: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za> Message-ID: <1431563069.46.0.43898845009.issue23757@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +patch Added file: http://bugs.python.org/file39365/fix_list_to_tuple.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 02:25:02 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 14 May 2015 00:25:02 +0000 Subject: [issue23757] tuple function gives wrong answer when called on list subclass with custom __iter__ In-Reply-To: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za> Message-ID: <1431563102.11.0.285892445959.issue23757@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +easy -patch priority: normal -> high versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 02:32:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 May 2015 00:32:33 +0000 Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a null-terminated string In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za> Message-ID: <20150514003229.25431.42930@psf.io> Roundup Robot added the comment: New changeset 99d2f83290c0 by R David Murray in branch '3.4': #23088: Clarify null termination of bytes and strings in C API. https://hg.python.org/cpython/rev/99d2f83290c0 New changeset 863f7c57081b by R David Murray in branch 'default': Merge: #23088: Clarify null termination of bytes and strings in C API. https://hg.python.org/cpython/rev/863f7c57081b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 02:34:22 2015 From: report at bugs.python.org (Timothy Cardenas) Date: Thu, 14 May 2015 00:34:22 +0000 Subject: [issue24183] ABCMeta classes do not support the **kwargs standard class interface In-Reply-To: <1431560792.95.0.495596888848.issue24183@psf.upfronthosting.co.za> Message-ID: <1431563662.24.0.827126550893.issue24183@psf.upfronthosting.co.za> Timothy Cardenas added the comment: Hmm Ok. You are right i can do the following: from collections import UserDict from abc import ABCMeta class MetaMyDict(ABCMeta): @classmethod def __prepare__(cls, name, bases, **kwargs): return {} def __new__(mcls, name, bases, namespace, **kwds): return super().__new__(mcls, name, bases, namespace) def __init__(cls, name, bases, namespace, **kargs): return super().__init__(name, bases, namespace) class MyDict(UserDict, metaclass=MetaMyDict, bar='baz'): pass dictionary = MyDict() But I guess i would have expected a core lib library to be consistent with the data model https://docs.python.org/3.4/reference/datamodel.html#preparing-the-class-namespace. As it stands an end user can't get a subclass of ABCMeta to work with the same **kwargs interface without creating a custom metaclass that strips it out before passing to ABCMeta. Wouldn't it be much easier and technically correct for the core ABCMeta library to adopt the same interface contract for class creation introduced in python3? ---------- resolution: not a bug -> remind status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 02:35:21 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 May 2015 00:35:21 +0000 Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a null-terminated string In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za> Message-ID: <1431563721.11.0.755891176722.issue23088@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, I just realized I committed this without checking how it rendered... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 02:41:12 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 May 2015 00:41:12 +0000 Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a null-terminated string In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za> Message-ID: <1431564072.79.0.16192623316.issue23088@psf.upfronthosting.co.za> R. David Murray added the comment: OK, I didn't see anything obvious at least :) Thanks, Martin. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 02:49:29 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 May 2015 00:49:29 +0000 Subject: [issue22931] cookies with square brackets in value In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za> Message-ID: <1431564569.88.0.966909773165.issue22931@psf.upfronthosting.co.za> R. David Murray added the comment: This needs a review from the people who created and applied the security patch. Demian, did you add them to nosy already? Since this is a regression I'm going to mark it as a release blocker so Benjamin can decide whether or not it is important enough to go in to 2.7.10 even though the RC is already out. ---------- nosy: +benjamin.peterson, georg.brandl, larry priority: normal -> release blocker versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 02:55:59 2015 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 14 May 2015 00:55:59 +0000 Subject: [issue24157] test_urandom_fd_reopened failure on Mac OS X In-Reply-To: <1431267025.82.0.688433219235.issue24157@psf.upfronthosting.co.za> Message-ID: <1431564959.49.0.998904407934.issue24157@psf.upfronthosting.co.za> Skip Montanaro added the comment: Sorry for the delay. With LANG=C I get this extra bit of output: 'this test triggers the Crash Reporter, that is intentional\x80TbG=\x0f\x19t' With LANG=en_US.UTF-8 (the encoding of my Terminal instance), I get this: 'this test triggers the Crash Reporter, that is intentional\xf6\xcd\x7f\xf1O\x91\t\xac' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 03:06:51 2015 From: report at bugs.python.org (Alex Lord) Date: Thu, 14 May 2015 01:06:51 +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: <1431565611.78.0.459762640299.issue16864@psf.upfronthosting.co.za> Changes by Alex Lord : Added file: http://bugs.python.org/file39366/sqlite_lastrowid_35_updated.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 03:29:19 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 01:29:19 +0000 Subject: [issue24183] ABCMeta classes do not support the **kwargs standard class interface In-Reply-To: <1431560792.95.0.495596888848.issue24183@psf.upfronthosting.co.za> Message-ID: <1431566959.77.0.804243783124.issue24183@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Wouldn't it be much easier and technically correct for the core ABCMeta library to adopt the same interface contract for class creation introduced in python3? No, it would not be technically correct. For the same reason, object.__init__ does not accept any parameters. ---------- nosy: +yselivanov resolution: remind -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 03:38:03 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 May 2015 01:38:03 +0000 Subject: [issue24183] ABCMeta classes do not support the **kwargs standard class interface In-Reply-To: <1431560792.95.0.495596888848.issue24183@psf.upfronthosting.co.za> Message-ID: <1431567483.5.0.386527326804.issue24183@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, this is exactly analogous to object.__init__ not accepting arguments, but subclasses being free to do so. ABCMeta *does* adopt the contract. keyword arguments to the class constructor are not accepted unless you write a meta class that accepts them. Period. (That is, "class Foo(bar='baz'): pass" fails.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 04:06:12 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 14 May 2015 02:06:12 +0000 Subject: [issue2704] IDLE: Patch to make PyShell behave more like a Terminal interface In-Reply-To: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za> Message-ID: <1431569172.49.0.360714979878.issue2704@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The PyShell patch does two things that I want to consider separately, and carefully, along with other possible solutions to the perceived problems. 1. Go to end-of-file when entering a letter or number in a read-only text area. In msg110889 Tal says "Note that not only letter/number keys should be passed on." I see the point, but expanding the set seems to me a complication and a move in the wrong direction. Doing nothing, or maybe beeping, is a normal response to entry in a read-only area. Regardless of what I wrote before, I am not completely comfortable with adding magical behavior. The fixed key-binding for goto-file-end is cntl-end (command-end). I propose adding as a synonym. Currently, it sometimes opens a completion box even in read-only areas, where it is useless and annoying. This should be changed anyway, and having it cause the cursor to jump to me seems to fit with its indent behavior. 2. Make and do double duty to both traverse statements in the history and lines within the current statement. However, the complicated rules to juggle two roles, in msg68299, make my head hurt. I would rather use Shift-, cntl-, or alt- up/down instead. The fundamental issue, touched on by Cherniavsky Beni in msg67706, is that Python is not a command-line language. It is a statement language. It does not fit well in a command-line terminal where history consists of lines rather than statements. PyShell is a statement terminal designed to fit Python, not a line terminal. I appreciate this *much* better than 7 years ago. When I wrote msg66119, I probably was not aware of being able to retrieve statements with Alt-P. ---------- stage: patch review -> needs patch versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 04:14:56 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 14 May 2015 02:14:56 +0000 Subject: [issue2704] IDLE: Patch to make PyShell behave more like a Terminal interface In-Reply-To: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za> Message-ID: <1431569696.21.0.268014388271.issue2704@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The changes I proposed would not have to be extensions, as they are basically non-conflicting alternate keybindings, though the tab effect would have to be conditional. I will experiment with using prefix-up/down in one of my installed pythons. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 04:27:36 2015 From: report at bugs.python.org (Timothy Cardenas) Date: Thu, 14 May 2015 02:27:36 +0000 Subject: [issue24183] ABCMeta classes do not support the **kwargs standard class interface In-Reply-To: <1431560792.95.0.495596888848.issue24183@psf.upfronthosting.co.za> Message-ID: <1431570456.05.0.952985032446.issue24183@psf.upfronthosting.co.za> Timothy Cardenas added the comment: Ahhh i see now. Even the simple case "class Foo(bar='baz'): pass" fails. I misunderstood the documentation then. I thought that python 3 introduced a new interface for all classes when it actually just introduced the option to add keyword arguments to your own metaclasses but didn't alter the base level class interface. I wanted a bit more background around the object.__init__ and found this ticket: http://bugs.python.org/issue1683368. While this is probably not the only place where this comes up I see the tact that the python core team took and understand your reference more completely now. I thank both of you for your help and quick responses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 04:32:26 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 May 2015 02:32:26 +0000 Subject: [issue23995] msvcrt could not be imported In-Reply-To: <1429382716.1.0.015048526051.issue23995@psf.upfronthosting.co.za> Message-ID: <1431570746.69.0.00451282633874.issue23995@psf.upfronthosting.co.za> Steve Dower added the comment: I'll just remove the ifdefs. We don't support any Windows versions that don't have these functions. ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 04:33:32 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 May 2015 02:33:32 +0000 Subject: [issue23995] msvcrt could not be imported In-Reply-To: <1429382716.1.0.015048526051.issue23995@psf.upfronthosting.co.za> Message-ID: <1431570812.01.0.636720247308.issue23995@psf.upfronthosting.co.za> Steve Dower added the comment: Short of hard-coding a list of expected functions and using hasattr, anyone have any ideas about how to test stuff like this? I kind of feel like alpha/beta releases are the most efficient way to find these. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 04:35:20 2015 From: report at bugs.python.org (Alex Lord) Date: Thu, 14 May 2015 02:35:20 +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: <1431570920.12.0.124298297878.issue16864@psf.upfronthosting.co.za> Changes by Alex Lord : Added file: http://bugs.python.org/file39367/sqlite_lastrowid_35_updated_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 04:36:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 May 2015 02:36:28 +0000 Subject: [issue23995] msvcrt could not be imported In-Reply-To: <1429382716.1.0.015048526051.issue23995@psf.upfronthosting.co.za> Message-ID: <20150514023625.8159.84295@psf.io> Roundup Robot added the comment: New changeset d56a941865fb by Steve Dower in branch 'default': Issue #23995: Removes _WCONIO_DEFINED check as the wchar_t console functions are always available. https://hg.python.org/cpython/rev/d56a941865fb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 04:49:47 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 14 May 2015 02:49:47 +0000 Subject: [issue23995] msvcrt could not be imported In-Reply-To: <1429382716.1.0.015048526051.issue23995@psf.upfronthosting.co.za> Message-ID: <1431571787.42.0.0696178980433.issue23995@psf.upfronthosting.co.za> Mark Lawrence added the comment: Shouldn't tests for these functions be part of our testing of the io module or similar? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 04:50:39 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 May 2015 02:50:39 +0000 Subject: [issue22027] RFC 6531 (SMTPUTF8) support in smtplib In-Reply-To: <1405978140.81.0.388141454985.issue22027@psf.upfronthosting.co.za> Message-ID: <1431571839.98.0.179078355365.issue22027@psf.upfronthosting.co.za> R. David Murray added the comment: Coming back to this, I noticed a number of things wrong with the logic that I'm not sure how I missed before. I had to rewrite pretty much all of the logic. The good news is the patch is now smaller :) The new tests are failing, because they are wrong: the msg argument to sendmail/mail *must* be a byte string if smtputf8 is in effect, since an email message may contain multiple encodings as well as other binary data. (Well, the msg argument could be an ascii string, but what would be the point?) I'm uploading this without fixing the tests because I'm out of time for now and may not get back to it before the weekend. Perhaps someone else will have time to work on the tests before then. ---------- nosy: +maciej.szulik Added file: http://bugs.python.org/file39368/smtplib_smtputf8v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 05:24:31 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 03:24:31 +0000 Subject: [issue24184] PEP 492: Add AsyncIterator and AsyncIterable to collections.abc Message-ID: <1431573871.68.0.565476513096.issue24184@psf.upfronthosting.co.za> New submission from Yury Selivanov: The attached patch adds AsyncIterator & AsyncIterable to collections.abc module. ---------- assignee: yselivanov components: Library (Lib) files: async_abc.patch keywords: patch messages: 243148 nosy: asvetlov, gvanrossum, haypo, ncoghlan, yselivanov priority: normal severity: normal stage: patch review status: open title: PEP 492: Add AsyncIterator and AsyncIterable to collections.abc type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39369/async_abc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 05:27:38 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 03:27:38 +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: <1431574058.26.0.240647012091.issue24017@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- dependencies: +PEP 492: Add AsyncIterator and AsyncIterable to collections.abc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 05:36:41 2015 From: report at bugs.python.org (Taylor Marks) Date: Thu, 14 May 2015 03:36:41 +0000 Subject: [issue24185] Add Function for Sending File to Trash (or Recycling Bin) Message-ID: <1431574601.59.0.7462724115.issue24185@psf.upfronthosting.co.za> New submission from Taylor Marks: When you have a file that you don't think you need anymore, the proper thing to do with it is move it to the Trash (or Recycling Bin, if you're on Windows.) The standard library, however, doesn't offer any way of doing this currently. Instead, the only thing it offers is the ability to delete files. Deleting files is a potentially dangerous operation. A novice programmer may end up carelessly delete the wrong file. I would suggest adding in a new function which allows for cross-platform moving of files to trash. It could go into the existing shutil or os modules. Or it could get its own module (like glob). It could be based upon (or even be exactly) this implementation: https://pypi.python.org/pypi/Send2Trash https://github.com/hsoft/send2trash Afterwards, the docs for os.remove and shutil.rmtree could have a warning added that suggests that instead of using such dangerous functions, it may be best for the user to use the new function. (If this is not the place to propose additions to the standard library, please redirect me for where I should go instead. PEP 5 covers how the language should evolve, but then only has a link to bugs.python.org.) ---------- components: Library (Lib) messages: 243149 nosy: Taylor.Marks priority: normal severity: normal status: open title: Add Function for Sending File to Trash (or Recycling Bin) type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 05:45:56 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 May 2015 03:45:56 +0000 Subject: [issue23995] msvcrt could not be imported In-Reply-To: <1429382716.1.0.015048526051.issue23995@psf.upfronthosting.co.za> Message-ID: <1431575156.06.0.182325481271.issue23995@psf.upfronthosting.co.za> Steve Dower added the comment: I wouldn't have thought so, since the IO stack is entirely portable, at least from the Python side of things. This would have to have been a test that somehow knows about optional functions and notifies you if they're missing but without failing the run. I don't think that's feasible, at least in this case, since there's no way to know that the function should be there. Potentially we could set up a test to ensure that we don't remove public functions by dumping a complete list, but that's beyond the scope of this one issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 06:43:04 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 May 2015 04:43:04 +0000 Subject: [issue24186] OpenSSL causes buffer overrun exception Message-ID: <1431578584.97.0.131803354946.issue24186@psf.upfronthosting.co.za> New submission from Steve Dower: There is an issue where an optimised OpenSSL function causes a buffer overrun in 64-bit Windows builds and terminates the process (this is why the buildbots aren't getting very far right now). I suspect it may be a compiler issue, but for now I'm disabling the optimised function. This issue is a reminder to myself to re-enable the function when we have a fix. I'll follow up with the compiler team and possibly the OpenSSL team separately. ---------- assignee: steve.dower components: Windows messages: 243151 nosy: steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: OpenSSL causes buffer overrun exception type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 06:44:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 May 2015 04:44:18 +0000 Subject: [issue24186] OpenSSL causes buffer overrun exception In-Reply-To: <1431578584.97.0.131803354946.issue24186@psf.upfronthosting.co.za> Message-ID: <20150514044414.25435.73238@psf.io> Roundup Robot added the comment: New changeset 25d78aa1ec21 by Steve Dower in branch 'default': Issue #24186: Disable optimised OpenSSL functions on 64-bit Windows to avoid crashing. https://hg.python.org/cpython/rev/25d78aa1ec21 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 07:31:26 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 14 May 2015 05:31:26 +0000 Subject: [issue24182] test_tcl assertion failure, 2.7, Win 7 In-Reply-To: <1431554287.05.0.384397214911.issue24182@psf.upfronthosting.co.za> Message-ID: <1431581486.98.0.687076570957.issue24182@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Reran, same result: 'a' != 'a\xc0\x80b' in class TclTest. Ran 39 tests, skipped 4 (bigmem) tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 07:34:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 May 2015 05:34:58 +0000 Subject: [issue24182] test_tcl assertion failure, 2.7, Win 7 In-Reply-To: <1431554287.05.0.384397214911.issue24182@psf.upfronthosting.co.za> Message-ID: <1431581698.92.0.192713330961.issue24182@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What if comment out this line? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 07:37:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 May 2015 05:37:55 +0000 Subject: [issue23757] tuple function gives wrong answer when called on list subclass with custom __iter__ In-Reply-To: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za> Message-ID: <1431581875.59.0.284751521769.issue23757@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 07:45:07 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 14 May 2015 05:45:07 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 In-Reply-To: <1431553670.83.0.456032288115.issue24181@psf.upfronthosting.co.za> Message-ID: <1431582307.0.0.0402526665636.issue24181@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I just downloaded the 3mb vc_community.exe. I intend to try it tomorrow and report. Unless you intend to support compiling with vs2010 after 3.5 is released, and from the devguide and your comment I presume not, then with beta nearing, I would agree that we should be testing 2015 builds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 07:50:24 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 14 May 2015 05:50:24 +0000 Subject: [issue24182] test_tcl assertion failure, 2.7, Win 7 In-Reply-To: <1431554287.05.0.384397214911.issue24182@psf.upfronthosting.co.za> Message-ID: <1431582624.4.0.305434993588.issue24182@psf.upfronthosting.co.za> Terry J. Reedy added the comment: All 39 pass. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 07:53:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 May 2015 05:53:59 +0000 Subject: [issue24182] test_tcl assertion failure, 2.7, Win 7 In-Reply-To: <1431554287.05.0.384397214911.issue24182@psf.upfronthosting.co.za> Message-ID: <1431582839.75.0.142570388459.issue24182@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is Tcl version? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 08:06:42 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 14 May 2015 06:06:42 +0000 Subject: [issue23757] tuple function gives wrong answer when called on list subclass with custom __iter__ In-Reply-To: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za> Message-ID: <1431583602.92.0.0280428102568.issue23757@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Added a patch. Needs to have the OP's test case added. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 08:10:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 May 2015 06:10:22 +0000 Subject: [issue23757] tuple function gives wrong answer when called on list subclass with custom __iter__ In-Reply-To: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za> Message-ID: <1431583822.92.0.134666237079.issue23757@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And it would be nice to add the same test for list, set, etc (if they don't exist). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 08:37:23 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 14 May 2015 06:37:23 +0000 Subject: [issue24136] document PEP 448 In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1431585443.41.0.785151640204.issue24136@psf.upfronthosting.co.za> Neil Girdhar added the comment: Just updated the "what's new". Also, thank you for adding my name to Misc/Acks. Should we also add Joshua Landau's name? He helped me quite a bit with the implementation, and he wrote the PEP. ---------- keywords: +patch nosy: +neil.g Added file: http://bugs.python.org/file39370/whatsnew.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 10:07:46 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 14 May 2015 08:07:46 +0000 Subject: [issue23985] Crash when deleting slices from duplicated bytearray In-Reply-To: <1429252668.91.0.45841644858.issue23985@psf.upfronthosting.co.za> Message-ID: <1431590866.71.0.547252541149.issue23985@psf.upfronthosting.co.za> Martin Panter added the comment: Antoine, would you have a chance to review my patches? I assume you were responsible for adding the ob_start field. It would be nice to see this bug fixed in the next 3.4 and 3.5 releases. As well as the original poster?s problem, I suspect this bug may be the cause of some occasional strange behaviour I have seen in my own bytearray() FIFO type code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 10:08:08 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 08:08:08 +0000 Subject: [issue23985] Crash when deleting slices from duplicated bytearray In-Reply-To: <1429252668.91.0.45841644858.issue23985@psf.upfronthosting.co.za> Message-ID: <1431590888.7.0.49305407315.issue23985@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sorry. I'll take a look! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 11:32:49 2015 From: report at bugs.python.org (Jon) Date: Thu, 14 May 2015 09:32:49 +0000 Subject: [issue24187] del statement documentation doesn't mention name binding behaviour Message-ID: <1431595969.01.0.32289440375.issue24187@psf.upfronthosting.co.za> New submission from Jon: The documentation for the del keyword in the language reference doesn't mention the name binding behaviour: https://docs.python.org/3/reference/simple_stmts.html#grammar-token-del_stmt It is mentioned in section 4.1 where it says: "A target occurring in a del statement is also considered bound for this purpose" But it's really not obvious to look there when trying to understand what del does. It would be great if this information were added or a reference made to the other section. ---------- assignee: docs at python components: Documentation messages: 243163 nosy: docs at python, jc13 priority: normal severity: normal status: open title: del statement documentation doesn't mention name binding behaviour type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 11:35:04 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 09:35:04 +0000 Subject: [issue24188] Signature objects not hashable Message-ID: <1431596104.89.0.97986855115.issue24188@psf.upfronthosting.co.za> New submission from Antoine Pitrou: inspect.Signature objects are immutable, but they are not hashable. It would be useful if they were. (I would have a similar request for bound arguments but unfortunately their mutability may make it less desirable) ---------- components: Library (Lib) messages: 243164 nosy: pitrou, yselivanov priority: normal severity: normal status: open title: Signature objects not hashable type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 11:47:40 2015 From: report at bugs.python.org (Anand B Pillai) Date: Thu, 14 May 2015 09:47:40 +0000 Subject: [issue23698] Multiprocessing.Manager: fix behavior and doc inconsistencies In-Reply-To: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za> Message-ID: <1431596860.75.0.139209382485.issue23698@psf.upfronthosting.co.za> Anand B Pillai added the comment: @sbt - Any comments on this ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 11:51:42 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 09:51:42 +0000 Subject: [issue24189] Parameter doesn't expose its index Message-ID: <1431597102.49.0.279641303992.issue24189@psf.upfronthosting.co.za> New submission from Antoine Pitrou: A signature Parameter object only exposes its name, not its index in the signature. I think that would be a useful information to have. ---------- components: Library (Lib) messages: 243166 nosy: pitrou, yselivanov priority: normal severity: normal status: open title: Parameter doesn't expose its index type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 12:20:00 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 10:20:00 +0000 Subject: [issue24190] BoundArguments facility to inject defaults Message-ID: <1431598800.08.0.914868739501.issue24190@psf.upfronthosting.co.za> New submission from Antoine Pitrou: The recipe to inject default values in a BoundArguments instance is given in the doc, but it's not trivial. Furthermore, it's actually incomplete: it doesn't handle any star-arguments, e.g.: >>> sig = inspect.signature(f) >>> ba = sig.bind(2, d=4) >>> for param in sig.parameters.values(): ... if (param.name not in ba.arguments ... and param.default is not param.empty): ... ba.arguments[param.name] = param.default ... >>> ba.arguments OrderedDict([('a', 2), ('d', 4), ('b', 5)]) ba['c'] would ideally contain the empty tuple. ---------- components: Library (Lib) messages: 243167 nosy: pitrou, yselivanov priority: normal severity: normal status: open title: BoundArguments facility to inject defaults type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 12:21:10 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 10:21:10 +0000 Subject: [issue24191] BoundArguments.signature not documented Message-ID: <1431598870.49.0.134760304526.issue24191@psf.upfronthosting.co.za> New submission from Antoine Pitrou: The "signature" property on BoundArguments seems to be deliberately public (since there's also a private "_signature" attribute), but it's not documented. ---------- assignee: docs at python components: Documentation keywords: easy messages: 243168 nosy: docs at python, pitrou, yselivanov priority: normal severity: normal status: open title: BoundArguments.signature not documented type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 12:22:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 May 2015 10:22:19 +0000 Subject: [issue24188] Signature objects not hashable In-Reply-To: <1431596104.89.0.97986855115.issue24188@psf.upfronthosting.co.za> Message-ID: <1431598939.58.0.374351550368.issue24188@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: ([],) is immutable, but is not hashable. If default values affect the hash, the signature can't be always hashable. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 12:22:29 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 10:22:29 +0000 Subject: [issue24190] BoundArguments facility to inject defaults In-Reply-To: <1431598800.08.0.914868739501.issue24190@psf.upfronthosting.co.za> Message-ID: <1431598949.55.0.69045924575.issue24190@psf.upfronthosting.co.za> Antoine Pitrou added the comment: My example forgets the function declaration, which is: >>> def f(a, b=5, *c, d=5): pass ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 12:23:52 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 10:23:52 +0000 Subject: [issue24188] Signature objects not hashable In-Reply-To: <1431596104.89.0.97986855115.issue24188@psf.upfronthosting.co.za> Message-ID: <1431599032.09.0.952113286712.issue24188@psf.upfronthosting.co.za> Antoine Pitrou added the comment: But that kind of makes my point. While ([],) is not hashable, other tuples are hashable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 12:24:53 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 10:24:53 +0000 Subject: [issue24188] Signature objects not hashable In-Reply-To: <1431596104.89.0.97986855115.issue24188@psf.upfronthosting.co.za> Message-ID: <1431599093.32.0.222354964491.issue24188@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Also, a workaround would be to id() the defaults when hashing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 12:59:56 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 May 2015 10:59:56 +0000 Subject: [issue24185] Add Function for Sending File to Trash (or Recycling Bin) In-Reply-To: <1431574601.59.0.7462724115.issue24185@psf.upfronthosting.co.za> Message-ID: <1431601196.09.0.61460811158.issue24185@psf.upfronthosting.co.za> R. David Murray added the comment: Heh, dangerous is in the eye of the beholder. I don't even have a trash bin on my system (no desktop, just X and shell windows). It is almost always the case that an application written in python that wants to get rid of a file *does* want to really delete it, because it is not operating on user-facing files. It is only when the program is implementing a GUI (and very occasionally when implementing a CLI) that it might want to move something to trash instead. I'm -1 on this proposal. Most python programs aren't GUI programs, so I don't think any significant fraction of python programs need it, and thus that the ones that do can just include it as a dependency along with all the other dependencies they need. (Yes, you can write a full GUI just using tkinter, but the number of GUI programs that have no non-stdlib dependencies is probably quite small.) This is the kind of thing that would need to go to python-ideas first in any case, so I'm going to close the issue. If you get consensus that it is a good idea on the python-ideas mailing list, you can re-open the issue. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed versions: -Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 13:06:55 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 May 2015 11:06:55 +0000 Subject: [issue23995] msvcrt could not be imported In-Reply-To: <1429382716.1.0.015048526051.issue23995@psf.upfronthosting.co.za> Message-ID: <1431601615.87.0.745936873876.issue23995@psf.upfronthosting.co.za> R. David Murray added the comment: You'll note that the problem shows up in the getpass module, which does have tests, but which does not have a test that discovers this. That's because writing tests that *use* these functions is not really practical :) Someone could open an issue about testing for the functions that are supposed to be available. There could also be another issue for gettpass to test for the availability of the functions it actually uses. Steve, looks like you forgot to close the issue? Or were you waiting for agreement about the tests? ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 13:27:51 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 May 2015 11:27:51 +0000 Subject: [issue24187] del statement documentation doesn't mention name binding behaviour In-Reply-To: <1431595969.01.0.32289440375.issue24187@psf.upfronthosting.co.za> Message-ID: <1431602871.51.0.522656386114.issue24187@psf.upfronthosting.co.za> R. David Murray added the comment: I don't understand, what do you think is missing from the description? It certainly talks about name binding. Also, can you provide a link to the other statement, as I can't find it, and out of context I have no idea what it is talking about. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 13:29:34 2015 From: report at bugs.python.org (Petr Viktorin) Date: Thu, 14 May 2015 11:29:34 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1431602974.51.0.061179480634.issue23699@psf.upfronthosting.co.za> Petr Viktorin added the comment: Well, as a newcomer, I think the macro makes it easier to both grok what the code does, and is about equally difficult when it comes to checking correctness of the code. But I understand that's a subjective. Marc-Andre, Barry, you expressed interest in the macro on the mailing list; do you still think it's a good idea? ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 13:33:04 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 May 2015 11:33:04 +0000 Subject: [issue24190] BoundArguments facility to inject defaults In-Reply-To: <1431598800.08.0.914868739501.issue24190@psf.upfronthosting.co.za> Message-ID: <1431603184.86.0.427104762149.issue24190@psf.upfronthosting.co.za> R. David Murray added the comment: See issue 22998. The more complete and thus more complex example in the last message makes it look like including this in the library might be a good idea. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 13:47:20 2015 From: report at bugs.python.org (Francis MB) Date: Thu, 14 May 2015 11:47:20 +0000 Subject: [issue12018] No tests for ntpath.samefile, ntpath.sameopenfile In-Reply-To: <1304694770.94.0.722245311346.issue12018@psf.upfronthosting.co.za> Message-ID: <1431604040.67.0.677223488391.issue12018@psf.upfronthosting.co.za> Francis MB added the comment: Can this issue be closed? IMHO it's not clear what still needs to be done. The patch seems to be there already. Thanks in advance! ---------- nosy: +francismb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 13:52:12 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 14 May 2015 11:52:12 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1431604332.58.0.670291322237.issue23699@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: @rhettinger: OTOH, a macro can provide uniformity and correctness. If (as appears evident from the patch) those "10 lines of boilerplate" are actually implemented subtly differently each time, bugs can be easily introduced. So a well written and documented macro can be both more readable and more correct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 13:53:50 2015 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 14 May 2015 11:53:50 +0000 Subject: [issue14399] zipfile and creat/update comment In-Reply-To: <1332606431.21.0.286905846716.issue14399@psf.upfronthosting.co.za> Message-ID: <1431604430.56.0.692686502945.issue14399@psf.upfronthosting.co.za> Mark Dickinson added the comment: Just for the record, David's comment at msg158136 is apposite: > We've had trouble in the past with a conversion to new style class > breaking people's code. People are less likely to be subclassing > ZipFile, though, so it is probably OK. We just spent some time this morning fixing a bug in some internal software; the cause was precisely this unexpected change from old-style class to new-style class in a bugfix release. And indeed, we were subclassing ZipFile. :-( ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 13:58:40 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 14 May 2015 11:58:40 +0000 Subject: [issue24192] unexpected system error with pep420 style namespace packages Message-ID: <1431604720.34.0.497693265378.issue24192@psf.upfronthosting.co.za> New submission from Ronald Oussoren: The script below creates a basic PEP 420 style package with a single module in it ('package.sub') and tries to import that module With 3.5 the script runs without problems and prints 42 (as expected). With a 3.5 (fresh checkout as of 2015-05-14) I get an SystemError: $ python3.5 demo.py Traceback (most recent call last): File "demo.py", line 10, in import package.mod File "", line 958, in _find_and_load File "", line 947, in _find_and_load_unlocked File "", line 657, in _load_unlocked File "", line 575, in module_from_spec File "", line 519, in _init_module_attrs SystemError: Parent module '' not loaded, cannot perform relative import ####### import os os.mkdir('path1') os.mkdir('path1/package') with open('path1/package/mod.py', 'w') as fp: fp.write('print(42)\n') import site site.addsitedir('path1') import package.mod ---------- components: Interpreter Core messages: 243181 nosy: ronaldoussoren priority: normal severity: normal status: open title: unexpected system error with pep420 style namespace packages versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 14:03:50 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 14 May 2015 12:03:50 +0000 Subject: [issue24193] Make LOGGING_FORMAT of assertLogs configurable Message-ID: <1431605029.99.0.444835301939.issue24193@psf.upfronthosting.co.za> New submission from Berker Peksag: It would be useful if we could change the logging format of assertLogs when we use it: with self.assertLogs('foo', level='INFO', format='%(message)s') as cm: logging.getLogger('foo').info('first message') self.assertEqual(cm.output, ['first message']) Or maybe with a class attribute like maxDiff: logFormat = '%(message)s' ---------- components: Library (Lib) messages: 243182 nosy: berker.peksag, ezio.melotti, michael.foord, rbcollins priority: normal severity: normal stage: needs patch status: open title: Make LOGGING_FORMAT of assertLogs configurable type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 14:05:06 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 14 May 2015 12:05:06 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1431602974.51.0.061179480634.issue23699@psf.upfronthosting.co.za> Message-ID: <55548F6A.5040307@egenix.com> Marc-Andre Lemburg added the comment: On 14.05.2015 13:29, Petr Viktorin wrote: > > Marc-Andre, Barry, you expressed interest in the macro on the mailing list; do you still think it's a good idea? Yes. The fact that the macro can save us more than a hundred lines of code in Python itself is proof enough that it's useful to have. Only once concept to learn, fewer bugs, one place to apply change (should they become necessary), etc. etc. This is a standard case of refactoring to simplify code and also a standard case where we use macros in Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 14:20:14 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 May 2015 12:20:14 +0000 Subject: [issue14399] zipfile and creat/update comment In-Reply-To: <1332606431.21.0.286905846716.issue14399@psf.upfronthosting.co.za> Message-ID: <1431606014.35.0.096716053172.issue14399@psf.upfronthosting.co.za> R. David Murray added the comment: :( :( OK, next time this comes up I won't say "it will probably be OK". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 14:22:37 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 May 2015 12:22:37 +0000 Subject: [issue12018] No tests for ntpath.samefile, ntpath.sameopenfile In-Reply-To: <1304694770.94.0.722245311346.issue12018@psf.upfronthosting.co.za> Message-ID: <1431606157.25.0.629847527116.issue12018@psf.upfronthosting.co.za> R. David Murray added the comment: Given that several comments say "this should be done", and your analysis indicates it is done, I think it should be safe to close it :) Thanks for the nudge. ---------- nosy: +r.david.murray resolution: -> fixed stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 14:24:48 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 May 2015 12:24:48 +0000 Subject: [issue24192] unexpected system error with pep420 style namespace packages In-Reply-To: <1431604720.34.0.497693265378.issue24192@psf.upfronthosting.co.za> Message-ID: <1431606288.54.0.768495181712.issue24192@psf.upfronthosting.co.za> R. David Murray added the comment: I presume you meant that it works with 3.4? ---------- nosy: +brett.cannon, eric.snow, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 14:47:21 2015 From: report at bugs.python.org (Joshua Landau) Date: Thu, 14 May 2015 12:47:21 +0000 Subject: [issue21593] Clarify re.search documentation first match In-Reply-To: <1401287966.38.0.860641123785.issue21593@psf.upfronthosting.co.za> Message-ID: <1431607641.75.0.287656912455.issue21593@psf.upfronthosting.co.za> Joshua Landau added the comment: This should also be applied to regex.search's docstring. https://docs.python.org/3.5/library/re.html#re.regex.search ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 15:00:27 2015 From: report at bugs.python.org (Joshua Landau) Date: Thu, 14 May 2015 13:00:27 +0000 Subject: [issue24194] tokenize yield an ERRORTOKEN if an identifier uses Other_ID_Start or Other_ID_Continue Message-ID: <1431608427.75.0.966529056278.issue24194@psf.upfronthosting.co.za> New submission from Joshua Landau: This is valid: ?? = 1 print(??) #>>> 1 But this gives an error token: from io import BytesIO from tokenize import tokenize stream = BytesIO("??".encode("utf-8")) print(*tokenize(stream.read), sep="\n") #>>> TokenInfo(type=56 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line='') #>>> TokenInfo(type=53 (ERRORTOKEN), string='?', start=(1, 0), end=(1, 1), line='??') #>>> TokenInfo(type=53 (ERRORTOKEN), string='?', start=(1, 1), end=(1, 2), line='??') #>>> TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='') This is a continuation of http://bugs.python.org/issue9712. I'm not able to reopen the issue, so I thought I should report it anew. It is tokenize that is wrong - Other_ID_Start and Other_ID_Continue are documented to be valid: https://docs.python.org/3.5/reference/lexical_analysis.html#identifiers ---------- components: Library (Lib) messages: 243188 nosy: Joshua.Landau priority: normal severity: normal status: open title: tokenize yield an ERRORTOKEN if an identifier uses Other_ID_Start or Other_ID_Continue type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 15:20:04 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 13:20:04 +0000 Subject: [issue24188] Signature objects not hashable In-Reply-To: <1431599093.32.0.222354964491.issue24188@psf.upfronthosting.co.za> Message-ID: <14CE4570-92B0-42CB-9084-F89B63CE5A0B@gmail.com> Yury Selivanov added the comment: Signatures and Parameters are already hash able in 3.5. Please close the issue. ---------- nosy: +Yury.Selivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 15:20:39 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 13:20:39 +0000 Subject: [issue24188] Signature objects not hashable In-Reply-To: <1431596104.89.0.97986855115.issue24188@psf.upfronthosting.co.za> Message-ID: <1431609639.75.0.411427285844.issue24188@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Oh, great! Thank you. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 15:41:57 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 14 May 2015 13:41:57 +0000 Subject: [issue24192] unexpected system error with pep420 style namespace packages In-Reply-To: <1431604720.34.0.497693265378.issue24192@psf.upfronthosting.co.za> Message-ID: <1431610917.24.0.16292386733.issue24192@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 17:15:37 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 May 2015 15:15:37 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 In-Reply-To: <1431553670.83.0.456032288115.issue24181@psf.upfronthosting.co.za> Message-ID: <1431616537.14.0.613419013728.issue24181@psf.upfronthosting.co.za> Steve Dower added the comment: Just so you're not too surprised - that vc_community.exe is a downloader that will eventually need 6-8GB :( I'm working with the teams involved to try and get a compiler-only release, but for now the smallest installation that should work is Express for Desktop (from https://www.visualstudio.com/downloads/visual-studio-2015-downloads-vs.aspx, under the "Visual Studio 2015" expander at the lower left). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 17:19:56 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 May 2015 15:19:56 +0000 Subject: [issue23985] Crash when deleting slices from duplicated bytearray In-Reply-To: <1429252668.91.0.45841644858.issue23985@psf.upfronthosting.co.za> Message-ID: <1431616796.21.0.73042006.issue23985@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- nosy: -steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 17:20:46 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 May 2015 15:20:46 +0000 Subject: [issue23995] msvcrt could not be imported In-Reply-To: <1429382716.1.0.015048526051.issue23995@psf.upfronthosting.co.za> Message-ID: <1431616846.96.0.451668302197.issue23995@psf.upfronthosting.co.za> Steve Dower added the comment: Was waiting for agreement or opposition, but I intended to close it within 24 hours if nothing was raised :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 17:23:27 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 14 May 2015 15:23:27 +0000 Subject: [issue24182] test_tcl assertion failure, 2.7, Win 7 In-Reply-To: <1431554287.05.0.384397214911.issue24182@psf.upfronthosting.co.za> Message-ID: <1431617007.98.0.0488413008816.issue24182@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The one bundled with 2.7, which now is 8.5.15.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 17:28:56 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 15:28:56 +0000 Subject: [issue24191] BoundArguments.signature not documented In-Reply-To: <1431598870.49.0.134760304526.issue24191@psf.upfronthosting.co.za> Message-ID: <1431617336.66.0.315296701194.issue24191@psf.upfronthosting.co.za> Yury Selivanov added the comment: Good catch! Please take a look at the attached patch. ---------- keywords: +patch Added file: http://bugs.python.org/file39371/sig_ba_docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 17:40:44 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 15:40:44 +0000 Subject: [issue24189] Parameter doesn't expose its index In-Reply-To: <1431597102.49.0.279641303992.issue24189@psf.upfronthosting.co.za> Message-ID: <1431618044.08.0.216462030076.issue24189@psf.upfronthosting.co.za> Yury Selivanov added the comment: Do you have any good use case for this? In one of the first iterations of PEP 362 we had Parameter.index. However, we later redesigned the object to work as a building block -- immutable, and explicitly detached from its parent Signature. This way there is nothing wrong in taking a parameters from one signature, and using them to build a new one. And since (I think) I'm doing this kind of things in my own code, adding this attribute (or even reference to the parent Signature) to Parameter might break things, or even introduce strange side effects. Another reason is that we don't preserve the order of keyword arguments. And having things like '*args' further disconnects parameters indexes from arguments indexes. We can add an 'index(name)' or 'index(param)' method to the Signature class, but I don't know any good use case why would we need that. ---------- nosy: +brett.cannon, larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 17:42:44 2015 From: report at bugs.python.org (Fabio Perez) Date: Thu, 14 May 2015 15:42:44 +0000 Subject: [issue23089] Update libffi config files In-Reply-To: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za> Message-ID: <1431618164.26.0.469249164982.issue23089@psf.upfronthosting.co.za> Fabio Perez added the comment: Ping ---------- nosy: +fabiovmp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 17:42:55 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 14 May 2015 15:42:55 +0000 Subject: [issue24185] Add Function for Sending File to Trash (or Recycling Bin) In-Reply-To: <1431574601.59.0.7462724115.issue24185@psf.upfronthosting.co.za> Message-ID: <1431618175.98.0.893969408268.issue24185@psf.upfronthosting.co.za> Steven D'Aprano added the comment: This has been discussed on Python-Ideas some time ago, possibly more than once. See here for one such (short) discussion: https://mail.python.org/pipermail/python-ideas/2013-April/020148.html I think that move-to-trash functionality is quite useful, I needed something like that the other day, but there are at least two trash systems on Linux (although one is quite old and may not be used in recent systems), plus Windows, OS X, Android, iOS, etc. So it isn't a trivial piece of code, and it should spend some time as a third-party module first, at least until it reaches a stable and mature state. Since it's been more than two years since the discussion above, perhaps it is worth considering it again (assuming that the library is stable and mature). Are you interested in taking this discussion to python-ideas? ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 17:43:24 2015 From: report at bugs.python.org (Fabio Perez) Date: Thu, 14 May 2015 15:43:24 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1431618204.75.0.146442943489.issue23085@psf.upfronthosting.co.za> Fabio Perez added the comment: Ping ---------- nosy: +fabiovmp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 17:44:11 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 15:44:11 +0000 Subject: [issue24189] Parameter doesn't expose its index In-Reply-To: <1431618044.08.0.216462030076.issue24189@psf.upfronthosting.co.za> Message-ID: <5554C2C7.30708@free.fr> Antoine Pitrou added the comment: Le 14/05/2015 17:40, Yury Selivanov a ?crit : > > Do you have any good use case for this? Passing a parameter around without having to pass the index separately :-) > In one of the first iterations of PEP 362 we had Parameter.index. However, we later redesigned the object to work as a building block -- immutable, and explicitly detached from its parent Signature. This way there is nothing wrong in taking a parameters from one signature, and using them to build a new one. I see. That might be annoying in that case, indeed. > Another reason is that we don't preserve the order of keyword arguments. What do you mean? In Signature or in BoundArguments? I would hope that Signature keeps it. > And having things like '*args' further disconnects parameters > indexes from arguments indexes. Not necessarily. In my case, I treat a stararg parameter as a single parameter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 17:45:40 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 15:45:40 +0000 Subject: [issue24190] BoundArguments facility to inject defaults In-Reply-To: <1431598800.08.0.914868739501.issue24190@psf.upfronthosting.co.za> Message-ID: <1431618340.7.0.127097117514.issue24190@psf.upfronthosting.co.za> Yury Selivanov added the comment: Well, the docs example only binds explicit defaults in function signature. Implicit defaults for *args and **kwargs (`()` and `{}`) aren't usually useful (in my opinion). Do you guys have any good use case for such method? I use the Signature API extensively for argument types validation and for serialization of RPC calls, but I never needed this functionality from BoundArguments. ---------- nosy: +brett.cannon, larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 17:49:44 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 15:49:44 +0000 Subject: [issue24189] Parameter doesn't expose its index In-Reply-To: <1431597102.49.0.279641303992.issue24189@psf.upfronthosting.co.za> Message-ID: <1431618584.06.0.505440297178.issue24189@psf.upfronthosting.co.za> Yury Selivanov added the comment: > What do you mean? In Signature or in BoundArguments? I would hope that Signature keeps it. I mean during the actual call, as **kwargs aren't ordered. I think having indexes for parameters would make sense for a language like JS or C, where there are no keyword arguments, and indexes of parameters match indexes of arguments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 17:53:41 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 15:53:41 +0000 Subject: [issue24190] BoundArguments facility to inject defaults In-Reply-To: <1431618340.7.0.127097117514.issue24190@psf.upfronthosting.co.za> Message-ID: <5554C502.7040100@free.fr> Antoine Pitrou added the comment: Le 14/05/2015 17:45, Yury Selivanov a ?crit : > > Well, the docs example only binds explicit defaults in function > signature. Implicit defaults for *args and **kwargs (`()` and `{}`) > aren't usually useful (in my opinion). When the defaults are filled I expect ba.arguments to be "complete", that is have a value for every signature parameter. Otherwise I have to special-case *args and **kwargs. > Do you guys have any good use case for such method? A use case was given in issue22998. My use case is JIT-compiling functions and function calls in Numba. We reimplement the function calls ourselves, so need a complete mapping of arguments to values. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 17:58:32 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 15:58:32 +0000 Subject: [issue24189] Parameter doesn't expose its index In-Reply-To: <1431618584.06.0.505440297178.issue24189@psf.upfronthosting.co.za> Message-ID: <5554C626.8010103@free.fr> Antoine Pitrou added the comment: Le 14/05/2015 17:49, Yury Selivanov a ?crit : > >> What do you mean? In Signature or in BoundArguments? I would hope >> that > Signature keeps it. > > I mean during the actual call, as **kwargs aren't ordered. > > I think having indexes for parameters would make sense for a language > like JS or C, where there are no keyword arguments, and indexes of > parameters match indexes of arguments. As mentioned in the issue, when re-implementing function calls, you have to flatten the arguments into a simple argument list (because the function parameters are actually a sequence (*), despite Python's rich function call possibilities). (*) at least for pure Python functions, where the arguments are simply pushed sequentially on the ceval stack ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 17:59:47 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 15:59:47 +0000 Subject: [issue24190] BoundArguments facility to inject defaults In-Reply-To: <1431598800.08.0.914868739501.issue24190@psf.upfronthosting.co.za> Message-ID: <1431619187.5.0.213142298965.issue24190@psf.upfronthosting.co.za> Yury Selivanov added the comment: >> Do you guys have any good use case for such method? > A use case was given in issue22998. > My use case is JIT-compiling functions and function calls in Numba. We > reimplement the function calls ourselves, so need a complete mapping of > arguments to values. This is a great use case ;-) Let's add it. I propose the following method: BoundArguments.apply_defaults() It will iterate through its parent Signature's parameters and assign default values to BoundArguments.arguments (when an arg is missing), including setting '()' for *args, and '{}' for **kwargs. If you're OK with this, I can draft a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 18:00:45 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 16:00:45 +0000 Subject: [issue24190] BoundArguments facility to inject defaults In-Reply-To: <1431598800.08.0.914868739501.issue24190@psf.upfronthosting.co.za> Message-ID: <1431619245.05.0.150110694167.issue24190@psf.upfronthosting.co.za> Antoine Pitrou added the comment: That sounds good to me, thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 18:02:27 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 16:02:27 +0000 Subject: [issue24189] Parameter doesn't expose its index In-Reply-To: <1431597102.49.0.279641303992.issue24189@psf.upfronthosting.co.za> Message-ID: <1431619347.66.0.18549387863.issue24189@psf.upfronthosting.co.za> Yury Selivanov added the comment: > As mentioned in the issue, when re-implementing function calls, you have to flatten the arguments into a simple argument list [..] Then you probably need indexes for BoundArguments, not Parameters. > (*) at least for pure Python functions, where the arguments are simply pushed sequentially on the ceval stack TBH I think this is a very special use case. I'm -0.5 on including this to the stdlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 18:19:30 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 May 2015 16:19:30 +0000 Subject: [issue24184] PEP 492: Add AsyncIterator and AsyncIterable to collections.abc In-Reply-To: <1431573871.68.0.565476513096.issue24184@psf.upfronthosting.co.za> Message-ID: <20150514161922.1924.80155@psf.io> Roundup Robot added the comment: New changeset 4347ce7acd84 by Yury Selivanov in branch 'default': Issue 24184: Add AsyncIterator and AsyncIterable to collections.abc. https://hg.python.org/cpython/rev/4347ce7acd84 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 18:20:21 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 16:20:21 +0000 Subject: [issue24184] PEP 492: Add AsyncIterator and AsyncIterable to collections.abc In-Reply-To: <1431573871.68.0.565476513096.issue24184@psf.upfronthosting.co.za> Message-ID: <1431620421.72.0.371694105844.issue24184@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thank you Guido for the review! Committed to the default branch. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 18:29:14 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 16:29:14 +0000 Subject: [issue24189] Parameter doesn't expose its index In-Reply-To: <1431597102.49.0.279641303992.issue24189@psf.upfronthosting.co.za> Message-ID: <1431620954.55.0.477703310057.issue24189@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Given the drawback you mentioned above, I agree that this may be a hard sell :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 18:56:09 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 16:56:09 +0000 Subject: [issue24190] BoundArguments facility to inject defaults In-Reply-To: <1431598800.08.0.914868739501.issue24190@psf.upfronthosting.co.za> Message-ID: <1431622569.4.0.595441893397.issue24190@psf.upfronthosting.co.za> Yury Selivanov added the comment: FWIW it wasn't as easy as I thought it would be :) You were right, docs example is very basic. Please take a look at the attached patch. ---------- assignee: -> yselivanov keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file39372/sig_ba_default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 19:08:06 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 May 2015 17:08:06 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 In-Reply-To: <1431553670.83.0.456032288115.issue24181@psf.upfronthosting.co.za> Message-ID: <1431623286.27.0.0533087125886.issue24181@psf.upfronthosting.co.za> Steve Dower added the comment: Express for Desktop still takes about 4GB... I'm going to up the urgency of a sensibly sized package for people who just need the compiler. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 20:14:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 May 2015 18:14:37 +0000 Subject: [issue24191] BoundArguments.signature not documented In-Reply-To: <1431598870.49.0.134760304526.issue24191@psf.upfronthosting.co.za> Message-ID: <20150514181423.1939.55659@psf.io> Roundup Robot added the comment: New changeset 1012a8138fcb by Yury Selivanov in branch '3.4': Issue 24191: Document BoundArguments.signature https://hg.python.org/cpython/rev/1012a8138fcb New changeset 970454df99cd by Yury Selivanov in branch 'default': Issue 24191: Document BoundArguments.signature https://hg.python.org/cpython/rev/970454df99cd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 20:15:00 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 18:15:00 +0000 Subject: [issue24191] BoundArguments.signature not documented In-Reply-To: <1431598870.49.0.134760304526.issue24191@psf.upfronthosting.co.za> Message-ID: <1431627300.16.0.825131791707.issue24191@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 20:16:10 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 18:16:10 +0000 Subject: [issue24189] Parameter doesn't expose its index In-Reply-To: <1431597102.49.0.279641303992.issue24189@psf.upfronthosting.co.za> Message-ID: <1431627370.25.0.23649934111.issue24189@psf.upfronthosting.co.za> Yury Selivanov added the comment: OK, I'm closing this one. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 20:16:21 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 14 May 2015 18:16:21 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 In-Reply-To: <1431553670.83.0.456032288115.issue24181@psf.upfronthosting.co.za> Message-ID: <1431627381.06.0.91600496684.issue24181@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks for the warning. I was expecting 'expansion', but 5 GB (what site says for ...Desktop) is a big chunk of the 17 GM I have left on C: (111GB SSD). (Do you have any idea how much free space I will need for Win 10 upgrade?) So I think I will reverse myself and wait to install and suggest holding off on forced upgrade. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 20:32:47 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 14 May 2015 18:32:47 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 In-Reply-To: <1431553670.83.0.456032288115.issue24181@psf.upfronthosting.co.za> Message-ID: <1431628367.19.0.416426044781.issue24181@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I download vc_community.exe by just clicking and giving a save directory. When started, it says 9GB with options unchecked (10 GB before I unchecked one). (At which point I quit.) Downloading just Express for Desktop requires an MS account. It seems odd to need more (an account) to get half. It is unclear what type of account is needed -- the old free MS Now account, or the normally paid developer account. Skipping for now rather than proceed further. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 21:47:51 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 May 2015 19:47:51 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 In-Reply-To: <1431553670.83.0.456032288115.issue24181@psf.upfronthosting.co.za> Message-ID: <1431632871.69.0.612515232659.issue24181@psf.upfronthosting.co.za> Steve Dower added the comment: It's just a free account - any Hotmail, live.com or outlook.com email will do. The Microsoft equivalent of having a Google or Facebook account. (An MSDN Subscription is the other usual option, though that's associated with a Microsoft account anyway. I don't think there are actually any other account types these days.) I haven't looked too closely at Win 10, but I'd be surprised if you could install it with only 17GB. It's possible that it would clean up a lot of the existing Windows files and not take that much though, I really don't know right now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 23:26:42 2015 From: report at bugs.python.org (Ram Rachum) Date: Thu, 14 May 2015 21:26:42 +0000 Subject: [issue24195] Add `Executor.filter` Message-ID: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> New submission from Ram Rachum: `Executor.filter` is to `filter` what `Executor.map` is to `map`. See Python-ideas thread: https://groups.google.com/forum/#!topic/python-ideas/EBOC5YCWPyo Patch attached. I don't know how to run the Python test suite (I'm guessing it involves building Python and I don't know how to do that.) Please tell me whether the tests I wrote pass. I'm guessing that other than that, the main thing missing in my patch is documentation. If there's agreement that this feature is desirable and the implementation is good, I'll be happy to write the docs. Let me know. ---------- components: Library (Lib) files: 1.patch keywords: patch messages: 243217 nosy: cool-RR priority: normal severity: normal status: open title: Add `Executor.filter` type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39373/1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 14 23:28:15 2015 From: report at bugs.python.org (Ram Rachum) Date: Thu, 14 May 2015 21:28:15 +0000 Subject: [issue24195] Add `Executor.filter` In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431638895.51.0.794676155257.issue24195@psf.upfronthosting.co.za> Ram Rachum added the comment: Also, I notice Python 3.5 feature freeze is a bit over a week away, and I hope we can get that in so it could go in Python 3.5. (Assuming it goes in at all.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 00:01:13 2015 From: report at bugs.python.org (Boris) Date: Thu, 14 May 2015 22:01:13 +0000 Subject: [issue24196] Fail to create file if name starts with prn. Message-ID: <1431640873.55.0.0369746969915.issue24196@psf.upfronthosting.co.za> New submission from Boris: >>> f=open('prn.txt','w') Traceback (most recent call last): File "", line 1, in f=open('prn.txt','w') FileNotFoundError: [Errno 2] No such file or directory: 'prn.txt' Names that fail: prn. prn.txt prn.yourmmama.txt ... Names that do not fail: prn prn_.txt npr.txt ... Happens on Windows 7, Python3.3, both 32 bit and 64 bit This should be easy to replicate. ---------- components: IO messages: 243219 nosy: borisompol priority: normal severity: normal status: open title: Fail to create file if name starts with prn. type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 00:02:34 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 22:02:34 +0000 Subject: [issue24196] Fail to create file if name starts with prn. In-Reply-To: <1431640873.55.0.0369746969915.issue24196@psf.upfronthosting.co.za> Message-ID: <1431640954.77.0.060790280193.issue24196@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 00:03:15 2015 From: report at bugs.python.org (Virgil Dupras) Date: Thu, 14 May 2015 22:03:15 +0000 Subject: [issue24185] Add Function for Sending File to Trash (or Recycling Bin) In-Reply-To: <1431574601.59.0.7462724115.issue24185@psf.upfronthosting.co.za> Message-ID: <1431640995.94.0.239743513382.issue24185@psf.upfronthosting.co.za> Virgil Dupras added the comment: For further references, there's also https://mail.python.org/pipermail/python-ideas/2014-December/030547.html which is a deeper discussion and brings even more arguments against it. Even though I'd love to have some of my code integrated into the core, arguments against its inclusion are pretty strong. ---------- nosy: +vdupras _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 00:03:22 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 14 May 2015 22:03:22 +0000 Subject: [issue24195] Add `Executor.filter` In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431641002.95.0.910627570309.issue24195@psf.upfronthosting.co.za> Paul Moore added the comment: You should add docs for the new method, as well. ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 00:09:14 2015 From: report at bugs.python.org (=?utf-8?b?UGF3ZcWC?=) Date: Thu, 14 May 2015 22:09:14 +0000 Subject: [issue24197] minidom parses comments wrongly Message-ID: <1431641354.19.0.986717632735.issue24197@psf.upfronthosting.co.za> New submission from Pawe?: from xml.dom import minidom html = """ """ minidom.parseString(html) Result: Traceback (most recent call last): File "minidom.py", line 10, in minidom.parseString(html) File "/usr/lib/python2.7/xml/dom/minidom.py", line 1928, in parseString return expatbuilder.parseString(string) File "/usr/lib/python2.7/xml/dom/expatbuilder.py", line 940, in parseString return builder.parseString(string) File "/usr/lib/python2.7/xml/dom/expatbuilder.py", line 223, in parseString parser.Parse(string, True) xml.parsers.expat.ExpatError: not well-formed (invalid token): line 3, column 34 Tested versions: 2.7.6, 2.7.3 Reason: -- between obraz and super; ---------- components: XML messages: 243222 nosy: Wanat priority: normal severity: normal status: open title: minidom parses comments wrongly type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 00:18:21 2015 From: report at bugs.python.org (Matthias Klose) Date: Thu, 14 May 2015 22:18:21 +0000 Subject: [issue24198] please align the platform tag for windows Message-ID: <1431641901.05.0.53080075621.issue24198@psf.upfronthosting.co.za> New submission from Matthias Klose: Steve, I'd like to align the platform tag across platforms to "something" uniform. For POSIX systems we currently use the form --. This is derived from the autoconf host definition. Currently the windows builds use "win32", "win_ia64", "win_arm", "win_amd64". Would you consider (in descending priority): - to replace the _ with a -. The autoconf host definition use the dash as a separator, while the _ is used inside the single fields. - to change the order to - - to use the cpu names i386, x86_64, ia64 and arm (and maybe for the future aarch64). It maybe doesn't make sense to change these where these tags exist in released versions, but it would be nice to have some common scheme used for the major platforms. Note that Darwin uses this too, but chooses to only encode the . Also it would be nice to see the ABITAGS used for windows as well. ---------- components: Windows messages: 243223 nosy: doko, ned.deily, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: please align the platform tag for windows versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 00:18:28 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 14 May 2015 22:18:28 +0000 Subject: [issue24196] Fail to create file if name starts with prn. In-Reply-To: <1431640873.55.0.0369746969915.issue24196@psf.upfronthosting.co.za> Message-ID: <1431641908.4.0.789092255203.issue24196@psf.upfronthosting.co.za> Martin Panter added the comment: I could be wrong, but I thought this was normal Windows behaviour, not related to Python. Same probably applies to other special names like NUL, COM1. ---------- components: +Windows nosy: +tim.golden, vadmium, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 00:21:01 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 14 May 2015 22:21:01 +0000 Subject: [issue24157] test_urandom_fd_reopened failure if OS X crash reporter default set to Developer In-Reply-To: <1431267025.82.0.688433219235.issue24157@psf.upfronthosting.co.za> Message-ID: <1431642061.93.0.134892844173.issue24157@psf.upfronthosting.co.za> Ned Deily added the comment: OK, that explains the failure. You must have set the OS X crash reporter default to "Developer" mode on that machine at some point. In that case, code that is now in the SuppressCrashReport context manager in Lib/test/support/__init__.py checks for that setting by "shelling out" on OS X to /usr/bin/defaults for each use of the context manager in tests and, if set to "Developer", outputs that message to stdout. So that will interfere with a test like this where the contents of stdout is used as part of the test. But the code seems problematic in a couple of other respects. You can still get some crash popups even if the preference is not set to Developer. Also if the preference has never been set, you get a spurious error message to stderr for each test case that uses the context manager: 2015-05-14 14:34:44.185 defaults[90018:2205666] The domain/default pair of (/Users/nad/Library/Preferences/com.apple.CrashReporter, DialogType) does not exist My initial reaction without full testing of the effects of the Crash Reporter settings would be to: (1) not print a message to stdout since none of the other non-OS X cases do; (2) cache the results of the initial /usr/bin/defaults call. As a workaround, you could comment out the print. https://developer.apple.com/library/mac/technotes/tn2004/tn2123.html ---------- nosy: +ronaldoussoren stage: -> needs patch title: test_urandom_fd_reopened failure on Mac OS X -> test_urandom_fd_reopened failure if OS X crash reporter default set to Developer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 00:22:34 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 May 2015 22:22:34 +0000 Subject: [issue24196] Fail to create file if name starts with prn. In-Reply-To: <1431640873.55.0.0369746969915.issue24196@psf.upfronthosting.co.za> Message-ID: <1431642154.36.0.640207853642.issue24196@psf.upfronthosting.co.za> Steve Dower added the comment: It's a name reserved by Windows - see https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247.aspx#file_and_directory_names If you have a full (and 100% resolved) path, you can prefix it with \\?\ (plus escaping) to access a file by that name, but I wouldn't recommend it as you'll probably break Explorer. In any case, this is an OS limitation and not a Python issue. ---------- resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 00:33:47 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 May 2015 22:33:47 +0000 Subject: [issue24198] please align the platform tag for windows In-Reply-To: <1431641901.05.0.53080075621.issue24198@psf.upfronthosting.co.za> Message-ID: <1431642827.31.0.22655856229.issue24198@psf.upfronthosting.co.za> Steve Dower added the comment: Currently we have the form -, and the _ is within the OS field. There are no released final versions with these tags, so we can go ahead and change them however we like. Not sure exactly what you mean by "the ABITAGS" - Windows has no ABITAGS to my knowledge. Since I assume they're going to remain hard-coded into PC/pyconfig.h, I'm quite happy for anyone to go in and change them. While I started off thinking they were a great idea, I'm not so enamoured anymore and don't really mind how they look. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 00:42:52 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 14 May 2015 22:42:52 +0000 Subject: [issue24195] Add `Executor.filter` In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431643372.7.0.147147051395.issue24195@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 00:47:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 May 2015 22:47:35 +0000 Subject: [issue22547] Implement an informative `BoundArguments.__repr__` In-Reply-To: <1412353594.59.0.76573265737.issue22547@psf.upfronthosting.co.za> Message-ID: <20150514224721.31574.98737@psf.io> Roundup Robot added the comment: New changeset a444464a2e87 by Yury Selivanov in branch 'default': Issue 22547: Implement informative __repr__ for inspect.BoundArguments https://hg.python.org/cpython/rev/a444464a2e87 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 00:47:54 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 22:47:54 +0000 Subject: [issue22547] Implement an informative `BoundArguments.__repr__` In-Reply-To: <1412353594.59.0.76573265737.issue22547@psf.upfronthosting.co.za> Message-ID: <1431643674.42.0.432458718344.issue22547@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 00:55:26 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 May 2015 22:55:26 +0000 Subject: [issue24196] Fail to create file if name starts with prn. In-Reply-To: <1431640873.55.0.0369746969915.issue24196@psf.upfronthosting.co.za> Message-ID: <1431644126.42.0.690904933755.issue24196@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 01:05:33 2015 From: report at bugs.python.org (eryksun) Date: Thu, 14 May 2015 23:05:33 +0000 Subject: [issue23995] msvcrt could not be imported In-Reply-To: <1429382716.1.0.015048526051.issue23995@psf.upfronthosting.co.za> Message-ID: <1431644733.4.0.584878723866.issue23995@psf.upfronthosting.co.za> eryksun added the comment: Testing getpass shouldn't be that difficult if you use ctypes to call WriteConsoleInput [1]. For example: from ctypes import * from ctypes.wintypes import * kernel32 = WinDLL('kernel32') IN, OUT, INOUT = 1, 2, 3 KEY_EVENT = 0x0001 STD_INPUT_HANDLE = -10 STD_OUTPUT_HANDLE = -11 STD_ERROR_HANDLE = -12 INVALID_HANDLE_VALUE = HANDLE(-1).value class KEY_EVENT_RECORD(Structure): class UCHAR(Union): _fields_ = (('UnicodeChar', WCHAR), ('AsciiChar', CHAR)) _fields_ = (('bKeyDown', BOOL), ('wRepeatCount', WORD), ('wVirtualKeyCode', WORD), ('wVirtualScanCode', WORD), ('uChar', UCHAR), ('dwControlKeyState', DWORD)) class INPUT_RECORD(Structure): class EVENT(Union): _fields_ = (('KeyEvent', KEY_EVENT_RECORD),) _fields_ = (('EventType', WORD), ('Event', EVENT)) PINPUT_RECORD = POINTER(INPUT_RECORD) class HANDLE_IHV(HANDLE): @classmethod def _check_retval_(cls, retval): if retval.value == INVALID_HANDLE_VALUE: raise WinError(get_last_error()) return retval.value def errcheck_bool(result, func, args): if not result: raise WinError(get_last_error()) return args def WINAPI(name, dll, restype, *argspec): if argspec: argtypes = tuple(p[0] for p in argspec) paramflags = tuple(p[1:] for p in argspec) else: argtypes = paramflags = () prototype = WINFUNCTYPE(restype, *argtypes, use_last_error=True) func = prototype((name, dll), paramflags) if restype in (BOOL, HANDLE): func.errcheck = errcheck_bool setattr(dll, name, func) WINAPI('GetStdHandle', kernel32, HANDLE_IHV, (DWORD, IN, 'nStdHandle')) WINAPI('WriteConsoleInputW', kernel32, BOOL, (HANDLE, IN, 'hConsoleInput'), (PINPUT_RECORD, IN, 'lpBuffer'), (DWORD, IN, 'nLength'), (LPDWORD, OUT, 'lpNumberOfEventsWritten')) def write_console_input(s): hInput = kernel32.GetStdHandle(STD_INPUT_HANDLE) recs = (INPUT_RECORD * len(s))() for c, rec in zip(s, recs): rec.EventType = KEY_EVENT rec.Event.KeyEvent.bKeyDown = True rec.Event.KeyEvent.wRepeatCount = 1 rec.Event.KeyEvent.uChar.UnicodeChar = c return kernel32.WriteConsoleInputW(hInput, recs, len(recs)) if __name__ == '__main__': import getpass test_input = 'Console test input.\n' n = write_console_input(test_input) assert n == len(test_input) read_input = getpass.getpass() assert read_input == test_input.rstrip() This requires that python.exe is run with an attached console (conhost.exe), i.e. the process can't be created as a DETACHED_PROCESS [2] nor can it be run using pythonw.exe without first calling AllocConsole. [1]: https://msdn.microsoft.com/en-us/library/ms687403 [2]: https://msdn.microsoft.com/en-us/library/ms684863 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 01:13:51 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 14 May 2015 23:13:51 +0000 Subject: [issue23184] Unused imports, variables, file in IDLE In-Reply-To: <1420626411.51.0.528702156456.issue23184@psf.upfronthosting.co.za> Message-ID: <1431645231.34.0.441746728111.issue23184@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I got hg working and pushed the patch I had in January as a980da5f79f9, 5386aedf3ac9, 15701e89d710, and 3fa58e779308. Having forgotten that this issue was on the tracker (rather than just idle-sig post), I omitted the issue number and acknowledgement for the initial patch. I will add both when I add a new entry. I am working on another patch to include maxOsSupport and other changes found by pyflakes. I will add in the 'frame' change, the double use *is* confusing. pyflakes identifies files with * imports with a note that this prevents checks. I try to removed them when adding tests. I might do more just to make files checkable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 01:14:57 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 14 May 2015 23:14:57 +0000 Subject: [issue23184] Unused imports, variables, file in IDLE In-Reply-To: <1420626411.51.0.528702156456.issue23184@psf.upfronthosting.co.za> Message-ID: <1431645297.57.0.380813817957.issue23184@psf.upfronthosting.co.za> Terry J. Reedy added the comment: News entry, not new entry (Cannot edit commit messages) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 01:17:52 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 May 2015 23:17:52 +0000 Subject: [issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za> Message-ID: <1431645472.08.0.806385498705.issue23812@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- priority: normal -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 01:19:57 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 14 May 2015 23:19:57 +0000 Subject: [issue24198] please align the platform tag for windows In-Reply-To: <1431641901.05.0.53080075621.issue24198@psf.upfronthosting.co.za> Message-ID: <1431645597.4.0.283916071648.issue24198@psf.upfronthosting.co.za> Ned Deily added the comment: @doko, are you referring to the results of {sysconfig,distutils.util}.get_platform()? What effect would this have on third-party packages that currently support multiple versions of Python? Also, if get_platform() is meant, I don't understand the comment "Darwin uses this too, but chooses to only encode the ". On OS X for get_platform(), we provide a string of the form: "macosx"-- where ABI is derived from the minimum OS X level deployment target and UNIVERSAL_CPU_ARCHS is a name that identifies the set of CPU architectures included in the fat binaries for this build. Common examples: macosx-10.5-fat -> runs on 10.5 or later systems with Intel-32 or PPC-32 support macosx-10.6-intel -> runs on 10.6 or later systems with Intel-32 (i386) or Intel-64 (x86_64) support macosx-10.10-x86_64 -> runs on 10.10 or later with only Intel-64 support ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 01:22:23 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 14 May 2015 23:22:23 +0000 Subject: [issue23227] Generator's finally block not run if close() called before first iteration In-Reply-To: <1421134546.13.0.154248882029.issue23227@psf.upfronthosting.co.za> Message-ID: <1431645743.23.0.425387439634.issue23227@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 01:25:17 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 14 May 2015 23:25:17 +0000 Subject: [issue24192] unexpected system error with pep420 style namespace packages In-Reply-To: <1431604720.34.0.497693265378.issue24192@psf.upfronthosting.co.za> Message-ID: <1431645917.25.0.999306268842.issue24192@psf.upfronthosting.co.za> Eric Snow added the comment: The problem is right where the traceback says. Apparently there is a gap in the namespace package tests that I slipped through with my recent work to split out path-based import. I'll work up a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 01:25:18 2015 From: report at bugs.python.org (Matthias Klose) Date: Thu, 14 May 2015 23:25:18 +0000 Subject: [issue24198] please align the platform tag for windows In-Reply-To: <1431641901.05.0.53080075621.issue24198@psf.upfronthosting.co.za> Message-ID: <1431645918.88.0.0740481236958.issue24198@psf.upfronthosting.co.za> Matthias Klose added the comment: no, I mean something like the attached patch. get_platform() is dependent on the environment, not the platform that python was built for (e.g. it tells you x86_64 when running a 32bit python) on a 64bit kernel). ---------- keywords: +patch Added file: http://bugs.python.org/file39374/windows-tags.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 01:29:20 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 14 May 2015 23:29:20 +0000 Subject: [issue24198] please align the platform tag for windows In-Reply-To: <1431641901.05.0.53080075621.issue24198@psf.upfronthosting.co.za> Message-ID: <1431646160.43.0.39261088658.issue24198@psf.upfronthosting.co.za> Ned Deily added the comment: OK, but I still don't understand your comment about OS X. get_platform() on OS X in general returns info about the platform build environment (e.g. the implied set of all OS versions and CPU archs supported), not about the specific machine environment this instance is executing in. Is there something you think should be changed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 01:51:00 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 14 May 2015 23:51:00 +0000 Subject: [issue24198] please align the platform tag for windows In-Reply-To: <1431641901.05.0.53080075621.issue24198@psf.upfronthosting.co.za> Message-ID: <1431647460.37.0.962759763406.issue24198@psf.upfronthosting.co.za> Steve Dower added the comment: The patch makes it a little clearer, but I'd prefer the OS to be "win32" rather than just "win". Win32 is the name of the API set that Python is built against - it's as close to an ABI for the operating system as we ever get. (For contrast, WinRT is the only other API set, and it's not entirely compatible with Win32 even though there is some overlap. Python currently doesn't support WinRT except in the custom builds used for PTVS for IoT at http://ms-iot.github.io/content/Downloads.htm - it's a bit tricky to get to the dl from there though...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 02:12:19 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 15 May 2015 00:12:19 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1431648739.17.0.479271208283.issue23201@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 02:38:05 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 15 May 2015 00:38:05 +0000 Subject: [issue24199] Idle: remove idlelib.idlever.py and its use in About dialog Message-ID: <1431650285.59.0.600694723613.issue24199@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Once upon a time, Idle was versioned separately from Python, though updated in lockstep with Python (#1515164, Martin's comment). The version was kept in idlever.py, with one line IDLE_VERSION = "m.n.p" Several years ago, the separate versioning was dropped (or decreed to be the same as the Python version -- no issue for this). idlever.py was kept and made to contain the initial part of sys.version (sys.version.split()[0]). It gets patched as part of the version bump process, Most recently 80ccce248ba2 (Benjamin) and 413e0e0004f4 (Larry). Is that part of an automated script? The only current use of idlever is for the About Idle box (aboutDialog.py), which prints two lines with redundant information: 'Python version: ' + sys.version.split()[0] 'IDLE version: ' + idlever.IDLE_VERSION idlever.py is not needed and I intend to remove it. But before or as I do, its patching needs to be removed from the version bump process. I would also like to remove "IDLE version ..." from the dialog box, but even if not, idlever.py is not needed. ---------- assignee: terry.reedy components: IDLE messages: 243237 nosy: benjamin.peterson, larry, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: remove idlelib.idlever.py and its use in About dialog type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 02:46:52 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 15 May 2015 00:46:52 +0000 Subject: [issue24195] Add `Executor.filter` In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431650812.31.0.0680576095123.issue24195@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 03:24:34 2015 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 15 May 2015 01:24:34 +0000 Subject: [issue24157] test_urandom_fd_reopened failure if OS X crash reporter default set to Developer In-Reply-To: <1431642061.93.0.134892844173.issue24157@psf.upfronthosting.co.za> Message-ID: Skip Montanaro added the comment: > OK, that explains the failure. You must have set the OS X crash reporter default to "Developer" mode on that machine at some point. Thanks. I certainly don't remember doing anything like that. (I'm not a Mac user at such a sophisticated level.) At any rate, I set it to "server" and verified that the crash reporter stopped being displayed. Skip ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 04:13:11 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 15 May 2015 02:13:11 +0000 Subject: [issue23184] Unused imports, variables, file in IDLE In-Reply-To: <1420626411.51.0.528702156456.issue23184@psf.upfronthosting.co.za> Message-ID: <1431655991.34.0.0183556389576.issue23184@psf.upfronthosting.co.za> Terry J. Reedy added the comment: More idlelib fixes. Will push after reviewing. pyflakes shows extraneous items in idle_test also. ---------- Added file: http://bugs.python.org/file39375/@unused.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 04:13:31 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 15 May 2015 02:13:31 +0000 Subject: [issue23184] Unused imports, variables, file in IDLE In-Reply-To: <1420626411.51.0.528702156456.issue23184@psf.upfronthosting.co.za> Message-ID: <1431656011.64.0.741629234418.issue23184@psf.upfronthosting.co.za> Changes by Terry J. Reedy : Added file: http://bugs.python.org/file39376/@unused27.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 04:24:54 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 15 May 2015 02:24:54 +0000 Subject: [issue24195] Add `Executor.filter` In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431656694.45.0.218574000966.issue24195@psf.upfronthosting.co.za> Ethan Furman added the comment: Updated the tests (had to use real defs, not lambdas, and the expected results for filter_exception weren't right). Tests pass. Get some docs written! :) (More reviews would also be good. ;) ---------- Added file: http://bugs.python.org/file39377/issue24195.stoneleaf.01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 04:31:39 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 15 May 2015 02:31:39 +0000 Subject: [issue24197] minidom parses comments wrongly In-Reply-To: <1431641354.19.0.986717632735.issue24197@psf.upfronthosting.co.za> Message-ID: <1431657099.98.0.488445477916.issue24197@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for your report. Alas, according to the W3C XML 1.0 specification: "For compatibility, the string " -- " (double-hyphen) MUST NOT occur within comments." So, it appears minidom (and other XML parsers) are correct in rejecting your example as not well-formed XML. http://www.w3.org/TR/xml/#sec-comments ---------- nosy: +ned.deily resolution: -> not a bug stage: -> resolved status: open -> closed type: crash -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 05:08:16 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 15 May 2015 03:08:16 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431659296.96.0.0591211387292.issue24195@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +bquinlan, jnoller, sbt title: Add `Executor.filter` -> Add `Executor.filter` to concurrent.futures _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 05:29:19 2015 From: report at bugs.python.org (Brian Quinlan) Date: Fri, 15 May 2015 03:29:19 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431660559.37.0.607536351567.issue24195@psf.upfronthosting.co.za> Brian Quinlan added the comment: This feature seems unnecessary to me but couldn't the implementation be simplified to work in terms of map? i.e. (pseudocode): def filter(self, fn, iterable, timeout=None): l = list(iterable) return (item for (item, keep) in zip(l, self.map(fn, l, timeout)) if keep) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 06:26:55 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 15 May 2015 04:26:55 +0000 Subject: [issue24192] unexpected system error with pep420 style namespace packages In-Reply-To: <1431604720.34.0.497693265378.issue24192@psf.upfronthosting.co.za> Message-ID: <1431664015.06.0.87569530712.issue24192@psf.upfronthosting.co.za> Eric Snow added the comment: Hmm, look like the test suite masks the issue due to the fact that importlib gets imported before running the applicable tests in test_namespace_pkgs.py. This causes _frozen_importlib.__package__ to get set properly, thus masking the problem. The problem is the use of relative imports in importlib._bootstrap. The solution is to accomplish this in a different way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 07:04:50 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 15 May 2015 05:04:50 +0000 Subject: [issue23804] SSLSocket.recv(0) receives up to 1024 bytes In-Reply-To: <1427625023.61.0.148010223441.issue23804@psf.upfronthosting.co.za> Message-ID: <1431666290.08.0.934027337454.issue23804@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch for 3.5 that changes the default size to explicitly be 1024, and tests that recv(0) and read(0) now work as I expect they should by returning nothing. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file39378/recv-zero.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 07:07:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 May 2015 05:07:58 +0000 Subject: [issue22133] IDLE: Set correct WM_CLASS on X11 In-Reply-To: <1407162622.12.0.711549475862.issue22133@psf.upfronthosting.co.za> Message-ID: <1431666478.25.0.073268613331.issue22133@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Just a suggestion, can we use sys.version_info to get Python major version to have uniform code? Uniform code is too verbose. WM_CLASS should be "Idle" on Python 2 and "Idle3" on Python 3. top = Toplevel(self.root, class_='Idle' if sys.version_info[0] <= 2 else 'Idle%s' % sys.version_info[0]) It is easy to write just the constant literal. It is changed only when the major version is changed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 07:14:20 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 15 May 2015 05:14:20 +0000 Subject: [issue24199] Idle: remove idlelib.idlever.py and its use in About dialog In-Reply-To: <1431650285.59.0.600694723613.issue24199@psf.upfronthosting.co.za> Message-ID: <1431666860.77.0.561960196466.issue24199@psf.upfronthosting.co.za> Benjamin Peterson added the comment: That's fine. Just delete idlever.py, and I'll deal with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 08:24:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 May 2015 06:24:48 +0000 Subject: [issue24200] Redundant id in informative reprs Message-ID: <1431671088.82.0.205930864804.issue24200@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: >>> import inspect >>> def foo(a, *, b=10): pass ... >>> inspect.signature(foo) I think the id is not needed in informative repr if you implemented __eq__. Identity doesn't matter if different instances can be equal. The id in the repr only adds a noise. ---------- components: Library (Lib) messages: 243247 nosy: serhiy.storchaka, yselivanov priority: normal severity: normal status: open title: Redundant id in informative reprs type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 08:30:38 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 15 May 2015 06:30:38 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1431671438.28.0.504655836221.issue15582@psf.upfronthosting.co.za> Martin Panter added the comment: getdoc-news.patch suggests some wording to add to What?s New, and also adds a ?Changed in version 3.5? note to inspect.getdoc(). BTW I also noticed that the class doc strings are not inherited from object.__doc__, although method doc strings _are_ inherited from object(), such as object.__init__.__doc__. The current documentation suggests that the class doc string ?The most base type? should also be inherited. $ cat module.py class SomeClass: '''CLASS DOCSTRING''' def __init__(self): '''METHOD DOCSTRING''' $ ./python -m pydoc module.SomeClass # Doc strings intact [. . .] module.SomeClass = class SomeClass(builtins.object) | CLASS DOCSTRING | | Methods defined here: | | __init__(self) | METHOD DOCSTRING | [. . .] $ ./python -OOm pydoc module.SomeClass # Method inherited, class stripped [. . .] module.SomeClass = class SomeClass(builtins.object) | Methods defined here: | | __init__(self) | Initialize self. See help(type(self)) for accurate signature. | [. . .] I also wonder how well this feature would work when someone tries to override a base method by using a mix-in type class. ---------- Added file: http://bugs.python.org/file39379/getdoc-news.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 08:43:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 May 2015 06:43:04 +0000 Subject: [issue22547] Implement an informative `BoundArguments.__repr__` In-Reply-To: <1412353594.59.0.76573265737.issue22547@psf.upfronthosting.co.za> Message-ID: <1431672184.67.0.40711374524.issue22547@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be omit names for positionalarguments? >>> def foo(a, *args, b=10, **kwargs): pass ... >>> inspect.signature(foo).bind(1, 2, 3, b=4, c=5) I think it would look better as: ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 08:56:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 May 2015 06:56:20 +0000 Subject: [issue22547] Implement an informative `BoundArguments.__repr__` In-Reply-To: <1412353594.59.0.76573265737.issue22547@psf.upfronthosting.co.za> Message-ID: <1431672980.15.0.782585493541.issue22547@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is an implementation. ---------- keywords: +patch Added file: http://bugs.python.org/file39380/BoundArguments_repr_alt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 09:13:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 May 2015 07:13:13 +0000 Subject: [issue24013] Improve os.scandir() and DirEntry documentation In-Reply-To: <1429473711.62.0.571757122461.issue24013@psf.upfronthosting.co.za> Message-ID: <20150515071307.113160.94223@psf.io> Roundup Robot added the comment: New changeset e7c7431f91b2 by Victor Stinner in branch 'default': Closes #24013: Improve os.scandir() and DirEntry documentation https://hg.python.org/cpython/rev/e7c7431f91b2 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 09:14:50 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 May 2015 07:14:50 +0000 Subject: [issue24013] Improve os.scandir() and DirEntry documentation In-Reply-To: <1429473711.62.0.571757122461.issue24013@psf.upfronthosting.co.za> Message-ID: <1431674090.43.0.84559871679.issue24013@psf.upfronthosting.co.za> STINNER Victor added the comment: > 8. Added "Availability: Unix, Windows." to scandir docs like listdir and most other os functions have. That's wrong: availability should only be explained when a function is not always available. os.listdir() and os.scandir() are always available. I made the opposite change: I removed the availability information from os.listdir() and many other os functions in the changeset 77ebd3720284. Thanks Ben, I applied your patch (except of the Availability line). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 09:32:45 2015 From: report at bugs.python.org (Jon) Date: Fri, 15 May 2015 07:32:45 +0000 Subject: [issue24187] del statement documentation doesn't mention name binding behaviour In-Reply-To: <1431595969.01.0.32289440375.issue24187@psf.upfronthosting.co.za> Message-ID: <1431675165.06.0.588894626733.issue24187@psf.upfronthosting.co.za> Jon added the comment: Sorry, I think I just misread this section. I was confused by the fact that del binds names like assignment does, so that the following tries to delete a local name and fails: x = 1 def f(): del x f() In fact the documentation does say that there must be global statement in the block for del to delete a global name, so my bad. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 09:36:59 2015 From: report at bugs.python.org (Ram Rachum) Date: Fri, 15 May 2015 07:36:59 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431675419.11.0.204000630295.issue24195@psf.upfronthosting.co.za> Ram Rachum added the comment: Patch with documentation attached. (I don't know how to concatenate patches, so 2.patch contains only the documentation, while 1.patch has the implementation and the tests (but Ethan's patch is better.)) Brian, regarding your simpler implementation based on `Executor.map`: It looks good to me, but I'm not sure if it passes the tests. If it does then I don't mind if that's the implementation that would be used. ---------- Added file: http://bugs.python.org/file39381/2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 09:44:29 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 15 May 2015 07:44:29 +0000 Subject: [issue24160] Pdb sometimes crashes when trying to remove a breakpoint defined in a different debugger sessoon In-Reply-To: <1431275416.99.0.134014878289.issue24160@psf.upfronthosting.co.za> Message-ID: <1431675869.41.0.70469217149.issue24160@psf.upfronthosting.co.za> Xavier de Gaye added the comment: I can reproduce the problem on python 3.5 with test3.py as: def foo(): foo = 7789 bar = 7788 $ python Python 3.5.0a4+ (default:8bac00eadfda, May 6 2015, 17:40:12) [GCC 4.9.2 20150304 (prerelease)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import pdb, test3 >>> pdb.run('test3.foo()') > (1)() (Pdb) step --Call-- > /home/xavier/tmp/test3.py(1)foo() -> def foo(): (Pdb) break 3 Breakpoint 1 at /home/xavier/tmp/test3.py:3 (Pdb) continue > /home/xavier/tmp/test3.py(3)foo() -> bar = 7788 (Pdb) continue >>> pdb.run('test3.foo()') > (1)() (Pdb) step --Call-- > /home/xavier/tmp/test3.py(1)foo() -> def foo(): (Pdb) break # 'break' lists no breakpoints. (Pdb) break 2 Breakpoint 2 at /home/xavier/tmp/test3.py:2 (Pdb) break # 'break' lists two breakpoints. Num Type Disp Enb Where 1 breakpoint keep yes at /home/xavier/tmp/test3.py:3 breakpoint already hit 1 time 2 breakpoint keep yes at /home/xavier/tmp/test3.py:2 (Pdb) On the second debugging session, the first 'break' command lists no breakpoints, while the second 'break' command lists two breakpoints including the one set in the first debugging session. The problem is that the 'breaks' attribute of the Pdb instance is inconsistent with the 'bplist' and 'bpbynumber' class attributes of the bdb.Breakpoint class when the second debugging session is started. ---------- nosy: +xdegaye versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 10:21:59 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 15 May 2015 08:21:59 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431678119.72.0.83983568149.issue24195@psf.upfronthosting.co.za> Paul Moore added the comment: Just as a note - to test a pure Pthon patch like this, you can apply the patch to your installed Python 3.4 installation, and just run the test using that. There should be no need to build your own Python. >python C:\Apps\Python34\Lib\test\test_concurrent_futures.py test_cancel (__main__.FutureTests) ... ok test_cancelled (__main__.FutureTests) ... ok test_done (__main__.FutureTests) ... ok test_done_callback_already_cancelled (__main__.FutureTests) ... ok test_done_callback_already_failed (__main__.FutureTests) ... ok test_done_callback_already_successful (__main__.FutureTests) ... ok [... etc] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 10:36:51 2015 From: report at bugs.python.org (JohnLeitch) Date: Fri, 15 May 2015 08:36:51 +0000 Subject: [issue24201] _winreg PyHKEY Type Confusion Message-ID: <1431679011.32.0.0649667606823.issue24201@psf.upfronthosting.co.za> New submission from JohnLeitch: The Python _winreg module suffers from a type confusion vulnerability wherein pointers can be passed directly in place of PyHKEY instances e.g. _winreg.QueryValue(0x41414141, "") This behavior is due to the underlying PyHKEY_AsHKEY function of _winreg.c: BOOL PyHKEY_AsHKEY(PyObject *ob, HKEY *pHANDLE, BOOL bNoneOK) { if (ob == Py_None) { if (!bNoneOK) { PyErr_SetString( PyExc_TypeError, "None is not a valid HKEY in this context"); return FALSE; } *pHANDLE = (HKEY)0; } else if (PyHKEY_Check(ob)) { PyHKEYObject *pH = (PyHKEYObject *)ob; *pHANDLE = pH->hkey; } else if (PyInt_Check(ob) || PyLong_Check(ob)) { <<<<<< if ob is an int/long, this path is taken. /* We also support integers */ PyErr_Clear(); *pHANDLE = (HKEY)PyLong_AsVoidPtr(ob); <<<<<< ob is casted to a void* here if (PyErr_Occurred()) return FALSE; } else { PyErr_SetString( PyExc_TypeError, "The object is not a PyHKEY object"); return FALSE; } return TRUE; } When *ob is an integer or long, the function casts it to a void*. This behavior can be triggered using many of the _winreg functions, such as QueryValue, QueryValueEx, EnumValue, etc. 0:000> r eax=41414140 ebx=0027fbc8 ecx=00000000 edx=00000000 esi=770e351e edi=00000000 eip=74bf9af3 esp=0027f738 ebp=0027f764 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246 RPCRT4!NDRCContextBinding+0x13: 74bf9af3 81780498badcfe cmp dword ptr [eax+4],0FEDCBA98h ds:002b:41414144=???????? 0:000> k ChildEBP RetAddr 0027f764 74c0390c RPCRT4!NDRCContextBinding+0x13 0027f774 74c86dce RPCRT4!ExplicitBindHandleMgr+0x33 0027fba8 770e625c RPCRT4!NdrClientCall2+0x2ea 0027fbc0 771041e2 ADVAPI32!SafeBaseRegQueryInfoKey+0x24 0027fc04 76eacdca ADVAPI32!RemoteRegQueryInfoKeyWrapper+0x42 0027fcbc 1e0de85c KERNELBASE!LocalOpenPerformanceText+0x1c60 0027fd14 1e0ac6fc python27!PyEnumValue+0x6c [c:\build27\cpython\pc\_winreg.c @ 1213] 0027fd58 1e0efabf python27!_PyObject_GenericGetAttrWithDict+0x12c [c:\build27\cpython\objects\object.c @ 1428] 0027fde8 1e0f27eb python27!PyEval_EvalFrameEx+0x1cdf [c:\build27\cpython\python\ceval.c @ 2269] 0027fe00 1e0f11b2 python27!compiler_free+0x3b [c:\build27\cpython\python\compile.c @ 322] 0027fe2c 1e11707a python27!PyEval_EvalCode+0x22 [c:\build27\cpython\python\ceval.c @ 672] 0027fe44 1e1181c5 python27!run_mod+0x2a [c:\build27\cpython\python\pythonrun.c @ 1371] 0027fe64 1e118760 python27!PyRun_FileExFlags+0x75 [c:\build27\cpython\python\pythonrun.c @ 1358] 0027fea4 1e1190d9 python27!PyRun_SimpleFileExFlags+0x190 [c:\build27\cpython\python\pythonrun.c @ 950] 0027fec0 1e038d35 python27!PyRun_AnyFileExFlags+0x59 [c:\build27\cpython\python\pythonrun.c @ 753] 0027ff3c 1d00116d python27!Py_Main+0x965 [c:\build27\cpython\modules\main.c @ 643] 0027ff80 74d57c04 python!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 586] 0027ff94 7741ad1f KERNEL32!BaseThreadInitThunk+0x24 0027ffdc 7741acea ntdll!__RtlUserThreadStart+0x2f 0027ffec 00000000 ntdll!_RtlUserThreadStart+0x1b 0:000> !analyze -v ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* FAULTING_IP: RPCRT4!NDRCContextBinding+13 74bf9af3 81780498badcfe cmp dword ptr [eax+4],0FEDCBA98h EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 74bf9af3 (RPCRT4!NDRCContextBinding+0x00000013) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: 41414144 Attempt to read from address 41414144 CONTEXT: 00000000 -- (.cxr 0x0;r) eax=41414140 ebx=0027fbc8 ecx=00000000 edx=00000000 esi=770e351e edi=00000000 eip=74bf9af3 esp=0027f738 ebp=0027f764 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246 RPCRT4!NDRCContextBinding+0x13: 74bf9af3 81780498badcfe cmp dword ptr [eax+4],0FEDCBA98h ds:002b:41414144=???????? FAULTING_THREAD: 00000274 DEFAULT_BUCKET_ID: INVALID_POINTER_READ PROCESS_NAME: python.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: 41414144 READ_ADDRESS: 41414144 FOLLOWUP_IP: python27!PyEnumValue+6c [c:\build27\cpython\pc\_winreg.c @ 1213] 1e0de85c 85c0 test eax,eax NTGLOBALFLAG: 70 APPLICATION_VERIFIER_FLAGS: 0 APP: python.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 74c0390c to 74bf9af3 STACK_TEXT: 0027f764 74c0390c 41414140 770bfc78 0027fba8 RPCRT4!NDRCContextBinding+0x13 0027f774 74c86dce 770e351e 0027f8f8 40b1cbac RPCRT4!ExplicitBindHandleMgr+0x33 0027fba8 770e625c 770bfc78 770e3514 0027fbc8 RPCRT4!NdrClientCall2+0x2ea 0027fbc0 771041e2 41414140 0027fc44 0027fbfc ADVAPI32!SafeBaseRegQueryInfoKey+0x24 0027fc04 76eacdca 41414140 0027fc44 0027fc78 ADVAPI32!RemoteRegQueryInfoKeyWrapper+0x42 0027fcbc 1e0de85c 41414141 00000000 00000000 KERNELBASE!LocalOpenPerformanceText+0x1c60 0027fd14 1e0ac6fc 1e0aafd7 00000000 01d8e620 python27!PyEnumValue+0x6c 0027fd58 1e0efabf 1e0f017a 0027fdb4 01d06b18 python27!_PyObject_GenericGetAttrWithDict+0x12c 0027fde8 1e0f27eb 01e05238 003c196b 00000000 python27!PyEval_EvalFrameEx+0x1cdf 0027fe00 1e0f11b2 01d06b18 01d34030 01d0aa50 python27!compiler_free+0x3b 0027fe2c 1e11707a 01d06b18 01d0aa50 01d0aa50 python27!PyEval_EvalCode+0x22 0027fe44 1e1181c5 01dca848 01d0aa50 01d0aa50 python27!run_mod+0x2a 0027fe64 1e118760 72f27408 003c196b 00000101 python27!PyRun_FileExFlags+0x75 0027fea4 1e1190d9 72f27408 003c196b 00000001 python27!PyRun_SimpleFileExFlags+0x190 0027fec0 1e038d35 72f27408 003c196b 00000001 python27!PyRun_AnyFileExFlags+0x59 0027ff3c 1d00116d 00000002 003c1948 003c1cf0 python27!Py_Main+0x965 0027ff80 74d57c04 7ffde000 74d57be0 409574f3 python!__tmainCRTStartup+0x10f 0027ff94 7741ad1f 7ffde000 433d59cc 00000000 KERNEL32!BaseThreadInitThunk+0x24 0027ffdc 7741acea ffffffff 77400223 00000000 ntdll!__RtlUserThreadStart+0x2f 0027ffec 00000000 1d001314 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b STACK_COMMAND: .cxr 0x0 ; kb FAULTING_SOURCE_LINE: c:\build27\cpython\pc\_winreg.c FAULTING_SOURCE_FILE: c:\build27\cpython\pc\_winreg.c FAULTING_SOURCE_LINE_NUMBER: 1213 FAULTING_SOURCE_CODE: 1209: 1210: if ((rc = RegQueryInfoKey(hKey, NULL, NULL, NULL, NULL, NULL, NULL, 1211: NULL, 1212: &retValueSize, &retDataSize, NULL, NULL)) > 1213: != ERROR_SUCCESS) 1214: return PyErr_SetFromWindowsErrWithFunction(rc, 1215: "RegQueryInfoKey"); 1216: ++retValueSize; /* include null terminators */ 1217: ++retDataSize; 1218: bufDataSize = retDataSize; SYMBOL_STACK_INDEX: 6 SYMBOL_NAME: python27!PyEnumValue+6c FOLLOWUP_NAME: MachineOwner MODULE_NAME: python27 IMAGE_NAME: python27.dll DEBUG_FLR_IMAGE_TIMESTAMP: 5488ac17 FAILURE_BUCKET_ID: INVALID_POINTER_READ_c0000005_python27.dll!PyEnumValue BUCKET_ID: APPLICATION_FAULT_INVALID_POINTER_READ_python27!PyEnumValue+6c ANALYSIS_SOURCE: UM FAILURE_ID_HASH_STRING: um:invalid_pointer_read_c0000005_python27.dll!pyenumvalue FAILURE_ID_HASH: {b72db5fa-dbfd-ad6f-cf69-1ef0b8d49eed} Followup: MachineOwner --------- ---------- components: Windows files: _winregTypeConfusion.py messages: 243257 nosy: JohnLeitch, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: _winreg PyHKEY Type Confusion type: security versions: Python 2.7 Added file: http://bugs.python.org/file39382/_winregTypeConfusion.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 10:44:09 2015 From: report at bugs.python.org (levkivskyi) Date: Fri, 15 May 2015 08:44: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: <1431679449.23.0.346535933144.issue24129@psf.upfronthosting.co.za> levkivskyi added the comment: Since no one proposed alternative ideas, I am submitting my proposal as a patch, with the following wording: """ A class definition is an executable statement that may use and define names. Free variables follow the normal rules for name resolution, while unbound local variables are looked up in the global namespace. The namespace of the class definition becomes the attribute dictionary of the class. Names defined at the class scope are not visible in methods """ ---------- keywords: +patch Added file: http://bugs.python.org/file39383/classdoc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 11:08:35 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 15 May 2015 09:08:35 +0000 Subject: [issue24130] Remove -fno-common compile option from OS X framework builds? In-Reply-To: <1430875287.46.0.873192743789.issue24130@psf.upfronthosting.co.za> Message-ID: <1431680915.79.0.838413420919.issue24130@psf.upfronthosting.co.za> Ronald Oussoren added the comment: According to [1] common symbols are not allowed in frameworks. I guess that's why we added '-fno-common' to the linker flags. [1] https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkBinding.html#//apple_ref/doc/uid/20002256-BAJICBDD ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 11:24:16 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 May 2015 09:24:16 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431681856.58.0.59965917689.issue24195@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This feature looks unnecessary to me as well. Adding features has a non-zero cost in maintenance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 11:25:56 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 15 May 2015 09:25:56 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1431681956.55.0.961544677152.issue23085@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: issue23042 is fixed now. libffi 3.2.1 apparently has the same issue, so the issue23042 patch would probably have to be reapplied (slightly modified, though). Seeing that libffi has had a major compilation problem breaking it on at least FreeBSD and most probably a lot of other x86 based systems as well, I don't really have much confidence in the libffi maintenance, so the usual "latest is the greatest" may not be the best approach. Are there any issue *we* have with libffi which an update to 3.2.1 would solve ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 11:37:38 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 15 May 2015 09:37:38 +0000 Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za> Message-ID: <1431682658.15.0.686288525141.issue18378@psf.upfronthosting.co.za> Changes by Ronald Oussoren : Added file: http://bugs.python.org/file39384/issue-18378-py27.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 11:37:51 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 15 May 2015 09:37:51 +0000 Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za> Message-ID: <1431682671.76.0.174825642251.issue18378@psf.upfronthosting.co.za> Changes by Ronald Oussoren : Added file: http://bugs.python.org/file39385/issue-18378-py35.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 11:44:25 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 15 May 2015 09:44:25 +0000 Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za> Message-ID: <1431683065.29.0.750689657156.issue18378@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Dimitry's patch looks good, I added my patch before checking if there already is patch. The only thing that might be cause discussion is when to accept 'UTF-8' as a valid locale name. My patch only accepts in on OSX, while Dimitry's patch accepts it everywwhere. Writing this I'm slightly in favour of Dimitry's approach: I quite often run into problems when using SSH to log in to a Linux box from my OSX laptop (with LC_CTYPE=UTF-8). Almost everything works correctly, except for Python code that uses the locale module (which craps out with the exception in the first message in this issue). IMHO Dimitry's patch should be applied as is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 13:30:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 May 2015 11:30:00 +0000 Subject: [issue24199] Idle: remove idlelib.idlever.py and its use in About dialog In-Reply-To: <1431650285.59.0.600694723613.issue24199@psf.upfronthosting.co.za> Message-ID: <1431689400.05.0.110122333008.issue24199@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Are there third-party IDLE plugins? If yes, this change can break them. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 14:41:48 2015 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 15 May 2015 12:41:48 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1431693708.34.0.742968607719.issue23699@psf.upfronthosting.co.za> Petr Viktorin added the comment: What can I, not a core developer, do to resolve this disagreement? Should I submit a PEP? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 14:42:49 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 15 May 2015 12:42:49 +0000 Subject: [issue24198] please align the platform tag for windows In-Reply-To: <1431641901.05.0.53080075621.issue24198@psf.upfronthosting.co.za> Message-ID: <1431693769.83.0.794471273496.issue24198@psf.upfronthosting.co.za> Paul Moore added the comment: So just to be clear - this proposal would *only* affect the tagged filename used for loading ".pyd" files? (And in practice, the untagged form is normally used for Windows .pyd files anyway...) ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 14:45:24 2015 From: report at bugs.python.org (Abhishek Manandhar) Date: Fri, 15 May 2015 12:45:24 +0000 Subject: [issue24202] Multiprocessing Pool not working for userdefined function Message-ID: <1431693924.76.0.51745910964.issue24202@psf.upfronthosting.co.za> New submission from Abhishek Manandhar: I was looking to implement multiprocess pool. It worked fine with the numpy function while with the user defined function it ran into error. import numpy >>> import multiprocessing >>> P = multiprocessing.Pool(5) >>> P.map(numpy.sqrt,range(50)) [0.0, 1.0, 1.4142135623730951, 1.7320508075688772, 2.0, 2.2360679774997898, 2.4494897427831779, 2.6457513110645907, 2.8284271247461903, 3.0, 3.1622776601683795, 3.3166247903553998, 3.4641016151377544, 3.6055512754639891, 3.7416573867739413, 3.872983346207417, 4.0, 4.1231056256176606, 4.2426406871192848, 4.358898943540674, 4.4721359549995796, 4.5825756949558398, 4.6904157598234297, 4.7958315233127191, 4.8989794855663558, 5.0, 5.0990195135927845, 5.196152422706632, 5.2915026221291814, 5.3851648071345037, 5.4772255750516612, 5.5677643628300215, 5.6568542494923806, 5.7445626465380286, 5.8309518948453007, 5.9160797830996161, 6.0, 6.0827625302982193, 6.164414002968976, 6.2449979983983983, 6.324555320336759, 6.4031242374328485, 6.4807406984078604, 6.5574385243020004, 6.6332495807107996, 6.7082039324993694, 6.7823299831252681, 6.8556546004010439, 6.9282032302755088, 7.0] >>> def f(x): return x*x >>> P.map(f, range(50)) Exception in thread Thread-2: Traceback (most recent call last): File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner self.run() File "C:\Python27\lib\threading.py", line 483, in run self.__target(*self.__args, **self.__kwargs) File "C:\Python27\lib\multiprocessing\pool.py", line 285, in _handle_tasks put(task) TypeError: expected string or Unicode object, NoneType found ---------- components: Windows messages: 243266 nosy: abheeman, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Multiprocessing Pool not working for userdefined function type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 14:52:08 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 15 May 2015 12:52:08 +0000 Subject: [issue24202] Multiprocessing Pool not working for userdefined function In-Reply-To: <1431693924.76.0.51745910964.issue24202@psf.upfronthosting.co.za> Message-ID: <1431694328.87.0.400007931628.issue24202@psf.upfronthosting.co.za> Paul Moore added the comment: Multiprocessing works by firing up additional processes. Those processes won't have access to functions defined in the interactive interpreter. Can you reproduce this problem in a standalone script? I suspect not, but if you can please post the script here. Marking as "not a bug", but I haven't closed it yet in case a script reproducing the issue can be provided. ---------- nosy: +paul.moore resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 15:03:14 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 15 May 2015 13:03:14 +0000 Subject: [issue24202] Multiprocessing Pool not working for userdefined function In-Reply-To: <1431693924.76.0.51745910964.issue24202@psf.upfronthosting.co.za> Message-ID: <1431694994.24.0.178219735815.issue24202@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 15:06:20 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 15 May 2015 13:06:20 +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: <1431695180.25.0.983335437094.issue24033@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 15:56:59 2015 From: report at bugs.python.org (Abhishek Manandhar) Date: Fri, 15 May 2015 13:56:59 +0000 Subject: [issue24202] Multiprocessing Pool not working for userdefined function In-Reply-To: <1431694328.87.0.400007931628.issue24202@psf.upfronthosting.co.za> Message-ID: Abhishek Manandhar added the comment: Yes actually it produce no erroe on standalone script. But the script executes without any outputs. not even for numpy function. I used code below in script. import multiprocessing import numpy def f(x): return x*x if __name__ = "__main__": p= multiprocessing.Pool(5) print p.map(numpy.sqrt,[1,2,3,4]) print p.map(f,[1,2,3,4]) On May 15, 2015 2:52 PM, "Paul Moore" wrote: > > Paul Moore added the comment: > > Multiprocessing works by firing up additional processes. Those processes > won't have access to functions defined in the interactive interpreter. > > Can you reproduce this problem in a standalone script? I suspect not, but > if you can please post the script here. > > Marking as "not a bug", but I haven't closed it yet in case a script > reproducing the issue can be provided. > > ---------- > nosy: +paul.moore > resolution: -> not a bug > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 16:07:07 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 15 May 2015 14:07:07 +0000 Subject: [issue24202] Multiprocessing Pool not working for userdefined function In-Reply-To: <1431693924.76.0.51745910964.issue24202@psf.upfronthosting.co.za> Message-ID: <1431698827.53.0.662852939504.issue24202@psf.upfronthosting.co.za> Paul Moore added the comment: OK, if it's not reproducible in a standalone script, I'll close this as it's expected behaviour. Correcting the typo in your script (__name__ == "__main__"), I ran it and it worked as expected on my system: >type multi.py import multiprocessing import numpy def f(x): return x*x if __name__ == "__main__": p= multiprocessing.Pool(5) print(p.map(numpy.sqrt,[1,2,3,4])) print(p.map(f,[1,2,3,4])) PS 15:05 {00:00.089} C:\Work\Scratch >py .\multi.py [1.0, 1.4142135623730951, 1.7320508075688772, 2.0] [1, 4, 9, 16] I'm not sure why you weren't getting output, but it doesn't look like a Python issue. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 16:45:17 2015 From: report at bugs.python.org (eryksun) Date: Fri, 15 May 2015 14:45:17 +0000 Subject: [issue24201] _winreg PyHKEY Type Confusion In-Reply-To: <1431679011.32.0.0649667606823.issue24201@psf.upfronthosting.co.za> Message-ID: <1431701117.51.0.1139406478.issue24201@psf.upfronthosting.co.za> eryksun added the comment: > wherein pointers can be passed directly in place of PyHKEY > instances e.g. _winreg.QueryValue(0x41414141, "") If a debugger is attached you see the first-chance exception for the access violation. Normally the registry function simply returns ERROR_INVALID_HANDLE (6), which gets raised as an OSError in Python. The call took the RPC path because the low bit (1) marks a remote handle, which is actually a pointer to a data structure. RPCRT4!NDRCContextBinding looks for a signature (0xFEDCBA98) to validate this structure. In this case the attempt raised an access violation, which gets handled by raising another exception with the exception code set to ERROR_INVALID_HANDLE. The same exception gets raised if it can't validate the handle. Subsequently this exception is handled by calling RPCRT4!NdrClientMapCommFault to map the code to a return value. For example (x64 ISA): >>> _winreg.QueryInfoKey(0x41414141) (a2c.828): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. RPCRT4!NDRCContextBinding+0x4: 000007fe`fefca6e4 81790898badcfe cmp dword ptr [rcx+8],0FEDCBA98h ds:00000000`41414148=???????? 0:000> gN (a2c.828): Unknown exception - code 00000006 (first chance) Breakpoint 0 hit RPCRT4!NdrClientMapCommFault: 000007fe`ff05f010 fff3 push rbx 0:000> kc 8 Call Site RPCRT4!NdrClientMapCommFault RPCRT4!NdrpClientCall3 RPCRT4!NdrClientCall3 ADVAPI32!SafeBaseRegQueryInfoKey ADVAPI32!RemoteRegQueryInfoKeyWrapper kernel32!TlsGetValue ADVAPI32!RegQueryInfoKeyAStub python27!PyQueryInfoKey The exception code is passed in register r8 and gets assigned to the address in r9: 0:000> r r8, r9 r8=0000000000000006 r9=000000000021f1d8 0:000> dd 21f1d8 l1 00000000`0021f1d8 00000000 0:000> pt RPCRT4!NdrClientMapCommFault+0x80: 000007fe`ff05f080 c3 ret 0:000> dd 21f1d8 l1 00000000`0021f1d8 00000006 This return value gets passed back up the call stack: 0:000> gu; pt; r rax rax=0000000000000006 0:000> gu; pt; r rax rax=0000000000000006 0:000> gu; pt; r rax rax=0000000000000006 0:000> gu; pt; r rax rax=0000000000000006 0:000> gu; pt; r rax rax=0000000000000006 0:000> r rax=0000000000000006 rbx=0000000000e1cda0 rcx=0000000000000000 rdx=0000000000000000 rsi=0000000000000000 rdi=000000001e1027b0 rip=00000000779ba204 rsp=000000000021f9d8 rbp=0000000000eb61c8 r8=000000000021f1d8 r9=0000000000000000 r10=000000000021f1d8 r11=000000000021f8b0 r12=0000000000e1cda0 r13=0000000000807bb0 r14=000000001e2b3210 r15=0000000000eb7060 iopl=0 nv up ei pl nz na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206 kernel32!RegQueryInfoKeyA+0x364: 00000000`779ba204 c3 ret Until finally getting raised as a Python exception: 0:000> g Traceback (most recent call last): File "", line 1, in WindowsError: [Error 6] The handle is invalid The odds are extremely low that someone will pass in an integer address that's flagged as a remote handle (ends in 1) and is a valid, mapped address that contains the RPC handle signature. Even then, it won't reference an actual proxy handle for a remote registry, so it'll just fail farther along the chain. I'm sure if a feature exists that someone, somewhere depends on it, so I don't see a reason to change this unless there's a real problem here. Is there a specific technical or security problem that you see here? ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 16:50:06 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 May 2015 14:50:06 +0000 Subject: [issue24192] unexpected system error with pep420 style namespace packages In-Reply-To: <1431604720.34.0.497693265378.issue24192@psf.upfronthosting.co.za> Message-ID: <1431701406.61.0.291190202488.issue24192@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 16:51:06 2015 From: report at bugs.python.org (Christian Heimes) Date: Fri, 15 May 2015 14:51:06 +0000 Subject: [issue17305] IDNA2008 encoding missing In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za> Message-ID: <1431701466.23.0.575320043131.issue17305@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 17:02:20 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 15 May 2015 15:02:20 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1431702140.86.0.98623376864.issue23699@psf.upfronthosting.co.za> Raymond Hettinger added the comment: You don't need a PEP. If Barry and Marc-Andre want this to go forward, I won't hold it back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 17:59:36 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 15 May 2015 15:59:36 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431705576.49.0.498619980139.issue24195@psf.upfronthosting.co.za> Ethan Furman added the comment: Short History: ============= (Ram Rachum) What do you think about adding a method: `Executor.filter`? I was using something like this: my_things = [thing for thing in things if some_condition(thing)] But the problem was that `some_condition` took a long time to run waiting on I/O, which is a great candidate for parallelizing with ThreadPoolExecutor. I made it work using `Executor.map` and some improvizing, but it would be nicer if I could do: with concurrent.futures.ThreadPoolExecutor(100) as executor: my_things = executor.filter(some_condition, things) And have the condition run in parallel on all the threads. (Nick Coughlan) I think this is sufficiently tricky to get right that it's worth adding filter() as a parallel to the existing map() API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 18:19:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 May 2015 16:19:48 +0000 Subject: [issue24162] [2.7 regression] test_asynchat test failure on i586-linux-gnu In-Reply-To: <1431303240.23.0.685308735341.issue24162@psf.upfronthosting.co.za> Message-ID: <20150515161944.107537.51383@psf.io> Roundup Robot added the comment: New changeset 7adfc99103d2 by Benjamin Peterson in branch '2.7': deque is not varsized, so using Py_SIZE is nonsensical (closes #24162) https://hg.python.org/cpython/rev/7adfc99103d2 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 18:30:51 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 May 2015 16:30:51 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431707451.45.0.614427714546.issue24195@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > (Nick Coughlan) Nick Coghlan isn't currently on this issue. Unless you were talking about another, separate Nick Coughlan that I don't know of? :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 18:33:11 2015 From: report at bugs.python.org (anon) Date: Fri, 15 May 2015 16:33:11 +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: <1431707591.18.0.988707069277.issue19915@psf.upfronthosting.co.za> anon added the comment: I'm struggling to get time for this. I hope someone else can take responsibility. Sorry :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 18:33:51 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 15 May 2015 16:33:51 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431707631.85.0.530721182178.issue24195@psf.upfronthosting.co.za> Antoine Pitrou added the comment: But to answer your argument: > I think this is sufficiently tricky to get right that it's worth > adding filter() as a parallel to the existing map() API. "Tricky to get right" is not a good criterion. The question is whether it's useful or not. Only the OP has had that need AFAIK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 18:38:54 2015 From: report at bugs.python.org (anon) Date: Fri, 15 May 2015 16:38:54 +0000 Subject: [issue24203] Depreciate threading.Thread.isDaemon etc Message-ID: <1431707934.14.0.173246279453.issue24203@psf.upfronthosting.co.za> New submission from anon: In threading.Thread isDaemon, setDaemon, getName, setName are not needed since 2.6 (preferring directly changing daemon or name instead). They should probably be depreciated in 3.5 and removed later. isAlive has already been removed. ---------- messages: 243277 nosy: anon priority: normal severity: normal status: open title: Depreciate threading.Thread.isDaemon etc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 18:42:36 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 15 May 2015 16:42:36 +0000 Subject: [issue22547] Implement an informative `BoundArguments.__repr__` In-Reply-To: <1412353594.59.0.76573265737.issue22547@psf.upfronthosting.co.za> Message-ID: <1431708156.83.0.732616835152.issue22547@psf.upfronthosting.co.za> Yury Selivanov added the comment: Actually, I like the current repr (minus the object ID, I'll update the code). The thing about BoundArguments is that '.arguments' is the main property. You use it to add more stuff to *args & **kwargs, or to add/remove positional/keyword arguments. Seeing a flattened call signature in the repr won't help you with debugging. Perhaps, we can implement __str__ using your approach. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 18:43:27 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 15 May 2015 16:43:27 +0000 Subject: [issue24200] Redundant id in informative reprs In-Reply-To: <1431671088.82.0.205930864804.issue24200@psf.upfronthosting.co.za> Message-ID: <1431708207.79.0.109083675372.issue24200@psf.upfronthosting.co.za> Yury Selivanov added the comment: Agree. Let's remove them. I'll update the code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 18:54:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 May 2015 16:54:03 +0000 Subject: [issue24200] Redundant id in informative reprs In-Reply-To: <1431671088.82.0.205930864804.issue24200@psf.upfronthosting.co.za> Message-ID: <20150515165400.21190.14774@psf.io> Roundup Robot added the comment: New changeset d72d31f4b69a by Yury Selivanov in branch 'default': inspect: Remove "0x..." IDs from Signature objects' __repr__ https://hg.python.org/cpython/rev/d72d31f4b69a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 18:55:10 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 15 May 2015 16:55:10 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431708910.43.0.267949876442.issue24195@psf.upfronthosting.co.za> Ethan Furman added the comment: That comment was from an email by Nick, not to Nick. But now I've added him. ;) ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 18:55:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 May 2015 16:55:26 +0000 Subject: [issue24200] Redundant id in informative reprs In-Reply-To: <1431671088.82.0.205930864804.issue24200@psf.upfronthosting.co.za> Message-ID: <20150515165524.4521.69948@psf.io> Roundup Robot added the comment: New changeset f23d0a4278aa by Yury Selivanov in branch 'default': Issue 24200: Fix broken unittest. https://hg.python.org/cpython/rev/f23d0a4278aa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 18:55:49 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 15 May 2015 16:55:49 +0000 Subject: [issue24200] Redundant id in informative reprs In-Reply-To: <1431671088.82.0.205930864804.issue24200@psf.upfronthosting.co.za> Message-ID: <1431708949.2.0.337635801952.issue24200@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 22:49:36 2015 From: report at bugs.python.org (Jim) Date: Fri, 15 May 2015 20:49:36 +0000 Subject: [issue24204] string.strip() documentation is misleading Message-ID: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za> New submission from Jim: This probably applies to all versions with the strip() method, but I'm using 3.4. Section 4.7.1 of the documentation has a poorly worded description/example for the behaviour of string.strip([chars]). A casual reading of "The chars argument is not a prefix or suffix; rather, all combinations of its values are stripped" lead me to believe this >>> '0.0'.strip('.') '0.0' should be equivalent to the solution I found later >>> '0.0'.replace('.', '') '00' The bit about [chars] requires recursive thinking ("are _stripped_") and clouds the fact that strip() iterates from beginning and end, discarding characters until it reaches a character that isn't in [chars]. In the example, it's not obvious (or wasn't to me) that the 'm' wasn't removed from 'example', and the missing periods gave the impression that they had been removed from the middle of the string instead of iterated to from the ends. I can't think of a good way to rewrite the description, but perhaps you could borrow an example from rstrip() and add/replace: >>> 'mississippi'.strip('mip') 'ssiss' The glaring existence of that 'i' in the middle, when all others have been removed makes the limitation clear. >>> ' hello world '.strip() 'hello world' Makes another good example. Just trying to save someone else 20 minutes of confusion. ---------- assignee: docs at python components: Documentation messages: 243283 nosy: PhoenixofMT, docs at python priority: normal severity: normal status: open title: string.strip() documentation is misleading type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 15 23:28:19 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 15 May 2015 21:28:19 +0000 Subject: [issue24204] string.strip() documentation is misleading In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za> Message-ID: <1431725299.68.0.921956930805.issue24204@psf.upfronthosting.co.za> Mark Lawrence added the comment: https://docs.python.org/3/library/stdtypes.html#str.strip first sentence "Return a copy of the string with the leading and trailing characters removed." How can that be reworded to make it clearer? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 00:26:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 May 2015 22:26:27 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1431728786.99.0.47158751767.issue23840@psf.upfronthosting.co.za> STINNER Victor added the comment: > You should see the new file in the next 30 minutes. I don't see the new file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 00:42:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 May 2015 22:42:49 +0000 Subject: [issue17620] Python interactive console doesn't use sys.stdin for input In-Reply-To: <1364921954.86.0.527255608282.issue17620@psf.upfronthosting.co.za> Message-ID: <1431729769.77.0.65053569645.issue17620@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: -haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 01:17:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 May 2015 23:17:12 +0000 Subject: [issue24064] Make the property doctstring writeable In-Reply-To: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> Message-ID: <20150515231709.10812.76396@psf.io> Roundup Robot added the comment: New changeset 5262dd507ee5 by Raymond Hettinger in branch 'default': Issue #24064: Docuement that oroperty docstrings are now writeable. https://hg.python.org/cpython/rev/5262dd507ee5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 01:48:53 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 15 May 2015 23:48:53 +0000 Subject: [issue24205] signature.bind error messages are sub-optimal Message-ID: <1431733733.27.0.866799524337.issue24205@psf.upfronthosting.co.za> New submission from R. David Murray: I have an application where I'm calling a handler function with passed in arguments. I want to generate an error if the handler is called with the wrong arguments. I can't just catch TypeError since a TypeError could easily result from some programming error in the handler, rather than an error in the calling args. So, doing this seems obvious: sig = signature(handler) try: bound = sig.bind(message, payload, *args, **kw) except TypeError as exc: print("Invalid handler call: {}".format(str(exc)) handler(*bound.args, **bound.kwargs) Now, suppose I have a function like: def foo(message, payload, anarg, akeyword='bar'): pass If I call it directly with an invalid keyword argument I get: >>> foo(1, 2, 3, badword=7) Traceback (most recent call last): File "", line 1, in TypeError: foo() got an unexpected keyword argument 'badword' However, bind gives me: >>> sig.bind(1, 2, 3, badword=7) Traceback (most recent call last): File "", line 1, in File "/home/rdmurray/python/p35/Lib/inspect.py", line 2818, in bind return args[0]._bind(args[1:], kwargs) File "/home/rdmurray/python/p35/Lib/inspect.py", line 2809, in _bind raise TypeError('too many keyword arguments') TypeError: too many keyword arguments Similarly, for a missing argument I get: >>> foo(1, 2) Traceback (most recent call last): File "", line 1, in TypeError: foo() missing 1 required positional argument: 'anarg' While bind gives: >>> sig.bind(1, 2) Traceback (most recent call last): File "", line 1, in File "/home/rdmurray/python/p35/Lib/inspect.py", line 2818, in bind return args[0]._bind(args[1:], kwargs) File "/home/rdmurray/python/p35/Lib/inspect.py", line 2737, in _bind raise TypeError(msg) from None TypeError: 'anarg' parameter lacking default value So, using this to replace catching the TypeError from incorrectly calling a function does not work. Nor are the messages in fact accurate. Is there any chance we could make bind's error handling work like regular function binding? That's certainly what I expected would happen! ---------- components: Library (Lib) messages: 243287 nosy: r.david.murray, yselivanov priority: normal severity: normal status: open title: signature.bind error messages are sub-optimal type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 02:02:49 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 May 2015 00:02:49 +0000 Subject: [issue24114] ctypes.utils uninitialized variable 'path' In-Reply-To: <1430578995.23.0.112303250331.issue24114@psf.upfronthosting.co.za> Message-ID: <1431734569.67.0.400832066754.issue24114@psf.upfronthosting.co.za> Martin Panter added the comment: I fail to see how this patch does anything. What is the actual error or traceback? Perhaps it is for ?paths? (plural)? ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 02:06:41 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 16 May 2015 00:06:41 +0000 Subject: [issue24205] signature.bind error messages are sub-optimal In-Reply-To: <1431733733.27.0.866799524337.issue24205@psf.upfronthosting.co.za> Message-ID: <1431734801.21.0.150436784769.issue24205@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 02:14:36 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 May 2015 00:14:36 +0000 Subject: [issue24204] string.strip() documentation is misleading In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za> Message-ID: <1431735276.65.0.549169265022.issue24204@psf.upfronthosting.co.za> R. David Murray added the comment: Indeed, the sentence that confused you was added because people were continually confused by the fact that doing: 'foo.boo'.strip('.boo') would result in 'f' rather than 'foo'. We would welcome an improvement, but apparently this is very hard to make clear. Repeating the mississippi example is probably a good idea. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 02:30:11 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 May 2015 00:30:11 +0000 Subject: [issue9694] argparse required arguments displayed under "optional arguments" In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za> Message-ID: <1431736211.15.0.778643261566.issue9694@psf.upfronthosting.co.za> Martin Panter added the comment: Is there any interest in my or Ryan?s patches, which change the default heading away from ?optional arguments?? Changing the default is my preferred fix, but if others don?t like it (e.g. compatibility concerns), I am happy to work on a documentation patch according to . I don?t see how adding an extra help groups API is very helpful though. The problem here is that the default help group headings are wrong (or at least misleading to many people). ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 02:30:42 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 16 May 2015 00:30:42 +0000 Subject: [issue24192] unexpected system error with pep420 style namespace packages In-Reply-To: <1431604720.34.0.497693265378.issue24192@psf.upfronthosting.co.za> Message-ID: <1431736242.42.0.104052626733.issue24192@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a fix. If I don't hear from anyone right away I'll push it in a few hours (or tomorrow morning). ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file39386/issue24192.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 02:30:54 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 16 May 2015 00:30:54 +0000 Subject: [issue24192] unexpected system error with pep420 style namespace packages In-Reply-To: <1431604720.34.0.497693265378.issue24192@psf.upfronthosting.co.za> Message-ID: <1431736254.79.0.493768125495.issue24192@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- assignee: -> eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 02:36:39 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 May 2015 00:36:39 +0000 Subject: [issue24205] signature.bind error messages are sub-optimal In-Reply-To: <1431733733.27.0.866799524337.issue24205@psf.upfronthosting.co.za> Message-ID: <1431736599.31.0.631645560021.issue24205@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 04:42:40 2015 From: report at bugs.python.org (JohnLeitch) Date: Sat, 16 May 2015 02:42:40 +0000 Subject: [issue24201] _winreg PyHKEY Type Confusion In-Reply-To: <1431679011.32.0.0649667606823.issue24201@psf.upfronthosting.co.za> Message-ID: <1431744160.33.0.503696400543.issue24201@psf.upfronthosting.co.za> JohnLeitch added the comment: Thank you for taking the time to peruse my report and explain the behavior I observed. My understanding of Windows RPC internals is lacking, and perhaps I jumped the gun upon catching an AV while fuzzing. That said, after poking around to better understand the matter, I discovered a few things: 1) There are code paths where it is possible to trigger an unhandled access violation: 0:000> g (11a0.d54): Access violation - code c0000005 (!!! second chance !!!) eax=60dad396 ebx=00000000 ecx=00000000 edx=00000000 esi=000000a0 edi=000000a0 eip=776f1037 esp=0027f790 ebp=0027f80c iopl=0 nv up ei pl nz ac pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010216 ntdll!RtlAllocateHeap+0x17: 776f1037 8b4344 mov eax,dword ptr [ebx+44h] ds:002b:00000044=?????? ?? 0:000> k ChildEBP RetAddr 0027f80c 75471731 ntdll!RtlAllocateHeap+0x17 0027f82c 75479616 RPCRT4!AllocWrapper+0x2d 0027f840 75479791 RPCRT4!ThreadSelfHelper+0x16 0027f848 754f6b2a RPCRT4!ThreadSelf+0x18 0027fc74 753a5d94 RPCRT4!NdrClientCall2+0x13a 0027fc8c 7539f48b ADVAPI32!BaseRegGetVersion+0x24 0027fce4 7538dfce ADVAPI32!RegDeleteKeyW+0x14aeb 0027fd00 1e0de533 ADVAPI32!RegDeleteKeyA+0x2e 0027fd18 1e0aafd7 python27!PyDeleteKey+0x53 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 75967c04 python!__tmainCRTStartup+0x10f 0027ff94 7770ad1f KERNEL32!BaseThreadInitThunk+0x24 0027ffdc 7770acea ntdll!__RtlUserThreadStart+0x2f 0027ffec 00000000 ntdll!_RtlUserThreadStart+0x1b 0:000> This doesn't appear to be outright exploitable for anything beyond DoS, but it does crash the process. 2) Assuming attacker control of the hkey parameter to a _winreg call, I believe it would be possible to leverage the RPC signature check to disclose the location of valid memory such as the RPC module itself, thereby bypassing ASLR. >>> import _winreg >>> _winreg.DeleteKey(0x75469AF1, '') Traceback (most recent call last): File "", line 1, in _winreg.DeleteKey(0x75469AF1, '') WindowsError: [Error 6] The handle is invalid >>> _winreg.DeleteKey(0x75469AF3, '') >>> ================================ RESTART ================================ >>> 0:000> dd 0x75469AF3 75469af3 98047881 0ffedcba 01d9a085 fc45c700 75469b03 fffffffe 8fe8008b c20000a2 90900004 75469b13 90909090 fffffe90 000000ff ffffd400 75469b23 000000ff fffffe00 49d901ff 49d92575 75469b33 06f76875 b2e80000 8b000161 47c7e845 75469b43 0000003c 50478900 00a661e9 09be0f00 75469b53 00a649e9 06f76800 8ee80000 68000161 75469b63 000006e6 016184e8 90909000 499e5190 0:000> !address 0x75469AF3 Usage: Image Base Address: 75451000 End Address: 754fa000 Region Size: 000a9000 State: 00001000 MEM_COMMIT Protect: 00000020 PAGE_EXECUTE_READ Type: 01000000 MEM_IMAGE Allocation Base: 75450000 Allocation Protect: 00000080 PAGE_EXECUTE_WRITECOPY Image Path: C:\WINDOWS\SysWOW64\RPCRT4.dll Module Name: RPCRT4 Loaded Image Name: C:\WINDOWS\SYSTEM32\RPCRT4.dll Mapped Image Name: More info: lmv m RPCRT4 More info: !lmi RPCRT4 More info: ln 0x75469af3 More info: !dh 0x75450000 3) Finally, I still suspect it may be possible to achieve memory corruption with this bug, but cannot verify without a better understanding of the structures at play and further analysis. The hypothetical attack goes like this: a) The attacker sprays memory with carefully constructed buffers containing the expected magic numbers at the correct offsets. b) Once memory has been sufficiently sprayed, the attacker triggers the bug with an hkey value that is actually an address predicted to be one of the sprayed structures. c) While working with the attacker controlled buffer, RPC inadvertently corrupts memory. Step C is, of course, dependent on what what fields are available in the structure, and what RPC does with them. Unfortunately I can't find any relevant documentation or code, but in my testing I was able to force different code paths. Some look fruitful, but determining whether they're reachable would be costly time-wise, and it's a bit of a moot point because we're talking about Microsoft's internal implementation, which could change at any point, altering exploitability. Given that, I'd say it's best to err on the side of caution, and assume corruption is possible with the right primitives. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 05:04:24 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 03:04:24 +0000 Subject: [issue23184] Unused imports, variables, file in IDLE In-Reply-To: <1420626411.51.0.528702156456.issue23184@psf.upfronthosting.co.za> Message-ID: <20150516030421.32303.97443@psf.io> Roundup Robot added the comment: New changeset d50d661a08f5 by Terry Jan Reedy in branch '2.7': Issue #23184: idlelib, remove more unused names and imports. https://hg.python.org/cpython/rev/d50d661a08f5 New changeset 777569dd4bca by Terry Jan Reedy in branch '3.4': Issue #23184: idlelib, remove more unused names and imports. https://hg.python.org/cpython/rev/777569dd4bca New changeset 6c424b06320b by Terry Jan Reedy in branch 'default': Merge with 3.4 Issue #23184: idlelib, remove more unused names and imports. https://hg.python.org/cpython/rev/6c424b06320b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 05:56:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 03:56:16 +0000 Subject: [issue23184] Unused imports, variables, file in IDLE In-Reply-To: <1420626411.51.0.528702156456.issue23184@psf.upfronthosting.co.za> Message-ID: <20150516035613.44693.34164@psf.io> Roundup Robot added the comment: New changeset 8875d7c6a99d by Terry Jan Reedy in branch '2.7': Issue #23184: idle tests, remove unused names and imports. https://hg.python.org/cpython/rev/8875d7c6a99d New changeset 526ce81f700d by Terry Jan Reedy in branch '3.4': Issue #23184: idle tests, remove unused names and imports. https://hg.python.org/cpython/rev/526ce81f700d New changeset 2a56eb5c08cc by Terry Jan Reedy in branch 'default': Merge 3.4 #23184: idle tests, remove unused names and imports. https://hg.python.org/cpython/rev/2a56eb5c08cc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 05:56:48 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 May 2015 03:56:48 +0000 Subject: [issue23184] Unused imports, variables, file in IDLE In-Reply-To: <1420626411.51.0.528702156456.issue23184@psf.upfronthosting.co.za> Message-ID: <1431748608.19.0.245681065263.issue23184@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 05:57:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 03:57:11 +0000 Subject: [issue24192] unexpected system error with pep420 style namespace packages In-Reply-To: <1431604720.34.0.497693265378.issue24192@psf.upfronthosting.co.za> Message-ID: <20150516035709.10824.41395@psf.io> Roundup Robot added the comment: New changeset 46b2c99121f5 by Eric Snow in branch 'default': Issue #24192: Fix namespace package imports. https://hg.python.org/cpython/rev/46b2c99121f5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 05:57:49 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 16 May 2015 03:57:49 +0000 Subject: [issue24192] unexpected system error with pep420 style namespace packages In-Reply-To: <1431604720.34.0.497693265378.issue24192@psf.upfronthosting.co.za> Message-ID: <1431748669.78.0.649578225895.issue24192@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> pending type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 08:13:36 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 16 May 2015 06:13:36 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431756816.78.0.442594049045.issue24195@psf.upfronthosting.co.za> Nick Coghlan added the comment: filter() usage has always been less common than map() usage, and we see a similar pattern in comprehension usage as well (i.e. [f(x) for x in y] is a far more common construct than [x for x in p(y)]). That "less common" status doesn't keep us from providing filter() as builtin, or syntactic support for filtering in the comprehension syntax. As a result, the main question I'd like to see a clear and authoritative answer to is "Given 'seq2 = filter(p, seq)' or 'seq2 = [x for seq if p(x)]', what's the concurrent.futures based parallel execution syntax in cases where the filtering key is expensive to calculate?" I'd be quite OK with Brian's 2-line implementation going into the concurrent.futures documentation as a filtering recipe, similar to the way Raymond uses the recipes in the itertools documentation to help minimise complexity growth in the core API. I *don't* mind if Brian's judgement is that it doesn't rise to the level of being worth including as a core feature in its own right, as I agree that the typical case of filtering functions is that they're fast, and when they're not, it's often a sign that data model denormalisation may be desirable in order to cache the relevant derived property. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 09:52:04 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 16 May 2015 07:52:04 +0000 Subject: [issue24192] unexpected system error with pep420 style namespace packages In-Reply-To: <1431604720.34.0.497693265378.issue24192@psf.upfronthosting.co.za> Message-ID: <1431762724.74.0.837503053088.issue24192@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I can confirm that this fixes the problem I was having, both for the sample code I posted and for the real codebase I extracted this from. Thanks. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 09:58:55 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 16 May 2015 07:58:55 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431763135.78.0.663546813473.issue24195@psf.upfronthosting.co.za> Nick Coghlan added the comment: Folks could probably guess what I meant, but both filter comprehensions in my comment should have read: "[x for x in seq if p(x)]" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 10:04:23 2015 From: report at bugs.python.org (Kees Bos) Date: Sat, 16 May 2015 08:04:23 +0000 Subject: [issue24114] ctypes.utils uninitialized variable 'path' In-Reply-To: <1430578995.23.0.112303250331.issue24114@psf.upfronthosting.co.za> Message-ID: <1431763463.86.0.268032461715.issue24114@psf.upfronthosting.co.za> Kees Bos added the comment: Sorry, yes. It's plural: 'paths' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 10:26:43 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 16 May 2015 08:26:43 +0000 Subject: [issue23969] please set a SOABI for MacOSX In-Reply-To: <1429125133.46.0.136772675069.issue23969@psf.upfronthosting.co.za> Message-ID: <1431764803.03.0.351196128731.issue23969@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I'm in favour of using SOABI on OSX as well. The build system currently uses "darwin" for the platform triplet, that's a bit to minimal. I'd prefer to use "macosx" instead of "darwin" for the platform name, the same as is done for platform specific directories/files in distutils. I'm not sure yet about what to do with the hardware architecture and deployment target. On the one hand it could be nice to reflect those in the name of extensions, on the other hand that makes it harder to mix and match binaries. In particular, a fat binary for Python with deployment target 10.5 can currently load single architecture extensions with a different deployment target. That is useful functionality to have (for example to be able to load C bindings for newer OSX libraries in a python.org binary, the newer OSX libraries don't support PPC and some of them even don't support 32-bit i386 code). It would be a shame when the extension name would have lie about what's actually inside. BTW. It might be useful change the suffix for extensions as well when adding the SOABI. The extension is currently ".so" and might be changed to something like ".pyext" to make it clearer what the file is for. That would also make it possible to use custom icons for extensions in the Finder and be smarter about them in spotlight and quicklook. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 10:28:58 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 16 May 2015 08:28:58 +0000 Subject: [issue13797] Allow objects implemented in pure Python to export PEP 3118 buffers In-Reply-To: <1326709751.32.0.965094376059.issue13797@psf.upfronthosting.co.za> Message-ID: <1431764938.33.0.419730358937.issue13797@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 11:04:15 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 16 May 2015 09:04:15 +0000 Subject: [issue11477] Incorrect operand precedence when implementing sequences in C In-Reply-To: <1299965091.63.0.267715976543.issue11477@psf.upfronthosting.co.za> Message-ID: <1431767055.03.0.739353633886.issue11477@psf.upfronthosting.co.za> Nick Coghlan added the comment: Nathaniel Smith pointed out on python-dev (https://mail.python.org/pipermail/python-dev/2015-May/140006.html) that NumPy is relying on this bug to implement elementwise multiplication of a list by a scalar array: In [9]: [1, 2] * np.array(2) Out[9]: array([2, 4]) He also pointed out that PyPy implemented bug-for-bug compatibility with this some time back: https://bitbucket.org/pypy/pypy/src/a1a494787f4112e42f50c6583e0fea18db3fb4fa/pypy/objspace/descroperation.py?at=default#cl-692 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 11:22:31 2015 From: report at bugs.python.org (Tal Einat) Date: Sat, 16 May 2015 09:22:31 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1431768151.75.0.21676254964.issue20182@psf.upfronthosting.co.za> Tal Einat added the comment: Here's a patch just for Modules/sysmodule.c (and related files), based on Georg's patch, updated to apply against current default, including fixes thanks to Serhiy's review. Despite Serhiy's suggestions, I've not used parameter groups, due to Larry's statement of his dislike of this (ab)use of the feature. I've left an alias of the form "args as args_value:" since the latest clinic.py doesn't automatically alias "args" (causing a compile error). At Serhiy's suggestion, I've also converted sys.callstats. I couldn't find any tests for it, so someone should definitely review this conversion! All tests pass on my OSX 10.10. ---------- Added file: http://bugs.python.org/file39387/issue20182.sysmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 11:54:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 09:54:36 +0000 Subject: [issue24206] Issues with equality of inspect objects Message-ID: <1431770076.76.0.66184936679.issue24206@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: There are issues with implementations of equality in inspect classes. 1. __eq__ doesn't return NotImplemented. This causes that testing for equality with an instance of different classes always returns False, even when other class implements __eq__ that handles inspect class. 2. __ne__ returns False if __eq__ returns NotImplemented (in subclass). 3. All tests test only one of "==" or "!=" operations. Proposed patch fixes these issues. ---------- components: Library (Lib) files: inspect_eq.patch keywords: patch messages: 243303 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Issues with equality of inspect objects type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file39388/inspect_eq.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 12:21:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 10:21:04 +0000 Subject: [issue24207] Argument Clinic doesn't mangle conflicting names Message-ID: <1431771664.0.0.459061806874.issue24207@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Argument Clinic adds the "_value" suffix to the end of variable names in C if the parameter name is C keyword. But it left unmodified parameter names that can conflict with parameter names of C function: args and kwargs (and module and self if they are used not as the first parameter). Following declaration generates a code that can't bi compiled: mod.func args: object kwargs: object Either Argument Clinic should add the "_value" suffix to the end of these names, or use other names for parameters of generated parser function. ---------- components: Argument Clinic messages: 243304 nosy: larry, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Argument Clinic doesn't mangle conflicting names type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 12:26:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 10:26:54 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1431772014.5.0.550047622283.issue20182@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The signature of sys.getsizeof() is not correct. sys.getsizeof(obj) is not the same as sys.getsizeof(obj, None). If not use optional group, then this function should not be converted to Argument Clinic. See also dict.get() with similar signature. Opened new issue (issue24207) for the bug with the args parameter. You can commit the patch for the signal module Tal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 12:30:51 2015 From: report at bugs.python.org (eryksun) Date: Sat, 16 May 2015 10:30:51 +0000 Subject: [issue24201] _winreg PyHKEY Type Confusion In-Reply-To: <1431679011.32.0.0649667606823.issue24201@psf.upfronthosting.co.za> Message-ID: <1431772251.27.0.757647500525.issue24201@psf.upfronthosting.co.za> eryksun added the comment: > ntdll!RtlAllocateHeap+0x17: > 776f1037 8b4344 mov eax,dword ptr [ebx+44h] ds:002b:00000044=???????? Some functions in RPCRT4 assume RPCRT4!PerformRpcInitialization has already been called. How else could you get an RPC handle? In this case RPCRT4!hRpcHeap hasn't been initialized yet. That said, if you first perform some operation that properly initializes RPCRT4 -- such as query a privilege value from LSA -- then using a corrupt RPC handle will possibly trigger an unhandled exception farther down the line. I don't think this is a problem that needs to be addressed in winreg. It's an application bug. Also, note that changing this in the winreg module isn't as simple as just commenting out the code in PyHKEY_AsHKEY. You'd also have to special case the HKEY constants, one way or another. Here's an example that first calls an LSA API to initialize RPCRT4 (test system: 64-bit Windows 10, 32-bit Python 2.7). Microsoft (R) Windows Debugger Version 10.0.10075.9 X86 Copyright (c) Microsoft Corporation. All rights reserved. CommandLine: python ************* Symbol Path validation summary ************** Response Time (ms) Location Deferred symsrv*symsrv.dll* C:\Symbols*http://msdl.microsoft.com/download/symbols Symbol search path is: symsrv*symsrv.dll* C:\Symbols*http://msdl.microsoft.com/download/symbols Executable search path is: (818.b4c): Break instruction exception - code 80000003 (first chance) eax=00000000 ebx=00000000 ecx=0cbe0000 edx=00000000 esi=1d0000e8 edi=7ffde000 eip=7756fb65 esp=0028fa64 ebp=0028fa90 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 ntdll!LdrpDoDebuggerBreak+0x2b: 7756fb65 cc int 3 0:000> bp RPCRT4!PerformRpcInitialization 0:000> g Python 2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes, _winreg >>> advapi32 = ctypes.WinDLL('advapi32') >>> x = (ctypes.c_void_p * 4)() >>> advapi32.LookupPrivilegeValueA(None, 'SeDebugPrivilege', x) Breakpoint 0 hit eax=0028f558 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=0028f580 eip=7477183a esp=0028f51c ebp=0028f530 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 RPCRT4!PerformRpcInitialization: 7477183a 8bff mov edi,edi 0:000> dd RPCRT4!hRpcHeap l1 747dc870 00000000 0:000> pt; dd RPCRT4!hRpcHeap l1 747dc870 003a0000 0:000> g 1 >>> x[0] = 123 # bad internal RPC handle >>> x[1] = 0xFEDCBA98 # RPC context handle signature >>> _winreg.DeleteKey(ctypes.addressof(x) | 1, '') RPCRT4 is initialized, so the unhandled exception shown below is no longer due to RPCRT4!hRpcHeap. Checking the context handle also succeeds in this case since I added the 0xFEDCBA98 signature, but it fails while checking the internal handle (0x7b, in register esi) for the signature 0x89ABCDEF. (818.b4c): Access violation - code c0000005 (!!! second chance !!!) eax=9b4e8357 ebx=0028f860 ecx=00000024 edx=00000001 esi=0000007b edi=748c66d0 eip=74766121 esp=0028f814 ebp=0028f828 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 RPCRT4!I_RpcGetBufferWithObject+0x21: 74766121 817e04efcdab89 cmp dword ptr [esi+4],89ABCDEFh ds:002b:0000007f=???????? In a 64-bit process this example doesn't crash the process. Instead the x64 version of RPCRT4.DLL handles the access violation by returning the exception code 0xC0000005. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 12:50:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 10:50:58 +0000 Subject: [issue24208] test_inspect leaks temporary directory Message-ID: <1431773458.03.0.895470927219.issue24208@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -m test.regrtest -vv -m '*_eq*' test_inspect == CPython 3.5.0a4+ (default:a444464a2e87+, May 15 2015, 09:50:37) [GCC 4.8.2] == Linux-3.13.0-52-generic-i686-with-debian-jessie-sid little-endian == hash algorithm: siphash24 32bit == /home/serhiy/py/cpython/build/test_python_17721 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_inspect test_signature_equality (test.test_inspect.TestSignatureObject) ... ok test_signature_parameter_equality (test.test_inspect.TestParameterObject) ... ok test_signature_bound_arguments_equality (test.test_inspect.TestBoundArguments) ... ok ---------------------------------------------------------------------- Ran 3 tests in 0.032s OK Warning -- files was modified by test_inspect Before: [] After: ['@test_17721_tmp_dir/'] 1 test altered the execution environment: test_inspect ---------- components: Tests messages: 243307 nosy: serhiy.storchaka, yselivanov priority: normal severity: normal status: open title: test_inspect leaks temporary directory type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 13:04:50 2015 From: report at bugs.python.org (Tal Einat) Date: Sat, 16 May 2015 11:04:50 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1431774290.11.0.814691215155.issue20182@psf.upfronthosting.co.za> Tal Einat added the comment: Attached in a conversion patch for Modules/_hashopenssl.c. Since it appear that zlib has already been converted, that's the last file to convert in this batch! All tests pass on my OSX 10.10 (after running "touch Modules/hashlib.h" to get make to recompile things that use _hashopenssl). Notes: 1) In HASH.__init__, the "name" parameter must be a string. However, the current code accepts any object and checks something else before checking whether the given object is a string. Therefore, changing the type from "object" to "str" would slightly change the parameter checking behavior. For now I've left it as it was. Also, since HASH.__new__ mirrors this, I've left it as-is as well. 2) I slightly changed the first line of the HASH object's doc-string, to make it fit in one line. It was: "A hash represents the object used to calculate a checksum of a string of information." I've changed the beginning to "A hash is an object used to calculate ..." 3) pbkdb_hmac accepts an optional "dklen" parameter which may be either a long or None. I left this as an "object", since long(accept={int, NoneType}) gives "long_converter: default value None for field dklen_obj is not of type int". ---------- Added file: http://bugs.python.org/file39389/issue20182._hashopenssl.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 13:15:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 11:15:00 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <20150516111457.10810.376@psf.io> Roundup Robot added the comment: New changeset 5342fad7cd59 by Tal Einat in branch 'default': Issue #20182: converted the signal module to use Argument Clinic https://hg.python.org/cpython/rev/5342fad7cd59 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 13:40:23 2015 From: report at bugs.python.org (Tal Einat) Date: Sat, 16 May 2015 11:40:23 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1431776423.6.0.759194897221.issue20182@psf.upfronthosting.co.za> Tal Einat added the comment: Serhiy: Indeed, you're right about sys.getsizeof(). I'm tending towards changign it to use an optional group and per Serhiy's suggestion. Larry? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 14:00:58 2015 From: report at bugs.python.org (Almad) Date: Sat, 16 May 2015 12:00:58 +0000 Subject: [issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za> Message-ID: <1431777658.14.0.622939986647.issue9377@psf.upfronthosting.co.za> Almad added the comment: I'd add that this bug is very practical and can render a lot of software unusable/noisy/confusing on Windows, including Django (I discovered this bug when mentoring on Django Girls]. The simple step to reproduce is to take any windows and set regional settings to non-English (I've used Czech). You can verify that using "import locale; locale.getpreferredencoding()", that should display something else ("cp1250" in my case). Then, set "name" (= hostname, in Windows settings) of the computer to anything containing non-ascii character (like "Didejo-no?as"). As Windows apparently encodes the hostname using their default encoding, it fails with ``` File "C:\Python34\lib\wsgiref\simple_server.py", line 50, in server_bind HTTPServer.server_bind(self) File "C:\Python34\lib\http\server.py", line 135, in server_bind self.server_name = socket.getfqdn(host) File "C:\Python34\lib\socket.py", line 463, in getfqdn hostname, aliases, ipaddrs = gethostbyaddr(name) UnicodeDecodeError: 'utf-8' codec can't decode byte 0x9d in position 9: invalid start byte ``` ---------- nosy: +Almad _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 14:35:16 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 16 May 2015 12:35:16 +0000 Subject: [issue17045] Improve C-API doc for PyTypeObject In-Reply-To: <1359245485.06.0.557532055897.issue17045@psf.upfronthosting.co.za> Message-ID: <1431779716.61.0.331115120894.issue17045@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 14:37:20 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 16 May 2015 12:37:20 +0000 Subject: [issue12816] smtpd uses library outside of the standard libraries In-Reply-To: <1314002733.23.0.776557128792.issue12816@psf.upfronthosting.co.za> Message-ID: <1431779840.48.0.826939723831.issue12816@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 14:58:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 12:58:19 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <20150516125816.125520.1488@psf.io> Roundup Robot added the comment: New changeset 738ac3ad9ee4 by Serhiy Storchaka in branch 'default': Fixed compilation error in signalmodule.c (issue #20182). https://hg.python.org/cpython/rev/738ac3ad9ee4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 15:33:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 13:33:05 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <20150516133302.4237.96020@psf.io> Roundup Robot added the comment: New changeset 0c93868f202e by Serhiy Storchaka in branch '2.7': Reverted issue #24134 changes. https://hg.python.org/cpython/rev/0c93868f202e New changeset a69a346f0c34 by Serhiy Storchaka in branch '3.4': Reverted issue #24134 changes (except new tests). https://hg.python.org/cpython/rev/a69a346f0c34 New changeset ac13f0390866 by Serhiy Storchaka in branch 'default': Issue #24134: assertRaises(), assertRaisesRegex(), assertWarns() and https://hg.python.org/cpython/rev/ac13f0390866 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 15:43:19 2015 From: report at bugs.python.org (Jim) Date: Sat, 16 May 2015 13:43:19 +0000 Subject: [issue24204] string.strip() documentation is misleading In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za> Message-ID: <1431783799.68.0.677328788867.issue24204@psf.upfronthosting.co.za> Jim added the comment: Maybe, "... all combinations of its values are stripped from the beginning and end." It is rather difficult to be both clear AND concise. Heck, I'm having trouble just trying to explain it. Mark, that part is clear, but I think somehow reiterating how the method works would be helpful to someone who is only familiar with a handful of the string methods, knows strip() removes characters, sees that several characters can be specified, and assumes that all such characters will be removed. As it is, it's sort of like a puzzle that's glaringly obvious once you figure it out, but frustrating in proportion to the amount of time spent figuring. Almost more trouble to figure out how to explain it without turning it into a tutorial than it is to sort it out on your own at the console. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 15:43:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 13:43:23 +0000 Subject: [issue23637] Warnings error with non-ascii chars. In-Reply-To: <1426062904.63.0.0951614232281.issue23637@psf.upfronthosting.co.za> Message-ID: <20150516134320.4241.26757@psf.io> Roundup Robot added the comment: New changeset 22e44a7ee89f by Serhiy Storchaka in branch '2.7': Issue #23637: Showing a warning no longer fails with UnicodeErrror. https://hg.python.org/cpython/rev/22e44a7ee89f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 15:45:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 13:45:05 +0000 Subject: [issue24176] Incorrect parsing of unpacked expressions in call In-Reply-To: <1431526045.58.0.199670957567.issue24176@psf.upfronthosting.co.za> Message-ID: <20150516134502.125536.46080@psf.io> Roundup Robot added the comment: New changeset 38b2307372bf by Benjamin Peterson in branch 'default': allow test node after ** in calls (closes #24176) https://hg.python.org/cpython/rev/38b2307372bf ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 15:54:45 2015 From: report at bugs.python.org (Link Mauve) Date: Sat, 16 May 2015 13:54:45 +0000 Subject: [issue24209] Allow IPv6 bind in http.server Message-ID: <1431784485.93.0.0140060801451.issue24209@psf.upfronthosting.co.za> New submission from Link Mauve: When running `python -m http.server -b ::` (or any other IPv6), I?d expect people to be able to download from my IPv6. This patch fixes that issue. I also tested it on a dual-stack kernel, IPv4 requests work just fine and appear as ::ffff:127.0.0.1 for example. ---------- components: Library (Lib) files: ipv6.patch keywords: patch messages: 243317 nosy: Link Mauve priority: normal severity: normal status: open title: Allow IPv6 bind in http.server type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39390/ipv6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 15:59:21 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 May 2015 13:59:21 +0000 Subject: [issue24208] test_inspect leaks temporary directory In-Reply-To: <1431773458.03.0.895470927219.issue24208@psf.upfronthosting.co.za> Message-ID: <1431784761.13.0.681816796161.issue24208@psf.upfronthosting.co.za> Yury Selivanov added the comment: That's strange. None of these test touch any files-related stuff. At least I can't see it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 16:01:52 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 May 2015 14:01:52 +0000 Subject: [issue24208] test_inspect leaks temporary directory In-Reply-To: <1431773458.03.0.895470927219.issue24208@psf.upfronthosting.co.za> Message-ID: <1431784912.95.0.250001716997.issue24208@psf.upfronthosting.co.za> Yury Selivanov added the comment: Look's like it's TestNoEOL.__init__ method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 16:10:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 14:10:28 +0000 Subject: [issue24208] test_inspect leaks temporary directory In-Reply-To: <1431773458.03.0.895470927219.issue24208@psf.upfronthosting.co.za> Message-ID: <20150516141025.16320.28628@psf.io> Roundup Robot added the comment: New changeset 08829230079b by Yury Selivanov in branch 'default': Issue 24208: Fix tests -- don't create a tempdir in __init__. https://hg.python.org/cpython/rev/08829230079b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 16:13:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 14:13:25 +0000 Subject: [issue20014] Makes array.array constructor accepts ascii-unicode typecode In-Reply-To: <1387360195.98.0.786950742842.issue20014@psf.upfronthosting.co.za> Message-ID: <20150516141322.21172.31663@psf.io> Roundup Robot added the comment: New changeset 7d60cb6c33cf by Serhiy Storchaka in branch '2.7': Issue #20014: array.array() now accepts unicode typecodes. Based on patch by https://hg.python.org/cpython/rev/7d60cb6c33cf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 16:16:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 14:16:53 +0000 Subject: [issue24208] test_inspect leaks temporary directory In-Reply-To: <1431773458.03.0.895470927219.issue24208@psf.upfronthosting.co.za> Message-ID: <1431785813.29.0.586521474584.issue24208@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 16:17:03 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 May 2015 14:17:03 +0000 Subject: [issue24208] test_inspect leaks temporary directory In-Reply-To: <1431773458.03.0.895470927219.issue24208@psf.upfronthosting.co.za> Message-ID: <1431785823.41.0.780748192704.issue24208@psf.upfronthosting.co.za> Yury Selivanov added the comment: I think it should be fixed now. Thanks for finding this! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 16:21:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 14:21:40 +0000 Subject: [issue24210] Tests failed with -Werror Message-ID: <1431786100.36.0.3334828892.issue24210@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -Werror -m test.regrtest -u all -vv == CPython 3.5.0a4+ (default:5342fad7cd59+, May 16 2015, 15:55:16) [GCC 4.8.2] Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/home/serhiy/py/cpython/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/serhiy/py/cpython/Lib/test/regrtest.py", line 1589, in main_in_temp_cwd() File "/home/serhiy/py/cpython/Lib/test/regrtest.py", line 1564, in main_in_temp_cwd main() File "/home/serhiy/py/cpython/Lib/test/regrtest.py", line 602, in main print("== ", platform.platform(aliased=True), File "/home/serhiy/py/cpython/Lib/platform.py", line 1441, in platform distname, distversion, distid = dist('') File "/home/serhiy/py/cpython/Lib/platform.py", line 378, in dist PendingDeprecationWarning, stacklevel=2) PendingDeprecationWarning: dist() and linux_distribution() functions are deprecated in Python 3.5 and will be removed in Python 3.7 ---------- components: Tests messages: 243323 nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Tests failed with -Werror type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 16:42:19 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 16 May 2015 14:42:19 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1431787339.44.0.396201303317.issue15216@psf.upfronthosting.co.za> Nick Coghlan added the comment: Revisiting the idea Nikolaus raised last year regarding whether or not this could be done using a dedicated API in the sys module, I realised today that even if we decided to use a separate public API, *that API* would still need a defined way to modify the stream encoding and error handling in place. Since we're going to need the object level in-place modification API regardless, a separate sys module API for modifying the standard streams in particular would then introduce additional complexity without providing a proportional benefit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 16:52:02 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 16 May 2015 14:52:02 +0000 Subject: [issue24210] Tests failed with -Werror In-Reply-To: <1431786100.36.0.3334828892.issue24210@psf.upfronthosting.co.za> Message-ID: <1431787922.58.0.138571394443.issue24210@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 17:04:59 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 16 May 2015 15:04:59 +0000 Subject: [issue24210] Tests failed with -Werror In-Reply-To: <1431786100.36.0.3334828892.issue24210@psf.upfronthosting.co.za> Message-ID: <1431788699.21.0.0316436376832.issue24210@psf.upfronthosting.co.za> Berker Peksag added the comment: This is caused by issue 1322. I'll fix it. ---------- assignee: -> berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 17:17:52 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 May 2015 15:17:52 +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: <1431789472.66.0.229277841027.issue16864@psf.upfronthosting.co.za> R. David Murray added the comment: Added review comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 17:28:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 15:28:30 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1431790110.15.0.245499723134.issue22939@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 17:50:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 15:50:00 +0000 Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility In-Reply-To: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za> Message-ID: <1431791400.4.0.790365991448.issue15267@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 17:59:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 15:59:16 +0000 Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility In-Reply-To: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za> Message-ID: <20150516155913.125522.77821@psf.io> Roundup Robot added the comment: New changeset c34513c2a894 by Serhiy Storchaka in branch '2.7': Issue #15267: HTTPConnection.request() now is compatibile with old-style https://hg.python.org/cpython/rev/c34513c2a894 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 18:07:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 16:07:44 +0000 Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility In-Reply-To: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za> Message-ID: <1431792464.83.0.353325592508.issue15267@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Catching TypeError or AttributeError on len() is a hack, but it is compatible with Python 3 and older code. We could handle this in issue23740. Changing TemporaryFile would solve this issue, but only for TemporaryFile. len() raises AttributeError for other file-like classic classes. So I committed slightly modified Atsuo's patch (extended test as Victor suggested). As for converting classic classes to new-style classes, see for example issue14399. It is not so harmless, as expected, unfortunately. But perhaps it was done multiple times in bug-fix releases. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 18:11:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 16:11:09 +0000 Subject: [issue22958] Constructors of weakref mapping classes don't accept "self" and "dict" keyword arguments In-Reply-To: <1417104803.61.0.896440563309.issue22958@psf.upfronthosting.co.za> Message-ID: <1431792669.37.0.11897906402.issue22958@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Constructors of some mapping classes don't accept `self` keyword argument _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 18:11:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 16:11:32 +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: <1431792692.84.0.901234952654.issue22609@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please look at the new patch Raymond? This is the dependency for issue22958. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 18:12:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 16:12:40 +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: <1431792760.77.0.12851531843.issue19176@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 18:26:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 16:26:21 +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: <1431793581.58.0.611573563153.issue19176@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated to the tip. If Eli doesn't have objections, I'll commit it. ---------- Added file: http://bugs.python.org/file39391/doctype-remove.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 18:27:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 16:27:57 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1431793677.94.0.758392362749.issue15836@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 18:42:17 2015 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 16 May 2015 16:42:17 +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: <1431794537.9.0.109685828871.issue19176@psf.upfronthosting.co.za> Eli Bendersky added the comment: I don't know how important this is to really warrant removal. Removal means potentially breaking working code when trying to run it with Python 3.5, and my impression was that the core devs are somewhat alergic to this, at least while the transition to Python 3 is ongoing. Unless it has already been discussed (sorry if I missed it, haven't had much time for CPython recently, unfortunately), may be worth a quick check with python-dev ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 18:54:34 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 May 2015 16:54:34 +0000 Subject: [issue18330] Fix idlelib.PyShell.build_subprocess_arglist use of __import__ In-Reply-To: <1372543764.27.0.834894616208.issue18330@psf.upfronthosting.co.za> Message-ID: <1431795274.18.0.0853591662217.issue18330@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since filing this, I have decided that starting Idle directly with PyShell should be deprecated. That would affect any patch for this. In the meanwhile, there are other priorities. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 18:58:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 16:58:39 +0000 Subject: [issue23780] Surprising behaviour when passing list to os.path.join. In-Reply-To: <1427356923.25.0.682691905774.issue23780@psf.upfronthosting.co.za> Message-ID: <1431795519.11.0.190634956895.issue23780@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is extended patch, with tests. ---------- assignee: -> serhiy.storchaka stage: -> patch review versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 19:10:03 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 16 May 2015 17:10:03 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1431796203.35.0.302093255119.issue15836@psf.upfronthosting.co.za> Berker Peksag added the comment: Since the patch has been reviewed by several core developers, I think you can go ahead and commit it. I'm +0 on the 2.7 version of the patch (the isinstance(e, types.ClassType) part looks fine, but I haven't tested it). It's probably not worth to change anything on the 2.7 branch now :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 19:16:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 17:16:06 +0000 Subject: [issue23689] Memory leak in Modules/sre_lib.h In-Reply-To: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za> Message-ID: <1431796566.71.0.787162556976.issue23689@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 19:24:47 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 17:24:47 +0000 Subject: [issue24210] Tests failed with -Werror In-Reply-To: <1431786100.36.0.3334828892.issue24210@psf.upfronthosting.co.za> Message-ID: <20150516172444.39265.96605@psf.io> Roundup Robot added the comment: New changeset 6181146842ba by Berker Peksag in branch 'default': Issue #24210: Silence a PendingDeprecationWarning warning in platform.platform(). https://hg.python.org/cpython/rev/6181146842ba ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 19:25:45 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 16 May 2015 17:25:45 +0000 Subject: [issue24210] Tests failed with -Werror In-Reply-To: <1431786100.36.0.3334828892.issue24210@psf.upfronthosting.co.za> Message-ID: <1431797145.14.0.126210525403.issue24210@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks Serhiy. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 19:33:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 17:33:47 +0000 Subject: [issue24210] Tests failed with -Werror In-Reply-To: <1431786100.36.0.3334828892.issue24210@psf.upfronthosting.co.za> Message-ID: <1431797627.36.0.89383085599.issue24210@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: test_platform is failed. ====================================================================== ERROR: test_dist (test.test_platform.PlatformTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/test/test_platform.py", line 239, in test_dist res = platform.dist() File "/home/serhiy/py/cpython/Lib/platform.py", line 380, in dist PendingDeprecationWarning, stacklevel=2) PendingDeprecationWarning: dist() and linux_distribution() functions are deprecated in Python 3.5 and will be removed in Python 3.7 ====================================================================== ERROR: test_linux_distribution_encoding (test.test_platform.PlatformTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/test/test_platform.py", line 308, in test_linux_distribution_encoding distname, version, distid = platform.linux_distribution() File "/home/serhiy/py/cpython/Lib/platform.py", line 305, in linux_distribution PendingDeprecationWarning, stacklevel=2) PendingDeprecationWarning: dist() and linux_distribution() functions are deprecated in Python 3.5 and will be removed in Python 3.7 ---------------------------------------------------------------------- ---------- resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 19:36:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 17:36:28 +0000 Subject: [issue24210] Tests failed with -Werror In-Reply-To: <1431786100.36.0.3334828892.issue24210@psf.upfronthosting.co.za> Message-ID: <1431797788.16.0.588882609442.issue24210@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And test_ssl. $ ./python -Werror -m test.regrtest -vv test_ssl == CPython 3.5.0a4+ (default:08829230079b+, May 16 2015, 19:19:38) [GCC 4.8.2] == Linux-3.13.0-53-generic-i686-athlon-with-debian-jessie-sid little-endian == hash algorithm: siphash24 32bit == /home/serhiy/py/cpython/build/test_python_9027 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_ssl test test_ssl crashed -- Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/test/regrtest.py", line 1280, in runtest_inner test_runner() File "/home/serhiy/py/cpython/Lib/test/test_ssl.py", line 3303, in test_main plat = func() File "/home/serhiy/py/cpython/Lib/platform.py", line 305, in linux_distribution PendingDeprecationWarning, stacklevel=2) PendingDeprecationWarning: dist() and linux_distribution() functions are deprecated in Python 3.5 and will be removed in Python 3.7 1 test failed: test_ssl ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 19:38:43 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 16 May 2015 17:38:43 +0000 Subject: [issue24192] unexpected system error with pep420 style namespace packages In-Reply-To: <1431604720.34.0.497693265378.issue24192@psf.upfronthosting.co.za> Message-ID: <1431797923.46.0.107092418632.issue24192@psf.upfronthosting.co.za> Eric Snow added the comment: Great! The buildbots are happy too. :) ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 19:45:27 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 17:45:27 +0000 Subject: [issue24190] BoundArguments facility to inject defaults In-Reply-To: <1431598800.08.0.914868739501.issue24190@psf.upfronthosting.co.za> Message-ID: <20150516174524.16318.47730@psf.io> Roundup Robot added the comment: New changeset ea61d8eb8a28 by Yury Selivanov in branch 'default': Issue 24190: Add inspect.BoundArguments.apply_defaults() method. https://hg.python.org/cpython/rev/ea61d8eb8a28 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 19:45:53 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 May 2015 17:45:53 +0000 Subject: [issue24190] BoundArguments facility to inject defaults In-Reply-To: <1431598800.08.0.914868739501.issue24190@psf.upfronthosting.co.za> Message-ID: <1431798353.14.0.0684834661176.issue24190@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks for the suggestion, Antoine! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 19:49:22 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 May 2015 17:49:22 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1431798562.88.0.464138542385.issue16991@psf.upfronthosting.co.za> Yury Selivanov added the comment: Raymond, is there any chance you can review the patch before beta1? Sorry, for bugging you with this, I just really hope we can have fast OrderedDict in 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 19:58:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 17:58:31 +0000 Subject: [issue22027] RFC 6531 (SMTPUTF8) support in smtplib In-Reply-To: <1405978140.81.0.388141454985.issue22027@psf.upfronthosting.co.za> Message-ID: <20150516175828.4239.21714@psf.io> Roundup Robot added the comment: New changeset 6b0e4c87bf9e by R David Murray in branch 'default': #22027: Add RFC6531 support to smtplib. https://hg.python.org/cpython/rev/6b0e4c87bf9e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 19:58:37 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 16 May 2015 17:58:37 +0000 Subject: [issue24210] Tests failed with -Werror In-Reply-To: <1431786100.36.0.3334828892.issue24210@psf.upfronthosting.co.za> Message-ID: <1431799117.39.0.782630740716.issue24210@psf.upfronthosting.co.za> Berker Peksag added the comment: Interesting, I ran the test suite twice before commit the patch. I will take a look, thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 20:05:28 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 May 2015 18:05:28 +0000 Subject: [issue22027] RFC 6531 (SMTPUTF8) support in smtplib In-Reply-To: <1405978140.81.0.388141454985.issue22027@psf.upfronthosting.co.za> Message-ID: <1431799528.43.0.712424312094.issue22027@psf.upfronthosting.co.za> R. David Murray added the comment: Rewrote the tests to keep all the existing tests working against an unmodified SimSMTPServer, so that we know backward compatibility is maintained. And as I said, I changed the tests to reflect that a non-ascii body must be provided as binary data, which means I deleted two tests. (Note: in thinking about this, I vaguely remember some conversations where we thought it might make sense that if someone provided a message string that when encoded to utf-8 then conforms to the RFC, it would be OK to auto-encode it as utf-8, but I'm just not comfortable with that idea. It provides insufficient value compared to the danger of blindly encoding something that is not RFC conformant...if someone does build a such a unicode message, they should have to convert it themselves before passing it to smtplib, as a sign they know what they are doing :) Thanks for your work Milan. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 20:06:45 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 May 2015 18:06:45 +0000 Subject: [issue21800] Implement RFC 6855 (IMAP Support for UTF-8) in imaplib. In-Reply-To: <1404175815.98.0.684783714649.issue21800@psf.upfronthosting.co.za> Message-ID: <1431799605.86.0.902008520166.issue21800@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 20:16:50 2015 From: report at bugs.python.org (Carol Willing) Date: Sat, 16 May 2015 18:16:50 +0000 Subject: [issue24204] string.strip() documentation is misleading In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za> Message-ID: <1431800210.75.0.718768391084.issue24204@psf.upfronthosting.co.za> Carol Willing added the comment: Additional text added about stripping characters from the leading end and trailing end of the string. An additional example that illustrates the outer characters being stripped while the inner string characters, even though matching the chars set of characters, remain. ---------- keywords: +patch nosy: +willingc stage: -> patch review Added file: http://bugs.python.org/file39392/iss24204.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 20:18:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 18:18:25 +0000 Subject: [issue19662] smtpd.py should not decode utf-8 In-Reply-To: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za> Message-ID: <20150516181821.32309.76179@psf.io> Roundup Robot added the comment: New changeset a7d3074fa888 by R David Murray in branch 'default': #19662: Make requirement to support arbitrary keywords explicit. https://hg.python.org/cpython/rev/a7d3074fa888 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 20:19:14 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 May 2015 18:19:14 +0000 Subject: [issue21804] Implement thr UTF8 command (RFC 6856) in poplib. In-Reply-To: <1403133284.52.0.0735782261823.issue21804@psf.upfronthosting.co.za> Message-ID: <1431800354.75.0.705073199729.issue21804@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> commit review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 20:24:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 18:24:33 +0000 Subject: [issue23964] Update README documentation for IDLE tests. In-Reply-To: <1429104753.6.0.763987492268.issue23964@psf.upfronthosting.co.za> Message-ID: <20150516182430.26836.3973@psf.io> Roundup Robot added the comment: New changeset 19e111891e39 by Terry Jan Reedy in branch '2.7': Issue #23964: Update idlelib/idle_test/README.txt. first patch by Al Sweigart. https://hg.python.org/cpython/rev/19e111891e39 New changeset 35b84ba2f8b1 by Terry Jan Reedy in branch '3.4': Issue #23964: Update idlelib/idle_test/README.txt. first patch by Al Sweigart. https://hg.python.org/cpython/rev/35b84ba2f8b1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 20:26:24 2015 From: report at bugs.python.org (Florian Bruhin) Date: Sat, 16 May 2015 18:26:24 +0000 Subject: [issue23780] Surprising behaviour when passing list to os.path.join. In-Reply-To: <1427356923.25.0.682691905774.issue23780@psf.upfronthosting.co.za> Message-ID: <1431800784.76.0.839098381864.issue23780@psf.upfronthosting.co.za> Florian Bruhin added the comment: Serhiy, I don't see a new patch added - did you forget to attach it or am I missing something? :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 20:28:24 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 May 2015 18:28:24 +0000 Subject: [issue23964] Update README documentation for IDLE tests. In-Reply-To: <1429104753.6.0.763987492268.issue23964@psf.upfronthosting.co.za> Message-ID: <1431800904.59.0.993526732727.issue23964@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks for the push. I incorporated most of your suggestions and added more changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 20:28:54 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 May 2015 18:28:54 +0000 Subject: [issue23964] Update README documentation for IDLE tests. In-Reply-To: <1429104753.6.0.763987492268.issue23964@psf.upfronthosting.co.za> Message-ID: <1431800934.64.0.0883855069347.issue23964@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 20:39:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 18:39:42 +0000 Subject: [issue18682] [PATCH] remove bogus codepath from pprint._safe_repr In-Reply-To: <1375950566.41.0.226660086473.issue18682@psf.upfronthosting.co.za> Message-ID: <20150516183939.10802.98617@psf.io> Roundup Robot added the comment: New changeset c77a42c234d6 by Serhiy Storchaka in branch 'default': Issue #18682: Optimized pprint functions for builtin scalar types. https://hg.python.org/cpython/rev/c77a42c234d6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 20:41:43 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 16 May 2015 18:41:43 +0000 Subject: [issue24210] Tests failed with -Werror In-Reply-To: <1431786100.36.0.3334828892.issue24210@psf.upfronthosting.co.za> Message-ID: <1431801703.15.0.635522895571.issue24210@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a patch. An unrelated failure: $ ./python -Werror -m test test_slice [1/1] test_slice test test_slice failed -- Traceback (most recent call last): File "/home/berker/projects/cpython/default/Lib/test/test_slice.py", line 82, in test_hash self.assertRaises(TypeError, slice(5).__hash__) File "/home/berker/projects/cpython/default/Lib/unittest/case.py", line 711, in assertRaises return context.handle('assertRaises', args, kwargs) File "/home/berker/projects/cpython/default/Lib/unittest/case.py", line 153, in handle DeprecationWarning, 3) DeprecationWarning: callable is None ---------- keywords: +patch Added file: http://bugs.python.org/file39393/issue24210.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 20:42:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 18:42:02 +0000 Subject: [issue18682] [PATCH] remove bogus codepath from pprint._safe_repr In-Reply-To: <1375950566.41.0.226660086473.issue18682@psf.upfronthosting.co.za> Message-ID: <1431801722.1.0.873895356124.issue18682@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Are there tests for all the "builtin scalars"? Yes, now there are. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 20:43:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 18:43:07 +0000 Subject: [issue23780] Surprising behaviour when passing list to os.path.join. In-Reply-To: <1427356923.25.0.682691905774.issue23780@psf.upfronthosting.co.za> Message-ID: <1431801787.92.0.0757103430842.issue23780@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, sorry, I forget to attach it. ---------- Added file: http://bugs.python.org/file39394/join_datatype_check_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 20:56:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 18:56:58 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1431802618.67.0.767363777549.issue24134@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Interesting, the last patch exposed a flaw in test_slice. def test_hash(self): # Verify clearing of SF bug #800796 self.assertRaises(TypeError, hash, slice(5)) self.assertRaises(TypeError, slice(5).__hash__) But the second self.assertRaises() doesn't call __hash__. It is successful by accident, because slice(5).__hash__ is None. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 21:02:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 19:02:26 +0000 Subject: [issue24210] Tests failed with -Werror In-Reply-To: <1431786100.36.0.3334828892.issue24210@psf.upfronthosting.co.za> Message-ID: <1431802946.07.0.157496668878.issue24210@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch LGTM. But what to do with this code after 3.7? And why not to do this right now? > An unrelated failure: Ah, this is issue24134. Thank you for reporting this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 21:06:28 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 May 2015 19:06:28 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1431803188.48.0.729469623119.issue16991@psf.upfronthosting.co.za> Yury Selivanov added the comment: As for refleak -- I looked at it briefly: simple "a = OrderedDict(); a = None" code leaks, so it must be somewhere in tp_new/tp_dealloc. And I know what object is leaking - it's None. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 21:06:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 19:06:39 +0000 Subject: [issue21804] Implement thr UTF8 command (RFC 6856) in poplib. In-Reply-To: <1403133284.52.0.0735782261823.issue21804@psf.upfronthosting.co.za> Message-ID: <20150516190636.39257.62780@psf.io> Roundup Robot added the comment: New changeset 6ea762200e27 by R David Murray in branch 'default': #21804: Add RFC 6856 (UTF8) support to poplib. https://hg.python.org/cpython/rev/6ea762200e27 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 21:07:32 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 May 2015 19:07:32 +0000 Subject: [issue21804] Implement thr UTF8 command (RFC 6856) in poplib. In-Reply-To: <1403133284.52.0.0735782261823.issue21804@psf.upfronthosting.co.za> Message-ID: <1431803252.98.0.280641331248.issue21804@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Milan. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 21:13:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 19:13:50 +0000 Subject: [issue16314] Support xz compression in distutils In-Reply-To: <1351114378.64.0.718374634123.issue16314@psf.upfronthosting.co.za> Message-ID: <20150516191347.26842.46704@psf.io> Roundup Robot added the comment: New changeset 09bd552999bf by Serhiy Storchaka in branch 'default': Issue #16314: Added support for the LZMA compression in distutils. https://hg.python.org/cpython/rev/09bd552999bf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 21:18:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 19:18:57 +0000 Subject: [issue18986] Add a case-insensitive case-preserving dict In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za> Message-ID: <1431803937.73.0.406457469382.issue18986@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 21:41:21 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 19:41:21 +0000 Subject: [issue21083] Add get_content_disposition() to email.message.Message In-Reply-To: <1396005202.84.0.754707033491.issue21083@psf.upfronthosting.co.za> Message-ID: <20150516194118.26838.1251@psf.io> Roundup Robot added the comment: New changeset 29ba76f5c3dc by R David Murray in branch 'default': #21083: add get_content_disposition method to email.message. https://hg.python.org/cpython/rev/29ba76f5c3dc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 21:42:03 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 May 2015 19:42:03 +0000 Subject: [issue21083] Add get_content_disposition() to email.message.Message In-Reply-To: <1396005202.84.0.754707033491.issue21083@psf.upfronthosting.co.za> Message-ID: <1431805323.64.0.978697298788.issue21083@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Abhilash. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 21:51:23 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 May 2015 19:51:23 +0000 Subject: [issue8489] Support RFC 6531 in smptlib In-Reply-To: <1271877469.99.0.897777864709.issue8489@psf.upfronthosting.co.za> Message-ID: <1431805883.61.0.715909115443.issue8489@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> RFC 6531 (SMTPUTF8) support in smtplib versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 22:12:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 May 2015 20:12:07 +0000 Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za> Message-ID: <1431807127.72.0.0270415291259.issue22955@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: methodcaller with keyword arguments pickled with pickle_getter_and_caller3.patch needs Python 3.5 to unpickle. Following patch pickles it in backward compatible way. ---------- Added file: http://bugs.python.org/file39395/pickle_getter_and_caller4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 22:21:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 20:21:33 +0000 Subject: [issue24210] Tests failed with -Werror In-Reply-To: <1431786100.36.0.3334828892.issue24210@psf.upfronthosting.co.za> Message-ID: <20150516202130.21146.25743@psf.io> Roundup Robot added the comment: New changeset e73182301a61 by Berker Peksag in branch 'default': Issue #24210: Silence more PendingDeprecationWarning warnings in tests. https://hg.python.org/cpython/rev/e73182301a61 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 22:24:05 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 16 May 2015 20:24:05 +0000 Subject: [issue24210] Tests failed with -Werror In-Reply-To: <1431786100.36.0.3334828892.issue24210@psf.upfronthosting.co.za> Message-ID: <1431807845.35.0.815264526238.issue24210@psf.upfronthosting.co.za> Berker Peksag added the comment: > But what to do with this code after 3.7? And why not to do this right now? It's on my TODO list, but I'll probably won't have time to work on in it before beta 1. Thanks for the review! ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 22:25:53 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 16 May 2015 20:25:53 +0000 Subject: [issue11477] Incorrect operand precedence when implementing sequences in C In-Reply-To: <1299965091.63.0.267715976543.issue11477@psf.upfronthosting.co.za> Message-ID: <1431807953.76.0.146477319405.issue11477@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 23:13:37 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 May 2015 21:13:37 +0000 Subject: [issue22804] Can't run Idle in Windows 8 or windows 64 In-Reply-To: <1415268649.04.0.373697042917.issue22804@psf.upfronthosting.co.za> Message-ID: <1431810817.73.0.327128340261.issue22804@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Closing because this report contains insufficient information to act on. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 23:19:10 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 May 2015 21:19:10 +0000 Subject: [issue24211] Add RFC 6532 support to the email library Message-ID: <1431811149.98.0.538401086698.issue24211@psf.upfronthosting.co.za> New submission from R. David Murray: I could have sworn there was an issue for this already, but I couldn't find it. Attached patch adds a utf8 policy knob and an SMTPUTF8 policy instance, and modifies BytesGenerator and the _header_value_parser to use that policy setting to generate utf8 headers instead of encoding non-ascii using encoded words. (I designed the new code to make it easy to support this RFC, but even I had no idea the patch would be so small. I hope I didn't miss anything.) I will probably commit this tomorrow, since the deadline is looming. ---------- components: email files: email_smtputf8.patch keywords: patch messages: 243368 nosy: barry, r.david.murray priority: normal severity: normal stage: patch review status: open title: Add RFC 6532 support to the email library type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39396/email_smtputf8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 23:34:50 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 May 2015 21:34:50 +0000 Subject: [issue24211] Add RFC 6532 support to the email library In-Reply-To: <1431811149.98.0.538401086698.issue24211@psf.upfronthosting.co.za> Message-ID: <1431812090.26.0.253562311038.issue24211@psf.upfronthosting.co.za> Changes by R. David Murray : Added file: http://bugs.python.org/file39397/email_smtputf8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 23:35:10 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 16 May 2015 21:35:10 +0000 Subject: [issue24211] Add RFC 6532 support to the email library In-Reply-To: <1431811149.98.0.538401086698.issue24211@psf.upfronthosting.co.za> Message-ID: <1431812110.78.0.286861898627.issue24211@psf.upfronthosting.co.za> Changes by R. David Murray : Removed file: http://bugs.python.org/file39396/email_smtputf8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 16 23:46:53 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 May 2015 21:46:53 +0000 Subject: [issue24212] Idle, 2.7, backport idlelib.__main__, enable py -m idlelib Message-ID: <1431812813.24.0.960232018759.issue24212@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Discussion on another issue suggested that 3.x idlelib.__main__ be backported to 2.7 so 'python -m idlelib would work with 2.7 as with 3.x. The current file: """ IDLE main entry point Run IDLE as python -m idlelib """ import idlelib.PyShell idlelib.PyShell.main() When I tried this, it failed two ways. 1. The AutoComplete and CallTips extensions did not import properly. The error messages are printed from the except clause in EditorWindow.load_standard_extensions. I presume this call results from "import EditorWindow" in PyShell. Failed to load extension 'AutoComplete' Traceback (most recent call last): File "C:\Programs\Python27\lib\idlelib\EditorWindow.py", line 1068, in load_standard_extensions self.load_extension(name) File "C:\Programs\Python27\lib\idlelib\EditorWindow.py", line 1083, in load_extension cls = getattr(mod, name) AttributeError: 'module' object has no attribute 'AutoComplete' Somehow AutoComplete was imported without an ImportError even though the class AutoComplete statement did not create the class asstribute. AutoComplete and CallTips are the two extensions containing "import __main__". Adding idlelib.__main__ somehow causes weird behavior in 2.7, though not in 3.x. Commenting out these imports removes the import problem. 2. Even with 1 temporarily fixed with '#', an unsaved file 'named' C:\users\terry\NNNNN.py is open in an editor window. ("Unsaved' and'named' areusually mutually exclusive.) Two shell windows, instead of one, are opened. One fails to connect to a subprocess. Clicking away the message box raises SystemExit. Changing __main__.py to ... from idlelib.PyShell import * main() had no effect. I will add a reference to this issue in the file. (If should be removed if this issue is fixed.) ---------- messages: 243369 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle, 2.7, backport idlelib.__main__, enable py -m idlelib type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 00:07:19 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 16 May 2015 22:07:19 +0000 Subject: [issue18986] Add a case-insensitive case-preserving dict In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za> Message-ID: <1431814039.87.0.284801590199.issue18986@psf.upfronthosting.co.za> Ethan Furman added the comment: >From https://mail.python.org/pipermail/python-dev/2015-May/140003.html ====================================================================== Before the Python 3.5 feature freeze, I should step-up and formally reject PEP 455 for "Adding a key-transforming dictionary to collections". I had completed an involved review effort a long time ago and I apologize for the delay in making the pronouncement. What made it a interesting choice from the outset is that the idea of a "transformation" is an enticing concept that seems full of possibility. I spent a good deal of time exploring what could be done with it but found that it mostly fell short of its promise. There were many issues. Here are some that were at the top: * Most use cases don't need or want the reverse lookup feature (what is wanted is a set of one-way canonicalization functions). Those that do would want to have a choice of what is saved (first stored, last stored, n most recent, a set of all inputs, a list of all inputs, nothing, etc). In database terms, it models a many-to-one table (the canonicalization or transformation function) with the one being a primary key into another possibly surjective table of two columns (the key/value store). A surjection into another surjection isn't inherently reversible in a useful way, nor does it seem to be a common way to model data. * People are creative at coming up with using cases for the TD but then find that the resulting code is less clear, slower, less intuitive, more memory intensive, and harder to debug than just using a plain dict with a function call before the lookup: d[func(key)]. It was challenging to find any existing code that would be made better by the availability of the TD. * The TD seems to be all about combining data scrubbing (case-folding, unicode canonicalization, type-folding, object identity, unit-conversion, or finding a canonical member of an equivalence class) with a mapping (looking-up a value for a given key). Those two operations are conceptually orthogonal. The former doesn't get easier when hidden behind a mapping API and the latter loses the flexibility of choosing your preferred mapping (an ordereddict, a persistentdict, a chainmap, etc) and the flexibility of establishing your own rules for whether and how to do a reverse lookup. Raymond Hettinger P.S. Besides the core conceptual issues listed above, there are a number of smaller issues with the TD that surfaced during design review sessions. In no particular order, here are a few of the observations: * It seems to require above average skill to figure-out what can be used as a transform function. It is more expert-friendly than beginner friendly. It takes a little while to get used to it. It wasn't self-evident that transformations happen both when a key is stored and again when it is looked-up (contrast this with key-functions for sorting which are called at most once per key). * The name, TransformDict, suggests that it might transform the value instead of the key or that it might transform the dictionary into something else. The name TransformDict is so general that it would be hard to discover when faced with a specific problem. The name also limits perception of what could be done with it (i.e. a function that logs accesses but doesn't actually change the key). * The tool doesn't self describe itself well. Looking at the help(), or the __repr__(), or the tooltips did not provide much insight or clarity. The dir() shows many of the _abc implementation details rather than the API itself. * The original key is stored and if you change it, the change isn't stored. The _original dict is private (perhaps to reduce the risk of putting the TD in an inconsistent state) but this limits access to the stored data. * The TD is unsuitable for bijections because the API is inherently biased with a rich group of operators and methods for forward lookup but has only one method for reverse lookup. * The reverse feature is hard to find (getitem vs __getitem__) and its output pair is surprising and a bit awkward to use. It provides only one accessor method rather that the full dict API that would be given by a second dictionary. The API hides the fact that there are two underlying dictionaries. * It was surprising that when d[k] failed, it failed with transformation exception rather than a KeyError, violating the expectations of the calling code (for example, if the transformation function is int(), the call d["12"] transforms to d[12] and either succeeds in returning a value or in raising a KeyError, but the call d["12.0"] fails with a TypeError). The latter issue limits its substitutability into existing code that expects real mappings and for exposing to end-users as if it were a normal dictionary. * There were other issues with dict invariants as well and these affected substitutability in a sometimes subtle way. For example, the TD does not work with __missing__(). Also, "k in td" does not imply that "k in list(td.keys())". * The API is at odds with wanting to access the transformations. You pay a transformation cost both when storing and when looking up, but you can't access the transformed value itself. For example, if the transformation is a function that scrubs hand entered mailing addresses and puts them into a standard format with standard abbreviations, you have no way of getting back to the cleaned-up address. * One design reviewer summarized her thoughts like this: "There is a learning curve to be climbed to figure out what it does, how to use it, and what the applications [are]. But, the [working out the same] examplea with plain dicts requires only basic knowledge." -- Patricia ---------- resolution: -> rejected stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 00:16:30 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 May 2015 22:16:30 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1431814590.61.0.837782071239.issue16991@psf.upfronthosting.co.za> Yury Selivanov added the comment: I must have used a better example :) >>> import sys; from collections import OrderedDict as OD >>> sys.getrefcount(None) 2053 >>> OD();OD();OD();OD(); OrderedDict() OrderedDict() OrderedDict() OrderedDict() >>> sys.getrefcount(None) 2057 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 00:22:28 2015 From: report at bugs.python.org (JohnLeitch) Date: Sat, 16 May 2015 22:22:28 +0000 Subject: [issue24201] _winreg PyHKEY Type Confusion In-Reply-To: <1431679011.32.0.0649667606823.issue24201@psf.upfronthosting.co.za> Message-ID: <1431814948.35.0.48183822332.issue24201@psf.upfronthosting.co.za> JohnLeitch added the comment: Thank you again for the explanation of the internals at play here. Armed with the knowledge you provided, I conducted further experimentation, and I believe I can now demonstrate how EIP control is possible with this bug. Note that RPC initialization is not necessary, thus lowering the barrier to entry. First, it is possible to satisfy both magic number checks using a single buffer, and the predicted address of said buffer. This can be simulated with the following script: import _winreg test = "AAAA\x98\xba\xdc\xfeCCCC\xEF\xCD\xAB\x89EEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPPPPQQQQAAAA" _winreg.QueryValueEx(0x41414141, 'test') A breakpoint is set at the first magic number check to give us an opportunity to patch up our buffer with the "predicted" addresses. Breakpoint 0 hit eax=41414140 ebx=0027fc2c ecx=00000000 edx=00000000 esi=753a3584 edi=00000000 eip=75469af3 esp=0027f79c ebp=0027f7c8 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 RPCRT4!NDRCContextBinding+0x13: 75469af3 81780498badcfe cmp dword ptr [eax+4],0FEDCBA98h ds:002b:41414144=? ??????? 0:000> s -b 0x0 L?0x7fffffff 41 41 41 41 98 ba dc fe 01ccc37c 41 41 41 41 98 ba dc fe-43 43 43 43 ef cd ab 89 AAAA....CCCC.... 0:000> r @eax=0x01ccc37c 0:000> ed eax eax+0x8 0:000> ed eax+0x8 eax+0xc 0:000> dc eax 01ccc37c 01ccc384 fedcba98 01ccc388 89abcdef ................ 01ccc38c 45454545 46464646 47474747 48484848 EEEEFFFFGGGGHHHH 01ccc39c 49494949 4a4a4a4a 4b4b4b4b 4c4c4c4c IIIIJJJJKKKKLLLL 01ccc3ac 4d4d4d4d 4e4e4e4e 4f4f4f4f 50505050 MMMMNNNNOOOOPPPP 01ccc3bc 51515151 41414141 01ccab00 01cbe048 QQQQAAAA....H... 01ccc3cc 01cbe070 01ccabe0 01cbe098 01cbe0c0 p............... 01ccc3dc baadf000 01ccc548 1e228bf8 00000062 ....H.....".b... 01ccc3ec ffffffff 00000000 72747320 6c6c6f63 ........ strcoll 0:000> r eax=01ccc37c ebx=0027fc2c ecx=00000000 edx=00000000 esi=753a3584 edi=00000000 eip=75469af3 esp=0027f79c ebp=0027f7c8 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 RPCRT4!NDRCContextBinding+0x13: 75469af3 81780498badcfe cmp dword ptr [eax+4],0FEDCBA98h ds:002b:01ccc380=f edcba98 While we patched up the buffer with two addresses, this is still viable through heap spraying because the second address is relative to the first. Continuing execution, we hit our second magic number check: 0:000> g Breakpoint 2 hit eax=e7fafcfb ebx=0027f7f8 ecx=0000009c edx=00000001 esi=01ccc384 edi=01ccc384 eip=75472451 esp=0027f7ac ebp=0027f7c0 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206 RPCRT4!I_RpcGetBufferWithObject+0x21: 75472451 817e04efcdab89 cmp dword ptr [esi+4],89ABCDEFh ds:002b:01ccc388=89 abcdef 0:000> dc esi+4 01ccc388 89abcdef 45454545 46464646 47474747 ....EEEEFFFFGGGG 01ccc398 48484848 49494949 4a4a4a4a 4b4b4b4b HHHHIIIIJJJJKKKK 01ccc3a8 4c4c4c4c 4d4d4d4d 4e4e4e4e 4f4f4f4f LLLLMMMMNNNNOOOO 01ccc3b8 50505050 51515151 41414141 01ccab00 PPPPQQQQAAAA.... 01ccc3c8 01cbe048 01cbe070 01ccabe0 01cbe098 H...p........... 01ccc3d8 01cbe0c0 baadf000 01ccc548 1e228bf8 ........H.....". 01ccc3e8 00000062 ffffffff 00000000 72747320 b........... str 01ccc3f8 6c6c6f63 72747328 2c676e69 69727473 coll(string,stri All is well. When execution is continued, we achieve EIP control: 0:000> g (10d8.15a8): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=41414141 ebx=0027f7f8 ecx=01ccc384 edx=00000001 esi=01ccc384 edi=00000040 eip=41414141 esp=0027f79c ebp=0027f7c0 iopl=0 nv up ei ng nz na pe cy cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010287 41414141 ?? ??? Apologies for the messy memory editing; there's probably a more Pythonic way of patching the buffer. And, of course, I believe it to be possible to achieve this via heap spraying, without any patching at all. Given this, I think exploitation in the real world is possible with two primitives: heap spraying and hkey value control. A web application, for example, might offer an attacker both of these primitives, while at the same time reasonably expecting arbitrary code execution to be prohibited. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 00:31:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 22:31:57 +0000 Subject: [issue24212] Idle, 2.7, backport idlelib.__main__, enable py -m idlelib In-Reply-To: <1431812813.24.0.960232018759.issue24212@psf.upfronthosting.co.za> Message-ID: <20150516223154.26854.96271@psf.io> Roundup Robot added the comment: New changeset 44fc6db34b69 by Terry Jan Reedy in branch '3.4': Issue #24212: Put reference in idle.__main__ to issue with explanation. https://hg.python.org/cpython/rev/44fc6db34b69 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 00:38:14 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 16 May 2015 22:38:14 +0000 Subject: [issue23572] functools.singledispatch fails when "not BaseClass" is True In-Reply-To: <1425385029.2.0.304023107943.issue23572@psf.upfronthosting.co.za> Message-ID: <1431815894.52.0.772288147431.issue23572@psf.upfronthosting.co.za> Ethan Furman added the comment: Attached is patch and test case. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file39398/issue23572.stoneleaf.01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 00:51:58 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 May 2015 22:51:58 +0000 Subject: [issue24209] Allow IPv6 bind in http.server In-Reply-To: <1431784485.93.0.0140060801451.issue24209@psf.upfronthosting.co.za> Message-ID: <1431816718.01.0.125778016194.issue24209@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 00:53:14 2015 From: report at bugs.python.org (OceanEngineer) Date: Sat, 16 May 2015 22:53:14 +0000 Subject: [issue24213] ProcessPoolExecutor().map() fails following an identical map() Message-ID: <1431816794.05.0.753595541802.issue24213@psf.upfronthosting.co.za> New submission from OceanEngineer: Attached file runs fine. Uncommenting line 19 makes python crash. Also, no crash happens if order of execution of map() and executor.map() is switched. This problem seems to be related to numpy in some way, the code does not crash if the commented return of function user_square is substituted for numpy functions. Using a mac with Yosemite 10.10.3. When program crashed I get window that says: " Python quit unexpectedly. Click Reopen to open the application again. Click Report to see more detailed information and send a report to Apple. " This is the traceback: Traceback (most recent call last): File "processExample.py", line 27, in main() File "processExample.py", line 22, in main result3 = list(executor.map(user_square, nums)) File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/concurrent/futures/_base.py", line 549, in result_iterator yield future.result() File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/concurrent/futures/_base.py", line 402, in result return self.__get_result() File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/concurrent/futures/_base.py", line 354, in __get_result raise self._exception concurrent.futures.process.BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending. ---------- components: Library (Lib) files: processExample.py messages: 243375 nosy: OceanEngineer priority: normal severity: normal status: open title: ProcessPoolExecutor().map() fails following an identical map() type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39399/processExample.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 00:56:34 2015 From: report at bugs.python.org (RalfM) Date: Sat, 16 May 2015 22:56:34 +0000 Subject: [issue24214] Exception with utf-8, surrogatepass and incremental decoding Message-ID: <1431816994.33.0.797161516902.issue24214@psf.upfronthosting.co.za> New submission from RalfM: I have an utf-8 encoded file containing single surrogates. Reading this file, specifying surrgatepass, works fine when I read the whole file with .read(), but raises an UnicodeDecodeError when I read the file line by line: ----- start of demo ----- Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AM D64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> with open("Demo.txt", encoding="utf-8", errors="surrogatepass") as f: ... s = f.read() ... >>> "\ud900" in s True >>> with open("Demo.txt", encoding="utf-8", errors="surrogatepass") as f: ... for line in f: ... pass ... Traceback (most recent call last): File "", line 2, in File "C:\Python\34x64\lib\codecs.py", line 319, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position 8190: inval id continuation byte >>> ----- end of demo ----- I attached the file used for the demo such that you can reproduce the problem. If I change all 0xED bytes in the file to 0xEC (i.e. effectively change all surrogates to non-surrogates), the problem disappears. The original file I noticed the problem with was 73 MB. The demo file was derived from the original by removing data around the critical section, keeping the alignment to 16-k-blocks, and then replacing all printable ASCII characters by x. If I change the file length by adding or removing 16 bytes to / from the beginning of the demo file, the problem disappears, so alignment seems to be an issue. All this seems to indicate that the utf-8 decoder has problems when used for incremental decoding and a single surrogate appears around the block boundary. ---------- components: Unicode files: Demo.txt messages: 243376 nosy: RalfM, ezio.melotti, haypo priority: normal severity: normal status: open title: Exception with utf-8, surrogatepass and incremental decoding type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file39400/Demo.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 01:03:08 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 16 May 2015 23:03:08 +0000 Subject: [issue16314] Support xz compression in distutils In-Reply-To: <1351114378.64.0.718374634123.issue16314@psf.upfronthosting.co.za> Message-ID: <1431817388.87.0.543959347274.issue16314@psf.upfronthosting.co.za> Ned Deily added the comment: The test for lzma being importable is not sufficient. ====================================================================== ERROR: test_make_archive_xztar (distutils.tests.test_archive_util.ArchiveUtilTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/tarfile.py", line 389, in __init__ import lzma File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/lzma.py", line 26, in from _lzma import * ImportError: No module named '_lzma' http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/3171/steps/test/logs/stdio ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 01:11:41 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 16 May 2015 23:11:41 +0000 Subject: [issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za> Message-ID: <1431817901.98.0.232661721777.issue9377@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 01:23:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 23:23:48 +0000 Subject: [issue16314] Support xz compression in distutils In-Reply-To: <1351114378.64.0.718374634123.issue16314@psf.upfronthosting.co.za> Message-ID: <20150516232345.10802.64497@psf.io> Roundup Robot added the comment: New changeset 25cb42a4bce9 by Serhiy Storchaka in branch 'default': Fixed issue #16314 test for the case when lzma is not available. https://hg.python.org/cpython/rev/25cb42a4bce9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 01:32:52 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 May 2015 23:32:52 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1431819172.28.0.761026311574.issue16991@psf.upfronthosting.co.za> Yury Selivanov added the comment: Started to look at the patch in more detail. Found one leak. There are more. Eric, maybe you can hunt them? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 01:34:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 May 2015 23:34:12 +0000 Subject: [issue24199] Idle: remove idlelib.idlever.py and its use in About dialog In-Reply-To: <1431650285.59.0.600694723613.issue24199@psf.upfronthosting.co.za> Message-ID: <20150516233409.32289.61999@psf.io> Roundup Robot added the comment: New changeset c473ac171041 by Terry Jan Reedy in branch '2.7': Issue #24199: Stop using idelver in aboutdialog. https://hg.python.org/cpython/rev/c473ac171041 New changeset c862166060ed by Terry Jan Reedy in branch '3.4': Issue #24199: Make idlever module self updating. Syop using it in aboutDialog. https://hg.python.org/cpython/rev/c862166060ed ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 01:39:24 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 May 2015 23:39:24 +0000 Subject: [issue24199] Idle: remove idlelib.idlever.py and its use in About dialog In-Reply-To: <1431650285.59.0.600694723613.issue24199@psf.upfronthosting.co.za> Message-ID: <1431819564.74.0.298901832108.issue24199@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Benjamim, I made idlever update from sys.version until removed, so remove it from release process. Serhiy, yes there are extensions which might possibly use this private api, even if they really should not. I want to bring Nick (PEP 434 approver) into the discussion of the timing of removal. Is there any problem with respect to buildbots of raising a DeprecationWarning when a module is imported? Is so, can a module be excluded from the import all test? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 06:03:45 2015 From: report at bugs.python.org (Zachary Ware) Date: Sun, 17 May 2015 04:03:45 +0000 Subject: [issue20035] Clean up Tcl library discovery in Tkinter on Windows In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za> Message-ID: <1431835425.65.0.125497161282.issue20035@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's a new patch that actually applies, and has a couple of improvements. I'd greatly appreciate some review on this; I'm planning on committing before beta1 anyway. ---------- nosy: +paul.moore, steve.dower, tim.golden priority: normal -> high Added file: http://bugs.python.org/file39401/issue20035.v6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 06:37:18 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 17 May 2015 04:37:18 +0000 Subject: [issue24213] ProcessPoolExecutor().map() fails following an identical map() In-Reply-To: <1431816794.05.0.753595541802.issue24213@psf.upfronthosting.co.za> Message-ID: <1431837438.18.0.401570849908.issue24213@psf.upfronthosting.co.za> Ned Deily added the comment: I can reproduce a crash with your sample program using the current numpy wheel (1.9.2) and the python.org 3.4.3. The significant parts of the OS X crash dump: Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000110 VM Regions Near 0x110: --> __TEXT 0000000100000000-0000000100001000 [ 4K] r-x/rwx SM=COW /Library/Frameworks/Python.framework/Versions/3.4.3_10_6/Resources/Python.app/Contents/MacOS/Python Application Specific Information: crashed on child side of fork pre-exec Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libdispatch.dylib 0x00007fff97347c13 dispatch_group_async + 533 1 libBLAS.dylib 0x00007fff96271a67 dsyrk_r + 565 2 libBLAS.dylib 0x00007fff96272183 APL_dsyrk + 370 3 libBLAS.dylib 0x00007fff96370696 cblas_dgemm + 1144 4 _dotblas.so 0x0000000104216775 dotblas_matrixproduct + 5733 5 org.python.python 0x00000001000e44ce PyEval_EvalFrameEx + 28894 6 org.python.python 0x00000001000e5ced PyEval_EvalCodeEx + 2349 7 org.python.python 0x000000010003e8ba function_call + 186 8 org.python.python 0x000000010000d3c8 PyObject_Call + 104 9 org.python.python 0x00000001000e0cb9 PyEval_EvalFrameEx + 14537 10 org.python.python 0x00000001000e5ced PyEval_EvalCodeEx + 2349 11 org.python.python 0x000000010003e8ba function_call + 186 12 org.python.python 0x000000010000d3c8 PyObject_Call + 104 13 org.python.python 0x00000001000e0cb9 PyEval_EvalFrameEx + 14537 14 org.python.python 0x00000001000e4455 PyEval_EvalFrameEx + 28773 15 org.python.python 0x00000001000e4455 PyEval_EvalFrameEx + 28773 16 org.python.python 0x00000001000e4455 PyEval_EvalFrameEx + 28773 17 org.python.python 0x00000001000e5ced PyEval_EvalCodeEx + 2349 18 org.python.python 0x000000010003e8ba function_call + 186 19 org.python.python 0x000000010000d3c8 PyObject_Call + 104 20 org.python.python 0x000000010002802c method_call + 140 21 org.python.python 0x000000010000d3c8 PyObject_Call + 104 22 org.python.python 0x000000010007b831 slot_tp_init + 81 23 org.python.python 0x0000000100072d14 type_call + 212 24 org.python.python 0x000000010000d3c8 PyObject_Call + 104 25 org.python.python 0x00000001000e1b09 PyEval_EvalFrameEx + 18201 26 org.python.python 0x00000001000e4455 PyEval_EvalFrameEx + 28773 27 org.python.python 0x00000001000e4455 PyEval_EvalFrameEx + 28773 28 org.python.python 0x00000001000e4455 PyEval_EvalFrameEx + 28773 29 org.python.python 0x00000001000e4455 PyEval_EvalFrameEx + 28773 30 org.python.python 0x00000001000e4455 PyEval_EvalFrameEx + 28773 31 org.python.python 0x00000001000e5ced PyEval_EvalCodeEx + 2349 32 org.python.python 0x000000010003e8ba function_call + 186 33 org.python.python 0x000000010000d3c8 PyObject_Call + 104 34 org.python.python 0x00000001000e0cb9 PyEval_EvalFrameEx + 14537 35 org.python.python 0x00000001000e5ced PyEval_EvalCodeEx + 2349 36 org.python.python 0x00000001000e4306 PyEval_EvalFrameEx + 28438 37 org.python.python 0x00000001000e5ced PyEval_EvalCodeEx + 2349 38 org.python.python 0x00000001000e4306 PyEval_EvalFrameEx + 28438 39 org.python.python 0x00000001000e4455 PyEval_EvalFrameEx + 28773 40 org.python.python 0x00000001000e5ced PyEval_EvalCodeEx + 2349 41 org.python.python 0x00000001000e5daf PyEval_EvalCode + 63 42 org.python.python 0x000000010011048e PyRun_FileExFlags + 206 43 org.python.python 0x000000010011083d PyRun_SimpleFileExFlags + 717 44 org.python.python 0x000000010012810e Py_Main + 3262 45 org.python.python 0x0000000100000e32 0x100000000 + 3634 46 org.python.python 0x0000000100000c84 0x100000000 + 3204 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000105001480 rbx: 0x0000000000000000 rcx: 0x0000000000000000 rdx: 0x0000000000000100 rdi: 0x00007fff7cd5fd40 rsi: 0x0000000000000000 rbp: 0x00007fff5bffbbd0 rsp: 0x00007fff5bffbba0 r8: 0x0000000105001400 r9: 0x0000000000000000 r10: 0x00000000000007d0 r11: 0xffff8001a446c4d8 r12: 0x00000001004682b0 r13: 0x0000000100437210 r14: 0x00007fff97341317 r15: 0x0000000000002000 rip: 0x00007fff97347c13 rfl: 0x0000000000010206 cr2: 0x0000000000000110 Logical CPU: 2 Error Code: 0x00000006 Trap Number: 14 [...] 0x104212000 - 0x104217ff7 +_dotblas.so (???) <15CB5D81-FD91-3005-A21C-A7D1432020C2> /Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/numpy/core/_dotblas.so [...] 0x7fff96258000 - 0x7fff963e6fff libBLAS.dylib (1128) <497912C1-A98E-3281-BED7-E9C751552F61> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib [...] So the crash is occurring as a result of a call from NumPy's _dotblas extension module to OS X's libBLAS. There's nothing obvious here that would indicate this is a problem in Python itself. Suggest you pursue this in the NumPy community and, if necessary, open an issue there: http://www.scipy.org/scipylib/mailing-lists.html ---------- nosy: +ned.deily resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 07:21:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 May 2015 05:21:59 +0000 Subject: [issue20035] Clean up Tcl library discovery in Tkinter on Windows In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za> Message-ID: <1431840119.95.0.394531278416.issue20035@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I afraid about Tix. _fix.py searches not only Tcl/Tk, but Tix too. New patch doesn't set TIX_LIBRARY. Unfortunately there are no Tix tests at all, and we can break the support of Tix without the notice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 07:30:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 May 2015 05:30:58 +0000 Subject: [issue24212] Idle, 2.7, backport idlelib.__main__, enable py -m idlelib In-Reply-To: <1431812813.24.0.960232018759.issue24212@psf.upfronthosting.co.za> Message-ID: <1431840658.92.0.557247467263.issue24212@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why idlelib.__main__ should be backported? You can start IDLE as "python -m idlelib.idle" in 2.7 and this works as well in 3.x. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 07:55:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 May 2015 05:55:50 +0000 Subject: [issue24215] test_trace uses test_pprint Message-ID: <1431842150.15.0.237267681297.issue24215@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Converting test_pprint to be unittest discoverable had broke the test_trace that uses test_main from test_pprint. ====================================================================== ERROR: test_coverage (test.test_trace.TestCoverage) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/test/test_trace.py", line 312, in test_coverage self._coverage(tracer) File "/home/serhiy/py/cpython/Lib/test/test_trace.py", line 305, in _coverage tracer.run(cmd) File "/home/serhiy/py/cpython/Lib/trace.py", line 500, in run self.runctx(cmd, dict, dict) File "/home/serhiy/py/cpython/Lib/trace.py", line 508, in runctx exec(cmd, globals, locals) File "", line 1, in AttributeError: module 'test.test_pprint' has no attribute 'test_main' ====================================================================== ERROR: test_coverage_ignore (test.test_trace.TestCoverage) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/test/test_trace.py", line 327, in test_coverage_ignore self._coverage(tracer) File "/home/serhiy/py/cpython/Lib/test/test_trace.py", line 305, in _coverage tracer.run(cmd) File "/home/serhiy/py/cpython/Lib/trace.py", line 500, in run self.runctx(cmd, dict, dict) File "/home/serhiy/py/cpython/Lib/trace.py", line 508, in runctx exec(cmd, globals, locals) File "", line 1, in AttributeError: module 'test.test_pprint' has no attribute 'test_main' ---------------------------------------------------------------------- The simplest way to fix the regression is to restore test_main in test_pprint. But for now test_pprint is much larger and slower than it was when test_trace was written. Perhaps it is not the best example for testing tracing. Are there better ideas? ---------- components: Tests messages: 243386 nosy: belopolsky, larry, serhiy.storchaka priority: release blocker severity: normal status: open title: test_trace uses test_pprint type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 09:23:16 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 17 May 2015 07:23:16 +0000 Subject: [issue22155] Out of date code example for tkinter's createfilehandler In-Reply-To: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za> Message-ID: <1431847396.51.0.541188211337.issue22155@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch which moves the documentation from the FAQ into a new section at the bottom of the main ?tkinter? reference manual page, and updates it. I also mentioned lack of Windows support. Let me know what you think! ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file39402/file-handlers.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 09:52:27 2015 From: report at bugs.python.org (Ram Rachum) Date: Sun, 17 May 2015 07:52:27 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431849147.05.0.499399039807.issue24195@psf.upfronthosting.co.za> Ram Rachum added the comment: Okay, let me understand what the opinions of people are about this feature. Ram Rachum: +1 Antoine Pitrou: -1 Nick Coghlan: Is that a +1 or a +0? Ethan and Paul, you've participated but I didn't get your opinion on whether you want to see this feature go in. If there are more -1s than +1s we can close this ticket. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 09:59:48 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Sun, 17 May 2015 07:59:48 +0000 Subject: [issue24216] Typo in bytes.join/bytearray.join documentation Message-ID: <1431849588.53.0.583435577111.issue24216@psf.upfronthosting.co.za> New submission from Dmitry Kazakov: This if there are any values in iterable that are note bytes-like objects should be if there are any values in iterable that are not bytes-like objects Here's a micropatch... ---------- assignee: docs at python components: Documentation files: bytes_join.diff keywords: patch messages: 243389 nosy: docs at python, vlth priority: normal severity: normal status: open title: Typo in bytes.join/bytearray.join documentation type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39403/bytes_join.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 10:02:56 2015 From: report at bugs.python.org (Paul Moore) Date: Sun, 17 May 2015 08:02:56 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431849776.56.0.423399958736.issue24195@psf.upfronthosting.co.za> Paul Moore added the comment: I'm not a heavy user of concurrent.futures, so I don't have a strong opinion. I've never felt a need for this function, though, so I guess I'm -0. A recipe in the docs would be good, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 11:14:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 May 2015 09:14:42 +0000 Subject: [issue18323] 'GzipFile' object has no attribute 'extrastart' In-Reply-To: <1372418817.06.0.791452748439.issue18323@psf.upfronthosting.co.za> Message-ID: <1431854082.67.0.626400449998.issue18323@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As a workaround specify mode='r' for GzipFile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 11:24:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 May 2015 09:24:16 +0000 Subject: [issue23637] Warnings error with non-ascii chars. In-Reply-To: <1426062904.63.0.0951614232281.issue23637@psf.upfronthosting.co.za> Message-ID: <1431854656.79.0.0255993095868.issue23637@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 May 17 11:50:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 May 2015 09:50:51 +0000 Subject: [issue23757] tuple function gives wrong answer when called on list subclass with custom __iter__ In-Reply-To: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za> Message-ID: <1431856251.65.0.270323917767.issue23757@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Raymond's patch LGTM. Here is updated patch with tests. ---------- assignee: -> rhettinger keywords: +patch stage: needs patch -> commit review Added file: http://bugs.python.org/file39404/fix_list_to_tuple_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 12:54:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 May 2015 10:54:18 +0000 Subject: [issue15809] 2.7 IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <20150517105415.32297.28198@psf.io> Roundup Robot added the comment: New changeset 247f003b42ea by Serhiy Storchaka in branch '2.7': Issue #15809: IDLE shell now uses locale encoding instead of Latin1 for https://hg.python.org/cpython/rev/247f003b42ea ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 14:19:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 May 2015 12:19:31 +0000 Subject: [issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za> Message-ID: <1431865171.57.0.581031038969.issue6598@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that changes the generating of message IDs: 1. The datetime is taken with higher precision, 2 decimal digits after dot. 2. The datetime is written as Unix time in 0.01 second units, not as YYYYmmddHHMMSS. This is more compact and faster. 3. The random part is taken as the random integer in the range 0 from to 2**64, not from 0 to 10**5. This increases the length of generated part of the ID from 26 to 39 characters in average. Perhaps in new releases we can use non-decimal or even non-alphanumeric characters in ID for compactness. ---------- nosy: +barry stage: -> patch review Added file: http://bugs.python.org/file39405/make_msgid_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 14:51:05 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 17 May 2015 12:51:05 +0000 Subject: [issue20035] Clean up Tcl library discovery in Tkinter on Windows In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za> Message-ID: <1431867065.54.0.272572068739.issue20035@psf.upfronthosting.co.za> Steve Dower added the comment: There's an MSBuild property that I set for release builds (either BuildForRelease or ReleaseBuild, not Configuration) that should exclude the preprocessor directive so we don't include an unnecessary full path. I can make that change later if you don't want to hold this patch up any longer though, as the rest looks fine to me. I don't know enough about Tix to comment on Serhiy's point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 14:54:17 2015 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 17 May 2015 12:54:17 +0000 Subject: [issue24147] doublequote are not well recognized with Dialect class In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za> Message-ID: <1431867257.63.0.0128209589762.issue24147@psf.upfronthosting.co.za> Skip Montanaro added the comment: In your Mon class, you've left the doublequote parameter unset (it defaults to None). It completely overrides the default dialect. When no Dialect class is given, the default is csv.excel. Note that doublequote is set to True in csv.excel. In your second example, the reader starts with csv.excel, then selectively overrides the named attributes. ---------- resolution: -> not a bug status: open -> closed Added file: http://bugs.python.org/file39406/quotebug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 15:06:13 2015 From: report at bugs.python.org (Mik) Date: Sun, 17 May 2015 13:06:13 +0000 Subject: [issue24147] doublequote are not well recognized with Dialect class In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za> Message-ID: <1431867973.37.0.896149626137.issue24147@psf.upfronthosting.co.za> Mik added the comment: Ok Thanks. But perhaps the documentation of csv.Dialect would be updated with the default parameters. If all attribute may be specified this would be indicated in the doc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 15:15:45 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 May 2015 13:15:45 +0000 Subject: [issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za> Message-ID: <1431868545.23.0.893803129609.issue6598@psf.upfronthosting.co.za> R. David Murray added the comment: Looking at my mail store, it looks like one more more mail clients use a GUID for the messageid, which is 36 characters. So 39 doesn't seem so bad. There's even one that is 74 characters long. There are also shorter ones, though, so compactifying the result wouldn't be a bad thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 15:18:29 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 May 2015 13:18:29 +0000 Subject: [issue24147] Dialect class defaults are not documented. In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za> Message-ID: <1431868709.37.0.905473366167.issue24147@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, I think the documentation should be improved. ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python, r.david.murray resolution: not a bug -> stage: -> needs patch status: closed -> open title: doublequote are not well recognized with Dialect class -> Dialect class defaults are not documented. versions: +Python 3.4, Python 3.5 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 16:17:47 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 May 2015 14:17:47 +0000 Subject: [issue24216] Typo in bytes.join/bytearray.join documentation In-Reply-To: <1431849588.53.0.583435577111.issue24216@psf.upfronthosting.co.za> Message-ID: <20150517141744.26578.60203@psf.io> Roundup Robot added the comment: New changeset ba271f116f94 by R David Murray in branch '3.4': #24216: fix typo https://hg.python.org/cpython/rev/ba271f116f94 New changeset 91ac3040a28d by R David Murray in branch 'default': Merge: #24216: fix typo https://hg.python.org/cpython/rev/91ac3040a28d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 16:18:21 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 May 2015 14:18:21 +0000 Subject: [issue24216] Typo in bytes.join/bytearray.join documentation In-Reply-To: <1431849588.53.0.583435577111.issue24216@psf.upfronthosting.co.za> Message-ID: <1431872301.72.0.887431668373.issue24216@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Dmitry. ---------- nosy: +r.david.murray resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 16:25:45 2015 From: report at bugs.python.org (Maciej Szulik) Date: Sun, 17 May 2015 14:25:45 +0000 Subject: [issue24211] Add RFC 6532 support to the email library In-Reply-To: <1431811149.98.0.538401086698.issue24211@psf.upfronthosting.co.za> Message-ID: <1431872745.0.0.930865272747.issue24211@psf.upfronthosting.co.za> Changes by Maciej Szulik : ---------- nosy: +maciej.szulik _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 16:50:32 2015 From: report at bugs.python.org (Skip Montanaro) Date: Sun, 17 May 2015 14:50:32 +0000 Subject: [issue24147] Dialect class defaults are not documented. In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za> Message-ID: <1431874232.39.0.885978525558.issue24147@psf.upfronthosting.co.za> Skip Montanaro added the comment: The defaults for the Dialect class are documented: https://docs.python.org/2/library/csv.html#dialects-and-formatting-parameters I think the problem is mostly that csv.Dialect must be subclassed. You can't use it directly, and if you subclass it as MiK did, you have to supply all the missing parameters. The default dialect is actually csv.excel, which does provide a suitable set of values for all attributes. There actually might be a bug lurking in the code as well. The value of csv.Dialect.doublequote is None, which will evaluate to False in a boolean context. The module docstring has this to say about that attribute: * doublequote - controls the handling of quotes inside fields. When True, two consecutive quotes are interpreted as one during read, and when writing, each quote character embedded in the data is written as two quotes Since the valid values of that attribute are actually only True and False, using None as a default value is an invitation to problems. It appears in this case that's what happened. csv.Dialect.__init__ doesn't seem to check that the overriding class properly sets all the required parameters. It checks to see if the class is Dialect. If not, and if the validate() call passes, all is assumed to be well. But digging a bit under the surface, it appears the validate step drops into C where the doublequote attribute of Dialog_Type is 0. I'm not sure the bug should be fixed in 2.7, but it's worth taking a look at the 3.5 code to see if that validation step can be improved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 16:51:38 2015 From: report at bugs.python.org (Maciej Szulik) Date: Sun, 17 May 2015 14:51:38 +0000 Subject: [issue24211] Add RFC 6532 support to the email library In-Reply-To: <1431811149.98.0.538401086698.issue24211@psf.upfronthosting.co.za> Message-ID: <1431874298.06.0.743417452733.issue24211@psf.upfronthosting.co.za> Maciej Szulik added the comment: David one small nit in docs, but otherwise the patch looks good, applies cleanly and works as expected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 17:20:16 2015 From: report at bugs.python.org (Jeffrey Armstrong) Date: Sun, 17 May 2015 15:20:16 +0000 Subject: [issue24217] O_RDWR undefined in mmapmodule.c Message-ID: <1431876016.63.0.693162312632.issue24217@psf.upfronthosting.co.za> New submission from Jeffrey Armstrong: While compiling on Linux/x86 with Open Watcom, I've run into the following at link time in Modules/mmapmodule.c: ./Modules/mmapmodule.c(1223): Error! E1011: Symbol 'O_RDWR' has not been declared The constant isn't defined because fcntl.h isn't included. Looking at the top of the file, it appears that, for the Apple platform only, this header is included, but no others. In order to support more runtime libraries outside of GNU libc, I would suggest including fcntl.h for all UNIX-y platforms, especially because the POSIX standard dictates that this constant be defined in fcntl.h. I don't know how it finds its way in under GCC/GNU libc, but an explicit include might be better. ---------- components: Extension Modules files: mmapmodule.py3.5.0a3.diff keywords: patch messages: 243404 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: O_RDWR undefined in mmapmodule.c type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file39407/mmapmodule.py3.5.0a3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 17:21:30 2015 From: report at bugs.python.org (Jeffrey Armstrong) Date: Sun, 17 May 2015 15:21:30 +0000 Subject: [issue20596] Support for alternate wcstok syntax for Windows compilers In-Reply-To: <1392123816.37.0.457546149708.issue20596@psf.upfronthosting.co.za> Message-ID: <1431876090.58.0.471968648855.issue20596@psf.upfronthosting.co.za> Changes by Jeffrey Armstrong : ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 17:23:44 2015 From: report at bugs.python.org (Jeffrey Armstrong) Date: Sun, 17 May 2015 15:23:44 +0000 Subject: [issue21931] Nonsense errors reported by msilib.FCICreate for bad argument In-Reply-To: <1404737590.72.0.85327158616.issue21931@psf.upfronthosting.co.za> Message-ID: <1431876224.35.0.989071816415.issue21931@psf.upfronthosting.co.za> Jeffrey Armstrong added the comment: I thought, while I'm here reporting another bug, I'd bump this once more. There is a patch here, and it corrects clearly broken code. Should I mark this as "won't fix?" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 17:24:35 2015 From: report at bugs.python.org (Christian Heimes) Date: Sun, 17 May 2015 15:24:35 +0000 Subject: [issue24217] O_RDWR undefined in mmapmodule.c In-Reply-To: <1431876016.63.0.693162312632.issue24217@psf.upfronthosting.co.za> Message-ID: <1431876275.88.0.315787150242.issue24217@psf.upfronthosting.co.za> Christian Heimes added the comment: I think it's more portable with a #ifdef HAVE_FCNTL_H block around the include. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 17:29:11 2015 From: report at bugs.python.org (Jeffrey Armstrong) Date: Sun, 17 May 2015 15:29:11 +0000 Subject: [issue24217] O_RDWR undefined in mmapmodule.c In-Reply-To: <1431876016.63.0.693162312632.issue24217@psf.upfronthosting.co.za> Message-ID: <1431876551.29.0.510916322659.issue24217@psf.upfronthosting.co.za> Jeffrey Armstrong added the comment: Indeed, I agree. Let's try this new patch. ---------- Added file: http://bugs.python.org/file39408/mmapmodule.py3.5.0a3.HAVE_FCNTL_H.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 17:29:37 2015 From: report at bugs.python.org (Jeffrey Armstrong) Date: Sun, 17 May 2015 15:29:37 +0000 Subject: [issue24217] O_RDWR undefined in mmapmodule.c In-Reply-To: <1431876016.63.0.693162312632.issue24217@psf.upfronthosting.co.za> Message-ID: <1431876577.62.0.0215179919239.issue24217@psf.upfronthosting.co.za> Changes by Jeffrey Armstrong : Removed file: http://bugs.python.org/file39407/mmapmodule.py3.5.0a3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 17:29:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 May 2015 15:29:53 +0000 Subject: [issue24211] Add RFC 6532 support to the email library In-Reply-To: <1431811149.98.0.538401086698.issue24211@psf.upfronthosting.co.za> Message-ID: <20150517152949.21168.79863@psf.io> Roundup Robot added the comment: New changeset 9f0d5e33230f by R David Murray in branch 'default': #24211: Add RFC6532 support to the email library. https://hg.python.org/cpython/rev/9f0d5e33230f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 17:36:12 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 17 May 2015 15:36:12 +0000 Subject: [issue24212] Idle, 2.7, backport idlelib.__main__, enable py -m idlelib In-Reply-To: <1431812813.24.0.960232018759.issue24212@psf.upfronthosting.co.za> Message-ID: <1431876972.93.0.251557080666.issue24212@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The idea, obviously, is for python -m idlelib to also work on all systems. When this was requested as part of the discussion on another issue, I thought there was no idlelib.__main__ because __main__ did not work on 2.7. Someone corrected me and the expectation of me and others was that the absence was just an easily corrected oversight. Turns out not so. I wanted to at least document that the backport is not trivial. I am rather curious why the same code behaves so differently on 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 17:58:53 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 17 May 2015 15:58:53 +0000 Subject: [issue22155] Out of date code example for tkinter's createfilehandler In-Reply-To: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za> Message-ID: <1431878333.16.0.273878191778.issue22155@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Assuming that the details are correct, which I cannot check on Windows :-(, this looks good to me. If the tkinter doc is expanded and reorganized, that section might move but I cannot see a better place for it now. Martin, have you used that code (with Tkinter/tkinter) on both 2.7 and 3.x? Serhiy, if you want me to apply this, after you check it, I will. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 18:03:48 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 17 May 2015 16:03:48 +0000 Subject: [issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za> Message-ID: <1431878628.86.0.986629727012.issue6598@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: An increase of 13 characters doesn't seem so bad. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 18:17:21 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 May 2015 16:17:21 +0000 Subject: [issue24211] Add RFC 6532 support to the email library In-Reply-To: <1431811149.98.0.538401086698.issue24211@psf.upfronthosting.co.za> Message-ID: <1431879441.65.0.0253695851638.issue24211@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Maciej. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 18:22:00 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 May 2015 16:22:00 +0000 Subject: [issue24218] Also support SMTPUTF8 in smtplib's send_message method. Message-ID: <1431879719.97.0.835565097524.issue24218@psf.upfronthosting.co.za> New submission from R. David Murray: Now that I've committed issue 24211, we can also add SMTPUTF8 support to smptlib's send_message command. See attached patch. ---------- files: send_message_smtputf8.patch keywords: patch messages: 243413 nosy: r.david.murray priority: normal severity: normal stage: patch review status: open title: Also support SMTPUTF8 in smtplib's send_message method. type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39409/send_message_smtputf8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 18:23:19 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 May 2015 16:23:19 +0000 Subject: [issue24218] Also support SMTPUTF8 in smtplib's send_message method. In-Reply-To: <1431879719.97.0.835565097524.issue24218@psf.upfronthosting.co.za> Message-ID: <1431879799.02.0.722574136222.issue24218@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- components: +email nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 18:23:27 2015 From: report at bugs.python.org (Jakub Wilk) Date: Sun, 17 May 2015 16:23:27 +0000 Subject: [issue16314] Support xz compression in distutils In-Reply-To: <1351114378.64.0.718374634123.issue16314@psf.upfronthosting.co.za> Message-ID: <1431879807.31.0.373169705123.issue16314@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 18:43:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 May 2015 16:43:24 +0000 Subject: [issue22155] Out of date code example for tkinter's createfilehandler In-Reply-To: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za> Message-ID: <1431881004.46.0.294493730962.issue22155@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm not sure that this is right place to document these functions (they are methods of undocumented class), but the patch looks correct to me. If you will commit the patch, Terry, note that tkinter should be replaced with Tkinter in 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 18:53:07 2015 From: report at bugs.python.org (Zachary Ware) Date: Sun, 17 May 2015 16:53:07 +0000 Subject: [issue21931] Nonsense errors reported by msilib.FCICreate for bad argument In-Reply-To: <1431876224.35.0.989071816415.issue21931@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: I'll try to have a look at this later today, but unfortunately can't guarantee anything (I don't know C, MSI, or _msi very well). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 18:59:16 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 17 May 2015 16:59:16 +0000 Subject: [issue24215] test_trace uses test_pprint In-Reply-To: <1431842150.15.0.237267681297.issue24215@psf.upfronthosting.co.za> Message-ID: <1431881956.1.0.766617501436.issue24215@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since test files should no longer have test_main, test_trace should no longer look for one. (And indeed, test_trace itself should be converted, which looks trivial.) The offending line is cmd='from test import test_pprint; test_pprint.test_main()'): The use of 'test_main' is just a convenience; it could just as well be 'trace_main'. But there is no need to put anything extra in the traced file. The following works for me on on 3.4.3 cmd='import unittest, test.test_pprint;' 'unittest.main(test.test_pprint, exit=False)'): This solves the problem of this issue, but the tracing takes about 10 of 14.5 seconds total, An alternative might be considered, but test_coverage is tied to the output from pprint run by unittest. Alexander, can you suggest an alternate target and output test that would still fulfill the intent of the test? ---------- nosy: +terry.reedy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 19:46:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 17 May 2015 17:46:32 +0000 Subject: [issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za> Message-ID: <1431884792.22.0.749023152251.issue6598@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Currently the maximal length of local part is 14+1+len(str(2**16))+1+len(str(10**5-1)) == 26 With the patch it will be len(str(2**31*100))+1+len(str(2**16))+1+len(str(2**64)) = 39 If encode all three numbers with hexadecimal, it will be len('%x'%(2**31*100))+1+len('%x'%(2**16))+1+len('%x'%(2**64)) = 34 If encode their with base32: math.ceil((31+math.log(100)/math.log(2))/5)+1+math.ceil(16/5)+1+math.ceil(64/5) = 27 Using base64 or base85 can be not safe, because message ID can be used as file name in case-insensitive file system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 20:03:30 2015 From: report at bugs.python.org (Maciej Szulik) Date: Sun, 17 May 2015 18:03:30 +0000 Subject: [issue24218] Also support SMTPUTF8 in smtplib's send_message method. In-Reply-To: <1431879719.97.0.835565097524.issue24218@psf.upfronthosting.co.za> Message-ID: <1431885810.54.0.935877611018.issue24218@psf.upfronthosting.co.za> Changes by Maciej Szulik : ---------- nosy: +maciej.szulik _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 20:10:51 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Sun, 17 May 2015 18:10:51 +0000 Subject: [issue24219] Repeated integer in Lexical analysis/Integer literals section Message-ID: <1431886251.68.0.470371931129.issue24219@psf.upfronthosting.co.za> New submission from Dmitry Kazakov: One of the integers under "Some examples of integer literals" is repeated twice: 7 2147483647 0o177 0b100110111 3 79228162514264337593543950336 0o377 0x100000000 79228162514264337593543950336 0xdeadbeef I believe this comes from the old docs: https://docs.python.org/2.7/reference/lexical_analysis.html#integer-and-long-integer-literals (the L suffix was removed). ---------- assignee: docs at python components: Documentation files: intliteral.diff keywords: patch messages: 243418 nosy: docs at python, vlth priority: normal severity: normal status: open title: Repeated integer in Lexical analysis/Integer literals section type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39410/intliteral.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 20:24:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 May 2015 18:24:51 +0000 Subject: [issue20098] email policy needs a mangle_from setting In-Reply-To: <1388446517.27.0.863185292033.issue20098@psf.upfronthosting.co.za> Message-ID: <20150517182448.10820.66931@psf.io> Roundup Robot added the comment: New changeset df81f9b67736 by R David Murray in branch 'default': #20098: add mangle_from_ policy option. https://hg.python.org/cpython/rev/df81f9b67736 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 20:25:22 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 May 2015 18:25:22 +0000 Subject: [issue20098] email policy needs a mangle_from setting In-Reply-To: <1388446517.27.0.863185292033.issue20098@psf.upfronthosting.co.za> Message-ID: <1431887122.97.0.325809165266.issue20098@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Milan. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 20:46:54 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 May 2015 18:46:54 +0000 Subject: [issue19678] smtpd.py: channel should be passed to process_message In-Reply-To: <1385031410.17.0.520349427654.issue19678@psf.upfronthosting.co.za> Message-ID: <1431888414.89.0.483075077764.issue19678@psf.upfronthosting.co.za> R. David Murray added the comment: At this point (3.5) we have settled on having process_message be required to have a **kwargs parameter in its signature in order to support new features (ex: enable_SMTPUTF8). So the solution here would be to use inspect.signature to find out if process_message has a **kwargs parameter (kind=VAR_KEYWORD), and if so to supply a 'channel' keyword and value. ---------- keywords: +easy stage: -> needs patch versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 20:50:24 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 May 2015 18:50:24 +0000 Subject: [issue22155] Out of date code example for tkinter's createfilehandler In-Reply-To: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za> Message-ID: <20150517185021.10810.53425@psf.io> Roundup Robot added the comment: New changeset e8dd65c7fb6b by Terry Jan Reedy in branch '2.7': Issue #22155: Add File Handlers subsection with createfilehandler to Tkinter https://hg.python.org/cpython/rev/e8dd65c7fb6b New changeset 1efcb7b6ec8a by Terry Jan Reedy in branch '3.4': Issue #22155: Add File Handlers subsection with createfilehandler to tkinter https://hg.python.org/cpython/rev/1efcb7b6ec8a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 20:56:34 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 May 2015 18:56:34 +0000 Subject: [issue22155] Out of date code example for tkinter's createfilehandler In-Reply-To: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za> Message-ID: <20150517185631.26566.12190@psf.io> Roundup Robot added the comment: New changeset 8bd9da5635fe by Terry Jan Reedy in branch '3.4': Issue #22155: News entry. https://hg.python.org/cpython/rev/8bd9da5635fe New changeset 850cbd54cc73 by Terry Jan Reedy in branch 'default': Issue #22155: News entry. https://hg.python.org/cpython/rev/850cbd54cc73 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 20:59:52 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 17 May 2015 18:59:52 +0000 Subject: [issue22155] Out of date code example for tkinter's createfilehandler In-Reply-To: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za> Message-ID: <1431889192.21.0.606352211572.issue22155@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Martin, thanks for the nice patch. ---------- assignee: docs at python -> terry.reedy resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 21:03:33 2015 From: report at bugs.python.org (Maciej Szulik) Date: Sun, 17 May 2015 19:03:33 +0000 Subject: [issue24218] Also support SMTPUTF8 in smtplib's send_message method. In-Reply-To: <1431879719.97.0.835565097524.issue24218@psf.upfronthosting.co.za> Message-ID: <1431889413.65.0.661459342658.issue24218@psf.upfronthosting.co.za> Maciej Szulik added the comment: David one small comment regarding typo in smtplib.py, but most importantly I'd suggest adding additional test case to cover the path (the newly added one) where you get a UnicodeEncodeError upon encoding from or to with UTF8 and then failing to find SMTPUTF8 on the server side. I see we already have test case to cover SMTPNotSupportedError but this covers just the case where the server does not have SMTPUTF8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 21:05:16 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 May 2015 19:05:16 +0000 Subject: [issue24218] Also support SMTPUTF8 in smtplib's send_message method. In-Reply-To: <1431879719.97.0.835565097524.issue24218@psf.upfronthosting.co.za> Message-ID: <1431889516.18.0.859240049519.issue24218@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, right, that's what I get for doing this at the end of a long chain of patch reviews :). I added that code after I'd written the test and forgot to go back and test it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 22:10:38 2015 From: report at bugs.python.org (Matthias Bussonnier) Date: Sun, 17 May 2015 20:10:38 +0000 Subject: [issue24220] ast.Call signature changed Message-ID: <1431893438.07.0.469229426161.issue24220@psf.upfronthosting.co.za> New submission from Matthias Bussonnier: The `ast.Call/_ast.Call` signature, changed on May 5th (https://hg.python.org/cpython/rev/95886) which causes some error in package using ast (https://bitbucket.org/pytest-dev/pytest/issue/744/pytest-assert-rewriting-broken-with-python#). There does not seem to be any docs in the what's new about the change, though http://bugs.python.org/issue24136 is suppose to track some docs change, so not complaining about that. Could `ast` shims the old signature and raise a warning until 3.6, to give some time for package to adapt ? ---------- components: Devguide messages: 243427 nosy: ezio.melotti, mbussonn, willingc priority: normal severity: normal status: open title: ast.Call signature changed type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 23:37:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 May 2015 21:37:48 +0000 Subject: [issue23757] tuple function gives wrong answer when called on list subclass with custom __iter__ In-Reply-To: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za> Message-ID: <20150517213745.125532.17482@psf.io> Roundup Robot added the comment: New changeset b6121a4afad7 by Raymond Hettinger in branch '2.7': Issue #23757: Only call the concrete list API for exact lists. https://hg.python.org/cpython/rev/b6121a4afad7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 23:47:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 May 2015 21:47:12 +0000 Subject: [issue23757] tuple function gives wrong answer when called on list subclass with custom __iter__ In-Reply-To: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za> Message-ID: <20150517214709.26570.57268@psf.io> Roundup Robot added the comment: New changeset c79530e08985 by Raymond Hettinger in branch '3.4': Issue #23757: Only call the concrete list API for exact lists. https://hg.python.org/cpython/rev/c79530e08985 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 23:47:59 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 17 May 2015 21:47:59 +0000 Subject: [issue23757] tuple function gives wrong answer when called on list subclass with custom __iter__ In-Reply-To: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za> Message-ID: <1431899279.98.0.893923090227.issue23757@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 23:58:03 2015 From: report at bugs.python.org (Arnon Yaari) Date: Sun, 17 May 2015 21:58:03 +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: <1431899883.03.0.605555085306.issue20362@psf.upfronthosting.co.za> Changes by Arnon Yaari : ---------- nosy: +wiggin15 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 23:58:24 2015 From: report at bugs.python.org (Arnon Yaari) Date: Sun, 17 May 2015 21:58:24 +0000 Subject: [issue20769] Reload() description is unclear In-Reply-To: <1393345435.57.0.757218905385.issue20769@psf.upfronthosting.co.za> Message-ID: <1431899904.58.0.0159373697852.issue20769@psf.upfronthosting.co.za> Changes by Arnon Yaari : ---------- nosy: +wiggin15 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 17 23:58:40 2015 From: report at bugs.python.org (Arnon Yaari) Date: Sun, 17 May 2015 21:58:40 +0000 Subject: [issue12485] textwrap.wrap: new argument for more pleasing output In-Reply-To: <1309745581.79.0.51605072509.issue12485@psf.upfronthosting.co.za> Message-ID: <1431899920.66.0.42045996136.issue12485@psf.upfronthosting.co.za> Changes by Arnon Yaari : ---------- nosy: +wiggin15 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 00:13:16 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 17 May 2015 22:13:16 +0000 Subject: [issue19737] Documentation of globals() and locals() should be improved In-Reply-To: <1385225461.09.0.671908077084.issue19737@psf.upfronthosting.co.za> Message-ID: <1431900796.89.0.44838982821.issue19737@psf.upfronthosting.co.za> Terry J. Reedy added the comment: My succinct version: Return the dictionary implementing the current module namespace. For code within functions, this is set when the function is defined and remains the same regardless of where a function is called. ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 00:41:48 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 17 May 2015 22:41:48 +0000 Subject: [issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose In-Reply-To: <1394620197.12.0.249138601017.issue20895@psf.upfronthosting.co.za> Message-ID: <1431902508.35.0.940976009556.issue20895@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> out of date stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 00:44:01 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 17 May 2015 22:44:01 +0000 Subject: [issue19846] Python 3 raises Unicode errors with the C locale In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za> Message-ID: <1431902641.43.0.114371100701.issue19846@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 00:49:14 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 17 May 2015 22:49:14 +0000 Subject: [issue2571] can cmd.py's API/docs for the use of an alternate stdin be improved? In-Reply-To: <1207594702.67.0.73869549091.issue2571@psf.upfronthosting.co.za> Message-ID: <1431902954.67.0.941355295214.issue2571@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: remind -> postponed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 01:33:21 2015 From: report at bugs.python.org (Alex Lord) Date: Sun, 17 May 2015 23:33:21 +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: <1431905601.2.0.955841405003.issue16864@psf.upfronthosting.co.za> Alex Lord added the comment: There was a bunch of things wrong with that patch. In addition to the issues you brought up in the review I was mixing up what the actual problem is REPLACE INTO is an alias for INSERT OR REPLACE. INSERT OR REPLACE was correctly setting the lastrowid values but REPLACE INTO was not setting the last rowid value. I changed the documentation modifications to reflect this. In addition I cleaned up the unit tests. The unit tests were kind of a mess because I was trying to figure out what the problem was and never refactored after getting a reproduction. I at first went down the path of making the tests use a for loop like you suggested for statement in ["INSERT OR REPLACE", "REPLACE"]: sql = "{} INTO test(id, unique_test) VALUES (?, ?)".format( statement) self.cu.execute(sql, (1, "foo")) self.assertEqual(self.cu.lastrowid, 1) self.cu.execute(sql, (1, "foo"))$ self.assertEqual(self.cu.lastrowid, 1) Which I don't think is as nice as a cleaned up unrolled version self.cu.execute("INSERT OR REPLACE INTO test(id, unique_test) VALUES (?, ?)", (1, "bar",)) self.assertEqual(self.cu.lastrowid, 1) self.cu.execute("INSERT OR REPLACE INTO test(id, unique_test) VALUES (?, ?)", (1, "bar",)) self.assertEqual(self.cu.lastrowid, 1) self.cu.execute("REPLACE INTO test(id, unique_test) VALUES (?, ?)", (1, "bar",)) self.assertEqual(self.cu.lastrowid, 1) I've created a patch that fixes all of the issues brought up in the code review and is just generally much cleaner. ---------- Added file: http://bugs.python.org/file39411/sqlite_after_review_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 01:38:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 May 2015 23:38:15 +0000 Subject: [issue24218] Also support SMTPUTF8 in smtplib's send_message method. In-Reply-To: <1431879719.97.0.835565097524.issue24218@psf.upfronthosting.co.za> Message-ID: <20150517233812.4231.14059@psf.io> Roundup Robot added the comment: New changeset 30795a477f85 by R David Murray in branch 'default': #24218: Add SMTPUTF8 support to send_message. https://hg.python.org/cpython/rev/30795a477f85 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 01:38:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 17 May 2015 23:38:15 +0000 Subject: [issue24211] Add RFC 6532 support to the email library In-Reply-To: <1431811149.98.0.538401086698.issue24211@psf.upfronthosting.co.za> Message-ID: <20150517233812.4231.99974@psf.io> Roundup Robot added the comment: New changeset 4a254750ad20 by R David Murray in branch 'default': #24211: Add missing docs for SMTPUTF8 policy instance. https://hg.python.org/cpython/rev/4a254750ad20 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 01:39:03 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 17 May 2015 23:39:03 +0000 Subject: [issue10170] Relationship between turtle speed setting and actual speed is not documented In-Reply-To: <1287692411.21.0.472855700629.issue10170@psf.upfronthosting.co.za> Message-ID: <1431905943.64.0.0619231463777.issue10170@psf.upfronthosting.co.za> Terry J. Reedy added the comment: After looking at these results in relation to the qualitative 'speed' documentation, I cannot think of any any enhancement appropriate for turtle doc audience. So I withdraw my request. ---------- resolution: -> works for me stage: -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 01:45:06 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 17 May 2015 23:45:06 +0000 Subject: [issue24218] Also support SMTPUTF8 in smtplib's send_message method. In-Reply-To: <1431879719.97.0.835565097524.issue24218@psf.upfronthosting.co.za> Message-ID: <1431906306.58.0.923055296601.issue24218@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks Maciej. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 01:48:53 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 17 May 2015 23:48:53 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431849776.56.0.423399958736.issue24195@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: I'm now +1 on a recipe in the docs, -0 on a concrete method on Executor that delegates to the map() method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 02:07:17 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 May 2015 00:07:17 +0000 Subject: [issue22155] Out of date code example for tkinter's createfilehandler In-Reply-To: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za> Message-ID: <1431907637.03.0.123927847921.issue22155@psf.upfronthosting.co.za> Martin Panter added the comment: For the record, I have used this code in 2.7 in the past (though I mainly use Python 3). The Python 2 version of the changes look fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 02:42:00 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 18 May 2015 00:42:00 +0000 Subject: [issue10685] trace does not ignore --ignore-module In-Reply-To: <1292157270.73.0.200325030661.issue10685@psf.upfronthosting.co.za> Message-ID: <1431909720.43.0.0160868605299.issue10685@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Tom, please sign the PSF Contributor Agreement https://www.python.org/psf/contrib/ https://www.python.org/psf/contrib/contrib-form/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 02:45:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 May 2015 00:45:03 +0000 Subject: [issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za> Message-ID: <20150518004500.39247.75527@psf.io> Roundup Robot added the comment: New changeset c7d82a7a9dea by R David Murray in branch 'default': Issue #13866: add *quote_via* argument to urlencode. https://hg.python.org/cpython/rev/c7d82a7a9dea ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 02:45:36 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 May 2015 00:45:36 +0000 Subject: [issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za> Message-ID: <1431909936.91.0.187383399195.issue13866@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks everyone. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 02:51:18 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 May 2015 00:51:18 +0000 Subject: [issue4254] _cursesmodule.c callable update_lines_cols() In-Reply-To: <1225724529.97.0.843166149521.issue4254@psf.upfronthosting.co.za> Message-ID: <1431910278.76.0.829818861042.issue4254@psf.upfronthosting.co.za> R. David Murray added the comment: Looks to like there is nothing left to do here, so I'm closing it. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 03:00:34 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 May 2015 01:00:34 +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: <1431910834.57.0.551389153197.issue16864@psf.upfronthosting.co.za> R. David Murray added the comment: All lines need to be wrapped to <80 columns. The idea behind the loop is this: sql = "{} INTO test(id, unique_test) VALUES (?, ?)" self.cu.execute(sql.format('INSERT OR REPLACE, (1, "foo") for statement in ["INSERT OR REPLACE", "REPLACE"]: with self.subTest(statement=statement): self.cu.execute(sql.format(statement), (1, "foo")) self.assertEqual(self.cu.lastrowid, 1) What this does is run *both* tests, even if one fails, and reports the results separately (labeled with 'statement='INSERT OR REPLACE', ect). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 03:00:48 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 18 May 2015 01:00:48 +0000 Subject: [issue10598] Add test for curses haskey replacement In-Reply-To: <1291234378.99.0.641306252968.issue10598@psf.upfronthosting.co.za> Message-ID: <1431910848.29.0.63548155896.issue10598@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Here is what I meant, but I cannot test on Windows. Mark, do you have *nix currently? ---------- Added file: http://bugs.python.org/file39412/has_key.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 03:05:53 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 18 May 2015 01:05:53 +0000 Subject: [issue24221] Clean-up and optimization for heapq siftup() and siftdown() Message-ID: <1431911153.11.0.995728012143.issue24221@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The siftup() and siftdown() routines rearrange pointers in a list. The generated code repeats the list object to ob_item lookup for each access. This patch does that lookup only once per iteration. It cleans up the code by replacing the PyList_GET_ITEM and PyList_SET_ITEM macros with normal array access (the usual way of presenting the algorithm). This gives about a 5% speed-up using CLANG (timing heapify(data[:]) for n=1000 goes from .3441 per iteration to .3299). However on GCC-4.9, the same patch gives a 2% slow-down (disassembly shows that this patch triggers a register spill and load in the inner loop which is a bummer). Since it speeds-up some builds and slows down others, I'm uncertain what to do with this one. I like the way the code reads with array accesses but was aiming for a consistent win. Am posting the patch here to collect thoughts on the subject and to not lose the work. ---------- components: Extension Modules files: heapitems5.diff keywords: patch messages: 243444 nosy: rhettinger priority: normal severity: normal status: open title: Clean-up and optimization for heapq siftup() and siftdown() type: performance versions: Python 3.5 Added file: http://bugs.python.org/file39413/heapitems5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 03:06:27 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 18 May 2015 01:06:27 +0000 Subject: [issue24221] Clean-up and optimization for heapq siftup() and siftdown() In-Reply-To: <1431911153.11.0.995728012143.issue24221@psf.upfronthosting.co.za> Message-ID: <1431911187.54.0.789010656218.issue24221@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file39414/time_heapify.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 03:10:39 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 18 May 2015 01:10:39 +0000 Subject: [issue10598] Add test for curses haskey replacement In-Reply-To: <1291234378.99.0.641306252968.issue10598@psf.upfronthosting.co.za> Message-ID: <1431911439.79.0.35311062934.issue10598@psf.upfronthosting.co.za> Mark Lawrence added the comment: Sorry, Windows 8.1 only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 03:19:47 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 18 May 2015 01:19:47 +0000 Subject: [issue24222] Idle 2.7 -c, -r compile with print as function. Message-ID: <1431911987.88.0.560675260792.issue24222@psf.upfronthosting.co.za> New submission from Terry J. Reedy: C:\Users\Terry>py -2 -m idlelib.idle -c "print True" >>> *** Error in script or command! Traceback (most recent call last): File "", line 1 print True ^ SyntaxError: invalid syntax https://stackoverflow.com/questions/30280525/python-idle-give-a-false-syntax-error In answer, phihag points out that PyShell.py has future import and compiles with code = compile(source, filename, "exec") The fix is to add dont_inherit=True. ---------- assignee: terry.reedy messages: 243446 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle 2.7 -c, -r compile with print as function. type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 03:20:00 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 18 May 2015 01:20:00 +0000 Subject: [issue24221] Clean-up and optimization for heapq siftup() and siftdown() In-Reply-To: <1431911153.11.0.995728012143.issue24221@psf.upfronthosting.co.za> Message-ID: <1431912000.75.0.0875159792403.issue24221@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 03:22:12 2015 From: report at bugs.python.org (Bob Alexander) Date: Mon, 18 May 2015 01:22:12 +0000 Subject: [issue24223] argparse parsing bug Message-ID: <1431912132.53.0.00377060178324.issue24223@psf.upfronthosting.co.za> New submission from Bob Alexander: Here is simple example of failure to parse arguments that should parse OK. In the following little program, the second from last line contains an aargument sequence that parses OK, but the last line should but doesn't. import argparse ap = argparse.ArgumentParser() ap.add_argument("--option", action="store_true") ap.add_argument("arg_1") ap.add_argument("arg_2", nargs="?") print("test 1:", ap.parse_args(["abc", "mmm", "--option"])) print("test 2:", ap.parse_args(["abc", "--option", "mmm"])) ---------- components: Library (Lib) messages: 243447 nosy: bobjalex priority: normal severity: normal status: open title: argparse parsing bug type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 03:59:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 May 2015 01:59:31 +0000 Subject: [issue21337] Add tests for Tix In-Reply-To: <1398286008.45.0.411979424173.issue21337@psf.upfronthosting.co.za> Message-ID: <20150518015928.32315.69452@psf.io> Roundup Robot added the comment: New changeset eeea91d0506b by Zachary Ware in branch 'default': Issue #21337: Add bare-bones Tix test https://hg.python.org/cpython/rev/eeea91d0506b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 04:02:06 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 18 May 2015 02:02:06 +0000 Subject: [issue21337] Add tests for Tix In-Reply-To: <1398286008.45.0.411979424173.issue21337@psf.upfronthosting.co.za> Message-ID: <1431914526.11.0.323315540784.issue21337@psf.upfronthosting.co.za> Zachary Ware added the comment: As a prerequisite for #20035, I've added the simplest test possible that just makes sure Tix is available on Windows. I only added it on default as I don't have the facilities to test it properly on 2.7 and 3.4 on Windows (which is the only platform actually testing anything so far), but it should be simple enough to copy it over if anybody wants to or ever writes some real tests for Tix. Leaving this issue open as some real tests would still be nice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 05:00:00 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 May 2015 03:00:00 +0000 Subject: [issue17239] XML vulnerabilities in Python In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za> Message-ID: <1431918000.07.0.552350837604.issue17239@psf.upfronthosting.co.za> Martin Panter added the comment: I did a rough merge with current ?default? (3.5 pre-release) branch so that I can have a closer look at this issue; see xmlbomb_20150518.patch for the result. There are some bits with Argument Clinit that need perfecting: * Unsure how to convert the ElementTree.XMLParser.__init__() signature (varied depending on XML_BOMB_PROTECTION compile-time flag) to Argument Clinic. So I just hard-coded it as if XML_BOMB_PROTECTION is always enabled. Why do we have to have a variable signature in the first place? * New pyexpat functions need porting to Argument Clinic. ---------- versions: +Python 3.5 Added file: http://bugs.python.org/file39415/xmlbomb_20150518.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 05:10:54 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 18 May 2015 03:10:54 +0000 Subject: [issue20035] Clean up Tcl library discovery in Tkinter on Windows In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za> Message-ID: <1431918654.65.0.67711597231.issue20035@psf.upfronthosting.co.za> Zachary Ware added the comment: I committed a presence test for Tix in #21337 that should catch problems with loading Tix after this patch. There shouldn't be any problem though, we actually install Tix into Tcl/Tk whereas TIX_LIBRARY is (to my understanding) for helping Tcl/Tk find a Tix that it can't find itself. Steve, I think I have BuildForRelease patched in properly; it works with BuildForRelease unset at least :) ---------- Added file: http://bugs.python.org/file39416/issue20035.v7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 05:29:16 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 May 2015 03:29:16 +0000 Subject: [issue24223] argparse parsing (mingling --option and optional positional argument) In-Reply-To: <1431912132.53.0.00377060178324.issue24223@psf.upfronthosting.co.za> Message-ID: <1431919756.88.0.268739707848.issue24223@psf.upfronthosting.co.za> Martin Panter added the comment: I suggest this is a duplicate of Issue 15112. The same problem also happens with nargs="*", and that issue apparently has a patch to handle both cases. For the record, this is the resulting error, and a demo that it works if the option comes before the positional arguments: >>> print("test 2:", ap.parse_args(["abc", "--option", "mmm"])) usage: [-h] [--option] arg_1 [arg_2] : error: unrecognized arguments: mmm Traceback (most recent call last): File "", line 1, in File "/home/proj/python/cpython/Lib/argparse.py", line 1729, in parse_args self.error(msg % ' '.join(argv)) File "/home/proj/python/cpython/Lib/argparse.py", line 2385, in error self.exit(2, _('%(prog)s: error: %(message)s\n') % args) File "/home/proj/python/cpython/Lib/argparse.py", line 2372, in exit _sys.exit(status) File "/home/pythonstartup.py", line 345, in exit raise SystemExit(code) __main__.SystemExit: 2 >>> ap.parse_args(["--option", "abc", "mmm"]) Namespace(arg_1='abc', arg_2='mmm', option=True) ---------- nosy: +vadmium resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional title: argparse parsing bug -> argparse parsing (mingling --option and optional positional argument) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 05:32:57 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 May 2015 03:32:57 +0000 Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional In-Reply-To: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za> Message-ID: <1431919977.39.0.428571603255.issue15112@psf.upfronthosting.co.za> Martin Panter added the comment: Closed Issue 24223 as a duplicate. I understand the patch here also fixes the case of an --option before an optional positional argument using nargs="?"; is that right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 06:44:30 2015 From: report at bugs.python.org (Carol Willing) Date: Mon, 18 May 2015 04:44:30 +0000 Subject: [issue24220] ast.Call signature changed In-Reply-To: <1431893438.07.0.469229426161.issue24220@psf.upfronthosting.co.za> Message-ID: <1431924270.4.0.780759062348.issue24220@psf.upfronthosting.co.za> Carol Willing added the comment: Matthias, Did you wish to mark this issue for additional Documentation and as a behavior change request (warning of signature change until 3.6) in addition to Devguide? I've summarized below some info from researching Matthias' original message. I see three questions to answer: a) Should `ast` shim the old signature and raise a warning until 3.6? b) What additional items should be added to Documentation or Porting Guide? c) What items should be added to Devguide? **Background** Implementation of PEP 448 (Additional Unpacking Generalizations) changed the ast.Call/_ast.Call signature by removing two arguments (args, kwargs). Testing errors are seen in existing code that does not take into account the signature change.['1'][1] **Workaround** Matthias' possible workaround for existing projects to check for version 3.5 or higher and adapt to two less arguments.['2'][2] **Devguide addition** Thomas Kluyver's supplementary information about AST use.['3'][3] Perhaps mention this in the AST section of the devguide. I recognize that typically the devguide does not reference external docs but this seems like it would be useful to future developers. [1]: https://bitbucket.org/pytest-dev/pytest/issue/744/pytest-assert-rewriting-broken-with-python# [2]: https://bitbucket.org/pytest-dev/pytest/pull-request/296/astcall-signature-changed-on-35/diff [3]: https://greentreesnakes.readthedocs.org/en/latest/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 06:47:20 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 May 2015 04:47:20 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <20150518044717.21172.35215@psf.io> Roundup Robot added the comment: New changeset 16d0e3dda31c by Zachary Ware in branch 'default': Issue #23488: Fix a syntax error on big endian platforms. https://hg.python.org/cpython/rev/16d0e3dda31c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 07:15:51 2015 From: report at bugs.python.org (Matthias Bussonnier) Date: Mon, 18 May 2015 05:15:51 +0000 Subject: [issue24220] ast.Call signature changed In-Reply-To: <1431893438.07.0.469229426161.issue24220@psf.upfronthosting.co.za> Message-ID: <1431926151.46.0.827541948261.issue24220@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: Hi Carol, > Matthias, Did you wish to mark this issue for additional Documentation and as a behavior change request (warning of signature change until 3.6) in addition to Devguide? Hum, probably, I'm not super familiar with this bug tracker and it use, I've tried to select both Devguide and Docs now. > a) Should `ast` shim the old signature and raise a warning until 3.6? >From Guido's comment on linked issue, I guess not: > "There is no compatibility guarantee for the ast module" > b) What additional items should be added to Documentation or Porting Guide? I guess that Call api changed in the what's new. A link to a rough implementation that show how to get code compatible on 3.5 and below would be nice, it is kind of painful to iterate through the new AST structure and figure things out. > c) What items should be added to Devguide? I can talk to Thomas Kluyver tomorrow about merging green tree snake into the devguide, or maybe into ast docs. Would that be useful/more acceptable than linking to external docs ? Thanks. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 07:49:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 May 2015 05:49:22 +0000 Subject: [issue21931] Nonsense errors reported by msilib.FCICreate for bad argument In-Reply-To: <1404737590.72.0.85327158616.issue21931@psf.upfronthosting.co.za> Message-ID: <20150518054919.26838.26077@psf.io> Roundup Robot added the comment: New changeset 41281737d71a by Zachary Ware in branch '3.4': Issue #21931: Fix error handling in msilib.FCICreate(). https://hg.python.org/cpython/rev/41281737d71a New changeset cb0d1d86215e by Zachary Ware in branch 'default': Closes #21931: Merge with 3.4 https://hg.python.org/cpython/rev/cb0d1d86215e ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 07:56:33 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 18 May 2015 05:56:33 +0000 Subject: [issue24224] test_msilib is inadequate Message-ID: <1431928593.08.0.843064802562.issue24224@psf.upfronthosting.co.za> New submission from Zachary Ware: test_msilib doesn't test much and could do with good expansion. Marked for 3.5, but 3.4 and 2.7 are just as barren if whoever takes this feels particularly ambitious. ---------- components: Tests, Windows keywords: easy messages: 243458 nosy: steve.dower, tim.golden, zach.ware priority: low severity: normal stage: needs patch status: open title: test_msilib is inadequate type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 07:57:13 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 18 May 2015 05:57:13 +0000 Subject: [issue21931] Nonsense errors reported by msilib.FCICreate for bad argument In-Reply-To: <1404737590.72.0.85327158616.issue21931@psf.upfronthosting.co.za> Message-ID: <1431928633.49.0.61278032315.issue21931@psf.upfronthosting.co.za> Zachary Ware added the comment: It's a simple enough fix, so I went ahead and committed it. Thanks for the patch! I've created issue24224 to track the addition of tests to test_msilib (for more than just this issue). ---------- resolution: fixed -> stage: resolved -> patch review status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 07:57:32 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 18 May 2015 05:57:32 +0000 Subject: [issue21931] Nonsense errors reported by msilib.FCICreate for bad argument In-Reply-To: <1404737590.72.0.85327158616.issue21931@psf.upfronthosting.co.za> Message-ID: <1431928652.23.0.460170433609.issue21931@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 08:29:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 May 2015 06:29:14 +0000 Subject: [issue24221] Clean-up and optimization for heapq siftup() and siftdown() In-Reply-To: <1431911153.11.0.995728012143.issue24221@psf.upfronthosting.co.za> Message-ID: <1431930554.4.0.181151131203.issue24221@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Perhaps the code will look simpler if introduce the macro _PyList_SWAP_ITEMS(list, i, j). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 08:36:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 May 2015 06:36:53 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1431931013.2.0.258810002987.issue23488@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Zachary for fixing this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 09:11:55 2015 From: report at bugs.python.org (Tom Hines) Date: Mon, 18 May 2015 07:11:55 +0000 Subject: [issue10685] trace does not ignore --ignore-module In-Reply-To: <1431909720.43.0.0160868605299.issue10685@psf.upfronthosting.co.za> Message-ID: Tom Hines added the comment: Done. On Sun, May 17, 2015 at 8:42 PM, Terry J. Reedy wrote: > > Terry J. Reedy added the comment: > > Tom, please sign the PSF Contributor Agreement > https://www.python.org/psf/contrib/ > https://www.python.org/psf/contrib/contrib-form/ > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 09:30:58 2015 From: report at bugs.python.org (Ram Rachum) Date: Mon, 18 May 2015 07:30:58 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431934258.88.0.106295294104.issue24195@psf.upfronthosting.co.za> Ram Rachum added the comment: Looks like this a recipe in the docs is where this ticket is headed. I took my original example for `Executor.filter` and changed it using Brian's suggestion so now it uses `Executor.map`. Please check it out. If someone other than me feels comfortable in putting it into the documentation page, I'll be happy if you could do that. Possible issues: This example uses `requests`, which isn't in the standard library. I would say that this `for` line: for person in (person for person, filter_result in zip(people, executor.map(has_wikipedia_page, people)) if filter_result): Is a bit ugly, but since the consensus here is that this is better than implementing `Executor.filter`, so be it. ---------- Added file: http://bugs.python.org/file39417/filter_example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 09:36:27 2015 From: report at bugs.python.org (Al Sweigart) Date: Mon, 18 May 2015 07:36:27 +0000 Subject: [issue24225] IDLE test filenames don't match script filenames. Message-ID: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za> New submission from Al Sweigart: >From the idlelib/idle_test/README.txt file: "The idle_test subdirectory should contain a test_xyz.py for each, where 'xyz' is lowercased even if xyz.py is not." However, this means the test file names are inconsistent with the scripts they test. Of the 20 test_*.py files, all 20 are inconsistent. Some of the test filenames don't even match the file, such as test_config_name.py which tests configSectionNameDialog.py. Since the original filenames aren't lowercase like the rest of the standard library, it would be better to rename them rather than renaming the test files: AutoComplete.py to autocomplete.py, ColorDelegator.py to colordelegator.py, etc. This is a find-and-replace change. Any shorter, better names for modules can also be made at this time. ---------- components: IDLE messages: 243464 nosy: Al.Sweigart priority: normal severity: normal status: open title: IDLE test filenames don't match script filenames. versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 10:31:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 May 2015 08:31:38 +0000 Subject: [issue20014] Makes array.array constructor accepts ascii-unicode typecode In-Reply-To: <1387360195.98.0.786950742842.issue20014@psf.upfronthosting.co.za> Message-ID: <1431937898.93.0.581000051103.issue20014@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed simplified version. Thank you Vajrasky for your patch. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 10:42:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 May 2015 08:42:45 +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: <1431938565.65.0.982083906808.issue19176@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Then what to do with the discrepancy between Python and C implementations (msg238783)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 11:07:57 2015 From: report at bugs.python.org (Ma Lin) Date: Mon, 18 May 2015 09:07:57 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1431940077.47.0.522248182793.issue24117@psf.upfronthosting.co.za> Ma Lin added the comment: >> I examined all Chinese codecs I said it above, but I forgot Taiwan and HongKong are using Chinese as well. BIG5 and CP950 are using a wrong convert table, test this: >>> u = b'\xC6\xA1'.decode('big5') >>> hex(ord(u)) '0x30fe' This should not happen, 0xC6A1 is neither in BIG5 nor in CP950. In BIG5-2003 and HKSCS-2008, 0xC6A1 is mapped to U+2460. I only had a look roughly, please check more. I won't check HongKong codec anymore, I suggest check it as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 11:17:52 2015 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 18 May 2015 09:17:52 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1431940672.7.0.163669212888.issue24117@psf.upfronthosting.co.za> Ezio Melotti added the comment: > The data come from ICU, Unicode.org, IBM, If you could provide links to the relevant pages/section we can verify that the codecs are indeed incorrect. Also keep in mind that there might people relying on these incorrectness, so we have to be careful while changing them. This is especially true if there are de-facto standards that diverge from the actual standards. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 12:44:13 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 May 2015 10:44:13 +0000 Subject: [issue17239] XML vulnerabilities in Python In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za> Message-ID: <1431945853.17.0.558584725865.issue17239@psf.upfronthosting.co.za> Martin Panter added the comment: I started looking at the lower Expat-level changes. Here are some thoughts, in the order that I thought them. :) But the end result is to investigate a different approach to disable entities in existing versions of Expat. Currently, it looks like max_entity_indirections = 0 is a special value meaning no limit. I think it would be better to use some other value such as None for this, and then 0 could disable all entity expansion (other than pre-defined entities like & &#xNNNN; etc). What is the benefit of having the indirection limit? I would have thought the entity expansion (character) limit on its own would already be effective at preventing nested expansion attacks like ?billion laughs?. Even if the entity expanded to an empty string, all of the intermediate entity references are still included in the character count. I wonder if it would make more sense to have a total character limit instead, which would include the characters from custom entity expansions as already counted by the patch, but also count characters directly from the XML body. Why would you want to avoid 8 million characters from entity expansion, but allow 8 million characters of plain XML (or gzipped XML)? (I am not an XML expert, so I could be missing something obvious here.) Now I have discovered that it seems you can build Python to use an external Expat library, which won?t be affected by Christian?s fix (correct me if I am wrong). I think we should find a different solution that will also work with existing external Expat versions. Maybe setting EntityDeclHandler to raise an error would be good enough: >>> from xml.parsers import expat >>> bomb = '\n\n\n]>\n\n' >>> p = expat.ParserCreate() >>> p.Parse(bomb, True) # Noticeable delay (DOS) while parsing 1 >>> p = expat.ParserCreate() >>> def handler(*so_much_argh): ... raise ValueError("Entity handling disabled") ... >>> p.EntityDeclHandler = handler >>> p.Parse(bomb, True) # Instant failure (no DOS) Traceback (most recent call last): File "", line 1, in File "/build/python/src/Python-3.4.3/Modules/pyexpat.c", line 494, in EntityDecl File "", line 2, in handler ValueError: Entity handling disabled This solution has been suggested and implemented elsewhere: * https://bugzilla.redhat.com/show_bug.cgi?id=1000109#c1 * http://mail-archives.apache.org/mod_mbox/apr-dev/200906.mbox/%3C20090602162934.GA28360 at redhat.com%3E (though I suspect the SetDefaultHandler option there is not sufficient) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 13:57:04 2015 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 18 May 2015 11:57: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: <1431950224.31.0.502254998637.issue19176@psf.upfronthosting.co.za> Eli Bendersky added the comment: I'm not sure. This is why I'm proposing asking on python-dev ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 14:18:38 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 18 May 2015 12:18:38 +0000 Subject: [issue24220] ast.Call signature changed In-Reply-To: <1431893438.07.0.469229426161.issue24220@psf.upfronthosting.co.za> Message-ID: <1431951518.14.0.510559593089.issue24220@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, Matthias. > I can talk to Thomas Kluyver tomorrow about merging green tree snake into the devguide, devguide isn't the correct place for such documentation. > or maybe into ast docs. Would that be useful/more acceptable than linking to external docs ? There is an open issue for that: issue 16544. I've talked to Thomas about merging greentreesnakes to the AST documentation last year and already have a WIP patch at https://gist.github.com/berkerpeksag/0be9bb0ada548185d9ef (I have more complete patch, but couldn't find it now :)) If you have time to work on it, I can upload it to the tracker item and we can work together. ---------- components: -Devguide nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 14:32:32 2015 From: report at bugs.python.org (Matthias Klose) Date: Mon, 18 May 2015 12:32:32 +0000 Subject: [issue24226] [3.5 Regression] unable to byte-compile the attached IN.py Message-ID: <1431952352.93.0.488762661749.issue24226@psf.upfronthosting.co.za> New submission from Matthias Klose: seen while byte-compiling the attached IN.py on x86_64-linux-gnu. $ python3.5 -m py_compile IN.py Sorry: IndentationError: too many levels of indentation (IN.py, line 806) the very same IN.py is accepted by 3.4. ---------- components: Library (Lib) messages: 243472 nosy: doko priority: normal severity: normal status: open title: [3.5 Regression] unable to byte-compile the attached IN.py versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 14:32:54 2015 From: report at bugs.python.org (Matthias Klose) Date: Mon, 18 May 2015 12:32:54 +0000 Subject: [issue24226] [3.5 Regression] unable to byte-compile the attached IN.py In-Reply-To: <1431952352.93.0.488762661749.issue24226@psf.upfronthosting.co.za> Message-ID: <1431952374.63.0.609163214949.issue24226@psf.upfronthosting.co.za> Changes by Matthias Klose : Added file: http://bugs.python.org/file39418/IN.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 14:58:25 2015 From: report at bugs.python.org (Matthias Klose) Date: Mon, 18 May 2015 12:58:25 +0000 Subject: [issue24226] [3.5 Regression] unable to byte-compile the attached IN.py In-Reply-To: <1431952352.93.0.488762661749.issue24226@psf.upfronthosting.co.za> Message-ID: <1431953904.99.0.994677262499.issue24226@psf.upfronthosting.co.za> Matthias Klose added the comment: looks like a parser issue: $ for i in $(seq 200); do echo "def f$i(x): return (x)" >> foo.py; done $ python3.5 -m py_compile foo.py Sorry: IndentationError: too many levels of indentation (foo.py, line 100) $ for i in $(seq 200); do echo "def f$i(x):">>bar.py; echo " return (x)" >> bar.py; done $ python3.5 -m py_compile bar.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 15:05:51 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 18 May 2015 13:05:51 +0000 Subject: [issue20035] Clean up Tcl library discovery in Tkinter on Windows In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za> Message-ID: <1431954351.05.0.944148845707.issue20035@psf.upfronthosting.co.za> Steve Dower added the comment: Use !='true' rather than =='', but otherwise it's good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 15:10:27 2015 From: report at bugs.python.org (Matthias Klose) Date: Mon, 18 May 2015 13:10:27 +0000 Subject: [issue24226] [3.5 Regression] unable to byte-compile the attached IN.py In-Reply-To: <1431952352.93.0.488762661749.issue24226@psf.upfronthosting.co.za> Message-ID: <1431954627.08.0.59167142778.issue24226@psf.upfronthosting.co.za> Matthias Klose added the comment: this seems to be caused by the PEP 492 merge in r95969. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 15:11:06 2015 From: report at bugs.python.org (Matthias Klose) Date: Mon, 18 May 2015 13:11:06 +0000 Subject: [issue24226] [3.5 Regression] unable to byte-compile the attached IN.py In-Reply-To: <1431952352.93.0.488762661749.issue24226@psf.upfronthosting.co.za> Message-ID: <1431954666.75.0.926740383951.issue24226@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- components: +Interpreter Core -Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 15:11:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 May 2015 13:11:26 +0000 Subject: [issue24102] Multiple type confusions in unicode error handlers In-Reply-To: <1430489646.71.0.827069473585.issue24102@psf.upfronthosting.co.za> Message-ID: <20150518131120.32299.84018@psf.io> Roundup Robot added the comment: New changeset 547bc11e3357 by Serhiy Storchaka in branch '2.7': Issue #24102: Fixed exception type checking in standard error handlers. https://hg.python.org/cpython/rev/547bc11e3357 New changeset 68eaa9409818 by Serhiy Storchaka in branch '3.4': Issue #24102: Fixed exception type checking in standard error handlers. https://hg.python.org/cpython/rev/68eaa9409818 New changeset 510819e5855e by Serhiy Storchaka in branch 'default': Issue #24102: Fixed exception type checking in standard error handlers. https://hg.python.org/cpython/rev/510819e5855e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 15:13:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 May 2015 13:13:20 +0000 Subject: [issue24102] Multiple type confusions in unicode error handlers In-Reply-To: <1430489646.71.0.827069473585.issue24102@psf.upfronthosting.co.za> Message-ID: <1431954800.22.0.668029214404.issue24102@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Greg Ewing suggested to use PyObject_TypeCheck (http://permalink.gmane.org/gmane.comp.python.devel/153216). ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 15:13:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 May 2015 13:13:38 +0000 Subject: [issue24102] Multiple type confusions in unicode error handlers In-Reply-To: <1430489646.71.0.827069473585.issue24102@psf.upfronthosting.co.za> Message-ID: <1431954818.64.0.905011553904.issue24102@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 15:22:34 2015 From: report at bugs.python.org (Matthias Bussonnier) Date: Mon, 18 May 2015 13:22:34 +0000 Subject: [issue24220] ast.Call signature changed In-Reply-To: <1431893438.07.0.469229426161.issue24220@psf.upfronthosting.co.za> Message-ID: <1431955354.59.0.235106541659.issue24220@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: > There is an open issue for that: issue 16544. I've talked to Thomas about merging greentreesnakes to the AST documentation last year and already have a WIP patch Ah, Thanks for the link, I see if I can rotate my chair 120deg clockwise and give a nudge to Thomas. I'll probably have a hard time working on that this week, but can try to push it forward to be up to date with 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 15:44:56 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 18 May 2015 13:44:56 +0000 Subject: [issue16544] Add external link to ast docs In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za> Message-ID: <1431956696.41.0.651612375242.issue16544@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 15:46:09 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 18 May 2015 13:46:09 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1431956769.79.0.255704514668.issue23699@psf.upfronthosting.co.za> Stefan Krah added the comment: The problem with this macro is that most of the time it takes the standard cmp return value {-1,0,1} and converts that into a bool. For this use case, it might be more appropriate to use a static inline function Py_cmp_to_bool(). To put it differently, the macro mostly does not perform the actual rich comparison but just post-processes the result. I don't like the dual use of converting cmp() return values and performing actual comparisons on integers, so -1 on the concept. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 16:04:27 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 18 May 2015 14:04:27 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1431956769.79.0.255704514668.issue23699@psf.upfronthosting.co.za> Message-ID: <5559F167.9080609@egenix.com> Marc-Andre Lemburg added the comment: On 18.05.2015 15:46, Stefan Krah wrote: > > Stefan Krah added the comment: > > The problem with this macro is that most of the time it takes the > standard cmp return value {-1,0,1} and converts that into a bool. > > For this use case, it might be more appropriate to use a > static inline function Py_cmp_to_bool(). > > To put it differently, the macro mostly does not perform the > actual rich comparison but just post-processes the result. > > > I don't like the dual use of converting cmp() return values > and performing actual comparisons on integers, so -1 on > the concept. I don't follow you. The macro performs a similar task as that of e.g. Py_RETURN_TRUE/Py_RETURN_FALSE/etc. that is to reduce boilerplate code and in this particular case also to remove potential sources of bugs in both the Python interpreter itself and C extensions written for it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 16:23:57 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 18 May 2015 14:23:57 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1431959037.49.0.0836539278623.issue23699@psf.upfronthosting.co.za> Stefan Krah added the comment: I mean it's clearer to have: result = long_compare(self, other); return Py_cmp_to_bool(result, op); than: result = long_compare(self, other); Py_RETURN_RICHCOMPARE(result, 0, op); This is because in other places, like the proposed use case in https://mail.python.org/pipermail/python-ideas/2015-March/032564.html , the macro actually *performs* the "rich" comparison. In the above case it just *converts* the result of long_compare(). Maybe the distinction does not matter in practice, but I'm not too happy with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 16:34:49 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 18 May 2015 14:34:49 +0000 Subject: [issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za> Message-ID: <1431959689.77.0.442805596676.issue13866@psf.upfronthosting.co.za> Berker Peksag added the comment: Just a suggestion: urlencode already has 5 parameters. We can make quote_via a keyword-only parameter. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 16:51:57 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 May 2015 14:51:57 +0000 Subject: [issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za> Message-ID: <1431960717.57.0.844449551486.issue13866@psf.upfronthosting.co.za> R. David Murray added the comment: I don't see any particular motivation to make it keyword only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 16:54:23 2015 From: report at bugs.python.org (Carol Willing) Date: Mon, 18 May 2015 14:54:23 +0000 Subject: [issue24220] ast.Call signature changed In-Reply-To: <1431893438.07.0.469229426161.issue24220@psf.upfronthosting.co.za> Message-ID: <1431960863.01.0.73731926104.issue24220@psf.upfronthosting.co.za> Carol Willing added the comment: Thanks Berker for pointing out the WIP patch for issue 16544. Issue 16544 seems a better place than this issue for addressing the ast documentation. There does not seem to be any additional action items left on this issue so I recommend closing this issue and moving discussion for ast documentation to Issue 16544. ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 16:55:56 2015 From: report at bugs.python.org (Petr Viktorin) Date: Mon, 18 May 2015 14:55:56 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1431960956.09.0.552237141293.issue23699@psf.upfronthosting.co.za> Petr Viktorin added the comment: Conceptually there's a distinction between the two cases, but you can implement one in terms of the other, so I don't think it's worth adding two functions/macros here. So let's pick the better API. "Py_cmp_to_bool" is better if you already have a cmp-style result. Python code is full of cmp-style results, but I think a big reason is that py2 required them, and (rightly) nobody wants to rewrite the algorithms. I believe the py3 way of passing in the operator is better API. I've seen (a - b) far too many times, which gives the right result in most but *not all* cases. (Think small floats where the difference is coerced to int for the Py_cmp_to_bool function. Or int overflow.) The correct ways to get a cmp-style result are "(a > b) - (a < b)" or "(a < b) ? -1 : (a > b)". Do we want to add a function that requires you to write, read, and understand that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 17:02:39 2015 From: report at bugs.python.org (Carol Willing) Date: Mon, 18 May 2015 15:02:39 +0000 Subject: [issue16544] Add external link to ast docs In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za> Message-ID: <1431961359.49.0.922992067922.issue16544@psf.upfronthosting.co.za> Carol Willing added the comment: Matthias, I've added you to the nosy list for this ast doc enhancements issue. Reference: msg243484 on Issue 24220. ---------- nosy: +mbussonn, willingc versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 17:22:46 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 18 May 2015 15:22:46 +0000 Subject: [issue24227] IndentationError caused by async / await changes in parser Message-ID: <1431962566.65.0.486130789822.issue24227@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: Revision eeeb666a5365 causes "IndentationError: too many levels of indentation" sometimes, e.g. in regenerated IN.py module (e.g. Lib/plat-linux/IN.py). $ ./python -c 'import IN' Traceback (most recent call last): File "", line 1, in File "/tmp/cpython/Lib/plat-linux/IN.py", line 710 def IN6_IS_ADDR_UNSPECIFIED(a): return \ ^ IndentationError: too many levels of indentation I attach regenerated version of Lib/plat-linux/IN.py, which allows to reproduce this problem. (Regeneration was performed by Lib/plat-linux/regen.) I suspect that the problem is in changes in Parser/tokenizer.c. ---------- components: Interpreter Core files: IN.py messages: 243487 nosy: Arfrever, asvetlov, gvanrossum, haypo, ncoghlan, scoder, yselivanov priority: release blocker severity: normal status: open title: IndentationError caused by async / await changes in parser versions: Python 3.5 Added file: http://bugs.python.org/file39419/IN.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 17:24:53 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 May 2015 15:24:53 +0000 Subject: [issue24227] IndentationError caused by async / await changes in parser In-Reply-To: <1431962566.65.0.486130789822.issue24227@psf.upfronthosting.co.za> Message-ID: <1431962693.96.0.687039565606.issue24227@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- assignee: -> yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 17:25:42 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 18 May 2015 15:25:42 +0000 Subject: [issue24227] IndentationError caused by async / await changes in parser In-Reply-To: <1431962566.65.0.486130789822.issue24227@psf.upfronthosting.co.za> Message-ID: <1431962742.14.0.88280996651.issue24227@psf.upfronthosting.co.za> Zachary Ware added the comment: Duplicate of #24226. ---------- nosy: +zach.ware resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> [3.5 Regression] unable to byte-compile the attached IN.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 17:26:45 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 18 May 2015 15:26:45 +0000 Subject: [issue24226] [3.5 Regression] unable to byte-compile the attached IN.py In-Reply-To: <1431952352.93.0.488762661749.issue24226@psf.upfronthosting.co.za> Message-ID: <1431962805.21.0.129767465761.issue24226@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- assignee: -> yselivanov nosy: +Arfrever priority: normal -> release blocker type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 17:34:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 May 2015 15:34:13 +0000 Subject: [issue24091] Use after free in Element.extend (1) In-Reply-To: <1430488567.85.0.132864592859.issue24091@psf.upfronthosting.co.za> Message-ID: <20150518153408.39255.58058@psf.io> Roundup Robot added the comment: New changeset 34523e53a342 by Serhiy Storchaka in branch '2.7': Issue #24091: Fixed various crashes in corner cases in cElementTree. https://hg.python.org/cpython/rev/34523e53a342 New changeset 157c4afca186 by Serhiy Storchaka in branch '3.4': Issue #24091: Fixed various crashes in corner cases in C implementation of https://hg.python.org/cpython/rev/157c4afca186 New changeset a8b8d1b211fe by Serhiy Storchaka in branch 'default': Issue #24091: Fixed various crashes in corner cases in C implementation of https://hg.python.org/cpython/rev/a8b8d1b211fe ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 17:49:39 2015 From: report at bugs.python.org (doz) Date: Mon, 18 May 2015 15:49:39 +0000 Subject: [issue24228] Interpreter triggers segmentation fault at the starting Message-ID: <1431964179.84.0.528825481324.issue24228@psf.upfronthosting.co.za> New submission from doz: Hello, Python 3.4.2 triggers a segmentation fault at the starting on my ARM9 platform. Crash occurs also with 3.3. The version 2.7 don't crash and seems to work correctly System is built with buildroot-2015.02 and gcc 4.2.1. Fault is always reproducible. Please find the following information about the crash and the conditions. Do you know restrictions with old kernel version and python ? On target : # uname -a Linux buildroot 2.6.30.10 #mvl-avb-0.8 Mon May 18 16:02:40 CEST 2015 armv5tejl GNU/Linux # python --version Python 3.4.2 # python Segmentation fault (core dumped) on host, I analyze core dump $ arm-none-linux-gnueabi-gdb -ex 'set sysroot .' -ex 'core-file ./core' usr/bin/python GNU gdb (CodeSourcery Sourcery G++ Lite 2007q3-51) 6.6.50.20070821-cvs Copyright (C) 2007 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi". For bug reporting instructions, please see: . .. Reading symbols from /home/xxx/projects/YYY/buildroot-2015.02/output/target/usr/lib/libpython3.4m.so.1.0...done. Loaded symbols for ./usr/lib/libpython3.4m.so.1.0 Reading symbols from /home/xxx/projects/YYY/buildroot-2015.02/output/target/lib/libpthread.so.0...done. Loaded symbols for ./lib/libpthread.so.0 Reading symbols from /home/xxx/projects/YYY/buildroot-2015.02/output/target/lib/libdl.so.2...done. Loaded symbols for ./lib/libdl.so.2 Reading symbols from /home/xxx/projects/YYY/buildroot-2015.02/output/target/lib/libutil.so.1...done. Loaded symbols for ./lib/libutil.so.1 Reading symbols from /home/xxx/projects/YYY/buildroot-2015.02/output/target/lib/libm.so.6...done. Loaded symbols for ./lib/libm.so.6 Reading symbols from /home/xxx/projects/YYY/buildroot-2015.02/output/target/lib/libc.so.6...done. Loaded symbols for ./lib/libc.so.6 Reading symbols from /home/xxx/projects/YYY/buildroot-2015.02/output/target/lib/libgcc_s.so.1...done. Loaded symbols for ./lib/libgcc_s.so.1 Reading symbols from /home/xxx/projects/YYY/buildroot-2015.02/output/target/lib/ld-linux.so.3...done. Loaded symbols for ./lib/ld-linux.so.3 Core was generated by `python'. Program terminated with signal 11, Segmentation fault. #0 insertdict (mp=0x4041e058, key=0x4041f020, hash=1075606564, value=0x4041d540) at Objects/dictobject.c:824 824 Py_DECREF(old_value); /* which **CAN** re-enter (see issue #22653) */ (gdb) bt #0 insertdict (mp=0x4041e058, key=0x4041f020, hash=1075606564, value=0x4041d540) at Objects/dictobject.c:824 #1 0x400a3be0 in add_subclass (base=, type=0x401c7424) at Objects/typeobject.c:4789 #2 0x400abb18 in PyType_Ready (type=0x401c7424) at Objects/typeobject.c:4745 #3 0x40094534 in _Py_ReadyTypes () at Objects/object.c:1546 #4 0x40116aec in _Py_InitializeEx_Private (install_sigs=1, install_importlib=1) at Python/pythonrun.c:382 #5 0x401263a8 in Py_Main (argc=1076832428, argv=0x11008) at Modules/main.c:654 #6 0x000088f4 in main (argc=1, argv=0x402fb844) at ./Modules/python.c:69 (gdb) info locals old_value = (PyObject *) 0x1 value_addr = (PyObject **) 0x400a3be0 ep = (PyDictKeyEntry *) 0x11390 (gdb) list 819 MAINTAIN_TRACKING(mp, key, value); 820 old_value = *value_addr; 821 if (old_value != NULL) { 822 assert(ep->me_key != NULL && ep->me_key != dummy); 823 *value_addr = value; 824 Py_DECREF(old_value); /* which **CAN** re-enter (see issue #22653) */ 825 } 826 else { 827 if (ep->me_key == NULL) { 828 Py_INCREF(key); ./arm-none-linux-gnueabi-gcc --version arm-none-linux-gnueabi-gcc (CodeSourcery Sourcery G++ Lite 2007q3-51) 4.2.1 Copyright (C) 2007 Free Software Foundation, Inc. Thank your for your help ---------- components: Interpreter Core messages: 243490 nosy: mdootb priority: normal severity: normal status: open title: Interpreter triggers segmentation fault at the starting type: crash versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 17:51:59 2015 From: report at bugs.python.org (doz) Date: Mon, 18 May 2015 15:51:59 +0000 Subject: [issue24228] Interpreter triggers segmentation fault at the starting In-Reply-To: <1431964179.84.0.528825481324.issue24228@psf.upfronthosting.co.za> Message-ID: <1431964319.77.0.684596198614.issue24228@psf.upfronthosting.co.za> doz added the comment: I already try to apply patches from http://bugs.python.org/issue22653 . It don't solve problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 17:54:13 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 18 May 2015 15:54:13 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1431964453.28.0.566532591344.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks for taking a look, Yury. I'll follow up on the ref leak soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 18:18:28 2015 From: report at bugs.python.org (Ethan Furman) Date: Mon, 18 May 2015 16:18:28 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1431965908.49.0.0640213475824.issue24195@psf.upfronthosting.co.za> Ethan Furman added the comment: I'd rather see an `Executor.filter()` myself, but it's Brian Quinlan's call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 18:35:14 2015 From: report at bugs.python.org (Josh Holland) Date: Mon, 18 May 2015 16:35:14 +0000 Subject: [issue24229] pathlib.Path should have a copy() method Message-ID: <1431966913.98.0.0205729823841.issue24229@psf.upfronthosting.co.za> New submission from Josh Holland: Path objects already have rename() and replace() methods; it would be useful for them also to have a copy() method to simplify that operation. I'll look into putting a patch together this evening. ---------- components: Library (Lib) messages: 243494 nosy: jshholland priority: normal severity: normal status: open title: pathlib.Path should have a copy() method type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 18:37:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 May 2015 16:37:25 +0000 Subject: [issue24229] pathlib.Path should have a copy() method In-Reply-To: <1431966913.98.0.0205729823841.issue24229@psf.upfronthosting.co.za> Message-ID: <1431967045.14.0.191985775217.issue24229@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Path objects are immutable, so the copy method is not needed. ---------- nosy: +pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 18:51:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 May 2015 16:51:00 +0000 Subject: [issue24226] [3.5 Regression] unable to byte-compile the attached IN.py In-Reply-To: <1431952352.93.0.488762661749.issue24226@psf.upfronthosting.co.za> Message-ID: <20150518165056.44683.27473@psf.io> Roundup Robot added the comment: New changeset fb5fcae0cf1f by Yury Selivanov in branch 'default': Issue 24226: Fix parsing of many sequential one-line 'def' statements. https://hg.python.org/cpython/rev/fb5fcae0cf1f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 18:52:42 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 May 2015 16:52:42 +0000 Subject: [issue24226] [3.5 Regression] unable to byte-compile the attached IN.py In-Reply-To: <1431952352.93.0.488762661749.issue24226@psf.upfronthosting.co.za> Message-ID: <1431967962.52.0.775380163424.issue24226@psf.upfronthosting.co.za> Yury Selivanov added the comment: Arfrever, Matthias, Thanks for reporting this issue. It should now be fixed. Please verify that it works for your usecase. ---------- nosy: +gvanrossum, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 19:04:54 2015 From: report at bugs.python.org (Augie Fackler) Date: Mon, 18 May 2015 17:04:54 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths Message-ID: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> New submission from Augie Fackler: Many things in the OS module work with bytestrings for paths in Python 3, but tempfile isn't so happy. It'd be very useful to be able to have the same bytes-in-bytes-out behavior in tempfile as for the os.path.* methods. This is something we're working around in hg, but I figured I'd file a bug anyway in case we can improve the situation. ---------- components: Library (Lib) messages: 243498 nosy: durin42 priority: normal severity: normal status: open title: tempfile.mkdtemp() doesn't work with bytes paths versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 19:17:06 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Mon, 18 May 2015 17:17:06 +0000 Subject: [issue16544] Add external link to ast docs In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za> Message-ID: <1431969426.4.0.0713235885732.issue16544@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Here's a simple patch that links to Green Tree Snakes from the ast module docs, using the 'sidebar' directive (that's what the logging module uses to link to tutorials, which seemed analogous). I'm still happy to contribute these docs to CPython if people want that, but I'm also happy to keep maintaining them as a separate resource. I can see advantages to both approaches. ---------- keywords: +patch Added file: http://bugs.python.org/file39420/link-gts.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 19:21:01 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 May 2015 17:21:01 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1431969661.61.0.0872250007542.issue24230@psf.upfronthosting.co.za> R. David Murray added the comment: Can you explain what you are looking for in more detail? It isn't obvious to me what "bytes in bytes out" means in the context of the tempfile API. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 19:23:41 2015 From: report at bugs.python.org (Matthew Wedgwood) Date: Mon, 18 May 2015 17:23:41 +0000 Subject: [issue24231] os.makedirs('/', exist_ok=True) fails on Darwin Message-ID: <1431969821.39.0.237201791785.issue24231@psf.upfronthosting.co.za> New submission from Matthew Wedgwood: On Darwin, os.mkdir('/') raises IsADirectory. On Linux, the same call raises FileExistsError. The implementation for os.makedirs() in Python 3.2+ checks only for the latter when evaluating the exists_ok parameter. This causes os.makedirs('/', exist_ok=True) to fail on Darwin but succeed on Linux. ---------- components: Library (Lib) messages: 243501 nosy: mew priority: normal severity: normal status: open title: os.makedirs('/', exist_ok=True) fails on Darwin type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 19:24:35 2015 From: report at bugs.python.org (Augie Fackler) Date: Mon, 18 May 2015 17:24:35 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1431969875.78.0.69349173215.issue24230@psf.upfronthosting.co.za> Augie Fackler added the comment: Today we're doing something like this: tmpdir = tempfile.mkdtemp('', 'hgtests.', d and d.decode('utf-8')).encode('utf-8') but would rather have tmpdir = tempfile.mkdtemp(b'', b'hgtests.', d) # and now tmpdir is a bytestring containing the path to the tmpdir basically, we want to maintain our pedantry around paths being sequences of bytes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 19:27:54 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 18 May 2015 17:27:54 +0000 Subject: [issue24226] [3.5 Regression] unable to byte-compile the attached IN.py In-Reply-To: <1431952352.93.0.488762661749.issue24226@psf.upfronthosting.co.za> Message-ID: <1431970074.38.0.384747728301.issue24226@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: This change works for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 19:28:41 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 May 2015 17:28:41 +0000 Subject: [issue24226] [3.5 Regression] unable to byte-compile the attached IN.py In-Reply-To: <1431952352.93.0.488762661749.issue24226@psf.upfronthosting.co.za> Message-ID: <1431970121.12.0.559422431969.issue24226@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks! Closing the issue. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 19:31:07 2015 From: report at bugs.python.org (Matt Mackall) Date: Mon, 18 May 2015 17:31:07 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1431970267.57.0.860561339991.issue24230@psf.upfronthosting.co.za> Matt Mackall added the comment: Another way of putting it is: os.listdir() -> [,...] os.listdir() -> [,...] is the usual pattern, and tempfile isn't following it. ---------- nosy: +Matt.Mackall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 19:31:13 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 May 2015 17:31:13 +0000 Subject: [issue24231] os.makedirs('/', exist_ok=True) fails on Darwin In-Reply-To: <1431969821.39.0.237201791785.issue24231@psf.upfronthosting.co.za> Message-ID: <1431970273.08.0.890117440991.issue24231@psf.upfronthosting.co.za> R. David Murray added the comment: This should (in theory at least) be something we test in our test suite, so I'm surprised by this result. If you run the test suite do you get any failures? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 19:33:38 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 May 2015 17:33:38 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1431970418.98.0.972136199072.issue24230@psf.upfronthosting.co.za> R. David Murray added the comment: I understand now. The problem is that this would be a backward incompatible change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 19:35:13 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 May 2015 17:35:13 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1431970513.64.0.952640162327.issue24230@psf.upfronthosting.co.za> R. David Murray added the comment: I'm sorry, hit send before I finished thinking. You are saying bytes input are rejected, so yes this could be fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 19:37:50 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 May 2015 17:37:50 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1431970670.25.0.168527412298.issue24230@psf.upfronthosting.co.za> R. David Murray added the comment: Would you care to supply a patch? The beta deadline is this coming weekend. ---------- stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 19:45:25 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 18 May 2015 17:45:25 +0000 Subject: [issue10685] trace does not ignore --ignore-module In-Reply-To: <1292157270.73.0.200325030661.issue10685@psf.upfronthosting.co.za> Message-ID: <1431971125.9.0.756741388967.issue10685@psf.upfronthosting.co.za> Terry J. Reedy added the comment: (When replying by email to an email, please remove any quotation, except possibly for a specific line or two. The message already appears about yours on the tracker.) Good. It will take about a week for the * to appear after your name. As the diff is posted, hg could not find trace.py to patch. Changing --- Lib/trace.py Fri Feb 24 15:58:24 2012 +++ Lib/trace.py Wed Oct 30 16:35:49 2013 --- a/Lib/trace.py Fri Feb 24 15:58:24 2012 +++ b/Lib/trace.py Wed Oct 30 16:35:49 2013 fixed that problem, and 3/4 chunks apply to 3.4 (map has already been replaced). Running test/test_trace.py (with repository 3.4) gives the same errors as without the patch. The changes look sensible. However, a test is needed that fails without the patch and passes with it. Can you write one that could be added to the test file, or at least pieces of a test and a manual test procedure? ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 20:02:20 2015 From: report at bugs.python.org (Ismail Donmez) Date: Mon, 18 May 2015 18:02:20 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1431972140.53.0.928896591257.issue4709@psf.upfronthosting.co.za> Ismail Donmez added the comment: Still a problem with mingw-w64 gcc 5.1 and Python 3.4.3, time to fix this? ---------- nosy: +cartman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 20:16:27 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 18 May 2015 18:16:27 +0000 Subject: [issue24231] os.makedirs('/', exist_ok=True) fails on Darwin In-Reply-To: <1431969821.39.0.237201791785.issue24231@psf.upfronthosting.co.za> Message-ID: <1431972987.54.0.681505202227.issue24231@psf.upfronthosting.co.za> Ned Deily added the comment: This appears to be a BSD-ism: I get the same result on FreeBSD 10 as with OS X 10.10. For whatever reason, mkdir('/') returns IsADirectoryError while mkdir('/other/existing/directory') returns FileExistsError. ---------- nosy: +ned.deily stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 20:34:38 2015 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 18 May 2015 18:34:38 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1431974078.32.0.734930152265.issue4709@psf.upfronthosting.co.za> Ralf Schmitt added the comment: Well, the time to fix this would have been six years ago. The python core developers have shown a disinterest to fix problems with gcc on windows for a rather long time. I wouldn't expect this issue to be fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 20:41:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 May 2015 18:41:32 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1431974492.56.0.782365705021.issue22107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added os.path.isdir(). Could anybody please run tests on Windows? ---------- Added file: http://bugs.python.org/file39421/tempfile_bad_tempdir_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 20:45:40 2015 From: report at bugs.python.org (Paul Moore) Date: Mon, 18 May 2015 18:45:40 +0000 Subject: [issue24229] pathlib.Path should have a copy() method In-Reply-To: <1431966913.98.0.0205729823841.issue24229@psf.upfronthosting.co.za> Message-ID: <1431974740.52.0.771253573551.issue24229@psf.upfronthosting.co.za> Paul Moore added the comment: I presume the copy method is intended as a file copy, not for copying the object. But calling the method copy() is likely to be confusing, precisely as happened here :-) ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 20:50:30 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 18 May 2015 18:50:30 +0000 Subject: [issue23377] HTTPResponse may drop buffer holding next response In-Reply-To: <1422881776.12.0.998068930599.issue23377@psf.upfronthosting.co.za> Message-ID: <1431975030.18.0.923212405507.issue23377@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Is this pending a review? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 20:51:24 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 18 May 2015 18:51:24 +0000 Subject: [issue24229] pathlib.Path should have a copy() method In-Reply-To: <1431966913.98.0.0205729823841.issue24229@psf.upfronthosting.co.za> Message-ID: <1431975084.45.0.40153812156.issue24229@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If copy() has a mandatory argument, it can't really be mixed up with an object-cloning method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 20:53:16 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 18 May 2015 18:53:16 +0000 Subject: [issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1431975196.79.0.839176321468.issue12319@psf.upfronthosting.co.za> Antoine Pitrou added the comment: What's the status on this one? It looks like some review comments need addressing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 20:55:31 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 May 2015 18:55:31 +0000 Subject: [issue24205] signature.bind error messages are sub-optimal In-Reply-To: <1431733733.27.0.866799524337.issue24205@psf.upfronthosting.co.za> Message-ID: <1431975331.42.0.580475755375.issue24205@psf.upfronthosting.co.za> Yury Selivanov added the comment: Hi David, Please see the attached patch. It doesn't make Signature.bind() exceptions look exactly like system messages, but it's now much closer. ---------- keywords: +patch Added file: http://bugs.python.org/file39422/sig_exc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 20:55:36 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 May 2015 18:55:36 +0000 Subject: [issue24205] signature.bind error messages are sub-optimal In-Reply-To: <1431733733.27.0.866799524337.issue24205@psf.upfronthosting.co.za> Message-ID: <1431975336.66.0.543137753709.issue24205@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- assignee: -> yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 21:03:04 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 May 2015 19:03:04 +0000 Subject: [issue24231] os.makedirs('/', exist_ok=True) fails on Darwin In-Reply-To: <1431969821.39.0.237201791785.issue24231@psf.upfronthosting.co.za> Message-ID: <1431975784.59.0.914293440337.issue24231@psf.upfronthosting.co.za> R. David Murray added the comment: Ah! That's why our tests don't catch it. Is it limited to '/', or is it any (mounted) mount point? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 21:07:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 May 2015 19:07:50 +0000 Subject: [issue24229] pathlib.Path should have a copy() method In-Reply-To: <1431966913.98.0.0205729823841.issue24229@psf.upfronthosting.co.za> Message-ID: <1431976070.22.0.780406677166.issue24229@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: File renaming is simple and usually atomic operation. File copying is complex operation. What memory buffer should be used for copying? What to do with growing files or reading with errors? Should file space be preallocated before copyiong to decrease fragmentation? How handle sparse files? Can be optimized copyiong on file systems with compression? What to do with NT streams? What to do with extended attributes? What to do with directories, links and other special files? I think that pathlib is not good place for this function (as well as for handling ZIP files or playing multimedia). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 21:08:30 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 18 May 2015 19:08:30 +0000 Subject: [issue24228] Interpreter triggers segmentation fault at the starting In-Reply-To: <1431964179.84.0.528825481324.issue24228@psf.upfronthosting.co.za> Message-ID: <1431976110.75.0.893511039473.issue24228@psf.upfronthosting.co.za> Ned Deily added the comment: Try building python with debug on: ./configure --with-pydebug [...] Also, 3.4.2 has been replaced by 3.4.3 which includes the fixes from Issue22653. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 21:14:25 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 18 May 2015 19:14:25 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <1431976465.74.0.881850196795.issue15027@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: In Objects/stringlib/codecs.h in 2 comments U+DC800 should be changed into U+D800 (from definition of Py_UNICODE_IS_SURROGATE) or U+DC80 (from result of b"\x80".decode(errors="surrogateescape")). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 21:22:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 May 2015 19:22:44 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <1431976964.04.0.579494947042.issue15027@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Arfrever. That was copy-pasted old typo. Fixed in 3d5bf6174c4b and bc6ed8360312. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 21:37:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 May 2015 19:37:52 +0000 Subject: [issue24222] Idle 2.7 -c, -r compile with print as function. In-Reply-To: <1431911987.88.0.560675260792.issue24222@psf.upfronthosting.co.za> Message-ID: <20150518193749.26854.45278@psf.io> Roundup Robot added the comment: New changeset cebd51686565 by Terry Jan Reedy in branch '2.7': Issue #24222: Fix regression introduced with idlelib/PyShell.py future print https://hg.python.org/cpython/rev/cebd51686565 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 21:38:30 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 18 May 2015 19:38:30 +0000 Subject: [issue24222] Idle 2.7 -c, -r compile with print as function. In-Reply-To: <1431911987.88.0.560675260792.issue24222@psf.upfronthosting.co.za> Message-ID: <1431977910.07.0.139383427951.issue24222@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I added "from __future__ import print_function" to 2.7 PyShell when I backported the bugfix of #22420. The use of print rather than write is part of the fix as print is more fault tolerant. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 21:42:26 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 18 May 2015 19:42:26 +0000 Subject: [issue24231] os.makedirs('/', exist_ok=True) fails on Darwin In-Reply-To: <1431969821.39.0.237201791785.issue24231@psf.upfronthosting.co.za> Message-ID: <1431978146.71.0.582296525595.issue24231@psf.upfronthosting.co.za> Ned Deily added the comment: It doesn't seem to be true for other mount points; the ones I tried raise FileExistsError. I suppose one could dig into the OS sources. I see that none of the FreeBSD or OS X mkdir man pages nor the POSIX 2013 spec document EISDIR as an expected error from mkdir(2) so one could argue it's an implementation bug. It is a somewhat unusual case, though, as I doubt you would ever run into a situation where you really needed to create '/' from a process :=) Still ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 21:46:35 2015 From: report at bugs.python.org (Christie) Date: Mon, 18 May 2015 19:46:35 +0000 Subject: [issue18576] Document test.support.script_helper In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za> Message-ID: <1431978395.54.0.279465078265.issue18576@psf.upfronthosting.co.za> Christie added the comment: I'm going to take a look at bringing these docs up to date and including the changes from issue24033. ---------- nosy: +bobcatfish _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 21:53:27 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 18 May 2015 19:53:27 +0000 Subject: [issue24222] Idle 2.7 -c, -r compile with print as function. In-Reply-To: <1431911987.88.0.560675260792.issue24222@psf.upfronthosting.co.za> Message-ID: <1431978807.94.0.352012961489.issue24222@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This trivial patch fixes a regression I introduced in 2.7.9. It would be nice if you could pull it into the .10 release. (I would not ask if it were not a recent regression.) ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 22:14:14 2015 From: report at bugs.python.org (Christie) Date: Mon, 18 May 2015 20:14:14 +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: <1431980054.94.0.609741406948.issue15376@psf.upfronthosting.co.za> Christie added the comment: @BreamoreBoy, it looks like the next step would be to revisit issue15403 and go through the steps outlined by @ncoghlan. ---------- nosy: +bobcatfish _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 22:15:54 2015 From: report at bugs.python.org (Paul Moore) Date: Mon, 18 May 2015 20:15:54 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1431980154.7.0.196301555148.issue4709@psf.upfronthosting.co.za> Paul Moore added the comment: Supporting mingw building of extensions has always been a complicated process, mainly because there appear to be many variants of mingw (and in particular, there seem to be multiple 64-bit builds). Add to this the fact that cygwin is sometimes used as a cross-compiler (often using the same code in distutils) and it's hard to know what to support, or what will break. I would be very happy to see support for building of Python extensions using mingw (even though I use MSVC myself). However, in order for core Python to have a stable target to aim at, I believe the users of mingw need to work to provide an easy to use, unified platform that can be the target for core support. I think the following would go a long way to giving the core developers (specifically me, I'd be willing to work on the core end of things to improve the situation) a chance of providing maintained support for using mingw as an alternative compiler for building Python extensions on Windows: 1. A well-documented and maintained process for setting up 32-bit and 64-bit mingw environments which can be used to build Python extensions. These need to use stable, well-maintained builds of mingw - ones that can be relied on to remain available in the long term (the links to equation.com and the Scipy instructions in this issue are now dead, for example, and both TDM and Mingw-W64 have been mentioned as toolchains, but it's not practical to try to support both - by support I mean at least that "some core developer installs them both and checks that things work"). Documentation patches to explain how to set up the official mingw build environment (once the community has agreed what it is) can be submitted to the packaging.python.org tracker. 2. Python 3.5 will be built using the MSVC 2015 "Universal CRT". From what I've seen on the mingw lists, there seem to be no plans for mingw to support this CRT in any form. Without that support, it's not clear to me how mingw builds for Python 3.5 will be possible, so the mingw community needs to work out how they will provide a solution for Python 3.5. Timely solutions for issues like this are needed if mingw is to be a supported build environment going forward. While it's understandable that the mingw community hasn't had much encouragement to work on things like this in the past, it is something that needs to change if full core Python support is to happen. So that's the position, really. If the mingw community can come up with an "official" mingw distribution that supports building extensions for Python 32 and 64 bit, including for 3.5+, I will look at how we ensure that distutils supports that distribution going forward (that will likely mean *dropping* support for other mingw builds at some point). I know the Scientific Python users make a lot of use of mingw for builds, so maybe their standard build environment is a good target to aim for. Bluntly, I'm not sure the community can achieve the above. It's a pretty hard goal, and lots of people have been working on it for a long time. But that's precisely why the core developers can't offer much in the way of support for mingw - it's too much of an unstable target as things stand. (Note for example, that I currently have *three* mingw 64-bit installations on my PC, and they all work slightly differently - to the extent that I have projects that I can *only* build with particular ones). With regard to this specific patch, it seems that according to msg132798 it's easy enough to work around the issue by manually defining the symbol. The patch seems to apply cleanly, still, but I'm not aware if it has been tested on cygwin, for example. So, like Martin, I'm reluctant to apply it just because it *looks* harmless. Particularly this close to the 3.5 beta deadline. ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 22:27:39 2015 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 18 May 2015 20:27:39 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1431980859.75.0.254268308827.issue4709@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: For what it's worth I dropped support for mingw32 in psutil for exact the same reasons. As such I cannot imagine how hard could it be to add and maintain support for mingw in a much larger project as Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 22:41:05 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 18 May 2015 20:41:05 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1431981665.27.0.128311330535.issue4709@psf.upfronthosting.co.za> Mark Lawrence added the comment: Hunting around I found this on #3871 https://mail.python.org/pipermail/python-dev/2013-January/123774.html. >From #17590 upwards there are perhaps 25 issues with mingw in the title, so there's certainly work to be done. Please don't look at me, I'm simply not interested. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 22:51:08 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 May 2015 20:51:08 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1431982268.68.0.0281159374209.issue4709@psf.upfronthosting.co.za> R. David Murray added the comment: Please note that Paul is pretty new to the core team, and is a crossover with the packaging folks (which is mainly where the mingw issues lie). What this means to the mingw community is that with Paul on the core team and willing to work on the support, the mingw users have the best chance they've ever had of making progress on this. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 23:07:47 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 18 May 2015 21:07:47 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1431983267.54.0.397359115759.issue4709@psf.upfronthosting.co.za> Mark Lawrence added the comment: Does this mean scarce Windows resources being diverted off to what I consider a side show? Unless it's categorically stated that mingw is officially supported in which case fine, provided the experts index and everything else associated with official support is updated accordingly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 23:14:43 2015 From: report at bugs.python.org (Ralf Schmitt) Date: Mon, 18 May 2015 21:14:43 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1431983683.74.0.843331460536.issue4709@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: -schmir _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 23:28:40 2015 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Mon, 18 May 2015 21:28:40 +0000 Subject: [issue24232] Speling fixes Message-ID: <1431984520.8.0.717388899903.issue24232@psf.upfronthosting.co.za> New submission from Ville Skytt?: Various doc spelling fixes in the attached patch. ---------- assignee: docs at python components: Documentation files: spelling.patch keywords: patch messages: 243536 nosy: docs at python, scop priority: normal severity: normal status: open title: Speling fixes type: enhancement Added file: http://bugs.python.org/file39423/spelling.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 23:35:44 2015 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Mon, 18 May 2015 21:35:44 +0000 Subject: [issue24233] Link to getfqdn rather than "see above" Message-ID: <1431984944.05.0.247984271227.issue24233@psf.upfronthosting.co.za> New submission from Ville Skytt?: Would be nice to link to getfqdn() instead of saying "see above" for it in socket.gethostname() docs. ---------- assignee: docs at python components: Documentation files: getfqdnlink.patch keywords: patch messages: 243537 nosy: docs at python, scop priority: normal severity: normal status: open title: Link to getfqdn rather than "see above" type: enhancement Added file: http://bugs.python.org/file39424/getfqdnlink.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 23:37:35 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 18 May 2015 21:37:35 +0000 Subject: [issue24234] Should we define complex.__complex__ and bytes.__bytes__? Message-ID: <1431985055.48.0.760233282847.issue24234@psf.upfronthosting.co.za> New submission from Guido van Rossum: The special methods __complex__ and __bytes__ are not present on the corresponding builtin types. Compare this to __int__ and __float__, which do exist on int and float, respectively. Should we add the eponymous methods to complex and bytes? (This came up in the context of PEP 484: https://github.com/ambv/typehinting/issues/68#issuecomment-88130156 ) ---------- messages: 243538 nosy: gvanrossum priority: normal severity: normal status: open title: Should we define complex.__complex__ and bytes.__bytes__? versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 23:38:23 2015 From: report at bugs.python.org (Paul Moore) Date: Mon, 18 May 2015 21:38:23 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1431985103.67.0.374819324801.issue4709@psf.upfronthosting.co.za> Paul Moore added the comment: Not at all. Mingw support is important for the scientific community, as I understand it, and I'm willing to help there if I can. That won't be at the cost of other areas I can contribute to, but I consider packaging as much my area of expertise as Windows - and mingw support covers both of those areas. To give some background, I was involved in adding mingw support for the MSVC 2010 builds of Python, which involved working with the mingw project on getting -lmsvcr100 support added. That was a battle, and I fully expect universal CRT support to be even harder[1]. I do *not* expect to get involved in that, but as I said, I do want it (along with a single mingw distribution blessed by the Python mingw user community) as a prerequisite for a higher level of core support. That's (IMO) a *very* high bar, and I don't expect it to be easy for the mingw-using community to achieve it. But if they do, then the amount of effort involves deserves some recognition, and for my part I am offering some of my time improving core Python support on that basis. [1] For example, AIUI, with the universal CRT, even the header definitions change - e.g., FILE* is not based on an _iob symbol - so you have to know the target CRT at *compile* time, not just at link time. That's an additional level of complexity not present in previous CRT releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 23:48:56 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Mon, 18 May 2015 21:48:56 +0000 Subject: [issue24235] ABCs don't fail metaclass instantiation Message-ID: <1431985736.79.0.831498694265.issue24235@psf.upfronthosting.co.za> New submission from Devin Jeanpierre: If a subclass has abstract methods, it fails to instantiate... unless it's a metaclass, and then it succeeds. >>> import abc >>> class A(metaclass=abc.ABCMeta): ... @abc.abstractmethod ... def foo(self): pass ... >>> class B(A): pass ... >>> B() Traceback (most recent call last): File "", line 1, in TypeError: Can't instantiate abstract class B with abstract methods foo >>> class C(A, type): pass ... >>> class c(metaclass=C): pass ... >>> C('', (), {}) >>> ---------- components: Library (Lib) messages: 243540 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: ABCs don't fail metaclass instantiation versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 18 23:50:01 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 18 May 2015 21:50:01 +0000 Subject: [issue5233] IDLE: exec IDLESTARTUP/PYTHONSTARTUP on restart In-Reply-To: <1234478082.8.0.463106292983.issue5233@psf.upfronthosting.co.za> Message-ID: <1431985801.28.0.0280479666335.issue5233@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Related issue #22893 is about __future__ statements in startup code having effect on future interactive input in the same way as it does with Python itself. I think a pure Shell start/restart (cntl-F6) should be handled separately from a restart that is a side-effect of running an editor file. There is a separate proposal to specify an individual file's startup condition (sys.args + STARTUP file). For Shell restart, a possible reason might be to get rid of the effect of a STARTUP file. Since ^F6 is rarely used (I think), asking whether to include the STARTUP might not be too intrusive. I think default behaviors should follow Python, though we can add more. On the other hand, Python has startup options not currently available with Idle. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 00:31:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 May 2015 22:31:26 +0000 Subject: [issue24233] Link to getfqdn rather than "see above" In-Reply-To: <1431984944.05.0.247984271227.issue24233@psf.upfronthosting.co.za> Message-ID: <20150518223123.10806.50452@psf.io> Roundup Robot added the comment: New changeset f6e7953b5431 by Berker Peksag in branch '3.4': Issue #24233: Add a proper link to socket.getfqdn() documentation. https://hg.python.org/cpython/rev/f6e7953b5431 New changeset 0d6902537062 by Berker Peksag in branch 'default': Issue #24233: Add a proper link to socket.getfqdn() documentation. https://hg.python.org/cpython/rev/0d6902537062 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 00:33:04 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 18 May 2015 22:33:04 +0000 Subject: [issue24233] Link to getfqdn rather than "see above" In-Reply-To: <1431984944.05.0.247984271227.issue24233@psf.upfronthosting.co.za> Message-ID: <1431988384.06.0.704953489411.issue24233@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Ville. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 00:38:06 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 May 2015 22:38:06 +0000 Subject: [issue24232] Speling fixes In-Reply-To: <1431984520.8.0.717388899903.issue24232@psf.upfronthosting.co.za> Message-ID: <20150518223803.26840.84987@psf.io> Roundup Robot added the comment: New changeset fd7ef3972215 by Berker Peksag in branch '3.4': Issue #24232: Fix typos. Patch by Ville Skytt?. https://hg.python.org/cpython/rev/fd7ef3972215 New changeset fc2eed9fc2d0 by Berker Peksag in branch 'default': Issue #24232: Fix typos. Patch by Ville Skytt?. https://hg.python.org/cpython/rev/fc2eed9fc2d0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 00:39:10 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 18 May 2015 22:39:10 +0000 Subject: [issue24232] Speling fixes In-Reply-To: <1431984520.8.0.717388899903.issue24232@psf.upfronthosting.co.za> Message-ID: <1431988750.77.0.749258009915.issue24232@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Ville. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 00:40:03 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 18 May 2015 22:40:03 +0000 Subject: [issue22893] Idle: __future__ does not work in startup code. In-Reply-To: <1416261777.24.0.465929106454.issue22893@psf.upfronthosting.co.za> Message-ID: <1431988803.79.0.357427350878.issue22893@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Easy test case using -c: \python_d.exe -m idlelib.idle -c "from __future__ import division; print(1/2)" >>> 0.5 >>> 1/2 0 >>> division _Feature((2, 2, 0, 'alpha', 2), (3, 0, 0, 'alpha', 0), 8192) Replace "-m idlelib.idle" with "-i" to get interactive interpreter and >>> 1/2 is .5 instead of 0. --- Implementation of -s in PyShell.py if o == '-s': startup = True # line 1504 if startup: # line 1586 filename = ... if filename ... ... execfile(filename) execfile (line 650) is the same method used to run -c and -r code. After compiling code, it calls runcode (779). That normally sends the code to the user process, but may run code in the debugger or in the idle process. When the future import is run, it is just an import and not also a 'from __future__' statement. Editor files are compiled in ScriptBinding.ScriptBinding.checksyntax. This is why not affected by __future__ import in PyShell (#24222). Run_module_event calls (interp.)runcode, as above. I believe Shell input is run by .runsource, which is called by .runit, which is called when appropriate by the callback. .runsource in turn calls the base class method code.InteractiveInterpreter.runsource, which uses 'self.compile', which is an instance of codeop.CommandCompiler. codeop.CommandCompiler indirectly uses 'self.compiler', which is an instance of codeop.Compiler. The latter is what actually calls the builtin function compile, with self.flags (futures imported), it updates self.flags from the flags in the code returned by compile. So I believe the solution is for the ExtendedInterpreter instance to get a reference to the Compiler instance, after InteractiveInterpreter is initialized, and call that, with symbol='exec' instead of 'single', instead of calling compile directly. A reason not to use the same pipeline as for statements enter interactively is that there is extra code to account for the possibility of compiling correct partial statements. "while True:\n" is not an error at a prompt, since more may follow, but is as a complete code string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 00:46:45 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 May 2015 22:46:45 +0000 Subject: [issue19737] Documentation of globals() and locals() should be improved In-Reply-To: <1385225461.09.0.671908077084.issue19737@psf.upfronthosting.co.za> Message-ID: <1431989205.17.0.292186665596.issue19737@psf.upfronthosting.co.za> Martin Panter added the comment: Terry?s ?dictionary implementing the namespace? version would work for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 01:53:15 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 May 2015 23:53:15 +0000 Subject: [issue24205] signature.bind error messages are sub-optimal In-Reply-To: <1431733733.27.0.866799524337.issue24205@psf.upfronthosting.co.za> Message-ID: <1431993195.51.0.182651401834.issue24205@psf.upfronthosting.co.za> Martin Panter added the comment: I think the patch is okay. Just beware that next(iter(kwargs)) can return different names if there is more than one unexpected argument, so the error message could vary. But it looks like the test cases are only when there is exactly one extra argument, so no problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 02:12:53 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 19 May 2015 00:12:53 +0000 Subject: [issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za> Message-ID: <1431994373.77.0.472088854666.issue13866@psf.upfronthosting.co.za> Martin Panter added the comment: Forcing the ?quote_via? keyword wouldn?t help that much. I suggest to leave it as it is. urlencode(query, True, "/", "ascii", "strict", quote) urlencode(query, True, "/", "ascii", "strict", quote_via=quote) On the other hand, forcing a keyword for the ?doseq=True? flag would encourage easier-to-read code, but that ship has already bolted :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 02:20:11 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 19 May 2015 00:20:11 +0000 Subject: [issue23377] HTTPResponse may drop buffer holding next response In-Reply-To: <1422881776.12.0.998068930599.issue23377@psf.upfronthosting.co.za> Message-ID: <1431994811.55.0.672855853602.issue23377@psf.upfronthosting.co.za> Martin Panter added the comment: Yes I would like someone to review my code changes for this; I don?t think anyone has done so yet. But I don?t consider this a very important bug, so there is no hurry. ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 02:48:10 2015 From: report at bugs.python.org (Aki Sasaki) Date: Tue, 19 May 2015 00:48:10 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1431996490.59.0.653568150705.issue1602@psf.upfronthosting.co.za> Changes by Aki Sasaki : ---------- nosy: +escapewindow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 03:08:03 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 19 May 2015 01:08:03 +0000 Subject: [issue10354] tempfile.template is broken In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za> Message-ID: <1431997683.8.0.21738390192.issue10354@psf.upfronthosting.co.za> Gregory P. Smith added the comment: backwards compatibility with what? i'd like to just remove tempfile.template in 3.5 as part of addressing issue24230. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 03:08:12 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 19 May 2015 01:08:12 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1431997692.29.0.758725889685.issue24230@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 03:25:16 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 19 May 2015 01:25:16 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1431998716.85.0.34569339432.issue24230@psf.upfronthosting.co.za> Gregory P. Smith added the comment: it seems a little messy to code this up the way Lib/tempfile.py is written but i'll take a stab at it tonight. Probably via parallel implementations of the methods internally rather than conditional logic throughout given how they work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 03:29:47 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 May 2015 01:29:47 +0000 Subject: [issue10354] tempfile.template is broken In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za> Message-ID: <1431998987.35.0.43696968279.issue10354@psf.upfronthosting.co.za> R. David Murray added the comment: Backward compatibility in that someone might be using the constant in their code. You could just leave the existing value there with a comment that it is unused and use a leading _ for the new constants. (Or you could delete it...it's not likely anyone is using it, I just tend to be conservative unless there is motivation to do otherwise.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 06:27:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 May 2015 04:27:57 +0000 Subject: [issue24205] signature.bind error messages are sub-optimal In-Reply-To: <1431733733.27.0.866799524337.issue24205@psf.upfronthosting.co.za> Message-ID: <20150519042753.26578.15710@psf.io> Roundup Robot added the comment: New changeset 3cc368d334c5 by Yury Selivanov in branch 'default': Issue 24205: Improve inspect.Signature.bind() error messages. https://hg.python.org/cpython/rev/3cc368d334c5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 06:29:08 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 May 2015 04:29:08 +0000 Subject: [issue24205] signature.bind error messages are sub-optimal In-Reply-To: <1431733733.27.0.866799524337.issue24205@psf.upfronthosting.co.za> Message-ID: <1432009748.43.0.85676075022.issue24205@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 06:30:13 2015 From: report at bugs.python.org (Ma Lin) Date: Tue, 19 May 2015 04:30:13 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1432009813.98.0.137022862116.issue24117@psf.upfronthosting.co.za> Ma Lin added the comment: This is not a de-facto standard, it should be fixed. I already posted this infomation on a Taiwan Python community, let's wait their inspection. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 06:40:00 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 May 2015 04:40:00 +0000 Subject: [issue22970] asyncio: Cancelling wait() after notification leaves Condition in an inconsistent state In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za> Message-ID: <1432010400.16.0.885763353695.issue22970@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- priority: normal -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 06:44:38 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 May 2015 04:44:38 +0000 Subject: [issue20691] inspect.signature: Consider exposing 'follow_wrapper_chains' option in public API In-Reply-To: <1392848461.48.0.35558236528.issue20691@psf.upfronthosting.co.za> Message-ID: <1432010678.69.0.232237036798.issue20691@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, what do you think of this one? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 08:16:05 2015 From: report at bugs.python.org (Tushar) Date: Tue, 19 May 2015 06:16:05 +0000 Subject: [issue24236] TestNG results to Junit results conversion Message-ID: <1432016165.44.0.72267035394.issue24236@psf.upfronthosting.co.za> New submission from Tushar: This tool/module will perform the TestNG type results to Junit results. This will be applicable for any TestNG result.xml file. ---------- components: Extension Modules messages: 243557 nosy: tusharm priority: normal severity: normal status: open title: TestNG results to Junit results conversion versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 08:16:24 2015 From: report at bugs.python.org (Tushar) Date: Tue, 19 May 2015 06:16:24 +0000 Subject: [issue24236] TestNG results to Junit results conversion In-Reply-To: <1432016165.44.0.72267035394.issue24236@psf.upfronthosting.co.za> Message-ID: <1432016184.71.0.506257330586.issue24236@psf.upfronthosting.co.za> Changes by Tushar : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 08:24:48 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 19 May 2015 06:24:48 +0000 Subject: [issue20691] inspect.signature: Consider exposing 'follow_wrapper_chains' option in public API In-Reply-To: <1392848461.48.0.35558236528.issue20691@psf.upfronthosting.co.za> Message-ID: <1432016688.15.0.895702563372.issue20691@psf.upfronthosting.co.za> Nick Coghlan added the comment: I like the idea of the following signature: def signature(callable, *, follow_wrapped=True): ... I'm less convinced about exposing the flag to optionally show the first positional arg for bound methods, as that's currently specific to method objects and builtins, rather than being a protocol like __wrapped__ that any callable can readily implement. If we *did* do that, then I think we should follow the convention of naming it after an attribute we look for (in this case, __self__) rather than limiting it to a specific type, and also make it default to true for consistency. That would give us: def signature(callable, *, follow_wrapped=True, omit_bound_self=True): ... The "omit_bound_self" flag would then be documented along the following lines: "If 'omit_bound_self' is true, and the callable has a '__self__' attribute set to a value other than None, then the first positional argument will be hidden from the displayed signature. Setting this to false means that bound methods will be displayed the same" However, as noted, I doubt the latter is worth it - let's just expose the flag to decide whether to resolve wrapper chains or not, and leave the inclusion of the already bound value in the reported signature solely as a legacy behaviour of getargspec and getfullargspec. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 08:28:24 2015 From: report at bugs.python.org (Ma Lin) Date: Tue, 19 May 2015 06:28:24 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1432016904.73.0.191780081269.issue24117@psf.upfronthosting.co.za> Ma Lin added the comment: >> If you could provide links to the relevant pages/section we can verify that the codecs are indeed incorrect. Here is CP950, 0xC6A1 is not in it. https://msdn.microsoft.com/zh-cn/goglobal/cc305155 I can provide one link, but there are many variants of BIG5 convert table on the Interenet, so one link doesn't bring persuasion. In this page: https://moztw.org/docs/big5/ Listed many variants of BIG5 tables, I found 0xC6A1<->U+30FE in this table "Unicode 1.1", the description of it is "it's a terrible table, many errors exist, sadlly many foreigners are using it", but IIRC Python's BIG5 codec is not fully same as that table. IMO, the most reliable way is reading a lot of stuff, and verify the key points and conflicts with authoritative source, but this way is very hard for foreigners. Anyway, let's wait Taiwanese and their opinion for whether this should be fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 08:43:26 2015 From: report at bugs.python.org (James Tocknell) Date: Tue, 19 May 2015 06:43:26 +0000 Subject: [issue18391] socket.fromfd()'s API is difficult or impossible to use correctly in general In-Reply-To: <1373153632.08.0.45299629619.issue18391@psf.upfronthosting.co.za> Message-ID: <1432017806.82.0.917629539606.issue18391@psf.upfronthosting.co.za> Changes by James Tocknell : ---------- nosy: +aragilar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 08:58:30 2015 From: report at bugs.python.org (Alex Lord) Date: Tue, 19 May 2015 06:58:30 +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: <1432018710.68.0.891233066918.issue16864@psf.upfronthosting.co.za> Alex Lord added the comment: Oh, alright. That makes a lot of sense. Sorry for being dense. I should have read the docs on subtest. All lines are under 80 characters and I modified the unit test to use subtest. Thanks for taking the time to walk me through this. ---------- Added file: http://bugs.python.org/file39425/sqlite_review_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 09:04:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 May 2015 07:04:32 +0000 Subject: [issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za> Message-ID: <1432019072.38.0.47908615753.issue6598@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 09:11:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 May 2015 07:11:08 +0000 Subject: [issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za> Message-ID: <20150519071105.10808.10688@psf.io> Roundup Robot added the comment: New changeset 6969bac411fa by Serhiy Storchaka in branch '2.7': Issue #6598: Increased time precision and random number range in https://hg.python.org/cpython/rev/6969bac411fa New changeset ea878f847eee by Serhiy Storchaka in branch '3.4': Issue #6598: Increased time precision and random number range in https://hg.python.org/cpython/rev/ea878f847eee New changeset 933addbc7041 by Serhiy Storchaka in branch 'default': Issue #6598: Increased time precision and random number range in https://hg.python.org/cpython/rev/933addbc7041 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 09:23:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 May 2015 07:23:10 +0000 Subject: [issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za> Message-ID: <1432020190.57.0.641736743026.issue6598@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now there is a question. Is it worth to use base16 (hexadecimal) to compact message id to 34 characters or base32 to compact it to 27 characters? Using base16 is pretty easy: just replace %d with %x. Using base32 is more complicated. With base64 and base85 the length can be decreased to 23 and 21, but I doubt that this is safe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 09:45:29 2015 From: report at bugs.python.org (Ruben Van Boxem) Date: Tue, 19 May 2015 07:45:29 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1432021529.59.0.503486988169.issue4709@psf.upfronthosting.co.za> Ruben Van Boxem added the comment: Paul, Thank you for your serious take on the issue. I'm Ruben, a long-time contributor and 3-ish year toolchain builder for MinGW-w64. I originally helped patching Qt 4.5/4.6 so that it worked with MinGW-w64 on 64-bit Windows. I can help liaison between you and the MinGW-w64 project, and point you towards stable, well-maintained MinGW-w64 builds. Perhaps we can discuss all the nitty gritty details elsewhere (or I can continue here of course), so we can get this straightened out. In short, this is the story: - MinGW.org is the "old" MinGW project, which has become pretty stale and is behind in soooo many aspects that it isn't even funny anymore (mostly new Windows APIs, DirectX support, and C++11 threading support is lacking). MinGW-w64 is a clean-room implementation that was released into the public domain, and by now included in all (I repeat, all) major Linux distro's as a cross compiler. Arch, Debian/Ubuntu, Fedora/Redhat etc. all provide a MinGW-w64 based cross-compiler. A complete list of MinGW-w64 features can be found on the web page: http://mingw-w64.yaxm.org/doku.php - TDM is a famous name in the MinGW world because he provided a high quality toolchain with installer when MinGW.org lacked in providing the new GCC 4. Unfortunately, he applies (perhaps useful) patches which break binary compatibility with upstream GCC. Since my toolchains (first uploads in September of 2010, last one in June 2013), and later with the MinGW-builds toolchains which are now installable through the MinGW-w64 website directly (and shipped with Qt), there is really no reason to go look elsewhere for toolchains. The MSYS2 project also provides numerous binary packages and I think almost exactly the same toolchains within their environment. The official MinGW-w64 installer can be found here: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/mingw-w64-install.exe (it might occasionally complain it cannot download repo.txt, that's a Sourceforge redirect error thing that's proving might hard to fix, in any case you can also find the toolchains directly below) http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/ http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/ - There are several ABI incompatible variants, explained nicely on the Qt wiki: http://wiki.qt.io/MinGW-64-bit#Exception_handling:_SJLJ.2C_DWARF.2C_and_SEH http://wiki.qt.io/MinGW-64-bit#GCC_Threading_model_.28posix_vs_win32.29 This is a choice you'll have to make. The greatest compatibility is offered by the "posix threading" (which gives C++11 support) and 32-bit sjlj and 64-bit seh variants. The 32-bit-dw2 provides a bit more juice in exception heavy code, but has the caveat that exceptions cannot be thrown across non-GCC-built code. The 32-bit dw2 variant is also what works with Clang, and is what is delivered in MSYS2 when installing the 32-bit toolchain. Since the 32-bit sturctured exception handling Borland Patents have expired, maybe a new, 32-bit seh version will emerge, but I have heard nothing concrete towards this direction. - The MSYS2 project also provides GCC-built Python binaries, which of course needs quite heavy patching. These patches and build scripts can be found here: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3 https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python2 - the -mno-cygwin option is really a dinosaur, and should be thrown into a deep pit, buried, and forgotten. Cygwin provides MinGW-w64 cross-compilers ({x86_64,i686}-w64-mingw32-gcc) which work in exactly the same way as a Linux->Windows cross-compiler. The official Windows binaries are just "gcc" and work as any native compiler on Linux. I hope this provides you with much of the information you need. If anything is unclear (I wrote this up in like ten minutes) or you need some concrete help figuring some things out, feel free to contact me directly or through the bugtracker. I sent an email to the MinGW-w64 public mailing list (subscription needed to post though, otherwise your message will be lost in the review queue) stating your and my intentions and current state of affairs: http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CALc40c_p56PAg8mfPyoUvAKWsqn0PBYQmgQW_qFMcRupof8wGg%40mail.gmail.com/#msg34124287 Ruben ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 10:00:16 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 19 May 2015 08:00:16 +0000 Subject: [issue19662] smtpd.py should not decode utf-8 In-Reply-To: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za> Message-ID: <1432022416.52.0.413175775971.issue19662@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: > New changeset a7d3074fa888 by R David Murray in branch 'default': > #19662: Make requirement to support arbitrary keywords explicit. > https://hg.python.org/cpython/rev/a7d3074fa888 s/keword/keyword/ ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 10:00:55 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 May 2015 08:00:55 +0000 Subject: [issue23780] Surprising behaviour when passing list to os.path.join. In-Reply-To: <1427356923.25.0.682691905774.issue23780@psf.upfronthosting.co.za> Message-ID: <20150519080050.39239.75911@psf.io> Roundup Robot added the comment: New changeset 84af71e8c051 by Serhiy Storchaka in branch 'default': Issue #23780: Improved error message in os.path.join() with single argument. https://hg.python.org/cpython/rev/84af71e8c051 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 10:09:15 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 19 May 2015 08:09:15 +0000 Subject: [issue24212] Idle, 2.7, backport idlelib.__main__, enable py -m idlelib In-Reply-To: <1431812813.24.0.960232018759.issue24212@psf.upfronthosting.co.za> Message-ID: <1432022955.14.0.0753194261504.issue24212@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 10:17:41 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 19 May 2015 08:17:41 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1432023461.41.0.556590450473.issue4709@psf.upfronthosting.co.za> Paul Moore added the comment: Ruben, Thanks for the detailed explanations. Just to be clear, I am *not* the person that will take this aspect of the process forward - that will be the community of people building (or wanting to build) extensions for Python with mingw. I don't know if that community has a spokesperson yet (or even if it's a well-defined "community") but they would be the ones to to engage with the mingw developers. In particular, the choices around ABI incompatible variants that you mention are precisely the sort of thing the community needs to establish - which variant is compatible with Python, how to get a maintained build of that variant (there seems to be a lot of "get such-and-such's personal build from this URL" in the current crop of instructions for building Python extensions with mingw - that's not really sustainable). The problem boils down to there needing to be a definitive, simple, and maintained set of instructions and software for "how to set up a mingw build environment for Python extensions". The core Python developers can't provide that (as we use MSVC). What we can do, when such a thing exists, is look at whether it's a toolchain that we can reasonably support. At the moment mingw patch requests come in based on someone's custom build environment, that we can't easily reproduce, and we can't be sure is the same as anyone else's. That's not something we can support - hence the frustration from the mingw-using community, because we have partial support from the days when mingw.org and cygwin were the only two options for gcc-on-windows and we didn't really communicate the change in status (which admittedly would have been "we no longer support mingw", so wouldn't have helped much...) Hopefully, the discussion on this issue clarifies the position a bit. Give us a well-defined "gcc on Windows" (mingw) platform definition, and we'll look at supporting it. Otherwise, we can maintain the status quo (what's there remains, but patches pretty much never go in, because reproducing issues and testing changes is too much effort to be viable) or formally drop support for mingw (which I'd be reluctant to do, but it may be worth it just to offer clarity). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 11:14:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 May 2015 09:14:28 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1432026868.6.0.475324314482.issue15836@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Core developers left a couple of notes and the patch itself is outdated. Here is updated patch that addresses all comments. It also extends the checking to assertRaisesRegex(), assertWarns() and assertWarnsRegex(). There is a risk to break existing incorrect tests if the argument is a tuple. They can be passed for now because caught exception or warning is found before incorrect value. For example: with self.assertRaises((ValueError, None)): int('a') ---------- Added file: http://bugs.python.org/file39426/issue15836_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 11:17:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 May 2015 09:17:32 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1432027052.91.0.24092021598.issue22939@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If Raymond will not stop me, I'll commit the patch tomorrow. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 11:19:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 May 2015 09:19:01 +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: <1432027141.53.0.853075967472.issue7267@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 11:44:40 2015 From: report at bugs.python.org (Ruben Van Boxem) Date: Tue, 19 May 2015 09:44:40 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1432028680.9.0.78464510071.issue4709@psf.upfronthosting.co.za> Ruben Van Boxem added the comment: Paul, OK, I understand your point of view. As you say, there is no single "MinGW" community, nor a guiding body that takes these decisions. If you're not willing to choose one, all I can say is this: it will probably not matter which version you choose (all will work), only mixing them won't work. A sound choice would be to follow the Qt Project (it's what they ship in their SDK): http://doc.qt.io/qt-5/supported-platforms.html#reference-configurations They chose the dw2/posix combo, which IMHO is the best choice all-round. For 64-bit, the obvious one is seh/posix. Incidentally, that's what MSYS2 people chose, and they regularly build all of Python with these toolchains (plus some other packages including numpy/scipy), see https://github.com/Alexpux/MINGW-packages/ and search for "-python-". These python builds are done from source, do not link to msvcr100, but just msvcrt.dll, which is the OS component MinGW GCC links to currently and in the foreseeable future. As it stands, you can easily reproduce these builds by: 1. Installing MSYS2 (download and install, see http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/) 2. Installing GCC (i.e. "pacman -S mingw-w64-i686-gcc" for 32-bit or "pacman -S mingw-w64-x86_64-gcc" for 64-bit) 3. Installing all of Python's dependencies (see e.g. PKGBUILD: https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-python2/PKGBUILD#L14) 4. running makepkg in the directory with the python PKGBUILD with the patches next to it. make sure to use the "MinGW-w64 Win64 Shell" or "MinGW-w64 Win32 Shell") that MSYS2 places in your start menu. This sets PATH to include the relevant toolchains and tools, much like the VS command prompts. You can then extract the necessary dependency DLLs from the MSYS2's /mingw32/bin and /mingw64/bin directories so that a standalone MinGW-w64 Python installation can be created from that without issue. If you feel this qualifies as an easy, maintainable, reproducible setup, perhaps work can be done to integrate the large amount of patches currently required. Note that these patches will work with any decent and/or official MinGW-w64 GCC build. The time of everyone needing to build their own toolchain is past. Even if some people still building all kinds of cludgy variants seem to have missed the memo. Note that these builds differ from the official MSVC builds (which may not be a bad thing: it keeps MSVC<->GCC compatibility issues arising from mixing the code to a minimum). Obviously, when MinGW-w64/GCC supports the UCRT stuff, this incompatibility can be harmoniously resolved. Until then, this seems to me like a good solution, and it is how everyone else is doing it (i.e. separate GCC builds on Windows). If there is no interest in having a (community-supported, semi-official) GCC-built Python on Windows, I'm sure something else can also be worked out, which would include stripping the current dinosaur -mno-cygwin code which is what this bug was originally all about. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 12:22:58 2015 From: report at bugs.python.org (Al Sweigart) Date: Tue, 19 May 2015 10:22:58 +0000 Subject: [issue24225] IDLE test filenames don't match script filenames. In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za> Message-ID: <1432030978.98.0.975250059197.issue24225@psf.upfronthosting.co.za> Al Sweigart added the comment: The idle_renaming.patch file is for the file renamings under idlelib The idletest_renaming.patch file is for the file renamings under idlelib/idle_test The idle_updating_imports.patch file is for the content updates (mostly for import statements) due to the renamings. The unit tests all pass with these changes. ---------- keywords: +patch type: -> enhancement Added file: http://bugs.python.org/file39427/idle_renaming.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 12:23:20 2015 From: report at bugs.python.org (Al Sweigart) Date: Tue, 19 May 2015 10:23:20 +0000 Subject: [issue24225] IDLE test filenames don't match script filenames. In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za> Message-ID: <1432031000.34.0.682346810675.issue24225@psf.upfronthosting.co.za> Changes by Al Sweigart : Added file: http://bugs.python.org/file39428/idletest_renaming.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 12:23:50 2015 From: report at bugs.python.org (Al Sweigart) Date: Tue, 19 May 2015 10:23:50 +0000 Subject: [issue24225] IDLE test filenames don't match script filenames. In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za> Message-ID: <1432031030.58.0.617529507493.issue24225@psf.upfronthosting.co.za> Al Sweigart added the comment: (I can reformat these patch files if that helps.) ---------- Added file: http://bugs.python.org/file39429/idle_updating_imports.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 12:33:30 2015 From: report at bugs.python.org (Al Sweigart) Date: Tue, 19 May 2015 10:33:30 +0000 Subject: [issue24225] IDLE test filenames don't match script filenames. In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za> Message-ID: <1432031610.34.0.82924938122.issue24225@psf.upfronthosting.co.za> Al Sweigart added the comment: For reference, here's all the files and their new filenames: aboutDialog.py about_dialog.py AutoComplete.py autocomplete.py AutoCompleteWindow.py autocomplete_window.py AutoExpand.py autoexpand.py Bindings.py bindings.py CallTips.py calltips.py CallTipWindow.py calltip_window.py ClassBrowser.py class_browser.py CodeContext.py code_context.py ColorDelegator.py color_delegator.py configDialog.py config_dialog.py configHandler.py config_handler.py configHelpSourceEdit.py config_help_source_edit.py configSectionNameDialog.py config_section_name_dialog.py Debugger.py debugger.py Delegator.py delegator.py dynOptionMenuWidget.py dyn_option_menu_widget.py EditorWindow.py editor_window.py FileList.py file_list.py FormatParagraph.py format_paragraph.py GrepDialog.py grep_dialog.py HyperParser.py hyper_parser.py IdleHistory.py idle_history.py idlever.py idle_ver.py IOBinding.py io_binding.py keybindingDialog.py keybinding_dialog.py macosxSupport.py mac_osx_support.py MultiCall.py multi_call.py MultiStatusBar.py multi_status_bar.py ObjectBrowser.py object_browser.py OutputWindow.py output_window.py ParenMatch.py paren_match.py PathBrowser.py path_browser.py Percolator.py percolator.py PyParse.py pyparse.py PyShell.py pyshell.py RemoteDebugger.py remote_debugger.py RemoteObjectBrowser.py remote_object_browser.py ReplaceDialog.py replace_dialog.py RstripExtension.py rstrip_extension.py ScriptBinding.py script_binding.py ScrolledList.py scrolled_list.py SearchDialog.py search_dialog.py SearchDialogBase.py search_dialog_base.py SearchEngine.py search_engine.py StackViewer.py stack_viewer.py tabbedpages.py tabbed_pages.py textView.py text_view.py ToolTip.py tool_tip.py TreeWidget.py tree_widget.py UndoDelegator.py undo_delegator.py WidgetRedirector.py widget_redirector.py WindowList.py window_list.py ZoomHeight.py zoom_height.py test_config_name.py test_config_section_name_dialog.py test_configdialog.py test_config_dialog.py test_formatparagraph.py test_format_paragraph.py test_grep.py test_grep_dialog.py test_hyperparser.py test_hyper_parser.py test_idlehistory.py test_idle_history.py test_parenmatch.py test_paren_match.py test_pathbrowser.py test_path_browser.py test_rstrip.py test_rstrip_extension.py test_searchdialogbase.py test_search_dialog_base.py test_textview.py test_text_view.py test_searchengine.py test_search_engine.py test_widgetredir.py test_widget_redirector.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 12:45:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 May 2015 10:45:30 +0000 Subject: [issue24225] IDLE test filenames don't match script filenames. In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za> Message-ID: <1432032330.71.0.874102428684.issue24225@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Usually we avoid such mass renamings. This is errorprone and can break third-party plugins or even applications that use parts of IDLE. It also will made much harder to transfer patches between versions. I'm -1 for this proposition. ---------- nosy: +kbk, roger.serwy, serhiy.storchaka, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 12:45:38 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 19 May 2015 10:45:38 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1432032338.48.0.820196189273.issue15836@psf.upfronthosting.co.za> Martin Panter added the comment: I posted a question on Reitveld, but the new patch looks fine in general. I wouldn?t worry too much about the (ValueError, None) case, since such code is probably already broken. If it is a problem though, maybe this could only go into the next feature relase (3.5). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 13:09:10 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 May 2015 11:09:10 +0000 Subject: [issue24236] TestNG results to Junit results conversion In-Reply-To: <1432016165.44.0.72267035394.issue24236@psf.upfronthosting.co.za> Message-ID: <1432033750.91.0.0480551457825.issue24236@psf.upfronthosting.co.za> R. David Murray added the comment: This doesn't appear to have anything to do with Python. What was your purpose in opening this issue? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 13:13:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 May 2015 11:13:53 +0000 Subject: [issue16314] Support xz compression in distutils In-Reply-To: <1351114378.64.0.718374634123.issue16314@psf.upfronthosting.co.za> Message-ID: <1432034033.3.0.713262812227.issue16314@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 May 19 13:16:20 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 19 May 2015 11:16:20 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used Message-ID: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> New submission from Nick Coghlan: >From the StopIteration-in-generators handling transition plan (https://www.python.org/dev/peps/pep-0479/#transition-plan): * Python 3.5: Enable new semantics under __future__ import; silent deprecation warning if StopIteration bubbles out of a generator not under __future__ import. The first half of that was implemented in issue 22906, but we missed the second half. The reason the latter is needed is so that people can turn the DeprecationWarning into an error to test for compatibility with the future default behaviour without needing to add the new future flag to their code (which would break compatibility with older Python versions). Ram Rachum pointed out the absence on python-ideas: https://mail.python.org/pipermail/python-ideas/2015-May/033580.html ---------- messages: 243576 nosy: ncoghlan priority: normal severity: normal status: open title: PEP 479: missing DeprecationWarning when generator_stop is not used _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 13:16:33 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 19 May 2015 11:16:33 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <1432034193.81.0.827957133142.issue24237@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- dependencies: +PEP 479: Change StopIteration handling inside generators _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 13:18:00 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 19 May 2015 11:18:00 +0000 Subject: [issue24238] Avoid entity expansion attacks in Element Tree Message-ID: <1432034279.35.0.728988379999.issue24238@psf.upfronthosting.co.za> New submission from Martin Panter: This patch could be the basis of an alternative to Christian Heimes?s patch in Issue 17239. It adds a parser flag to the Element Tree modules so that they will immediately raise an exception when an entity declaration is encountered. I believe this should be sufficient to avoid DOS vulnerabilities like the Billion Laughs attack, where a small XML entity reference expands into a large string, and/or involves a large number of entity expansions. I think the advantage of this patch over the patch in Issue 17239 is this one should work on the current Expat library (which I understand Python can load externally). The other patch modifies the Expat library itself, so would only be useful when Python?s internal Expat library is being used (or the external Expat library was also patched in a similar manner). The disadvantage of this patch is that it disables handling XML data as soon as an entity is declared, even if the entities are not actually used, or they are only used in a non-malicious way. The other patch allows a limited amount of entity expansion. I would like some feedback on: * What others think of the basic approach, compared with Christian?s approach in Issue 17239 * If reject_entities=True should be switched on by default, which could break compatibility, but could be sensible for most cases of basic XML parsing * If my changes to the examples in the documentation are excessive * If other Element Tree APIs should be modified similarly to XMLParser So far I have only changed the XMLParser class. The following APIs accept a parser object, so can also avoid the vulnerability by passing a custom parser object: * fromstringlist() * iterparse(), though ?parser? is listed as deprecated (by Issue 17741) * parse() (module-level function) * XML() * XMLID() * ElementTree.parse() (method of ElementTree class) These APIs don?t have a custom parser object, so they are still always vulnerable: * fromstring() * XMLPullParser ---------- components: XML files: etree_20130519.patch keywords: patch messages: 243577 nosy: christian.heimes, vadmium priority: normal severity: normal status: open title: Avoid entity expansion attacks in Element Tree type: security versions: Python 3.5 Added file: http://bugs.python.org/file39430/etree_20130519.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 13:18:13 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 19 May 2015 11:18:13 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1432034293.29.0.108245082721.issue22906@psf.upfronthosting.co.za> Nick Coghlan added the comment: We missed the deprecation warning part of the PEP (for when the future import is *not* in effect, but the default behaviour will change in 3.7), but rather than reopening this one, I filed a new issue: issue 24237 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 13:18:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 May 2015 11:18:53 +0000 Subject: [issue19662] smtpd.py should not decode utf-8 In-Reply-To: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za> Message-ID: <20150519111850.26580.50774@psf.io> Roundup Robot added the comment: New changeset a3f2b171b765 by R David Murray in branch 'default': #19662: fix typo https://hg.python.org/cpython/rev/a3f2b171b765 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 13:19:16 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 May 2015 11:19:16 +0000 Subject: [issue19662] smtpd.py should not decode utf-8 In-Reply-To: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za> Message-ID: <1432034356.23.0.89919444239.issue19662@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Arfrever. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 13:26:52 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 19 May 2015 11:26:52 +0000 Subject: [issue17239] XML vulnerabilities in Python In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za> Message-ID: <1432034812.83.0.00181862186913.issue17239@psf.upfronthosting.co.za> Martin Panter added the comment: I have opened Issue 24238 with a patch for Element Tree that uses my EntityDeclHandler technique, instead of patching Expat. I would be interested in other people?s thoughts on the approach. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 14:20:36 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 May 2015 12:20:36 +0000 Subject: [issue24215] test_trace uses test_pprint In-Reply-To: <1431842150.15.0.237267681297.issue24215@psf.upfronthosting.co.za> Message-ID: <1432038036.63.0.924111687033.issue24215@psf.upfronthosting.co.za> R. David Murray added the comment: I've backed out the change set that broke the buildbots (see de9c43fabda6). I can understand this changeset getting committed, since one doesn't normally expect a change in the tests to break other tests (though I myself do often run the full test suite anyway), but it is not acceptable that the breakage of the buildbots was not addressed quickly. The problem should have been fixed or the changeset backed out within hours of the problem being recognized. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 14:23:55 2015 From: report at bugs.python.org (Josh Holland) Date: Tue, 19 May 2015 12:23:55 +0000 Subject: [issue24229] pathlib.Path should have a copy() method In-Reply-To: <1431966913.98.0.0205729823841.issue24229@psf.upfronthosting.co.za> Message-ID: <1432038235.95.0.926314048107.issue24229@psf.upfronthosting.co.za> Josh Holland added the comment: Serhiy makes a series of good points, which I hadn't really considered before filing this report. It was mostly laziness on my part while dashing off a quick script - I knew I wouldn't have to deal with the edge cases so subconsciously dismissed them, especially as the code I wrote to copy was only a couple of lines. So I'm happy for this bug to be closed with no change needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 14:26:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 May 2015 12:26:11 +0000 Subject: [issue24215] test_trace uses test_pprint In-Reply-To: <1431842150.15.0.237267681297.issue24215@psf.upfronthosting.co.za> Message-ID: <20150519122608.4243.69369@psf.io> Roundup Robot added the comment: New changeset cf52756f19b6 by R David Murray in branch '3.4': #24215: also back out changeset that broke test_trace in 3.4. https://hg.python.org/cpython/rev/cf52756f19b6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 14:30:28 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 May 2015 12:30:28 +0000 Subject: [issue24215] test_trace uses test_pprint In-Reply-To: <1431842150.15.0.237267681297.issue24215@psf.upfronthosting.co.za> Message-ID: <1432038628.41.0.793638600325.issue24215@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 14:33:37 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 19 May 2015 12:33:37 +0000 Subject: [issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids In-Reply-To: <1432020190.57.0.641736743026.issue6598@psf.upfronthosting.co.za> Message-ID: <20150519083327.2935bf38@limelight.wooz.org> Barry A. Warsaw added the comment: On May 19, 2015, at 07:23 AM, Serhiy Storchaka wrote: >Now there is a question. Is it worth to use base16 (hexadecimal) to compact >message id to 34 characters or base32 to compact it to 27 characters? Using >base16 is pretty easy: just replace %d with %x. Using base32 is more >complicated. It might not be relevant, but we're using base 32 in Message-ID-Hash: http://wiki.list.org/DEV/Stable%20URLs We settled on base 32 after consulting with the curators of mail-archive.com and others. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 14:51:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 May 2015 12:51:10 +0000 Subject: [issue24091] Use after free in Element.extend (1) In-Reply-To: <1430488567.85.0.132864592859.issue24091@psf.upfronthosting.co.za> Message-ID: <1432039870.06.0.474708095075.issue24091@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 May 19 15:06:48 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Tue, 19 May 2015 13:06:48 +0000 Subject: [issue24239] Allow to configure which gpg to use in distutils upload Message-ID: <1432040808.9.0.641361051221.issue24239@psf.upfronthosting.co.za> New submission from C?dric Krier: 'gpg' is hard coded in distutils/command/upload.py and the spawn command doesn't even use the shell aliases. So if you have only gpg2 installed it doesn't work. I think the name (or even the all command line) should be configurable from ~/.pypirc ---------- components: Distutils messages: 243586 nosy: ced, dstufft, eric.araujo priority: normal severity: normal status: open title: Allow to configure which gpg to use in distutils upload type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 15:19:04 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 19 May 2015 13:19:04 +0000 Subject: [issue24240] PEP 448: Update the language reference Message-ID: <1432041544.18.0.803437691236.issue24240@psf.upfronthosting.co.za> New submission from Stefan Krah: Since Grammar/Grammar relies on semantic postprocessing in ast.c, it would be nice to have an update of the (human readable) Grammar in the language reference docs. ---------- messages: 243587 nosy: skrah priority: normal severity: normal status: open title: PEP 448: Update the language reference _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 15:20:21 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 19 May 2015 13:20:21 +0000 Subject: [issue24240] PEP 448: Update the language reference In-Reply-To: <1432041544.18.0.803437691236.issue24240@psf.upfronthosting.co.za> Message-ID: <1432041621.01.0.0495317108059.issue24240@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python stage: -> needs patch type: -> enhancement versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 15:33:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 May 2015 13:33:37 +0000 Subject: [issue24215] test_trace uses test_pprint In-Reply-To: <1431842150.15.0.237267681297.issue24215@psf.upfronthosting.co.za> Message-ID: <1432042417.79.0.387979764923.issue24215@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, I expected this issue be solved much faster. Unfortunately Terry's recipe doesn't work. Here is a patch that reapplies changes that broke buildbots (additional tests for buildins and making test_pprint discoverable), and also fixes test_trace and makes it discoverable. I found yet one issue with test_trace. It fails if run regrtest with the -m option (both patched and unpatched versions, there is no regression). $ ./python -m test.regrtest test_trace [1/1] test_trace 1 test OK. $ ./python -m test.regrtest -m test_coverage test_trace [1/1] test_trace test test_trace failed -- Traceback (most recent call last): File "/home/serhiy/py/cpython-3.4/Lib/test/test_trace.py", line 313, in test_coverage self.assertTrue("pprint.cover" in files) AssertionError: False is not true 1 test failed: test_trace It fails because run_unittest() is used in tested script. That is yet one argument against using test_pprint in test_trace. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file39431/issue24215.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 15:38:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 May 2015 13:38:13 +0000 Subject: [issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet (patch attached) In-Reply-To: <1358533279.94.0.666576182033.issue16995@psf.upfronthosting.co.za> Message-ID: <1432042693.19.0.580932544822.issue16995@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> patch review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 15:40:36 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 19 May 2015 13:40:36 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1432042836.36.0.11285192922.issue4709@psf.upfronthosting.co.za> Paul Moore added the comment: > If there is no interest in having a (community-supported, semi- > official) GCC-built Python on Windows, I'm sure something else > can also be worked out, which would include stripping the current > dinosaur -mno-cygwin code which is what this bug was originally > all about. The issue is about building Python *extensions* with gcc, not about building Python itself - that's not a supported approach at all (MSYS2 does it, but the patches used aren't going to be integrated in core Python). The problem is that the people who build those extensions (which is not me, nor is it anyone on the core Python team) have never settled on a single version of the mingw toolchain as "what they want the distutils to support". So each bug report or patch is needs different "how to install mingw" instructions to be followed before a core developer can work on it. I'm suggesting that the people raising distutils bugs about mingw support get together and agree on a common toolchain that they'll use as a basis for any future bugs/patches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 15:43:02 2015 From: report at bugs.python.org (David Steele) Date: Tue, 19 May 2015 13:43:02 +0000 Subject: [issue24241] webbrowser (very often) doesn't support the 'new' parameter Message-ID: <1432042982.05.0.828874094042.issue24241@psf.upfronthosting.co.za> New submission from David Steele: When calling webbrowser.open*(), the module goes through a list of installed browsers, and uses the first one that succeeds, to process the request. The first 'browsers' in the 'X' list are 'xdg-open' and others of that ilk. The problem is that they only have one 'open' behavior - the 'new' parameter is ignored ('same window', 'new window', 'new tab'). I can get the fully supported default browser in GNOME with e.g. def browser(): app = Gio.app_info_get_default_for_type('x-scheme-handler/https', True) bpath = app.get_filename() for candidate in webbrowser._tryorder: if candidate in bpath: return webbrowser.get(using=candidate) return webbrowser.get() ... but this code accesses a private list. The problems are: 1) webbrowser does not determine and return the current default browser. 2) There is no public interface for determining the current/installed browser type list. The problem can be mitigated by resolving (1) and/or (2). Also, the browser type list in the documentation is missing many entries. Checked on 2.7 and 3.4. I believe this is valid across all supported versions. ---------- messages: 243590 nosy: daves priority: normal severity: normal status: open title: webbrowser (very often) doesn't support the 'new' parameter type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 15:57:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 May 2015 13:57:38 +0000 Subject: [issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet (patch attached) In-Reply-To: <1358533279.94.0.666576182033.issue16995@psf.upfronthosting.co.za> Message-ID: <1432043858.32.0.999016645542.issue16995@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch can't be longer applied cleanly. It should be synchronized with sources. It is the last chance for this feature to get to 3.5 if somebody will update the patch and add the documentation. The feature itself LGTM. The only my doubt is about the name of boolean parameter. "base32hex" is recommended as encoding name. Parameter can be named as "exthex" or "extended_hex". Or may be add separate functions b32hexencode/b32hexdecode. I'm not sure. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 16:13:12 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 May 2015 14:13:12 +0000 Subject: [issue24215] test_trace uses test_pprint In-Reply-To: <1431842150.15.0.237267681297.issue24215@psf.upfronthosting.co.za> Message-ID: <1432044792.31.0.882715560664.issue24215@psf.upfronthosting.co.za> R. David Murray added the comment: If you are looking for a small test file to switch to, perhaps test_uu would be a good candidate. It isn't very likely to grow, since I don't think uu encoding is used much any more, so the likelyhood of someone caring about it is relatively low. But I haven't looked at what test_trace is using test_pprint for, so perhaps it isn't suitable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 16:19:09 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 May 2015 14:19:09 +0000 Subject: [issue24241] webbrowser default browser detection and/or public API for _trylist. In-Reply-To: <1432042982.05.0.828874094042.issue24241@psf.upfronthosting.co.za> Message-ID: <1432045149.42.0.160191343609.issue24241@psf.upfronthosting.co.za> R. David Murray added the comment: Any change is going to be an enhancement, so it will only go in 3.6 (at this point...beta/feature freeze for 3.5 is this weekend). Would you like to propose a patch? ---------- nosy: +r.david.murray stage: -> needs patch title: webbrowser (very often) doesn't support the 'new' parameter -> webbrowser default browser detection and/or public API for _trylist. type: behavior -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 16:23:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 May 2015 14:23:05 +0000 Subject: [issue24215] test_trace uses test_pprint In-Reply-To: <1431842150.15.0.237267681297.issue24215@psf.upfronthosting.co.za> Message-ID: <1432045385.97.0.0736772832906.issue24215@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There are issues with additional tests for uu. The fact that test_trace fails with the -m option means that any file that runs unittest is not good example (unittest looks on sys.argv). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 16:24:08 2015 From: report at bugs.python.org (=?utf-8?q?Hannes_Ovr=C3=A9n?=) Date: Tue, 19 May 2015 14:24:08 +0000 Subject: [issue24242] property performance regression Message-ID: <1432045448.44.0.686682029438.issue24242@psf.upfronthosting.co.za> New submission from Hannes Ovr?n: There seems to be a significant regression in performance when using @property in Python 2.x compared to 3.x. Test code: class A: def __init__(self, x, y): self.x = x self.y = y @property def y(self): return self._y @y.setter def y(self, value): self._y = value from timeit import timeit a = A(1, 2) timeit('a.x', 'from __main__ import a') timeit('a.y', 'from __main__ import a') On my machine (Fedora Linux, x64) I get the following timings: 2.7.8: a.x : 0.05482792854309082 a.y : 0.05585598945617676 3.4.1: a.x : 0.06391137995524332 a.y : 0.31193224899470806 I.e. The performace of using a property vs a ordinary member is more or less the same in 2.7, while it incurs a 5x penalty in 3.4. ---------- messages: 243595 nosy: hovren priority: normal severity: normal status: open title: property performance regression type: performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 16:30:45 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 19 May 2015 14:30:45 +0000 Subject: [issue23985] Crash when deleting slices from duplicated bytearray In-Reply-To: <1429252668.91.0.45841644858.issue23985@psf.upfronthosting.co.za> Message-ID: <1432045845.85.0.47305801952.issue23985@psf.upfronthosting.co.za> Martin Panter added the comment: Posting a new patch which combines both fixes and adds some test cases. However the test needs Python to be built with ?./configure --with-pydebug? to detect the buffer overrun; without this the test will probably silently pass. I removed the offending buffer space check, and let it always call PyBufferArray_Resize(). I also looked around the bytearray module for similar errors for other operations but I couldn?t find any. The other cases already tend to always call PyByteArray_Resize(). ---------- Added file: http://bugs.python.org/file39432/bytearray-fixes.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 16:37:55 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 19 May 2015 14:37:55 +0000 Subject: [issue24242] property performance regression In-Reply-To: <1432045448.44.0.686682029438.issue24242@psf.upfronthosting.co.za> Message-ID: <1432046275.3.0.349020587415.issue24242@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The test script has a bug. The class needs to inherit from object in Python 2.7 ---------- nosy: +rhettinger resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 16:43:54 2015 From: report at bugs.python.org (David Steele) Date: Tue, 19 May 2015 14:43:54 +0000 Subject: [issue24241] webbrowser default browser detection and/or public API for _trylist. In-Reply-To: <1432045149.42.0.160191343609.issue24241@psf.upfronthosting.co.za> Message-ID: David Steele added the comment: On Tue, May 19, 2015 at 10:19 AM, R. David Murray wrote: ... > Would you like to propose a patch? My preferred solution would be a bit intrusive - check for and use xdg-settings or gi.repository.Gio to identify the default browser, and match the result against the type list. I'm not sure that would get approval, nor am I sure of the best standard-library-compliant way to go about it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 16:44:38 2015 From: report at bugs.python.org (=?utf-8?q?Hannes_Ovr=C3=A9n?=) Date: Tue, 19 May 2015 14:44:38 +0000 Subject: [issue24242] property performance regression In-Reply-To: <1432045448.44.0.686682029438.issue24242@psf.upfronthosting.co.za> Message-ID: <1432046678.08.0.0523379222217.issue24242@psf.upfronthosting.co.za> Hannes Ovr?n added the comment: Yes, changing to class A(object) does indeed cause the same magnitude of performance drop in Python 2.7 as well. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 17:40:01 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 19 May 2015 15:40:01 +0000 Subject: [issue23377] HTTPResponse may drop buffer holding next response In-Reply-To: <1422881776.12.0.998068930599.issue23377@psf.upfronthosting.co.za> Message-ID: <1432050001.36.0.752492275255.issue23377@psf.upfronthosting.co.za> Demian Brecht added the comment: If nobody else gets to it first, I'll try to get to review this later today or tomorrow. Apologies for the delay on the review Martin, a new baby (coming next month), moving /and/ taking on a new job all at the same time seems to limit free time a little ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 17:43:01 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 19 May 2015 15:43:01 +0000 Subject: [issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1432050181.66.0.313192320245.issue12319@psf.upfronthosting.co.za> Demian Brecht added the comment: > What's the status on this one? It looks like some review comments need addressing. That's about it. Unfortunately I've been pretty tied up over the last month and a bit. I'll try to get to hopefully closing this out over the next few days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 17:50:26 2015 From: report at bugs.python.org (doz) Date: Tue, 19 May 2015 15:50:26 +0000 Subject: [issue24228] Interpreter triggers segmentation fault at the starting In-Reply-To: <1431964179.84.0.528825481324.issue24228@psf.upfronthosting.co.za> Message-ID: <1432050626.0.0.906515438777.issue24228@psf.upfronthosting.co.za> doz added the comment: I manually disabled xxlimited (file xxlimited.c removed , and lines in setup.py commented) because : In file included from ./Include/Python.h:68, from xxxx/build/python3-3.4.2/Modules/xxlimited.c:17: ./Include/object.h:65:2: error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG So python has been rebuilt with option -with-pydebug Now, I don't have segfault thanks to assert of line 821 #python python: Objects/dictobject.c:821: insertdict: Assertion `ep->me_key != ((void *)0) && ep->me_key != (&_dummy_struct)' failed. Aborted buildroot-2015.02 set the following configuration options : ./configure --target=arm-buildroot-linux-gnueabi --host=arm-buildroot-linux-gnueabi --build=x86_64-unknown-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --localstatedir=/var --program-prefix="" --enable-ipv6 --enable-shared --disable-curses --with-libmpdec=none --with-expat=none --enable-old-stdlib-cache --disable-sqlite3 --disable-codecs-cjk --disable-ossaudiodev --with-pydebug --without-ensurepip --without-cxx-main --with-system-ffi --disable-pydoc --disable-test-modules --disable-lib2to3 --disable-tk --disable-nis --disable-idle3 ?disable-pyo-build ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 18:04:54 2015 From: report at bugs.python.org (doz) Date: Tue, 19 May 2015 16:04:54 +0000 Subject: [issue24228] Interpreter triggers segmentation fault at the starting In-Reply-To: <1431964179.84.0.528825481324.issue24228@psf.upfronthosting.co.za> Message-ID: <1432051494.88.0.061568901982.issue24228@psf.upfronthosting.co.za> doz added the comment: value of ep->me_key equals 0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 18:08:23 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 19 May 2015 16:08:23 +0000 Subject: [issue22931] cookies with square brackets in value In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za> Message-ID: <1432051703.55.0.394686970448.issue22931@psf.upfronthosting.co.za> Demian Brecht added the comment: > This needs a review from the people who created and applied the security patch. + Guido (committed https://hg.python.org/cpython/rev/9e765e65e5cb) ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 18:09:31 2015 From: report at bugs.python.org (=?utf-8?b?0KDRg9GB0LvQsNC9INCY0LbQsdGD0LvQsNGC0L7Qsg==?=) Date: Tue, 19 May 2015 16:09:31 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1432051771.53.0.26083969067.issue4709@psf.upfronthosting.co.za> ?????? ????????? added the comment: >> If there is no interest in having a (community-supported, semi- >> official) GCC-built Python on Windows, I'm sure something else >> can also be worked out, which would include stripping the current >> dinosaur -mno-cygwin code which is what this bug was originally >> all about. > > The issue is about building Python *extensions* with gcc, not about > building Python itself - that's not a supported approach at all > (MSYS2 does it, but the patches used aren't going to be integrated > in core Python). Let's say you have the official, upstream W32 CPython, built with MSVC and linking with, say, msvcr90.dll You build, say, libarchive-1.dll with MinGW-w64, because that's what you use to build stuff. Because it's MinGW-w64, libarchive-1.dll links to msvcrt.dll. Then you want to build, say, pyarchive extension for your Python and you do that with MinGW-w64, because that's what you use to build stuff. Because it's msvcrt.dll, libpyarchive.pyd link to msvcrt.dll. Then you run Python code that takes, say, sys.stdout file object and passes it to pyarchive. Python file object is backed by msvcr90 file descriptor. pyarchive expects a file object backed by msvcrt file descriptor. Boom. Only three ways of avoiding this: 1) Use MSVC for everything. This is what upstream CPython does. 2) Use MinGW-w64 for everything (including CPython itself). This is what MSYS2 does. 3) Use MSVC for CPython and MinGW-w64 for the rest and somehow ensure that FDs are converted when passing the CRT barrier. And stat structs as well. And everything else that differs. This is a path of frustration that leads nowhere and does not seem sustainable to me. This is why the discussion keeps coming back to building Python with MinGW-w64. This is why Universal CRT can be a solution (the absence of CRT incompatibility would resolve a lot of issues; the rest is manageable - remember MinGW-w64 has to use the same CRT/W32API DLLs that MSVC does, so binary compatibility is always achievable for anything with C interface). ---------- nosy: +LRN _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 18:25:32 2015 From: report at bugs.python.org (doz) Date: Tue, 19 May 2015 16:25:32 +0000 Subject: [issue24228] Interpreter triggers segmentation fault at the starting In-Reply-To: <1431964179.84.0.528825481324.issue24228@psf.upfronthosting.co.za> Message-ID: <1432052732.96.0.114163755213.issue24228@psf.upfronthosting.co.za> doz added the comment: Problem also present with only configuration option : --enable-ipv6 --enable-shared --disable-curses --with-libmpdec=none --with-expat=none --enable-old-stdlib-cache --disable-sqlite3 --disable-codecs-cjk --disable-ossaudiodev --with-pydebug ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 18:39:01 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 19 May 2015 16:39:01 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1432051771.53.0.26083969067.issue4709@psf.upfronthosting.co.za> Message-ID: Paul Moore added the comment: On 19 May 2015 at 17:09, ?????? ????????? wrote: > 3) Use MSVC for CPython and MinGW-w64 for the rest and somehow ensure that FDs are converted when passing the CRT barrier. And stat structs as well. And everything else that differs. This is a path of frustration that leads nowhere and does not seem sustainable to me. That is the one this issue is about. It *is* possible (mingw grew the -lmsvcr100 and similar flags, at least in part to support it). But it's not easy to set up, and the people asking for it to be supported have never really addressed all of the issues involved (at least not in a reproducible/supportable way). Building Python with mingw, while out of scope for this particular issue, has always failed because nobody has been willing to step up and offer the long-term support commitment that would be required, AIUI. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 18:47:49 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 19 May 2015 16:47:49 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1432054069.6.0.540599236694.issue22107@psf.upfronthosting.co.za> Paul Moore added the comment: ====================================================================== ERROR: test_read_only_directory (test.test_tempfile.TestMkdtemp) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 267, in _inside_empty_temp_dir yield File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 286, in test_read_only_directory self.skipTest("can't set the directory read-only") File "C:\Work\Projects\cpython\lib\unittest\case.py", line 645, in skipTest raise SkipTest(reason) unittest.case.SkipTest: can't set the directory read-only During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 289, in test_read_only_directory self.assertEqual(os.listdir(tempfile.tempdir), []) File "C:\Work\Projects\cpython\lib\contextlib.py", line 77, in __exit__ self.gen.throw(type, value, traceback) File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 269, in _inside_empty_temp_dir support.rmtree(dir) File "C:\Work\Projects\cpython\lib\test\support\__init__.py", line 374, in rmtree _rmtree(path) File "C:\Work\Projects\cpython\lib\test\support\__init__.py", line 354, in _rmtree _waitfor(os.rmdir, path) File "C:\Work\Projects\cpython\lib\test\support\__init__.py", line 301, in _waitfor func(pathname) PermissionError: [WinError 5] Access is denied: 'C:\\Users\\Gustav\\AppData\\Local\\Temp\\tmpe53kiky0' ====================================================================== ERROR: test_read_only_directory (test.test_tempfile.TestMkstempInner) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 267, in _inside_empty_temp_dir yield File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 286, in test_read_only_directory self.skipTest("can't set the directory read-only") File "C:\Work\Projects\cpython\lib\unittest\case.py", line 645, in skipTest raise SkipTest(reason) unittest.case.SkipTest: can't set the directory read-only During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 289, in test_read_only_directory self.assertEqual(os.listdir(tempfile.tempdir), []) File "C:\Work\Projects\cpython\lib\contextlib.py", line 77, in __exit__ self.gen.throw(type, value, traceback) File "C:\Work\Projects\cpython\lib\test\test_tempfile.py", line 269, in _inside_empty_temp_dir support.rmtree(dir) File "C:\Work\Projects\cpython\lib\test\support\__init__.py", line 374, in rmtree _rmtree(path) File "C:\Work\Projects\cpython\lib\test\support\__init__.py", line 354, in _rmtree _waitfor(os.rmdir, path) File "C:\Work\Projects\cpython\lib\test\support\__init__.py", line 301, in _waitfor func(pathname) PermissionError: [WinError 5] Access is denied: 'C:\\Users\\Gustav\\AppData\\Local\\Temp\\tmp0qwkkr7l' ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 19:13:22 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 19 May 2015 17:13:22 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <1432055602.4.0.780529706026.issue23970@psf.upfronthosting.co.za> Steve Dower added the comment: New patch. I've renamed the new class _msvccompiler and changed ccompiler to use it instead of the old ones. The old ones are still there to avoid breaking people who were using them directly, and the old tests are still there too. Personally, I expect subtle breakages in actual use (that we couldn't possible test for reliably) and I don't like deliberately leaving cruft behind, but it seems like the best way to move forward without breaking people. Would adding a deprecation warning to the orphaned modules make sense? They should never be imported in normal use. ---------- Added file: http://bugs.python.org/file39433/msvccompiler_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 19:14:57 2015 From: report at bugs.python.org (Dan Bjorge) Date: Tue, 19 May 2015 17:14:57 +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: <1432055697.4.0.913542246356.issue24127@psf.upfronthosting.co.za> Dan Bjorge added the comment: Confirmed, this is a known Windows 10 tech preview bug - it is specific to using 32bit Python on 64bit Windows. It's already been fixed internally, and we expect the fix to make it out to one of the next couple of public tech preview builds. Thanks! -Dan Bjorge (MSFT) ---------- nosy: +dbjorge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 19:26:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 May 2015 17:26:41 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1432056401.76.0.073502757491.issue22107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Paul. What with updated patch? ---------- Added file: http://bugs.python.org/file39434/tempfile_bad_tempdir_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 19:29:53 2015 From: report at bugs.python.org (Al Sweigart) Date: Tue, 19 May 2015 17:29:53 +0000 Subject: [issue24225] IDLE test filenames don't match script filenames. In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za> Message-ID: <1432056593.23.0.364739153262.issue24225@psf.upfronthosting.co.za> Al Sweigart added the comment: Serhiy: I completely understand. My first instinct is to look at mass renamings and dismiss it as cosmetic changes for the sake of cosmetic changes. However, there are several problems that this fix corrects: 1) It makes it obvious which identifiers are modules and which are classes: - AutoComplete.AutoComplete is a module and class with the same name, making them ambiguous. - Same for AutoCompleteWindow.AutoCompleteWindow. - Same for AutoExpand.AutoExpand. - Bindings.py is a module but there is also a Bindings member in the EditorWindow class. - Same for CallTips.CallTips having ambiguous module/class name. - Same for ClassBrowser.ClassBrowser. - Same for CodeContext.CodeContext. - Same for ColorDelegator.ColorDelegator - But not the same for configDialog.ConfigDialog. - Same for Debugger.Debugger - Same for Delegator.Delegator - Same for EditorWindow (this is a big one, where the ambiguious use is in several files) - Same for FileList.FileList - Same for FormatParagraph.FormatParagraph - Same for HyperParser.HyperParser - Same for IOBinding.IOBinding - Same for MultiCall.MultiCallCreator's inner class, MultiCall. - Same for MultiStatusBar.MultiStatusBar - Same for OutputWindow, ParenMatch, PathBrowser, Percolator, PyShell, ReplaceDialog, RstripExtension, ScriptBinding, ScrolledList, SearchDialog, SearchDialogBase, SearchEngine, ToolTip, UndoDelegator, WidgetRedirector, WindowList, ZoomHeight - There is a StackViewer.py module and a StackViewer class, except the class is in Debugger.py This isn't a trivial, "just remember it works like this in one or two places" kind of technical debt. 2) These ambiguous names can be mitigated with "from x import *" statements; always use "from idlelib.AutoExpand import AutoExpand" and you can always assume "AutoExpand" refers to the class, not the module. But the codebase doesn't consistently do that. There is "from idlelib.AutoExpand import AutoExpand" but also "from idlelib import Debugger" (so in that file, Debugger refers to the module while Debugger.Debugger refers to the class). 2) It puts idle_test names in sync with the files they test. Currently there is a test_config_name.py but there is no config_name.py or configName.py file. (It tests configSectionNameDialog.py) 3) Any extensions that break due to these changes can be fixed in one line: import new_name as OldName I agree that large changes are error prone. In this case, that's partly because names are confusing and ambiguous, which is precisely what this change tries to mitigate. I really beg folks to not dismiss this change out of hand. These readability issues are death-by-a-thousand-paper-cuts. I think we should address this technical debt, not actively preserve it. IDLE dev is at a standstill, with the bulk of it resting on the efforts of a handful of people. Getting it into a better state can invite more contributors (I can personally name some people who would want to become involved with IDLE but are intimidated by labyrinthine codebases.) I volunteer to test any extension people can name for compatibility issues with this change. (Where should I start? IDLEX? The https://wiki.python.org/moin/IDLEextensions also lists lwickjr. Are there any others?) All the unit tests pass after these changes, which is something at least. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 19:29:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 May 2015 17:29:59 +0000 Subject: [issue24228] Interpreter triggers segmentation fault at the starting In-Reply-To: <1431964179.84.0.528825481324.issue24228@psf.upfronthosting.co.za> Message-ID: <1432056599.58.0.437457554495.issue24228@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 19:54:11 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 19 May 2015 17:54:11 +0000 Subject: [issue24225] IDLE test filenames don't match script filenames. In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za> Message-ID: <1432058051.1.0.0271287834097.issue24225@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The idlelib xyz.py filenames (about 60) are a collectively a mess. There are about 6 different styles. I would like to *eventually* change all to short, lowercase, PEP-8 names, but the reasons have nothing to do with test names (which intentionally look to the future). 1. The variety of styles and length of some makes some hard to learn and remember. This discourages new people from working on Idle code. After years, I still find some a problem. For this purpose, the patch does not go far enough. Merely changing 'X' to '_x' does not make a long, multi word or word pieces name into a short, one-word name. For examples: config_section_name_dialog.py and dyn_option_menu_widget.py are not where I want to end up. 2. Having a module and a class with the same name is confusing. Consider 'EditorWindow'. In text, having to disambiguate by appending 'module' or 'class' is a nuisance. In code, even that is not possible. One must jump up to the top of a file to see if the import is 'import EditorWindow' or 'from EditorWindow import EditorWindow'. 3. A deeper reason I want name changes to be possible is that I would also like to be able to do some package-level refactoring. 60 files is already a lot and we may need more. I think AutoComplete.py and AutoCompleteWindow.py should be combined into completions.py. I would combine CallTips.py and CallTipWindow.py (I had to look to be sure it was not CallTipsWindow.py) into calltips.py. In the other hand, PyShell.py has startup code (which I think might better be in a separate startup.py), some code for debugger and editor windows, and finally shell window code. I think the confusing Window class hierarchy should be redone, which would also mean some file reshuffling and renaming. 4. PEP434 suggested that a few generally useful, non-Idle specific files might be moved to the tkinter package. This would also be a name change. One problem with name changes is continued support for 2.7, which was originally scheduled to end about now. If it were not for that, it would more easily be possible to introduce new names in some 3.x.0, possible after deprecation warnings. Another barrier is the unknown usage by extensions of parts of idlelib beyond the narrow interface defined in extend.txt: an EditorWindow instance with Test, IOBinding, and FileList instances. Summary: I agree with the goal. But I have to reject the current patch because a) the change will have to be a process, not a single patch, and b) I do not agree with many of the new names. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 20:11:22 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 19 May 2015 18:11:22 +0000 Subject: [issue24215] test_trace uses test_pprint In-Reply-To: <1431842150.15.0.237267681297.issue24215@psf.upfronthosting.co.za> Message-ID: <1432059082.12.0.866228418107.issue24215@psf.upfronthosting.co.za> Terry J. Reedy added the comment: My recipe worked for me, but I am not surprised that it might fail elsewhere. Is the specific purpose of the two problemmatic test_trace test to test that trace works with unittest? It did not seem like it to me. If not, test_trace could be decoupled from other tests and use a 'tracetest.py' file that defines one function to be traced. In the meanwhile, I think you should disable the two tests in test_trace and apply the test_pprint changes, rather than hold test_pprint hostage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 20:11:46 2015 From: report at bugs.python.org (juj) Date: Tue, 19 May 2015 18:11:46 +0000 Subject: [issue22442] subprocess.check_call hangs on large PIPEd data. In-Reply-To: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za> Message-ID: <1432059106.45.0.332163317225.issue22442@psf.upfronthosting.co.za> juj added the comment: This issue still reads open, but there has not been activity in a long time. May I ask what is the latest status on this? Also, any chance whether this will be part of Python 2.x? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 20:11:56 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 19 May 2015 18:11:56 +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: <1432059116.17.0.853833108452.issue24127@psf.upfronthosting.co.za> Paul Moore added the comment: Fantastic news, thanks for the feedback. Closing this as a third party issue. ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 20:13:43 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 19 May 2015 18:13:43 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1432059223.97.0.998743242358.issue22107@psf.upfronthosting.co.za> Paul Moore added the comment: Works fine with the new patch: >.\rt.bat -x64 -q test_tempfile C:\Work\Projects\cpython\PCbuild>"C:\Work\Projects\cpython\PCbuild\amd64\python.exe" -Wd -E -bb "C:\Work\Projects\cpython\PCbuild\..\lib\test\regrtest.py" test_tempfile [1/1] test_tempfile 1 test OK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 20:55:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 May 2015 18:55:51 +0000 Subject: [issue23985] Crash when deleting slices from duplicated bytearray In-Reply-To: <1429252668.91.0.45841644858.issue23985@psf.upfronthosting.co.za> Message-ID: <20150519185548.44677.39710@psf.io> Roundup Robot added the comment: New changeset 98c1201d8eea by Antoine Pitrou in branch '3.4': Issue #23985: Fix a possible buffer overrun when deleting a slice from the front of a bytearray and then appending some other bytes data. https://hg.python.org/cpython/rev/98c1201d8eea New changeset 06fab9093973 by Antoine Pitrou in branch 'default': Issue #23985: Fix a possible buffer overrun when deleting a slice from the front of a bytearray and then appending some other bytes data. https://hg.python.org/cpython/rev/06fab9093973 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 21:06:47 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 May 2015 19:06:47 +0000 Subject: [issue23985] Crash when deleting slices from duplicated bytearray In-Reply-To: <1429252668.91.0.45841644858.issue23985@psf.upfronthosting.co.za> Message-ID: <1432062407.58.0.647998681149.issue23985@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've committed the patch. Thanks, Martin! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 21:22:18 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 19 May 2015 19:22:18 +0000 Subject: [issue24199] Idle: remove idlelib.idlever.py and its use in About dialog In-Reply-To: <1431650285.59.0.600694723613.issue24199@psf.upfronthosting.co.za> Message-ID: <1432063338.3.0.736143701816.issue24199@psf.upfronthosting.co.za> Terry J. Reedy added the comment: To answer my question, I checked test___all__.py. The check_all helper has this: with support.check_warnings( (".* (module|package)", DeprecationWarning), ("", ResourceWarning), quiet=True): I presume this means that DeprecationWarnings raised by the following import are suppressed. (There is also a blacklist.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 21:51:33 2015 From: report at bugs.python.org (Henrik Heimbuerger) Date: Tue, 19 May 2015 19:51:33 +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: <1432065093.16.0.495570958229.issue24127@psf.upfronthosting.co.za> Henrik Heimbuerger added the comment: Dan, thanks so much for taking the time to post back here, and for the good news! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 22:08:32 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 19 May 2015 20:08:32 +0000 Subject: [issue24225] Idlelib: changing file names In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za> Message-ID: <1432066112.12.0.153198665642.issue24225@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Nick, as PEP 434 approver, I would like your comments on this issue. The pep says that other than the startup modules, "the modules are undocumented and effectively private implementations." It also says that the documented extension API should be respected but is vague about the extent to which the existence of extensions should otherwise be reasons to block changes to idlelib. While this issue is about module names, changes to names and behavior within modules could also break extensions. We have in fact made such changes without worring about this. Fedora 22 replaced yum with dnf as its package managater. Accordig to http://dnf.baseurl.org/2015/05/11/yum-is-dead-long-live-dnf/ one of the reasons is problems with extensions. "Yum plugins are using any method from Yum code base thus any change there would cause the sudden crash of the Yum utility." (What yum and idlelib have is common is mostly being undocumented.) In a comment, the author summed up my feelings with respect to idlelib: "It really hard to maintain a project where you can?t change anything." An example is #24199. I want to remove a zombie module, idlever. Can I? At least for 2.7 and 3.4, I think I will add a deprecation warning. If we rename and refactor modules for 3.6, I would propose to add stub files to 2.7 and 3.5 with imports and a deprecation warning. A combined completions module, for example, would get two stub files. (An alternative for 2.7 could be to fix the worst bugs, declare Idle 2.7 frozen, and stop backporting.) During the PEP 434 discussion, some core developers said that they would like to drop Idle completely. This would break extensions much more thoroughly than changes proposed here. Al: some research into extension practices would be helpful. But keep in mind that idlex is much more than a set of extension modules. I believe it adds its own ui. Al: the current discrepancies between module and test names are intentional. The 'controversy' is entirely about idlelib, hence the title change. When idlelib modules get 'nice' names, test names can be changed to match. ---------- nosy: +ncoghlan title: IDLE test filenames don't match script filenames. -> Idlelib: changing file names versions: +Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 22:13:33 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 19 May 2015 20:13:33 +0000 Subject: [issue24225] Idlelib: changing file names In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za> Message-ID: <1432066413.94.0.699901993266.issue24225@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Al, I meant to add that msg243612 better expresses the proper rationale for disruptive changes: making it easier for people (newcomers and this no-longer-newcomer) to learn idlelib, fix bugs, and make improvements ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 22:23:23 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 May 2015 20:23:23 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1432067003.21.0.46451773672.issue4709@psf.upfronthosting.co.za> R. David Murray added the comment: My understanding matches yours, Paul. Core does not want to *distribute* a mingw built python, but if the mingw community came up with a support strategy, including one or more buildbots building using mingw, I believe that we would accept the patches. Basically, it has to meet the PEP 11 rules for supported platforms (including enough userbase to produce the people to maintain it long term :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 22:24:39 2015 From: report at bugs.python.org (Ralf Gommers) Date: Tue, 19 May 2015 20:24:39 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1432067079.93.0.14061370896.issue4709@psf.upfronthosting.co.za> Ralf Gommers added the comment: A few comments from the perspective of what's needed for the scientific Python stack: 1. Of the three options mentioned in msg243605, it's definitely (3) that is of interest. We want to build extensions with MinGW-w64 that work with the standard MSVC Python builds. We've done this with mingw32 for a very long time (which works fine); not being able to do this for 64-bit extensions is the main reason why there are no official 64-bit Windows installers for Numpy, Scipy, etc. 2. There is work ongoing on a mingw-w64 toolchain that would work for the scientific Python stack: https://github.com/numpy/numpy/wiki/Mingw-static-toolchain. It actually works pretty well today, what needs to be sorted out is ensuring long-term maintainability. More details about what it's based on are provided in https://github.com/numpy/numpy/wiki/Mingw-w64-faq - I think it's consistent with what Ruben van Boxem recommends. Carl Kleffner, who has done a lot of the heavy lifting on this toolchain, is working with upstream mingw-w64 and with WinPython to ensure not creating yet another incompatible flavor mingw. 3. It's good to realize why making mingw-w64 work is especially important for the scientific Python stack: there's a lot of Fortran code in packages like Scipy, for which there is no free compiler that works with MSVC. So one could use MSVC + ifort + Intel MKL (which is what Enthought Canopy and Continuum Anaconda do), but that's quite expensive and therefore not a good solution for the many of contributors to the core scientific Python stack nor okay from the point of view of needing to provide official binaries that can be redistributed. Paul's comments on picking a single mingw-w64 version, and that version not being a download from someone's personal homepage, make a lot of sense to me. We (Carl & several core numpy/scipy/scikit-learn devs) happened to have planned a call on this topic soon in order to move towards a long-term sustainable plan. I wouldn't expect everything to be sorted out in a couple of weeks (it's indeed a hard goal), but knowing that Paul is willing to review and merge patches definitely helps. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 23:14:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 May 2015 21:14:45 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <20150519211442.26854.83312@psf.io> Roundup Robot added the comment: New changeset 63f0ae6e218a by Serhiy Storchaka in branch '2.7': Issue #22107: tempfile.gettempdir() and tempfile.mkdtemp() now try again https://hg.python.org/cpython/rev/63f0ae6e218a New changeset 3a387854d106 by Serhiy Storchaka in branch '3.4': Issue #22107: tempfile.gettempdir() and tempfile.mkdtemp() now try again https://hg.python.org/cpython/rev/3a387854d106 New changeset 1134198e23bd by Serhiy Storchaka in branch 'default': Issue #22107: tempfile.gettempdir() and tempfile.mkdtemp() now try again https://hg.python.org/cpython/rev/1134198e23bd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 23:20:15 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 May 2015 21:20:15 +0000 Subject: [issue20691] inspect.signature: Consider exposing 'follow_wrapper_chains' option in public API In-Reply-To: <1392848461.48.0.35558236528.issue20691@psf.upfronthosting.co.za> Message-ID: <1432070415.65.0.944235584947.issue20691@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, > However, as noted, I doubt the latter is worth it - let's just expose the flag to decide whether to resolve wrapper chains or not, and leave the inclusion of the already bound value in the reported signature solely as a legacy behaviour of getargspec and getfullargspec. I agree. Please take a look at the attached patch. BTW, Signature.from_function and Signature.from_builtin aren't documented. Do you think it's OK if I drop them? There is no good use case for them (and we have Signature.from_callable in 3.5). Also, while working on the patch, I noticed that functools.wraps copies __annotations__ attribute. This is really strange. Most of the times, wrapper in python has signature akin to (*args, **kwargs). Blindly copying __annotations__ doesn't make any sense. What do you think about this? ---------- keywords: +patch Added file: http://bugs.python.org/file39435/sig_wrapped.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 23:24:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 May 2015 21:24:32 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1432070672.59.0.100405300183.issue22107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Unfortunately the patch doesn't fix original issue and looks as this can't be fixed until os.access will be more useful on Windows. But it fixes several related issues. mkstemp() now fails early if parent directory doesn't exist or is a file. gettempdir() and mkdtemp() now try again in case of collision on Windows as well as on Unix. I hope that fixing os.access will automatically fix original issue. Thanks Mark and Paul for testing on Windows. Thanks Tim for explaining issue with os.access. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 19 23:26:38 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 May 2015 21:26:38 +0000 Subject: [issue20691] inspect.signature: Consider exposing 'follow_wrapper_chains' option in public API In-Reply-To: <1392848461.48.0.35558236528.issue20691@psf.upfronthosting.co.za> Message-ID: <1432070798.75.0.722953874756.issue20691@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Do you think it's OK if I drop them? Dropping == DeprecationWarning ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 00:17:59 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 19 May 2015 22:17:59 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1432073879.82.0.00350163706455.issue4709@psf.upfronthosting.co.za> Paul Moore added the comment: Ralf, thanks for the comments. The scientific community is definitely the key group that *need* mingw (as opposed to people who merely want to use it because they don't want to buy into MS compilers, or for similar personal reasons). My personal view is that if the scientific community comes up with a mingw/gcc toolchain that they are happy with, and willing to support, then I would see that as a reasonable target to be "the" supported mingw toolchain for distutils. I'd like to see a single-file "download, unzip, and use" distribution rather than the current rather intimidating set of instructions on how to set the toolchain up - but I'm sure that's part of what you're intending to cover under "ensuring long-term maintainability". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 00:29:37 2015 From: report at bugs.python.org (Majeed Arni) Date: Tue, 19 May 2015 22:29:37 +0000 Subject: [issue10762] strftime('%f') segfault In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za> Message-ID: <1432074577.54.0.0755416276418.issue10762@psf.upfronthosting.co.za> Majeed Arni added the comment: The problem still exists in 3.4 and 3.5 a4 Unhandled exception in thread started by ---------- nosy: +MajeedArni versions: +Python 3.4, Python 3.5 -Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 00:51:09 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 19 May 2015 22:51:09 +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: <1432075869.9.0.338672542715.issue20344@psf.upfronthosting.co.za> Martin Panter added the comment: ?Only the first element . . . will be executed on Unix? is a bit simplistic. The behaviour is already described more fully in the ?shell? documentation under . Also, ?args? is allowed to be a _sequence_, but an _iterable_ is a more general concept. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 00:52:03 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 19 May 2015 22:52:03 +0000 Subject: [issue12020] Attribute error with flush on stdout,stderr In-Reply-To: <1304703877.7.0.898555574271.issue12020@psf.upfronthosting.co.za> Message-ID: <1432075923.16.0.307592672333.issue12020@psf.upfronthosting.co.za> Martin Panter added the comment: The documentation already says that ?stdout? and friends are meant to be text files, and that they may be replaced with file-like objects like StringIO. Perhaps the documentation could be more explicit about what text file API is required internally (either TextIOBase, or list the required subset of methods). ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 00:52:39 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 19 May 2015 22:52:39 +0000 Subject: [issue6445] Add check parameter to subprocess.Popen.communicate In-Reply-To: <1247131793.49.0.582429022768.issue6445@psf.upfronthosting.co.za> Message-ID: <1432075959.16.0.57122673624.issue6445@psf.upfronthosting.co.za> Martin Panter added the comment: In the mean time, a subprocess.run() API has been added which can call communicate() and raise CalledProcessError in one step (depending on arguments). See Issue 23342. This might satisfy some use cases, but maybe adding the check functionality to the low-level API would be nice as well. Perhaps a separate check_exit_status() method would be more flexible? Or maybe a flag stored in the subprocess object that causes wait() and poll() to do the check? ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 01:21:45 2015 From: report at bugs.python.org (Case Van Horsen) Date: Tue, 19 May 2015 23:21:45 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1432077705.21.0.479016336454.issue4709@psf.upfronthosting.co.za> Changes by Case Van Horsen : ---------- nosy: +casevh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 01:35:58 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 19 May 2015 23:35:58 +0000 Subject: [issue24225] Idlelib: changing file names In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za> Message-ID: <1432078558.38.0.554612829086.issue24225@psf.upfronthosting.co.za> Nick Coghlan added the comment: One path you may want to consider is progressively factoring out a public "idlelib.extensions" API, and treat everything else in idlelib as fair game for renaming. Folks tend to be more tolerant of disruption if the new state of affairs is also clearly better for them, not just the folks making the change. In terms of supporting legacy module names without retaining all that complexity in the main source code, I'd suggest looking into the way the "six.moves" module works. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 02:03:20 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 20 May 2015 00:03:20 +0000 Subject: [issue10762] strftime('%f') segfault In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za> Message-ID: <1432080200.05.0.217495594416.issue10762@psf.upfronthosting.co.za> Ned Deily added the comment: Majeed, the fixes for this issue were released several years ago and the issue has been closed. Comments on it will likely be ignored. If you believe there is a problem in the current versions of Python 3 (3.4.3) or Python 2 (2.7.9), please open a new issue with appropriate supporting documentation of how to reproduce the problem (including platforms and versions used) and any resulting tracebacks. ---------- nosy: +ned.deily versions: +Python 2.7, Python 3.2 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 02:55:29 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 May 2015 00:55:29 +0000 Subject: [issue23889] Speedup inspect.Signature.bind In-Reply-To: <1428514670.65.0.478019521392.issue23889@psf.upfronthosting.co.za> Message-ID: <1432083329.36.0.116064786395.issue23889@psf.upfronthosting.co.za> Yury Selivanov added the comment: After some experiments, it looks like bind() is already pretty fast. The only way to increase its performance is to rewrite it in C. I tried to approaches: 1. Refactor ._bind() to produce a high-level instruction set that can be cached, and is fast to iterate through and build BoundArguments. Repo: https://github.com/1st1/cpython/tree/bind Results: ==================================== =========== ============== =============== function / call bind (3.4) bind cache hit bind cache miss ==================================== =========== ============== =============== () / () 0.716s 0.746s (-4%) 0.799s (-10%) (a, b=1) / (10) 1.140s 0.910s (+20%) 1.294s (-12%) (a, b=1, *ar) / (10, 20, 30, 40) 1.352s 1.145s (+15%) 1.520s (-11%) (a, b=1, **ar) / (10, 20, z=30, y=4) 1.364s 1.233s (+10%) 1.660s (-18%) (a, b=1, *, z, **ar) / (1,2,z=3,y=4) 1.499s 1.363s (+10%) 1.897s (-26%) 2. Refactor ._bind() to compile a function that builds BoundArguments for te given args/kwargs shape. This approach yields more-or-less same results as (1), but performance of cache-miss case is just terrible (-200%). Compiling functions on the fly is expensive. Repo to play with: https://github.com/1st1/cpython/tree/bind_jit I'm closing this issue, until I (or someone else) can implement bind() in C (or come up with a faster pure-python implementation). ---------- resolution: -> postponed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 03:30:25 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 May 2015 01:30:25 +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: <1432085425.67.0.0550469600383.issue20344@psf.upfronthosting.co.za> R. David Murray added the comment: Can you suggest a better phrasing that is still succinct? (Maybe just 'appear to be executed' would make it accurate enough?) But, that's why there needs to be a reference of *some* sort to the full explanation. I'm not sure what the issue is with iterable/sequence. check_output/Popen accepts an iterable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 04:16:33 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 20 May 2015 02:16:33 +0000 Subject: [issue16261] Fix bare excepts in various places in std lib In-Reply-To: <1350461165.29.0.129000928595.issue16261@psf.upfronthosting.co.za> Message-ID: <1432088193.96.0.839914168832.issue16261@psf.upfronthosting.co.za> Martin Panter added the comment: I reviewed the patch on Reitveld. All of the changes that do not have comments look okay to me, although some will definitely have merge conflicts with the current code. If someone updated the patch based on the comments, I think it may be okay to commit. ---------- nosy: +vadmium stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 06:02:42 2015 From: report at bugs.python.org (swanson) Date: Wed, 20 May 2015 04:02:42 +0000 Subject: [issue24243] behavior for finding an empty string is inconsistent with documentation Message-ID: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za> New submission from swanson: Background: ----------- Perhaps this has been addressed elsewhere, but I couldn't find it. To me, semantically, the whole idea of finding nothing, whether in something or in nothing is complete and utter nonsense. I'm a fail-quickly, fail-loudly kind of guy, and I'd prefer that any attempt to find nothing would result in an exception being raised. But for whatever reason, the following behavior has long existed: >>> "".index("") == "A".index("") == 0 True >>> "" in "" and b"" in b"" and b"" in bytearray(b"") True >>> "" in "A" and b"" in b"A" and b"" in bytearray(b"A") True The Problem: ------------ The various string types (str, bytes, bytearray) all have the following functions: count, find, rfind, index, rindex Each of these functions accepts optional parameters "start" and "end". The documentation for each says something like "Optional arguments start and end are interpreted as in slice notation." This is not the case. On the one hand: >>> "".find("") == ""[0:0].find("") == "".find("", 0, 0) == 0 True Consistent so far, however: >>> "".find("") == ""[1:0].find("") == 0 and "".find("", 1, 0) == -1 True So, you see that 'start' and 'end' are NOT in all cases interpreted the same way as slicing. This problem has been around forever, affecting both Python 3 and 2, so I don't know how many people's code you'd break if you changed the behavior to make it consistent with the docs. But if it's not going to be changed, it should at least be a well-documented "feature" of the functions with a line or two of explanation in the relevant docs: https://docs.python.org/3/library/stdtypes.html#bytes-and-bytearray-operations https://docs.python.org/3/library/stdtypes.html#string-methods The built-in types bytes, bytearray, and str also have the functions "startswith" and "endswith" that also take optional 'start' and 'end' arguments. The documentation does not specifically say (as for count, (r)find, and (r)index) that these are "interpreted as in slice notation". Instead, it says: "With optional start, test string beginning at that position. With optional end, stop comparing string at that position." That wording is equally confusing and erroneous. The natural interpretation of that would lead you to believe that, unlike slicing: "A".startswith("A",0,0) == True however it's really == False because the 'end' index is like slicing. Now, as to the interpretation of finding nothing, it's a mixed bag: For str: >>> "".startswith("",0,0) True >>> "".startswith("",1,0) True >>> "".endswith("",0,0) True >>> "".endswith("",1,0) True For bytes: (and the same for bytearray) >>> b"".startswith(b"",0,0) True >>> b"".startswith(b"",1,0) False >>> b"".endswith(b"",0,0) True >>> b"".endswith(b"",1,0) False ---------- assignee: docs at python components: Documentation messages: 243640 nosy: docs at python, swanson priority: normal severity: normal status: open title: behavior for finding an empty string is inconsistent with documentation type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 06:37:46 2015 From: report at bugs.python.org (Majeed Arni) Date: Wed, 20 May 2015 04:37:46 +0000 Subject: [issue24244] Python Crash on strftime with %f on Python 3 Message-ID: <1432096666.93.0.307433086156.issue24244@psf.upfronthosting.co.za> New submission from Majeed Arni: http://bugs.python.org/issue11735 fixed in 2.7, but in 3.4 and 3.5 the same problem exists. Just crashes python. ---------- components: Library (Lib) messages: 243641 nosy: MajeedArni priority: normal severity: normal status: open title: Python Crash on strftime with %f on Python 3 versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 07:09:42 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 20 May 2015 05:09:42 +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: <1432098582.7.0.96858124014.issue20344@psf.upfronthosting.co.za> Martin Panter added the comment: Actually David I didn?t notice your suggested wording before. Adding that last sentence, pointing to the full description of the Popen constructor, would be fine. My complaint about mentioning ?iterable? is that iterables are not mentioned anywhere else in the documentation. I would rather leave it out or change it to ?sequence?, unless the rest of the documentation is made consistent, e.g. ?args . . . should be a string, or a sequence of program arguments? would also need fixing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 07:09:56 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 20 May 2015 05:09:56 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1432098596.31.0.499242133762.issue24230@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Attached is a patch with implementation, tests and docs. I didn't have to duplicate too much thankfully. Just figure out where to put the type conversions. Review would be nice, but I'll err on the side of getting this in before beta 1 (May 24 per https://www.python.org/dev/peps/pep-0478/) so any corrections can be dealt with during the beta cycle. Augie & Matt, can you confirm that this patch does what y'all need for Mercurial? ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file39436/issue24230-gps01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 07:14:40 2015 From: report at bugs.python.org (Tushar) Date: Wed, 20 May 2015 05:14:40 +0000 Subject: [issue24236] TestNG results to Junit results conversion In-Reply-To: <1432016165.44.0.72267035394.issue24236@psf.upfronthosting.co.za> Message-ID: <1432098880.87.0.760750883662.issue24236@psf.upfronthosting.co.za> Tushar added the comment: The intention was to facilitate the user who want to port TestNG reports format to Junit standard format. I sent a mail to PSF mailing list and I got the pointer that this can't be part of standard library but PyPI. So I will upload this as a package instead of a part of std library. ---------- components: +Devguide -Extension Modules nosy: +ezio.melotti, willingc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 07:15:23 2015 From: report at bugs.python.org (Tushar) Date: Wed, 20 May 2015 05:15:23 +0000 Subject: [issue24236] TestNG results to Junit results conversion In-Reply-To: <1432016165.44.0.72267035394.issue24236@psf.upfronthosting.co.za> Message-ID: <1432098923.42.0.572850944576.issue24236@psf.upfronthosting.co.za> Changes by Tushar : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 07:48:18 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 20 May 2015 05:48:18 +0000 Subject: [issue24245] Eliminate do-nothing exception handlers Message-ID: <1432100898.34.0.483516641129.issue24245@psf.upfronthosting.co.za> New submission from Martin Panter: These changes remove exception handlers that simply reraise the exception. They are not needed because either they are at the end of the exception handler list, or the exception being reraised would not be caught by any other handler (e.g. no need to reraise SystemExit if you are only interested in Exception). I think they make the code more confusing to read. I noticed the tkinter/font.py dead code when reading the code, Victor Stinner pointed out the distutils case in Issue 21259, and I found the rest by searching for similar cases. Lib/distutils/core.py | 2 -- Lib/idlelib/idle.pyw | 26 +++++++++++--------------- Lib/idlelib/rpc.py | 5 +---- Lib/test/regrtest.py | 4 ---- Lib/test/test_queue.py | 10 +++------- Lib/test/test_urllib2net.py | 2 -- Lib/tkinter/font.py | 2 -- Lib/unittest/test/support.py | 4 ---- ---------- components: Distutils, IDLE, Library (Lib), Tests, Tkinter files: reraise.patch keywords: patch messages: 243645 nosy: dstufft, eric.araujo, vadmium priority: normal severity: normal stage: patch review status: open title: Eliminate do-nothing exception handlers type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39437/reraise.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 07:48:27 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 May 2015 05:48:27 +0000 Subject: [issue24244] Python Crash on strftime with %f on Python 3 In-Reply-To: <1432096666.93.0.307433086156.issue24244@psf.upfronthosting.co.za> Message-ID: <1432100907.73.0.72094984492.issue24244@psf.upfronthosting.co.za> R. David Murray added the comment: Please follow Ned's suggestion that prompted you to open this issue and report the exact version of python, your OS, and how to reproduce it. I cannot reproduce it based on the existing issues using python 3.4.1 on Windows 7. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 07:55:15 2015 From: report at bugs.python.org (Ralf Gommers) Date: Wed, 20 May 2015 05:55:15 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1432101315.73.0.998430021455.issue4709@psf.upfronthosting.co.za> Ralf Gommers added the comment: Indeed, our idea of "easy to install" was/is a wheel or set of wheels so that "pip install mingw64py" does all you need. If necessary that can of course be repackaged as single download to unzip as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 08:36:40 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 20 May 2015 06:36:40 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1432103800.25.0.226011310855.issue24230@psf.upfronthosting.co.za> Martin Panter added the comment: Doing a quick review, expect a few comments on Rietveld ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 08:57:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 May 2015 06:57:15 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1432105035.9.0.977271651441.issue24230@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added comments on Rietveld. But I'm not sure that this change is worth to do. Only low-level functions in os.path and os modules (and few other) support bytes names (and only bytes, not bytearray!). High level interfaces, such as in tarfile or zipfile, work only with str paths. The question is what level the tempfile module? In any way Mercurial people need their own wrapper if they want to support Python <3.5. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 09:21:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 May 2015 07:21:54 +0000 Subject: [issue16261] Fix bare excepts in various places in std lib In-Reply-To: <1350461165.29.0.129000928595.issue16261@psf.upfronthosting.co.za> Message-ID: <1432106514.07.0.000417723886317.issue16261@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka stage: needs patch -> patch review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 09:34:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 May 2015 07:34:07 +0000 Subject: [issue16261] Fix bare excepts in various places in std lib In-Reply-To: <1350461165.29.0.129000928595.issue16261@psf.upfronthosting.co.za> Message-ID: <20150520073404.26582.63277@psf.io> Roundup Robot added the comment: New changeset b3a7215b9ce4 by Serhiy Storchaka in branch 'default': Issue #16261: Converted some bare except statements to except statements https://hg.python.org/cpython/rev/b3a7215b9ce4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 09:35:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 May 2015 07:35:47 +0000 Subject: [issue16261] Fix bare excepts in various places in std lib In-Reply-To: <1350461165.29.0.129000928595.issue16261@psf.upfronthosting.co.za> Message-ID: <1432107347.72.0.0460615704423.issue16261@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Resolved conflicts, fixed some noted issues in the patch and committed unquestionable changes. Thank you for your patch Ramchandra. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 09:39:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 May 2015 07:39:08 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1432107548.94.0.752724933514.issue21259@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Just committed smaller patch in issue16261 and closed the issue. Not all changes in the patch in this issue look innocent and correct. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 09:40:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 May 2015 07:40:22 +0000 Subject: [issue24245] Eliminate do-nothing exception handlers In-Reply-To: <1432100898.34.0.483516641129.issue24245@psf.upfronthosting.co.za> Message-ID: <1432107622.47.0.965026385461.issue24245@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 10:09:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 May 2015 08:09:54 +0000 Subject: [issue24245] Eliminate do-nothing exception handlers In-Reply-To: <1432100898.34.0.483516641129.issue24245@psf.upfronthosting.co.za> Message-ID: <1432109394.64.0.554420645967.issue24245@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Changes look mostly good, but IDLE changes should be applied to all versions and the code in test_queue.py is dim. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 14:18:32 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 May 2015 12:18:32 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1432124312.23.0.793555456913.issue24230@psf.upfronthosting.co.za> R. David Murray added the comment: We have a number of other places in the stdlib where bytes-in-bytes-out is observed, at various levels of abstraction. I think this is reasonable. To answer your direct question, I think tempfile is a convenience-and-do-it-right wrapper around what is really a pretty low level operation (creating a temporary file/directory securely). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 14:26:21 2015 From: report at bugs.python.org (Emmanuel Gamby) Date: Wed, 20 May 2015 12:26:21 +0000 Subject: [issue24246] mimetypes.guess_extension returns different values when init() is called several times Message-ID: <1432124781.6.0.673195721551.issue24246@psf.upfronthosting.co.za> New submission from Emmanuel Gamby: Hi, Following the principle of least astonishment, I would expect the function to return the same value. Python 2.7.3 (default, Mar 13 2014, 11:03:55) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mimetypes >>> mimetypes.init() >>> mimetypes.guess_extension('text/plain') '.ksh' >>> mimetypes.init() >>> mimetypes.guess_extension('text/plain') '.asc' >>> mimetypes.init() >>> mimetypes.guess_extension('text/plain') '.txt' It seems that each call overrides the global dictionnary, which changes the iteration order of the next call. Best Regards, Emmanuel ---------- components: Library (Lib) messages: 243655 nosy: egamby priority: normal severity: normal status: open title: mimetypes.guess_extension returns different values when init() is called several times versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 14:27:05 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 20 May 2015 12:27:05 +0000 Subject: [issue24243] behavior for finding an empty string is inconsistent with documentation In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za> Message-ID: <1432124825.33.0.978796634428.issue24243@psf.upfronthosting.co.za> Martin Panter added the comment: There are a few related issues here I think: 1. Empty string search: I think it is completely valid to be able to find an empty string inside another string, at least as long as the slice indexes are within range. Although I remember it was a bit of a revelation the first time I considered this. Anyway, the documentation should explicitly mention this case. 2. "".find("", 1, 0) -> -1: This is inconsistent with startswith() and slicing, but the only reasonable alternative would be to return 1, which would be a strange index for an empty string. Certainly needs documenting though. 3. starts/endswith() slice arguments: I think they should be described equivalently to find() etc. So ?start? points to the first character, ?end? points after the last character, negative indexes from the end, etc. 4. "".startswith("", 1, 0): This is True for str, and False for bytes, which is terribly inconsistent. My gut says both should be False, to match how find() works. Some other related undocumented quirks: >>> "abcd".count("") # Infinity? End of the universe? No! 5 >>> "abcd".replace("", "_", 10) # Might expect 10 underscores '_a_b_c_d_' >>> "abcd".split("", 10) # Might expect a list of 11 strings ValueError: empty separator >>> "abcd".partition("") # Why not ("", "", "abcd")? ValueError: empty separator ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 14:28:52 2015 From: report at bugs.python.org (Emmanuel Gamby) Date: Wed, 20 May 2015 12:28:52 +0000 Subject: [issue24246] mimetypes.guess_extension returns different values when init() is called several times In-Reply-To: <1432124781.6.0.673195721551.issue24246@psf.upfronthosting.co.za> Message-ID: <1432124932.31.0.0245510298865.issue24246@psf.upfronthosting.co.za> Changes by Emmanuel Gamby : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 14:48:52 2015 From: report at bugs.python.org (Matteo Dell'Amico) Date: Wed, 20 May 2015 12:48:52 +0000 Subject: [issue24068] statistics module - incorrect results with boolean input In-Reply-To: <1430211206.61.0.689765465928.issue24068@psf.upfronthosting.co.za> Message-ID: <1432126132.22.0.461626810332.issue24068@psf.upfronthosting.co.za> Changes by Matteo Dell'Amico : ---------- nosy: +della _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 15:15:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 May 2015 13:15:52 +0000 Subject: [issue24245] Eliminate do-nothing exception handlers In-Reply-To: <1432100898.34.0.483516641129.issue24245@psf.upfronthosting.co.za> Message-ID: <20150520131549.10796.56693@psf.io> Roundup Robot added the comment: New changeset 004c689d259c by Serhiy Storchaka in branch 'default': Issue #24245: Eliminated senseless expect clauses that have no any effect. https://hg.python.org/cpython/rev/004c689d259c New changeset 56e1d24806b3 by Serhiy Storchaka in branch '2.7': Issue #24245: Eliminated senseless expect clauses that have no any effect in https://hg.python.org/cpython/rev/56e1d24806b3 New changeset f10ba5313fbb by Serhiy Storchaka in branch '3.4': Issue #24245: Eliminated senseless expect clauses that have no any effect in https://hg.python.org/cpython/rev/f10ba5313fbb New changeset 5deb169ebb22 by Serhiy Storchaka in branch 'default': Issue #24245: Eliminated senseless expect clauses that have no any effect in https://hg.python.org/cpython/rev/5deb169ebb22 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 15:18:42 2015 From: report at bugs.python.org (swanson) Date: Wed, 20 May 2015 13:18:42 +0000 Subject: [issue24243] behavior for finding an empty string is inconsistent with documentation In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za> Message-ID: <1432127922.77.0.566669584573.issue24243@psf.upfronthosting.co.za> swanson added the comment: Thanks for pointing out how count and replace operate. I don't mind the "ValueError: empty separator" on split and partition - makes sense to me. re: "at least as long as the slice indexes are within range" If the slices indexes had to be in range, that would be inconsistent with the behavior of slicing, which is inconsistent with the docs, which was my main point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 15:19:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 May 2015 13:19:58 +0000 Subject: [issue24245] Eliminate do-nothing exception handlers In-Reply-To: <1432100898.34.0.483516641129.issue24245@psf.upfronthosting.co.za> Message-ID: <1432127998.85.0.56828238202.issue24245@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed all changes except test_queue.py. Looks as this file is worth separate issue for refactoring. For example asserRaises() can be used in multiple places instead of try/fail/except idiom. May be there is other non-idiomatic code. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 15:30:40 2015 From: report at bugs.python.org (eryksun) Date: Wed, 20 May 2015 13:30:40 +0000 Subject: [issue10653] test_time test_strptime fails on windows In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za> Message-ID: <1432128640.8.0.377125320908.issue10653@psf.upfronthosting.co.za> eryksun added the comment: This solution no longer works. If the system is configured to use the Japanese system locale and language pack, then 3.4.3 returns codepage 932 mojibake for the "%Z" time zone name. Originally [this approach worked][1] because it called PyUnicode_Decode using the 'mbcs' encoding. Currently it calls PyUnicode_DecodeLocaleAndSize, which just ends up calling mbstowcs. That's pretty much what wcsftime does. In the default C locale, mbstowcs casts the byte values to wchar_t: >>> time.strftime('%Z') '\x91\xbe\x95\xbd\x97m\x89\xc4\x8e\x9e\x8a\xd4' >>> time.strftime('%Z').encode('latin-1').decode('932') '??????' The problem is worse for 3.5 built with VC++ 14. In the new CRT strftime decodes the format string via MultiByteToWideChar, calls _Wcsftime_l, and encodes the result back via WideCharToMultiByte. The outer conversions use the default LC_TIME codepage, which is ANSI (ACP), so they're not the problem. The problem is the internal _mbstowcs_s_l conversion of the ANSI time zone name, which creates the above-shown mojibake 'unicode' string. This is then compounded by calling WideCharToMultiByte on the result: >>> time.strftime('%Z') '?????m?A???O' There's no way to fix this by transcoding. The result is just garbage. [1]: https://hg.python.org/cpython/file/79e60977fc04/Modules/timemodule.c#l501 ---------- nosy: +eryksun versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 15:34:28 2015 From: report at bugs.python.org (eryksun) Date: Wed, 20 May 2015 13:34:28 +0000 Subject: [issue24244] Python Crash on strftime with %f on Python 3 In-Reply-To: <1432096666.93.0.307433086156.issue24244@psf.upfronthosting.co.za> Message-ID: <1432128868.95.0.0709723725391.issue24244@psf.upfronthosting.co.za> eryksun added the comment: > I cannot reproduce it based on the existing issues using python > 3.4.1 on Windows 7. Majeed could be referring to the ValueError that gets raised for this [only on Windows][1]. In Linux %f passes through silently. Maybe for 3.5 an alternate approach would be to disable the Windows CRT's invalid parameter handler using _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH. Looking at this brought issue 10653 to my attention. It seems VC++ 14 has exacerbated that problem, but that the current solution no longer works even in 3.4.3 with VC++ 10. Should the issue be reopened or a new issue opened? [1]: https://hg.python.org/cpython/file/413e0e0004f4/Modules/timemodule.c#l611 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 15:37:29 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 May 2015 13:37:29 +0000 Subject: [issue24246] mimetypes.guess_extension returns different values when init() is called several times In-Reply-To: <1432124781.6.0.673195721551.issue24246@psf.upfronthosting.co.za> Message-ID: <1432129049.43.0.562715206887.issue24246@psf.upfronthosting.co.za> R. David Murray added the comment: This is a duplicate of issue 4963. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> mimetypes.guess_extension result changes after mimetypes.init() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 15:44:56 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 May 2015 13:44:56 +0000 Subject: [issue24244] Python Crash on strftime with %f on Python 3 In-Reply-To: <1432096666.93.0.307433086156.issue24244@psf.upfronthosting.co.za> Message-ID: <1432129496.03.0.0515007297727.issue24244@psf.upfronthosting.co.za> R. David Murray added the comment: The ValueError is not a bug. Not all format codes are supported on all platforms (we start from what the platform supports, and then we have a few we have implemented cross platform, but that isn't one of them). We also pass through the behavior of the underlying system as far as handling unknown codes. Whether that is the best policy or not is an interesting question, but one that should probably be addressed on python-ideas if someone wants to tackle it, since it has backward compatibility implications (and the wider discussion would affect the the behavior on FreeBSD as well, where unknown codes are handled differently than they are on linux, though they don't produce an exception.) For the other I think you should open a new issue referencing the old one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 15:54:59 2015 From: report at bugs.python.org (Majeed Arni) Date: Wed, 20 May 2015 13:54:59 +0000 Subject: [issue24244] Python Crash on strftime with %f on Python 3 In-Reply-To: <1432096666.93.0.307433086156.issue24244@psf.upfronthosting.co.za> Message-ID: <1432130099.23.0.5966491719.issue24244@psf.upfronthosting.co.za> Majeed Arni added the comment: When we have this for format: date_format = '%Y %m %d %H:%M:%S %z' I see our logs as: [2015 05 19 17:36:09 -0500] watcher modified When I change the format to: [2015 05 20 08:51:24 -0500] stderr AttributeError: 'StreamLogger' object has no attribute 'flush' Unhandled exception in thread started by ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 15:55:12 2015 From: report at bugs.python.org (Stefan Krah) Date: Wed, 20 May 2015 13:55:12 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1432130112.88.0.663330669441.issue23699@psf.upfronthosting.co.za> Stefan Krah added the comment: It seems that it won't be easy to find an API that pleases everyone. I don't want to prolong the discussion much, but if the macro goes in, returning PyErr_BadArgument() in the default case would be better than NotImplemented. assert(0) would be fine as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 16:00:55 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 May 2015 14:00:55 +0000 Subject: [issue24243] behavior for finding an empty string is inconsistent with documentation In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za> Message-ID: <1432130455.39.0.291181134884.issue24243@psf.upfronthosting.co.za> R. David Murray added the comment: "If the slices indexes had to be in range, that would be inconsistent with the behavior of slicing" No, it wouldn't. Your slice example is two operations: the slice returns an empty string (because that's how the *substring* operation is defined to behave for an out-of-range slice), and *then* the search operation is called on it; but in the call with index arguments, the indicies are specifying the slice to search in using the slice semantics of the indicies, but that substring is invalid for the *search* operation. I agree that the startswith/endswith difference between string a bytes looks like a bug, and that the bytes case looks to be the correct one, in terms of consistency with the other search operations. Those operations are a bit different from the other search operations, though, so I could see it argued the other way. The point is that the slice notation specifies how to compute the substring, but what happens if the substring is out of range depends on the *operation*. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 16:02:20 2015 From: report at bugs.python.org (Majeed Arni) Date: Wed, 20 May 2015 14:02:20 +0000 Subject: [issue24244] Python Crash on strftime with %f on Python 3 and Python 2 In-Reply-To: <1432096666.93.0.307433086156.issue24244@psf.upfronthosting.co.za> Message-ID: <1432130540.19.0.0425378115503.issue24244@psf.upfronthosting.co.za> Majeed Arni added the comment: Actually it is happening in Python 2.7 too.. Here is the format we are trying to use: date_format = '%Y %m %d %H:%M:%S:%f %z' Also, is there something millisecond if not microsecond? ---------- title: Python Crash on strftime with %f on Python 3 -> Python Crash on strftime with %f on Python 3 and Python 2 versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 16:03:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 May 2015 14:03:18 +0000 Subject: [issue24243] behavior for finding an empty string is inconsistent with documentation In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za> Message-ID: <1432130598.76.0.388031542143.issue24243@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Changing behavior of such base methods is dangerous and can break existing code. Even if the behavior is wrong, some code can depends on it. We should be very careful with this. There are several simple invariants for these methods. s1.index(s2, start, end) (for non-negative indices) returns minimal index i such that start <= i and i + len(s2) <= end and s1[i: i + len(s2)] = s2. Or raise an exception if such index doesn't exist. find() returns -1 instead of an exception. Therefore "".find("", 1, 0) should be -1 and it is. All right. The only bug is in inconsistency in startswith/endswith between str and bytes (unicode and str in Python 2). The worse, the behavior of str in Python 2 and Python 3 is different. s1.startswith(s2, start, end) (for non-negative indices and non-tuple s2) is equivalent to start + len(s2) <= end and s2[start: start + len(s2)] == s2. Or to s1.find(s2, start, end) == start. Therefore "".startswith("", 1, 0) should be False, and it is for bytes and str in Python 2. The behavior of "".startswith("", 1, 0) in Python 3 and u"".startswith(u"", 1, 0) in Python 3 is wrong. The question is can we fix this behavior in default branch (I think rather yes) and should we fix it in maintained releases (doubt)? ---------- components: +Interpreter Core, Unicode nosy: +benjamin.peterson, ezio.melotti, haypo, lemburg, pitrou, serhiy.storchaka versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 16:08:50 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 May 2015 14:08:50 +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: <1432130930.63.0.479955388943.issue24244@psf.upfronthosting.co.za> R. David Murray added the comment: So, this is expected behavior on Windows. I'm inclined to close the issue as not a bug unless the Windows folks think eryksun suggestion is worth considering. (If the error is suppressed, does windows fill in the rest of the values and just leave the %f in the string?) ---------- components: +Windows nosy: +steve.dower, tim.golden, zach.ware title: Python Crash on strftime with %f on Python 3 and Python 2 -> Python exception on strftime with %f on Python 3 and Python 2 on windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 16:13:01 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 May 2015 14:13:01 +0000 Subject: [issue24243] behavior for finding an empty string is inconsistent with documentation In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za> Message-ID: <1432131181.09.0.541834308314.issue24243@psf.upfronthosting.co.za> R. David Murray added the comment: Serhiy: I agree. I think the consistency with python2's string is the deciding factor, and we ought to fix it in default. But not 3.4, because it is a behavior change. I'd like other people's opinions, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 16:18:00 2015 From: report at bugs.python.org (eryksun) Date: Wed, 20 May 2015 14:18:00 +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: <1432131480.27.0.504942666922.issue24244@psf.upfronthosting.co.za> eryksun added the comment: > If the error is suppressed, does windows fill in the rest of > the values and just leave the %f in the string? No, it does not. I understand now why ValueError was an intentional choice here. The CRT actually breaks the loop with a goto if any call to expand_time fails. So raising a Python exception is the only reasonable course of action. (I still think maybe it's a good place to use the new _Py_BEGIN_SUPPRESS_IPH macro. That way instead of presuming what's a valid format code, it could just handle the EINVAL.) ---------- components: -Windows versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 16:24:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 May 2015 14:24:19 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1432131859.83.0.249286214689.issue24230@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I was vague about this feature, but if other core developer found it useful, I have no objections. Only few nitpicks to the implementation. ---------- nosy: +georg.brandl, ncoghlan, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 16:25:40 2015 From: report at bugs.python.org (Mateusz Loskot) Date: Wed, 20 May 2015 14:25:40 +0000 Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za> Message-ID: <1432131940.94.0.716121332467.issue17797@psf.upfronthosting.co.za> Mateusz Loskot added the comment: Re msg238016, I confirm python-3.5.0a2-fdvalidation.patch fixes the problem for Python 3.5.0a4 and VS2013. The only issue I encountered was with HAVE_FSTAT which is missing from PC/pyconifg.h, so I edited the patch and removed the check if defined(HAVE_FSTAT). Does PC/pyconifg.h need update? I also confirm vanilla Python 3.5.0a4 with VS2015RC does not require this patch, because the fileno regression/bug has been fixed in VS2015RC (details at https://connect.microsoft.com/VisualStudio/feedback/details/785119/). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 17:23:41 2015 From: report at bugs.python.org (Augie Fackler) Date: Wed, 20 May 2015 15:23:41 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1432135421.08.0.550736532087.issue24230@psf.upfronthosting.co.za> Augie Fackler added the comment: > In any way Mercurial people need their own wrapper if they want to support Python <3.5. We need format operations on bytes objects, so we have no plans to support Python3 for any version before 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 17:24:48 2015 From: report at bugs.python.org (Augie Fackler) Date: Wed, 20 May 2015 15:24:48 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1432135488.81.0.55951451357.issue24230@psf.upfronthosting.co.za> Augie Fackler added the comment: I'll build a patched Python3.5 tomorrow (I'm on the road today) and let you know if this does everything we need. I'd be shocked if it wasn't plenty. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 17:29:47 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 May 2015 15:29:47 +0000 Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za> Message-ID: <20150520152944.16310.65158@psf.io> Roundup Robot added the comment: New changeset 435bc22f39e3 by Serhiy Storchaka in branch 'default': Issue #22955: attrgetter, itemgetter and methodcaller objects in the operator https://hg.python.org/cpython/rev/435bc22f39e3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 17:39:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 May 2015 15:39:10 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <20150520153905.44665.53333@psf.io> Roundup Robot added the comment: New changeset cbe28273fd8d by Serhiy Storchaka in branch '2.7': Issue #24134: Use assertRaises() in context manager form in test_slice to https://hg.python.org/cpython/rev/cbe28273fd8d New changeset 3a1ee0b5a096 by Serhiy Storchaka in branch '3.4': Issue #24134: Use assertRaises() in context manager form in test_slice to https://hg.python.org/cpython/rev/3a1ee0b5a096 New changeset 36c4f8af99da by Serhiy Storchaka in branch 'default': Issue #24134: Use assertRaises() in context manager form in test_slice to https://hg.python.org/cpython/rev/36c4f8af99da ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 17:39:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 May 2015 15:39:48 +0000 Subject: [issue24134] assertRaises can behave differently In-Reply-To: <1430914617.89.0.683303246144.issue24134@psf.upfronthosting.co.za> Message-ID: <1432136388.33.0.807981077975.issue24134@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 Wed May 20 18:33:21 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 20 May 2015 16:33:21 +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: <1432139601.54.0.231975209722.issue24244@psf.upfronthosting.co.za> Steve Dower added the comment: _Py_*_SUPPRESS_IPH is the right thing to use here. It still displays an assertion dialog in debug builds, but ignoring it has the correct effect. Patch attached for 3.5 ---------- keywords: +patch Added file: http://bugs.python.org/file39438/24244_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 18:38:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 May 2015 16:38:31 +0000 Subject: [issue24215] test_trace uses test_pprint In-Reply-To: <1431842150.15.0.237267681297.issue24215@psf.upfronthosting.co.za> Message-ID: <20150520163828.16310.99965@psf.io> Roundup Robot added the comment: New changeset 2c074a8dd084 by Serhiy Storchaka in branch '3.4': Issue 24215: Added tests for more builtin types in test_pprint. https://hg.python.org/cpython/rev/2c074a8dd084 New changeset da711bdcc1bf by Serhiy Storchaka in branch 'default': Issue 24215: Added tests for more builtin types in test_pprint. https://hg.python.org/cpython/rev/da711bdcc1bf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 18:54:48 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 20 May 2015 16:54:48 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1432140888.97.0.153730917323.issue21259@psf.upfronthosting.co.za> Terry J. Reedy added the comment: A couple of years ago, when I pushed 'except: pass', I was told in post-review that grandfathered bad code is no excuse for more bad code and that I should be explicit, including if I actually meant "except BaseException:", which in this case I did. No other developer said otherwise. I took the above to be the general consensus. I agree with it, one reason being that bare excepts are speed bumps when reading someone else's code. Victor> generic change "except: pass" to "except Exception: pass" This is not correct without case-by-case examination. #16261 had 2 patches. The patch for doc examples changed 3 'except:'s to 'except Exception:' I believe these are correct, or correct enough. They all need to *not* catch KeyboardInterrupt. The patch for lib code never changed to Exception, but something tighter. The patch committed for #16261 patched 7 files (down from the original proposed 11). Even that took a couple of years to get a second review. I think further followup patches should probably change even fewer files and be attached to new, narrowly focused issues. Raymond, since you closed this once, and since no new patch has been submitted, I presume you do not mind if I reclose this. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 20:11:44 2015 From: report at bugs.python.org (Sergey Skripnick) Date: Wed, 20 May 2015 18:11:44 +0000 Subject: [issue24247] "unittest discover" does modify sys.path Message-ID: <1432145504.49.0.0792649435806.issue24247@psf.upfronthosting.co.za> New submission from Sergey Skripnick: "unittest discover" does add some directories to sys.path later some modules can not work with modified sys.path Here module `pdb` is trying to import standard module `cmd` but does import `cmd` module from `tests` directory: "unittest discover" should not modify sys.path in any way. http://dpaste.com/2RYV8E0 $ mkdir /tmp/t $ cd /tmp/t $ mkdir tests $ mkdir tests/cmd $ touch tests/cmd/__init__.py $ echo "import pdb" > tests/test_nothing.py $ python -m unittest discover tests E ====================================================================== ERROR: test_nothing (unittest.loader.ModuleImportFailure) ---------------------------------------------------------------------- ImportError: Failed to import test module: test_nothing Traceback (most recent call last): File "/usr/lib/python2.7/unittest/loader.py", line 254, in _find_tests module = self._get_module_from_name(name) File "/usr/lib/python2.7/unittest/loader.py", line 232, in _get_module_from_name __import__(name) File "/tmp/t/tests/test_nothing.py", line 1, in import pdb File "/usr/lib/python2.7/pdb.py", line 59, in class Pdb(bdb.Bdb, cmd.Cmd): AttributeError: 'module' object has no attribute 'Cmd' ---------------------------------------------------------------------- Ran 1 test in 0.000s FAILED (errors=1) ---------- messages: 243681 nosy: redixin priority: normal severity: normal status: open title: "unittest discover" does modify sys.path versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 20:30:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 May 2015 18:30:48 +0000 Subject: [issue20691] inspect.signature: Consider exposing 'follow_wrapper_chains' option in public API In-Reply-To: <1392848461.48.0.35558236528.issue20691@psf.upfronthosting.co.za> Message-ID: <20150520183039.125526.65663@psf.io> Roundup Robot added the comment: New changeset 0c298f1ee3f6 by Yury Selivanov in branch 'default': Issue 20691: Add follow_wrapped arg to inspect.signature/from_callable. https://hg.python.org/cpython/rev/0c298f1ee3f6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 20:31:21 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 May 2015 18:31:21 +0000 Subject: [issue20691] inspect.signature: Consider exposing 'follow_wrapper_chains' option in public API In-Reply-To: <1392848461.48.0.35558236528.issue20691@psf.upfronthosting.co.za> Message-ID: <1432146681.58.0.252154779875.issue20691@psf.upfronthosting.co.za> Yury Selivanov added the comment: Closing this one. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 20:33:34 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 May 2015 18:33:34 +0000 Subject: [issue24248] Deprecate inspect.Signature.from_function and from_builtin Message-ID: <1432146814.36.0.379160413915.issue24248@psf.upfronthosting.co.za> New submission from Yury Selivanov: I want to deprecate Signature.from_function and Signature.from_builtin in 3.5. There is no use for these methods (they aren't generic), and we also now have a very handy 'from_callable' for easy Signature subclassing. ---------- assignee: yselivanov components: Library (Lib) messages: 243684 nosy: brett.cannon, larry, ncoghlan, yselivanov priority: normal severity: normal status: open title: Deprecate inspect.Signature.from_function and from_builtin type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 20:40:18 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 May 2015 18:40:18 +0000 Subject: [issue24248] Deprecate inspect.Signature.from_function and from_builtin In-Reply-To: <1432146814.36.0.379160413915.issue24248@psf.upfronthosting.co.za> Message-ID: <1432147218.8.0.040344964671.issue24248@psf.upfronthosting.co.za> Yury Selivanov added the comment: Forgot to mention: from_function and from_builtin are not documented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 20:47:17 2015 From: report at bugs.python.org (Laura Rupprecht) Date: Wed, 20 May 2015 18:47:17 +0000 Subject: [issue9858] Python and C implementations of io are out of sync In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za> Message-ID: <1432147637.21.0.486759402292.issue9858@psf.upfronthosting.co.za> Laura Rupprecht added the comment: Can anyone provide feedback on this patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 21:03:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 May 2015 19:03:10 +0000 Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za> Message-ID: <20150520190307.10804.32358@psf.io> Roundup Robot added the comment: New changeset c93e5ba1cc20 by Serhiy Storchaka in branch 'default': Issue #22955: Fixed test_operator. It left Python implementation in https://hg.python.org/cpython/rev/c93e5ba1cc20 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 21:08:43 2015 From: report at bugs.python.org (Robert Collins) Date: Wed, 20 May 2015 19:08:43 +0000 Subject: [issue9858] Python and C implementations of io are out of sync In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za> Message-ID: <1432148923.31.0.528507709298.issue9858@psf.upfronthosting.co.za> Robert Collins added the comment: I think ignoring weakref is wrong: it means the two implementations are different. ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 21:41:42 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 May 2015 19:41:42 +0000 Subject: [issue9858] Python and C implementations of io are out of sync In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za> Message-ID: <1432150902.34.0.572467459521.issue9858@psf.upfronthosting.co.za> Antoine Pitrou added the comment: __weakref__ is just an implementation detail of how heap types expose weak references (actually, I'm not sure why it's exposed at all). Laura, thank you for contributing. Your patch looks good to me. ---------- assignee: gregory.p.smith -> resolution: accepted -> stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 21:51:31 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 May 2015 19:51:31 +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: <1432151491.82.0.417608051389.issue24244@psf.upfronthosting.co.za> R. David Murray added the comment: What's the behavior after this patch? Does it just return the string unmodified? Or return a null string? Or is the traceback generated at a higher level (and if so what is the error message?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 21:52:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 May 2015 19:52:31 +0000 Subject: [issue9858] Python and C implementations of io are out of sync In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za> Message-ID: <20150520195220.44683.66414@psf.io> Roundup Robot added the comment: New changeset 962b42d67b9e by Antoine Pitrou in branch 'default': Issue #9858: Add missing method stubs to _io.RawIOBase. Patch by Laura Rupprecht. https://hg.python.org/cpython/rev/962b42d67b9e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 21:52:57 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 May 2015 19:52:57 +0000 Subject: [issue9858] Python and C implementations of io are out of sync In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za> Message-ID: <1432151577.06.0.521060818747.issue9858@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've pushed this to the default branch. Thanks! ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 22:12:23 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 20 May 2015 20:12:23 +0000 Subject: [issue24240] PEP 448: Update the language reference In-Reply-To: <1432041544.18.0.803437691236.issue24240@psf.upfronthosting.co.za> Message-ID: <1432152743.95.0.093315148983.issue24240@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> duplicate status: open -> closed superseder: -> document PEP 448 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 23:00:42 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 20 May 2015 21:00:42 +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: <1432155642.23.0.151062137343.issue24244@psf.upfronthosting.co.za> Steve Dower added the comment: It raises ValueError just like now (no visible change), but it won't crash and doesn't require being able to validate the complete format string. If we want any different behaviour, we need to reimplement strftime for Python, which I'd be okay with, but I'm not the one to do it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 23:01:55 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 May 2015 21:01:55 +0000 Subject: [issue24249] unittest API for detecting test failure in cleanup/teardown Message-ID: <1432155715.32.0.956645145974.issue24249@psf.upfronthosting.co.za> New submission from R. David Murray: I have a situation where it would be really helpful to know in my cleanup routine whether or not the test failed. The situation is this: I'm running a command in a subprocess, and sometimes it writes output to stderr that I normally want to ignore. But if the test fails, I'd like my cleanup routine (that shuts down the test subprocess) to print out the stderr, because usually the information as to what went wrong is in stderr. I figure out this hack (for python3.4): for what, result in self._outcome.errors: if what._testMethodName == self._testMethodName and result: print(self.p.stderr.read().decode()) but obviously that uses non-public APIs. ---------- keywords: easy messages: 243694 nosy: ezio.melotti, michael.foord, r.david.murray, rbcollins priority: normal severity: normal stage: needs patch status: open title: unittest API for detecting test failure in cleanup/teardown type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 23:03:03 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 May 2015 21:03:03 +0000 Subject: [issue24248] Deprecate inspect.Signature.from_function and from_builtin In-Reply-To: <1432146814.36.0.379160413915.issue24248@psf.upfronthosting.co.za> Message-ID: <1432155783.0.0.778196247735.issue24248@psf.upfronthosting.co.za> Yury Selivanov added the comment: Patch is attached. ---------- keywords: +patch Added file: http://bugs.python.org/file39439/sig_warns.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 23:06:57 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 May 2015 21:06:57 +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: <1432156017.72.0.117462109681.issue24244@psf.upfronthosting.co.za> R. David Murray added the comment: OK. What made me wonder is that I saw that the 'invalid format string' exception was removed by the patch...I guess that is also raised at a higher level in the code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 23:23:09 2015 From: report at bugs.python.org (Bill Parker) Date: Wed, 20 May 2015 21:23:09 +0000 Subject: [issue24250] Optimization for strcpy(..., "") in file 'install.c' Message-ID: <1432156989.27.0.220297051277.issue24250@psf.upfronthosting.co.za> New submission from Bill Parker: In reviewing calls to strcpy(, ""), I found three instances which could be re-written as * = '\0'; which would save the minor overhead of a function call. The patch file is below: --- install.c.orig 2015-05-20 14:11:27.723397005 -0700 +++ install.c 2015-05-20 14:14:00.862860244 -0700 @@ -1640,8 +1640,8 @@ PSWIZB_BACK); SetDlgItemText(hwnd, IDC_PATH, ""); SetDlgItemText(hwnd, IDC_INSTALL_PATH, ""); - strcpy(python_dir, ""); - strcpy(pythondll, ""); + *python_dir = '\0'; /* replaces strcpy(python_dir, "") */ + *pythondll = '\0'; /* replaces strcpy(pythondll, "") */ } else { char *pbuf; int result; @@ -1680,7 +1680,7 @@ } free(pbuf); } else - strcpy(pythondll, ""); + *pythondll = '\0'; /* replaces strcpy(pythondll, "") */ /* retrieve the scheme for this version */ { char install_path[_MAX_PATH]; I am attaching the patch file to this bug report... ---------- components: Windows files: install.c.patch keywords: patch messages: 243697 nosy: dogbert2, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Optimization for strcpy(..., "") in file 'install.c' type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file39440/install.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 20 23:29:50 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 20 May 2015 21:29:50 +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: <1432157390.12.0.115113983581.issue24244@psf.upfronthosting.co.za> Steve Dower added the comment: It's raised by the existing handling for EINVAL at the end of the function. Previously we'd crash before getting that far because of the invalid parameter handler. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 00:23:31 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 20 May 2015 22:23:31 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432160611.02.0.81509088936.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: I've updated the cordereddict branch on the feature repo to fix the ref leak on None. I'm still seeing other leaks (regrtest -R 3:3), but I don't think that should block landing before the feature freeze. However, I'm concerned about a segfault I'm seeing roughly 3% of the time when running the following: ./python -m unittest test.test_configparser.ConfigParserTestCase.test_basic Presumably there is a dealloc bug there which manifests intermittently due to a GC race. I'm going work on tracking it down but help is appreciated. :) I'm also seeing consistent test failures in test_enum. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 00:35:14 2015 From: report at bugs.python.org (Hao Huang) Date: Wed, 20 May 2015 22:35:14 +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 Message-ID: <1432161314.48.0.939908418066.issue24251@psf.upfronthosting.co.za> New submission from Hao Huang: When I was trying to add the same argument to both the root command and the sub command and you put the arguments before the subcommand, In 2.7.8 the arguments would be parsed correctly. But in 2.7.9, they wouldn't but these arguments would show up in the help doc:( For python2.7.8 ~$ python2.7 Python 2.7.8 (default, Oct 29 2014, 13:45:48) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import argparse >>> >>> parser = argparse.ArgumentParser() >>> parser.add_argument("-s", dest="start") _StoreAction(option_strings=['-s'], dest='start', nargs=None, const=None, default=None, type=None, choices=None, help=None, metavar=None) >>> >>> subparsers = parser.add_subparsers() >>> subparser = subparsers.add_parser("command") >>> subparser.add_argument("-s", dest="start") _StoreAction(option_strings=['-s'], dest='start', nargs=None, const=None, default=None, type=None, choices=None, help=None, metavar=None) >>> >>> parser.parse_args(["-s", "1", "command"]) Namespace(start='1') >>> parser.parse_args(["command", "-s", "1"]) Namespace(start='1') For python 2.7.9 ~$ python2.7 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 argparse >>> parser = argparse.ArgumentParser() >>> parser.add_argument("-s", dest="start") _StoreAction(option_strings=['-s'], dest='start', nargs=None, const=None, default=None, type=None, choices=None, help=None, metavar=None) >>> >>> subparsers = parser.add_subparsers() >>> subparser = subparsers.add_parser("command") >>> subparser.add_argument("-s", dest="start") _StoreAction(option_strings=['-s'], dest='start', nargs=None, const=None, default=None, type=None, choices=None, help=None, metavar=None) >>> >>> parser.parse_args(["-s", "1", "command"]) Namespace(start=None) >>> parser.parse_args(["command", "-s", "1"]) Namespace(start='1') ---------- components: Argument Clinic messages: 243700 nosy: hhuang, larry priority: normal severity: normal status: open title: Different behavior for argparse between 2.7.8 and 2.7.9 when adding the same arguments to the root and the sub commands type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 00:35:49 2015 From: report at bugs.python.org (Hao Huang) Date: Wed, 20 May 2015 22:35:49 +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: <1432161349.74.0.682593862759.issue24251@psf.upfronthosting.co.za> Hao Huang added the comment: I think this patch cause the difference: https://hg.python.org/cpython/rev/1a3143752db2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 00:54:43 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 20 May 2015 22:54:43 +0000 Subject: [issue24247] "unittest discover" does modify sys.path In-Reply-To: <1432145504.49.0.0792649435806.issue24247@psf.upfronthosting.co.za> Message-ID: <1432162483.49.0.350987097351.issue24247@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ezio.melotti, michael.foord, rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 00:57:49 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 May 2015 22:57:49 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432162669.6.0.632006001671.issue16991@psf.upfronthosting.co.za> Antoine Pitrou added the comment: A patch shouldn't be integrated if there are known bugs with it (especially segfaults). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 00:57:55 2015 From: report at bugs.python.org (smparkes) Date: Wed, 20 May 2015 22:57:55 +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: <1432162675.88.0.302863471766.issue24251@psf.upfronthosting.co.za> Changes by smparkes : ---------- nosy: +smparkes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 00:59:46 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 20 May 2015 22:59:46 +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: <1432162786.47.0.711493551596.issue24251@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: +Library (Lib) -Argument Clinic nosy: +bethard, r.david.murray -larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 01:03:59 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 20 May 2015 23:03:59 +0000 Subject: [issue24249] unittest API for detecting test failure in cleanup/teardown In-Reply-To: <1432155715.32.0.956645145974.issue24249@psf.upfronthosting.co.za> Message-ID: <1432163039.26.0.0851823108387.issue24249@psf.upfronthosting.co.za> Martin Panter added the comment: Can?t you use the -b or --buffer command-line option , or equivalent option to unittest.main() or whatever? The standard output and standard error streams are buffered during the test run. Output during a passing test is discarded. Output is echoed normally on test fail or error and is added to the failure messages. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 01:06:05 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 20 May 2015 23:06:05 +0000 Subject: [issue24249] unittest API for detecting test failure in cleanup/teardown In-Reply-To: <1432155715.32.0.956645145974.issue24249@psf.upfronthosting.co.za> Message-ID: <1432163165.84.0.126835168126.issue24249@psf.upfronthosting.co.za> Martin Panter added the comment: Ah sorry I didn?t see the keyword ?subprocess?, so --buffer won?t work! But maybe you can dump the subprocess?s stderr to sys.stderr? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 01:15:46 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 20 May 2015 23:15:46 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432163746.72.0.318337199658.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Agreed. I wanted to be clear about what is blocking landing the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 01:35:01 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 20 May 2015 23:35:01 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432164901.14.0.788716610551.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: These are the leaks I'm seeing in test_collections (14/24 tests): test_copying : 178 test_iterators : 40 test_update : 29 test_init : 22 test_move_to_end : 21 test_sorted_iterators: 20 test_setdefault : 16 test_clear : 5 test_setitem : 5 test_delitem : 4 test_repr_recursive : 4 test_repr : 3 test_override_update : 2 test_reinsert : 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 01:42:25 2015 From: report at bugs.python.org (eryksun) Date: Wed, 20 May 2015 23:42:25 +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: <1432165345.56.0.160376300849.issue24244@psf.upfronthosting.co.za> Changes by eryksun : ---------- components: +Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 01:55:41 2015 From: report at bugs.python.org (Petr Viktorin) Date: Wed, 20 May 2015 23:55:41 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1432166141.87.0.624848777071.issue23699@psf.upfronthosting.co.za> Petr Viktorin added the comment: Well, in my opinion NotImplemented is a good value for "unknown operation", but I'll be happy to change to PyErr_BadArgument(); return NULL; if there's support for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 02:03:00 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 21 May 2015 00:03:00 +0000 Subject: [issue23377] HTTPResponse may drop buffer holding next response In-Reply-To: <1422881776.12.0.998068930599.issue23377@psf.upfronthosting.co.za> Message-ID: <1432166580.69.0.768921066447.issue23377@psf.upfronthosting.co.za> Demian Brecht added the comment: Added comments to Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 02:44:08 2015 From: report at bugs.python.org (ppperry) Date: Thu, 21 May 2015 00:44:08 +0000 Subject: [issue24252] IDLE removes elements from tracebacks. Message-ID: <1432169048.6.0.710293421877.issue24252@psf.upfronthosting.co.za> New submission from ppperry: When reproducing issue24160 in IDLE, I saw this traceback: Traceback (most recent call last): File "", line 1, in pdb.run("reload(test3)") File "C:\Python27\lib\pdb.py", line 1238, in run Pdb().run(statement, globals, locals) File "C:\Python27\lib\bdb.py", line 400, in run exec cmd in globals, locals File "", line 1, in File "test3.py", line 1, in [contents of test3.py] File "C:\Python27\lib\bdb.py", line 51, in trace_dispatch return self.dispatch_call(frame, arg) File "C:\Python27\lib\bdb.py", line 80, in dispatch_call self.user_call(frame, arg) File "C:\Python27\lib\pdb.py", line 148, in user_call self.interaction(frame, None) File "C:\Python27\lib\pdb.py", line 210, in interaction self.cmdloop() File "C:\Python27\lib\cmd.py", line 142, in cmdloop stop = self.onecmd(line) File "C:\Python27\lib\pdb.py", line 279, in onecmd return cmd.Cmd.onecmd(self, line) File "C:\Python27\lib\cmd.py", line 221, in onecmd return func(arg) File "C:\Python27\lib\pdb.py", line 622, in do_clear err = self.clear_bpbynumber(i) KeyError: 'c:\\documents and settings\\perry\\desktop\\coding_projects\\python\\test3.py' Reproducing the same bug in the standard interpreter produces a more detailed traceback: Traceback (most recent call last): File "", line 1, in pdb.run("reload(test3)") File "C:\Python27\lib\pdb.py", line 1238, in run Pdb().run(statement, globals, locals) File "C:\Python27\lib\bdb.py", line 400, in run exec cmd in globals, locals File "", line 1, in File "test3.py", line 1, in foo = 7789 File "C:\Python27\lib\bdb.py", line 51, in trace_dispatch return self.dispatch_call(frame, arg) File "C:\Python27\lib\bdb.py", line 80, in dispatch_call self.user_call(frame, arg) File "C:\Python27\lib\pdb.py", line 148, in user_call self.interaction(frame, None) File "C:\Python27\lib\pdb.py", line 210, in interaction self.cmdloop() File "C:\Python27\lib\cmd.py", line 142, in cmdloop stop = self.onecmd(line) File "C:\Python27\lib\pdb.py", line 279, in onecmd return cmd.Cmd.onecmd(self, line) File "C:\Python27\lib\cmd.py", line 221, in onecmd return func(arg) File "C:\Python27\lib\pdb.py", line 622, in do_clear err = self.clear_bpbynumber(i) File "C:\Python27\lib\bdb.py", line 297, in clear_bpbynumber self._prune_breaks(bp.file, bp.line) File "C:\Python27\lib\bdb.py", line 268, in _prune_breaks self.breaks[filename].remove(lineno) KeyError: 'c:\\documents and settings\\perry\\desktop\\coding_projects\\python\\test3.py' The actual error message is irrelevant, other than the fact that in the standard interpreter, the traceback contains two more entries. ---------- components: IDLE messages: 243709 nosy: kbk, ppperry, roger.serwy, terry.reedy priority: normal severity: normal status: open title: IDLE removes elements from tracebacks. type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 03:12:25 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 May 2015 01:12:25 +0000 Subject: [issue24243] behavior for finding an empty string is inconsistent with documentation In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za> Message-ID: <1432170745.53.0.949732139737.issue24243@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Changing behavior of such base methods is dangerous > and can break existing code. I agree. The time to argue an API design is before it released not years later after people have written code that relies on the behavior. > To me, semantically, the whole idea of finding nothing, > whether in something or in nothing is complete and utter nonsense. It might not be something you don't agree with, but it isn't nonsense. There are a number of ways to view it sensibly (empty sets always a subset of other sets). There a reason that any() and all() are well-defined for empty iterables. There a reason that math.factorial(0) returns 1. Those are useful corner cases that save us from writing special case code. > Empty string search: I think it is completely valid to be able to find an empty string inside another string, I concur. I am closing this one as "not a bug". Primum non nocere. First Do No Harm". Don't break existing code because the OP would "prefer that any attempt to find nothing would result in an exception being raised". That is a terrible reason to break code. For better or worse, this state of affairs has existed for a long time and no harm seems to have arisen. Also keep in mind that the current behaviors are tested, meaning that it is not accidental and is guaranteed across implementations. See Lib/test/string_tests.py. Though this is closed as not a bug, feel free to add an example or a mention in the documentation. Keep it short though. The purpose of the docs for str.count and str.index are to teach how to use the common case rather than getting lost in a discussion of corner case behavior. Also, the docs should be affirmatively worded (here is how something works and how to use it) rather than negatively worded (omg, finding nothing is something is nonsense). ---------- nosy: +rhettinger resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 03:31:21 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 21 May 2015 01:31:21 +0000 Subject: [issue24248] Deprecate inspect.Signature.from_function and from_builtin In-Reply-To: <1432146814.36.0.379160413915.issue24248@psf.upfronthosting.co.za> Message-ID: <1432171881.01.0.175329219916.issue24248@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 from me. The deprecation warning text in the patch has a typo (callback instead of callable). For the documentation, in addition to noting the deprecation itself, it may also be worth noting how to explicitly recreate the type restriction. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 03:33:34 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 01:33:34 +0000 Subject: [issue24248] Deprecate inspect.Signature.from_function and from_builtin In-Reply-To: <1432146814.36.0.379160413915.issue24248@psf.upfronthosting.co.za> Message-ID: <1432172014.01.0.101756308915.issue24248@psf.upfronthosting.co.za> Yury Selivanov added the comment: > For the documentation, in addition to noting the deprecation itself, it may also be worth noting how to explicitly recreate the type restriction. Nick, what do you mean by "type restriction"? Also, since the functions aren't documented, I think we don't need to document that they are deprecated? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 04:13:15 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 21 May 2015 02:13:15 +0000 Subject: [issue23973] PEP 484 implementation In-Reply-To: <1429209123.93.0.369207893318.issue23973@psf.upfronthosting.co.za> Message-ID: <1432174395.67.0.279457734128.issue23973@psf.upfronthosting.co.za> Guido van Rossum added the comment: I am going to commit this (or something very close to it) unless I hear an explicit rejection notice from Mark Shannon. Off-list he's promised he'll approve the PEP provisionally, and the window for beta 1 is closing. It's better to iterate than to miss the window entirely. ---------- keywords: +patch Added file: http://bugs.python.org/file39441/pep484.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 04:48:51 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 21 May 2015 02:48:51 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432176531.15.0.945470169426.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: I've fixed most of the leaks now. The only remaining ones are: test_clear : 5 test_repr_recursive : 3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 04:58:39 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 21 May 2015 02:58:39 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432177119.11.0.403806639459.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Regarding the segfault, the following does not fail: ./python -m test.regrtest --forever -m test_basic test_configparser but this does: for i in `seq 1 20`; do ./python -m test.regrtest -m test_basic test_configparser ; done ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 04:59:48 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 02:59:48 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432177187.99.0.529209789932.issue16991@psf.upfronthosting.co.za> Yury Selivanov added the comment: Eric, could you please upload your latest patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 05:07:27 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 21 May 2015 03:07:27 +0000 Subject: [issue24248] Deprecate inspect.Signature.from_function and from_builtin In-Reply-To: <1432146814.36.0.379160413915.issue24248@psf.upfronthosting.co.za> Message-ID: <1432177647.81.0.170164934133.issue24248@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oh, right - you said they weren't documented, and I completely glazed over that bit. The "type restrictions" comment isn't valid in the absence of documentation, but it was basically about how to fully replicate the behaviour of the existing functions in conjunction with "from_callable". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 05:08:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 May 2015 03:08:14 +0000 Subject: [issue24248] Deprecate inspect.Signature.from_function and from_builtin In-Reply-To: <1432146814.36.0.379160413915.issue24248@psf.upfronthosting.co.za> Message-ID: <20150521030811.26556.41636@psf.io> Roundup Robot added the comment: New changeset 64fba4ea031b by Yury Selivanov in branch 'default': Issue 24248: Deprecate inspect.Signature.from_function and .from_builtin https://hg.python.org/cpython/rev/64fba4ea031b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 05:09:09 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 03:09:09 +0000 Subject: [issue24248] Deprecate inspect.Signature.from_function and from_builtin In-Reply-To: <1432146814.36.0.379160413915.issue24248@psf.upfronthosting.co.za> Message-ID: <1432177749.15.0.952609959761.issue24248@psf.upfronthosting.co.za> Yury Selivanov added the comment: OK, committed! Thanks for the review, Nick. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 05:09:25 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 03:09:25 +0000 Subject: [issue24248] Deprecate inspect.Signature.from_function and from_builtin In-Reply-To: <1432146814.36.0.379160413915.issue24248@psf.upfronthosting.co.za> Message-ID: <1432177765.93.0.6053954788.issue24248@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 05:11:04 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 May 2015 03:11:04 +0000 Subject: [issue24249] unittest API for detecting test failure in cleanup/teardown In-Reply-To: <1432155715.32.0.956645145974.issue24249@psf.upfronthosting.co.za> Message-ID: <1432177864.28.0.437832290084.issue24249@psf.upfronthosting.co.za> R. David Murray added the comment: Having to specify a command line option to get a normally clean test run just doesn't feel like a good API. If there is a way to set that on the TestCase, that would be OK. There are other reasons to want the API I suggest, though...there is at least one StackOverflow question asking about how to do it, which is where I got the clue for implementing my hack. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 05:11:08 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 03:11:08 +0000 Subject: [issue24248] Deprecate inspect.Signature.from_function and from_builtin In-Reply-To: <1432146814.36.0.379160413915.issue24248@psf.upfronthosting.co.za> Message-ID: <1432177868.38.0.658143375282.issue24248@psf.upfronthosting.co.za> Yury Selivanov added the comment: I documented the deprecation in the whatsnew section anyways. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 05:17:41 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 May 2015 03:17:41 +0000 Subject: [issue24243] behavior for finding an empty string is inconsistent with documentation In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za> Message-ID: <1432178261.77.0.839594080888.issue24243@psf.upfronthosting.co.za> R. David Murray added the comment: Raymond: this is currently marked as a documentation bug, and documentation is mostly what the OP was asking for. So I'm reopening it. That said, I think it is very appropriate to discuss fixing the behavior of string's endswith and startswith, because people are still (and will be for a while yet) porting from python2 and supporting single-code-base code, where string behaves the way bytes does in python3. That should be addressed in a separate issue. So in fact, history and "code written for the current behavior" comes down, IMO, on the side of fixing this edge case. I'm willing to be argued out of that, though :) ---------- resolution: not a bug -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 05:33:32 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 03:33:32 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <1432179212.0.0.554795653577.issue24237@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, please review the patch. BTW, we will have *a lot* of warnings now when running tests with -Wall. Are we going to employ "from __future__ import generator_stop" everywhere in 3.5? ---------- keywords: +patch nosy: +yselivanov priority: normal -> release blocker stage: -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file39442/gen_stop_warn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 05:34:38 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 03:34:38 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <1432179278.64.0.671940234921.issue24237@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 05:51:10 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 03:51:10 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <1432180270.05.0.56644961308.issue24237@psf.upfronthosting.co.za> Changes by Yury Selivanov : Removed file: http://bugs.python.org/file39442/gen_stop_warn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 05:51:22 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 03:51:22 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <1432180282.94.0.663232015561.issue24237@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file39443/gen_stop_warn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 05:51:50 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 03:51:50 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <1432180310.26.0.72239368774.issue24237@psf.upfronthosting.co.za> Changes by Yury Selivanov : Removed file: http://bugs.python.org/file39443/gen_stop_warn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 05:55:48 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 21 May 2015 03:55:48 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <1432180548.04.0.989622161613.issue24237@psf.upfronthosting.co.za> Nick Coghlan added the comment: Given the two-release deprecation cycle, would it be worth using PendingDeprecationWarning here? That way folks that only turned on DeprecationWarning (rather than -Wall) wouldn't need to worry about this until 3.6. As far as our own test suite goes, when ResourceWarning was introduced, dealing with those in the test suite became an ongoing cleanup task. Are there really all that many warnings triggered for PEP 479? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 05:59:14 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 03:59:14 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <1432180754.1.0.853939792821.issue24237@psf.upfronthosting.co.za> Yury Selivanov added the comment: Had to regenerate the patch. Fixed some typos + now I use PyErr_WriteUnraisable if PyErr_WarnFormat returns non-zero. And yeah, PendingDeprecationWarning is a better choice. ---------- Added file: http://bugs.python.org/file39444/gen_stop_warn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 06:06:19 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 21 May 2015 04:06:19 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432181179.18.0.679130618156.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a diff from the current cordereddict branch of the feature repo. ---------- Added file: http://bugs.python.org/file39445/cOrderedDict-4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 06:07:10 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 04:07:10 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <1432181230.31.0.213623936103.issue24237@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Are there really all that many warnings triggered for PEP 479? Actually, with the attached patch the number of warnings is pretty low, we can definitely fix/silence them where necessary. (I think I had a bug in one of my first patches that triggered some false-positives). - test_difflib - will have to fix difflib; - test_contextlib - tests StopIteration propagation on purpose; will silence the warning; - test_with - test_generators ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 06:37:38 2015 From: report at bugs.python.org (Antony Lee) Date: Thu, 21 May 2015 04:37:38 +0000 Subject: [issue24253] pydoc for namespace packages indicates FILE as built-in Message-ID: <1432183058.22.0.402547757332.issue24253@psf.upfronthosting.co.za> New submission from Antony Lee: All's in the title: the output of "pydoc foo" where foo is a namespace package (... e.g. any directory in the cwd) says that the package is defined as a builtin (under the FILE entry) -- which is certainly incorrect. ---------- components: Library (Lib) messages: 243728 nosy: Antony.Lee priority: normal severity: normal status: open title: pydoc for namespace packages indicates FILE as built-in versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 07:34:48 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 21 May 2015 05:34:48 +0000 Subject: [issue24254] Make class definition namespace ordered by default Message-ID: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> New submission from Eric Snow: Here's a work-in-progress patch that uses OrderedDict as the default class definition namespace (instead of dict). While the actual class namespace is a dict, the definition order is preserved on a new attribute on class objects: __definition_order__. This is useful for cases such as class decorators that would make use of the definition order to post-process the class. This is something that Guido okay'ed a while back. It may be a stretch to get this into 3.5, but the final change should be pretty small. It also depends on the C implementation of OrderedDict (see issue #16991) which has not landed and may not make it in time. Note that the patch is still a bit buggy, partly due to bugs in the C OrderedDict patch. Also, the attached patch is based off the C OrderedDict patch, so I expect reitveld won't be able to handle it. The code on which the patch is based may be found in the "class-namespace" branch of https://pypi.python.org/pypi/cyordereddict. ---------- assignee: eric.snow components: Interpreter Core files: odict-class-definition-namespace.diff keywords: patch messages: 243729 nosy: eric.snow, ncoghlan priority: normal severity: normal status: open title: Make class definition namespace ordered by default type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file39446/odict-class-definition-namespace.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 07:55:49 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 21 May 2015 05:55:49 +0000 Subject: [issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1432187749.16.0.872662961278.issue12319@psf.upfronthosting.co.za> Demian Brecht added the comment: Latest patch should address all outstanding comments. ---------- Added file: http://bugs.python.org/file39447/issue12319_6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 07:56:25 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 21 May 2015 05:56:25 +0000 Subject: [issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1432187785.57.0.00863192825598.issue12319@psf.upfronthosting.co.za> Demian Brecht added the comment: BTW, thanks for the reviews Martin and the nudge Antoine! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 08:03:42 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 06:03:42 +0000 Subject: [issue24180] PEP 492: Documentation Message-ID: <1432188222.61.0.941907273276.issue24180@psf.upfronthosting.co.za> New submission from Yury Selivanov: Please find attached a docs patch for PEP 492 changes. I'd really appreciate if someone can review it / help me with it. I think it's important to have at least some documentation shipped with beta-1, so that people start testing the feature. ---------- assignee: -> yselivanov components: +Documentation keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file39448/async_docs_v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 08:06:16 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 06:06:16 +0000 Subject: [issue24180] PEP 492: Documentation In-Reply-To: <1432188222.61.0.941907273276.issue24180@psf.upfronthosting.co.za> Message-ID: <1432188376.92.0.416599631379.issue24180@psf.upfronthosting.co.za> Changes by Yury Selivanov : Removed file: http://bugs.python.org/file39448/async_docs_v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 08:06:25 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 06:06:25 +0000 Subject: [issue24180] PEP 492: Documentation In-Reply-To: <1432188222.61.0.941907273276.issue24180@psf.upfronthosting.co.za> Message-ID: <1432188385.64.0.47338871007.issue24180@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file39449/async_docs_v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 08:23:05 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 21 May 2015 06:23:05 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432189385.78.0.0404437180931.issue16991@psf.upfronthosting.co.za> Ned Deily added the comment: FWIW, the random segfault seems to be triggered by hash randomization. If I disable randomization, it does not seem to fail: for i in `seq 1 20`; do PYTHONHASHSEED=1 ./python -m test.regrtest -m test_basic test_configparser ; done Presumably, the --forever option does not vary the hash seed value? Also, FWIW, clang issues a warning: ../../source/Objects/odictobject.c:550:15: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (i < 0) { ~ ^ ~ for this: _odict_FOREACH(od, node) { size_t i = _odict_get_index(od, _odictnode_KEY(node)); if (i < 0) { od->od_size = prev_size; PyMem_FREE(fast_nodes); return -1; } fast_nodes[i] = node; I can supply OS X crash tracebacks if they would be of help. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 08:25:55 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 21 May 2015 06:25:55 +0000 Subject: [issue24255] Replace debuglevel-related logic with logging Message-ID: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za> New submission from Demian Brecht: Far too many times have I wished that changing the logging output in http.client was controllable through logging configuration rather than code changes modifying a connection's debuglevel. It would be nice if the http package was brought up to date and had debuglevel-related code replaced with logging and sane logging was added throughout. ---------- components: Library (Lib) messages: 243734 nosy: demian.brecht priority: normal severity: normal stage: needs patch status: open title: Replace debuglevel-related logic with logging type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 08:29:41 2015 From: report at bugs.python.org (John Runyon) Date: Thu, 21 May 2015 06:29:41 +0000 Subject: [issue24256] threading.Timer is not a class Message-ID: <1432189781.3.0.318420798275.issue24256@psf.upfronthosting.co.za> New submission from John Runyon: the documentation (https://docs.python.org/2/library/threading.html#threading.Timer) lists "threading.Timer" as a class. It is not, which means that (for example) you can not use it in isinstance(). "threading._Timer" is a class. "threading.Timer(...).__class__" is a class. "threading.Timer" is a function. >>> import threading >>> threading.Timer ---------- assignee: docs at python components: Documentation messages: 243735 nosy: docs at python, jrunyon priority: normal severity: normal status: open title: threading.Timer is not a class versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 08:44:41 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 21 May 2015 06:44:41 +0000 Subject: [issue24256] threading.Timer is not a class In-Reply-To: <1432189781.3.0.318420798275.issue24256@psf.upfronthosting.co.za> Message-ID: <1432190681.08.0.88316953903.issue24256@psf.upfronthosting.co.za> Ned Deily added the comment: This is really a duplicate of Issue5831 which ended up being closed as a duplicate of Issue10968. The resolution of the latter issue was to change threading.Timer in Python 3.3 to actually be a class, a new feature. But it appears that along the way the issue of correcting the documentation for 2.7 was never addressed. Perhaps you could propose wording for a documentation patch? ---------- nosy: +ned.deily stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 09:02:56 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 21 May 2015 07:02:56 +0000 Subject: [issue24252] IDLE removes elements from tracebacks. In-Reply-To: <1432169048.6.0.710293421877.issue24252@psf.upfronthosting.co.za> Message-ID: <1432191776.06.0.953744321846.issue24252@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The two additional entries are the last two. In this case, they are needed because KeyError pertains to the dict lookup in the last line "self.breaks[filename]". Mistaken in this particular case or not, the deletion is intentional. Run.print_exception has these two lines: exclude = ("run.py", "rpc.py", "threading.py", "Queue.py", "RemoteDebugger.py", "bdb.py") cleanup_traceback(tbe, exclude) The docstring for cleanup_traceback is "Remove excluded traces from beginning/end of tb; get cached lines". The intent of the first 4 excludes is to make the tracebacks displayed in Idle for normal (non-debug) code the same as with Python, without Idle. The intent of the last 2 is to continue the equivalence when using the Idle debugger (which inherits from bdb.py). Using pdb with Idle is known to be somewhat problematical because Idle revises the execution environment. In particular, identical tracebacks cannot be guaranteed. (I tried to find the issue bug the buggy tracker search did not return the issue.) A fix for this particular example would be to omit/remove bdb from exclude (which could be a set) when the first item contains 'pdb'. I would consider a patch to do that. ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 09:13:28 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 21 May 2015 07:13:28 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <1432192408.93.0.377419249254.issue24237@psf.upfronthosting.co.za> Nick Coghlan added the comment: Why the switch to WriteUnraisable? Unlike __del__ methods and similar operations that may be invoked at arbitrary points, there's nothing stopping us from emitting an exception here - indeed, we're *already* handling an exception. Getting a hard failure on deprecations is one of the expected consequences of using "-Wall" rather than the default settings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 10:40:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 May 2015 08:40:46 +0000 Subject: [issue24257] Incorrect use of PyObject_IsInstance Message-ID: <1432197646.74.0.848752631202.issue24257@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: PyObject_IsInstance() is used incorrectly for testing if Python object is an instance of specified builtin type before direct access to internals of object. This is not correct, because PyObject_IsInstance() checks the __class__ attribute that can be modified and even can be dynamic property. Correct way is to check static type. Proposed patch replaces PyObject_IsInstance() with PyObject_TypeCheck() if this is appropriate. See also similar issues issue24102 and issue24091. ---------- components: Extension Modules, Interpreter Core files: typecheck.patch keywords: patch messages: 243739 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Incorrect use of PyObject_IsInstance type: crash versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39450/typecheck.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 10:41:51 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 21 May 2015 08:41:51 +0000 Subject: [issue24250] Optimization for strcpy(..., "") in file 'install.c' In-Reply-To: <1432156989.27.0.220297051277.issue24250@psf.upfronthosting.co.za> Message-ID: <1432197711.97.0.93540383681.issue24250@psf.upfronthosting.co.za> Paul Moore added the comment: The patch looks fine to me, although I don't think you need the comment showing the old code. The new code is perfectly clear on its own. ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 10:49:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 May 2015 08:49:00 +0000 Subject: [issue24115] Unhandled error results of C API functions In-Reply-To: <1430585786.54.0.583087529416.issue24115@psf.upfronthosting.co.za> Message-ID: <1432198140.94.0.88358130526.issue24115@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch adds handling of error results of following functions: PyObject_IsTrue(), PyObject_Not(), PyObject_IsInstance(), PyObject_RichCompareBool(), _PyDict_Contains(). All these functions usually return 0 or 1, but also can return -1 in the case of error, and this case was not handled in some places. ---------- keywords: +patch stage: needs patch -> patch review title: PyObject_IsInstance() and PyObject_IsSubclass() can fail -> Unhandled error results of C API functions Added file: http://bugs.python.org/file39451/issue24115.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 10:55:37 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 21 May 2015 08:55:37 +0000 Subject: [issue24180] PEP 492: Documentation In-Reply-To: <1432188222.61.0.941907273276.issue24180@psf.upfronthosting.co.za> Message-ID: <1432198537.58.0.746679638789.issue24180@psf.upfronthosting.co.za> Nick Coghlan added the comment: Patch looks worth merging to me. Some minor questions/quibbles: Asynchronous iterator question: should the typical pattern for those be: def __aiter__(self): return self def __await__(self): return self "Did we put the ABC's in the right place?" question: reviewing the draft docs meant I just noticed that collections.abc is quite an odd home for some of these. Probably not worth worrying about, given that AsyncIterator and AsyncIterable do belong, and the others are building blocks for those. The What's New entry can be tweaked to replace "proposes" with "added". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 11:16:56 2015 From: report at bugs.python.org (Jozef Sivek) Date: Thu, 21 May 2015 09:16:56 +0000 Subject: [issue24258] BZ2File objects do not have name attribute Message-ID: <1432199816.0.0.178283144298.issue24258@psf.upfronthosting.co.za> New submission from Jozef Sivek: Unlike GzipFile the BZ2File does not have defined name attribute. The reading of this attribute results in: "AttributeError: 'BZ2File' object has no attribute 'name'". This is truly missing feature and wrong behaviour, compare: https://hg.python.org/releasing/3.4.3/file/933c3041d548/Lib/gzip.py and https://hg.python.org/releasing/3.4.3/file/933c3041d548/Lib/bz2.py In addition to that the BZ2File did have name attribute in python 2.7.* . In attachment there is tar ball with example files, expected results in python 3 and results in python 2. ---------- components: Library (Lib) files: bz2file.tar messages: 243743 nosy: jojko.sivek priority: normal severity: normal status: open title: BZ2File objects do not have name attribute type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file39452/bz2file.tar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 12:54:53 2015 From: report at bugs.python.org (John Runyon) Date: Thu, 21 May 2015 10:54:53 +0000 Subject: [issue24256] threading.Timer is not a class In-Reply-To: <1432189781.3.0.318420798275.issue24256@psf.upfronthosting.co.za> Message-ID: <1432205693.4.0.789421675361.issue24256@psf.upfronthosting.co.za> John Runyon added the comment: Concise documentation isn't my forte, but my confusion would've been avoided with a note that "for historical reasons, threading.Timer is actually a factory function for the underlying class threading._Timer" or something along those lines. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 13:19:38 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 21 May 2015 11:19:38 +0000 Subject: [issue24250] Optimization for strcpy(..., "") in file 'install.c' In-Reply-To: <1432156989.27.0.220297051277.issue24250@psf.upfronthosting.co.za> Message-ID: <1432207178.76.0.337064385714.issue24250@psf.upfronthosting.co.za> Martin Panter added the comment: For the record, the file being patched is PC/bdist_wininst/install.c My opinion is the original is more readable, and unless this is some inner loop bottleneck here it seems like premature optimization. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 13:20:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 May 2015 11:20:05 +0000 Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za> Message-ID: <20150521111959.21168.98447@psf.io> Roundup Robot added the comment: New changeset 2688655e431a by Serhiy Storchaka in branch 'default': Issue #22955: Fixed reference leak in attrgetter.repr(). https://hg.python.org/cpython/rev/2688655e431a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 13:21:07 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 21 May 2015 11:21:07 +0000 Subject: [issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1432207267.18.0.0932544611593.issue12319@psf.upfronthosting.co.za> Martin Panter added the comment: I left some new comments. However I remain concerned at how complicated and overloaded the API is becoming. It certainly makes it hard to review for correctness. I could easily have missed some corner case that is broken by the changes. There are a lot of odd body objects apparently permitted, e.g. GzipFile objects can always seek to the end but may not be able to go backwards, mmap() objects are both bytes-like and file-like. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 14:14:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 May 2015 12:14:43 +0000 Subject: [issue24250] Optimization for strcpy(..., "") in file 'install.c' In-Reply-To: <1432156989.27.0.220297051277.issue24250@psf.upfronthosting.co.za> Message-ID: <1432210483.62.0.60430517564.issue24250@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> low stage: -> patch review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 15:21:09 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 21 May 2015 13:21:09 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1432214469.44.0.551906384679.issue23699@psf.upfronthosting.co.za> Stefan Krah added the comment: NotImplemented is a non-error return value that's used when the objects cannot be compared, e.g. when the function receives Py_LT but the objects are unorderable. Getting a value outside {Py_EQ, ...} is a hard error that cannot occur in a correct program. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 15:47:30 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 21 May 2015 13:47:30 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432216050.86.0.0767927761375.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks for looking into this, Ned. I've changed that size_t to ssize_t which I expect will quiet that clang warning you saw. I'm glad you pointed it out because it means that that branch was never executing! Unfortunately fixing that does not solve all my problems. I'll look into the hash randomization connection. Thanks for pointing that out. Hopefully it doesn't complicate matters. My guess is that the segfaults only happen for certain seeds, so I'll check that first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 15:57:57 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 May 2015 13:57:57 +0000 Subject: [issue24255] Replace debuglevel-related logic with logging In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za> Message-ID: <1432216677.62.0.685621936166.issue24255@psf.upfronthosting.co.za> R. David Murray added the comment: +1 ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 15:59:03 2015 From: report at bugs.python.org (Rolf Krahl) Date: Thu, 21 May 2015 13:59:03 +0000 Subject: [issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1432216743.96.0.600911760277.issue12319@psf.upfronthosting.co.za> Rolf Krahl added the comment: Hi again, first of all, sorry for not contributing to the discussion for such a long time. I was quite busy lately. I tested the patch with Python 3.5.0a3. It works nicely for my use case. Thanks a lot! I have one issue though: urllib's HTTPHandler and HTTPSHandler still try to enforce a Content-length to be set (by AbstractHTTPHandler.do_request_()). But for chunked transfer encoding, the Content-length must not be set. Using to this patch, HTTPConnection also checks for the Content-length in _send_request() and sets it if missing. AFAICS, HTTPConnection now does a far better job checking this then HTTPHandler and - most importantly - does it in a way that is compatible with chunked transfer encoding. So, I would suggest, that there is no need for HTTPHandler to care about the content length and that it should just leave this header alone. E.g., I suggest that the "if not request.has_header('Content-length'): [...]" statement should completely be removed from AbstractHTTPHandler.do_request_() in urllib/request.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 16:02:04 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 May 2015 14:02:04 +0000 Subject: [issue24257] Incorrect use of PyObject_IsInstance In-Reply-To: <1432197646.74.0.848752631202.issue24257@psf.upfronthosting.co.za> Message-ID: <1432216924.84.0.113471046536.issue24257@psf.upfronthosting.co.za> R. David Murray added the comment: Is there any chance that these changes will break working code, or is it the case that if the current check passes incorrectly one will always get a segfauilt or other error? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 16:09:56 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 21 May 2015 14:09:56 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432217396.66.0.730527505157.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Cool. The following gives consistent failures at certain seed values: for i in `seq 1 100`; do echo $i; PYTHONHASHSEED=$i ./python -m test.regrtest -m test_basic test_configparser ; done Through 100 I get segfaults with 7, 15, 35, 37, 39, 40, 42, 47, 50, 66, 67, 85, 87, 88, and 92. The distribution is probably essentially uniform across the full set of seeds, even if the exact pattern of failures isn't precisely uniform. I'll try to see why those hashes are significant here. If I can't figured it out quickly then I'll post about it on python-dev. My hunch is that the hash randomization impacts either dict/odict resizing or dict/odict lookup (or both). TBH, I've been pretty sure for a while that the segfault is coming out of one of those two. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 16:57:22 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 21 May 2015 14:57:22 +0000 Subject: [issue24257] Incorrect use of PyObject_IsInstance In-Reply-To: <1432197646.74.0.848752631202.issue24257@psf.upfronthosting.co.za> Message-ID: <1432220242.65.0.185314682099.issue24257@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > is it the case that if the current check passes incorrectly > one will always get a segfauilt or other error? Yes, that is the case. All four of these checks precede a reference to an structure member that depends on being an exact type or subtype. So, yes they are all necessary to prevent segfaults or other undefined behavior. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 17:18:16 2015 From: report at bugs.python.org (=?utf-8?q?Thomas_G=C3=BCttler?=) Date: Thu, 21 May 2015 15:18:16 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF Message-ID: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> New submission from Thomas G?ttler: The Python tarfile library does not detect a broken tar. user at host$ wc -c good.tar 143360 good.tar user at host$ head -c 130000 good.tar > cut.tar user at host$ tar -tf cut.tar ... tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now Very nice, the command line tool recognizes an unexpected EOF. user at host$ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) >>> import tarfile >>> tar=tarfile.open('cut.tar') >>> tar.extractall() Not nice. The Python library decodes the file, but raises no exception. Is this a bug or feature? Source: http://stackoverflow.com/questions/30302204/tar-extractall-does-not-recognize-unexpected-eof ---------- messages: 243755 nosy: Thomas G?ttler priority: normal severity: normal status: open title: tar.extractall() does not recognize unexpected EOF _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 17:25:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 May 2015 15:25:23 +0000 Subject: [issue24257] Incorrect use of PyObject_IsInstance In-Reply-To: <1432197646.74.0.848752631202.issue24257@psf.upfronthosting.co.za> Message-ID: <1432221923.92.0.530954495966.issue24257@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, it is the case that if the current check passes incorrectly one will always get a segfauilt or other error. Added tests for types.SimpleNamespace and sqlite3.Cursor. It is not easy to reproduce a bug for StopIterator (not sure it is reproducible), but the code looks definitely erroneous in any case. ---------- Added file: http://bugs.python.org/file39453/typecheck_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 17:50:43 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 May 2015 15:50:43 +0000 Subject: [issue24180] PEP 492: Documentation In-Reply-To: <1432188222.61.0.941907273276.issue24180@psf.upfronthosting.co.za> Message-ID: <20150521155036.125546.46304@psf.io> Roundup Robot added the comment: New changeset 548d5704fcb3 by Yury Selivanov in branch 'default': Issue 24180: Documentation for PEP 492 changes. https://hg.python.org/cpython/rev/548d5704fcb3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 17:55:34 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 15:55:34 +0000 Subject: [issue24180] PEP 492: Documentation In-Reply-To: <1432188222.61.0.941907273276.issue24180@psf.upfronthosting.co.za> Message-ID: <1432223734.41.0.46244961647.issue24180@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks for the review Nick. I committed the patch with some additional minor fixes, including your suggestion. > Asynchronous iterator question: should the typical pattern for those be: def __aiter__(self): return self def __await__(self): return self Well, adding __await__ to asynchronous iterators is the same as adding __call__ to regular iterators. It would be like: i = iter(iterable) # __iter__ i = iterable() # __call__ ai = await iterable.__aiter__() # __aiter__ # or "ai = await aiter(iterable)", but we don't have it yet ai = await iterable # __await__ > "Did we put the ABC's in the right place?" question: reviewing the draft docs meant I just noticed that collections.abc is quite an odd home for some of these. Probably not worth worrying about, given that AsyncIterator and AsyncIterable do belong, and the others are building blocks for those. I had this question too. My impression is that Guido doesn't want to fix this in 3.5. FWIW, my initial suggestion was to have "Coroutine", "Awaitable" and "Hashable" in the top-level "abc" module (not ideal by any means). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 18:03:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 May 2015 16:03:49 +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: <20150521160345.44673.63337@psf.io> Roundup Robot added the comment: New changeset ff983ee10b3e by Yury Selivanov in branch 'default': Issue 24017: Use abc.Coroutine in inspect.iscoroutine() function https://hg.python.org/cpython/rev/ff983ee10b3e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 18:06:21 2015 From: report at bugs.python.org (Jeff McNeil) Date: Thu, 21 May 2015 16:06:21 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1432224381.8.0.90837081625.issue23863@psf.upfronthosting.co.za> Jeff McNeil added the comment: Do we have a decision on this yet? I'm willing to rework bits that may need it, but I'd like to know whether this is going to be a fruitful effort or not. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 18:21:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 May 2015 16:21:25 +0000 Subject: [issue23780] Surprising behaviour when passing list to os.path.join. In-Reply-To: <1427356923.25.0.682691905774.issue23780@psf.upfronthosting.co.za> Message-ID: <1432225285.08.0.134150823547.issue23780@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 Thu May 21 18:23:43 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 16:23:43 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <1432225423.22.0.295637605367.issue24237@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Why the switch to WriteUnraisable? After adding a unittest for the patch it became clear that it was indeed unnecessary ;) Please see the new patch. ---------- Added file: http://bugs.python.org/file39454/gen_stop_warn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 18:26:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 May 2015 16:26:51 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1432225611.25.0.404536275752.issue15836@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: michael.foord -> serhiy.storchaka versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 18:30:41 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 21 May 2015 16:30:41 +0000 Subject: [issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1432225841.61.0.348931694571.issue12319@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks for the report Rolf. I'll look into your suggestion for this patch. Antoine: Given beta is slated for the 24th and Martin's legitimate concerns, I think it might be a little hasty to get this in before feature freeze. Knocking it back to 3.6 (obviously feel free to change if you think it should remain for any reason). ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 18:41:57 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 21 May 2015 16:41:57 +0000 Subject: [issue24255] Replace debuglevel-related logic with logging In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za> Message-ID: <1432226517.99.0.55263137729.issue24255@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 18:46:53 2015 From: report at bugs.python.org (Bob Alexander) Date: Thu, 21 May 2015 16:46:53 +0000 Subject: [issue24223] argparse parsing (mingling --option and optional positional argument) In-Reply-To: <1431919756.88.0.268739707848.issue24223@psf.upfronthosting.co.za> Message-ID: Bob Alexander added the comment: Thanks for the note, Martin. I agree that it's a duplicate. (I had done a brief search for possible dups, but didn't find that one!) Bob On Sun, May 17, 2015 at 8:29 PM, Martin Panter wrote: > > Martin Panter added the comment: > > I suggest this is a duplicate of Issue 15112. The same problem also > happens with nargs="*", and that issue apparently has a patch to handle > both cases. > > For the record, this is the resulting error, and a demo that it works if > the option comes before the positional arguments: > > >>> print("test 2:", ap.parse_args(["abc", "--option", "mmm"])) > usage: [-h] [--option] arg_1 [arg_2] > : error: unrecognized arguments: mmm > Traceback (most recent call last): > File "", line 1, in > File "/home/proj/python/cpython/Lib/argparse.py", line 1729, in > parse_args > self.error(msg % ' '.join(argv)) > File "/home/proj/python/cpython/Lib/argparse.py", line 2385, in error > self.exit(2, _('%(prog)s: error: %(message)s\n') % args) > File "/home/proj/python/cpython/Lib/argparse.py", line 2372, in exit > _sys.exit(status) > File "/home/pythonstartup.py", line 345, in exit > raise SystemExit(code) > __main__.SystemExit: 2 > >>> ap.parse_args(["--option", "abc", "mmm"]) > Namespace(arg_1='abc', arg_2='mmm', option=True) > > ---------- > nosy: +vadmium > resolution: -> duplicate > stage: -> resolved > status: open -> closed > superseder: -> argparse: nargs='*' positional argument doesn't accept any > items if preceded by an option and another positional > title: argparse parsing bug -> argparse parsing (mingling --option and > optional positional argument) > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 18:49:42 2015 From: report at bugs.python.org (Petr Viktorin) Date: Thu, 21 May 2015 16:49:42 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1432226982.28.0.421615568723.issue23699@psf.upfronthosting.co.za> Petr Viktorin added the comment: Here is a version with PyErr_BadArgument. ---------- Added file: http://bugs.python.org/file39455/richcompare-macro-badargument.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 19:16:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 May 2015 17:16:18 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <20150521171615.26568.73923@psf.io> Roundup Robot added the comment: New changeset 84d7ec21cc43 by Serhiy Storchaka in branch 'default': Issue #15836: assertRaises(), assertRaisesRegex(), assertWarns() and https://hg.python.org/cpython/rev/84d7ec21cc43 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 19:20:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 May 2015 17:20:02 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1432228802.68.0.963627014568.issue15836@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Applied to 3.5 only, because this issue looks rather as new feature (preventing possible user error) and there is minimal chance to break existing tests (see issue24134). ---------- type: behavior -> enhancement versions: -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 19:51:38 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 21 May 2015 17:51:38 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1432230698.93.0.123569641809.issue24254@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a patch that drops adding __definition_order__. You can get the same effect by adding `__definition_order__ = list(locals())` at the bottom of your class definition. The benefit of having `__definition_order__` is that the information is automatically available for later use rather than forcing the class author to add the above line in order to benefit from external introspection/manipulation. The downside is that every syntax-defined class will have the extra attribute with the list of definition order, which might be an unnecessary waste, even if not a huge one. Ultimately, I'd prefer to keep `__definition_order__`. ---------- Added file: http://bugs.python.org/file39456/just-default-to-odict.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 19:52:29 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 May 2015 17:52:29 +0000 Subject: [issue23985] Crash when deleting slices from duplicated bytearray In-Reply-To: <1429252668.91.0.45841644858.issue23985@psf.upfronthosting.co.za> Message-ID: <20150521175225.39253.3024@psf.io> Roundup Robot added the comment: New changeset 274c1b0a2494 by Serhiy Storchaka in branch '2.7': Issue #23985: Fixed integer overflow in iterator object. Original patch by https://hg.python.org/cpython/rev/274c1b0a2494 New changeset 5b86a1abc8c3 by Serhiy Storchaka in branch '3.4': Issue #23985: Fixed integer overflow in iterator object. Patch by https://hg.python.org/cpython/rev/5b86a1abc8c3 New changeset 9f2a1d9d7164 by Serhiy Storchaka in branch 'default': Issue #23985: Fixed integer overflow in iterator object. Patch by https://hg.python.org/cpython/rev/9f2a1d9d7164 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 19:55:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 May 2015 17:55:28 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <20150521175519.21160.77412@psf.io> Roundup Robot added the comment: New changeset d6179accca20 by Serhiy Storchaka in branch '2.7': Fixed issue number for issue #22939. https://hg.python.org/cpython/rev/d6179accca20 New changeset 7fa2f4afcf5a by Serhiy Storchaka in branch '3.4': Fixed issue number for issue #22939. https://hg.python.org/cpython/rev/7fa2f4afcf5a New changeset f23533fa6afa by Serhiy Storchaka in branch 'default': Fixed issue number for issue #22939. https://hg.python.org/cpython/rev/f23533fa6afa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 19:57:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 May 2015 17:57:14 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1432231034.76.0.389066228301.issue15836@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 19:57:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 May 2015 17:57:46 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1432231066.88.0.548458430059.issue15836@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Daniel. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 20:00:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 May 2015 18:00:05 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1432231205.96.0.674978906829.issue22939@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Clement. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 20:01:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 May 2015 18:01:33 +0000 Subject: [issue23985] Crash when deleting slices from duplicated bytearray In-Reply-To: <1429252668.91.0.45841644858.issue23985@psf.upfronthosting.co.za> Message-ID: <1432231293.01.0.101591881393.issue23985@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, it was related to issue22939. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 20:29:33 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 18:29:33 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <1432232973.97.0.841757997917.issue24237@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, I've updated the patch to address all PendingDeprecationWarnings related to the PEP 479 in the test suite. ---------- Added file: http://bugs.python.org/file39457/gen_stop_warn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 20:38:12 2015 From: report at bugs.python.org (Tim Golden) Date: Thu, 21 May 2015 18:38:12 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1432233492.18.0.0114388318968.issue21916@psf.upfronthosting.co.za> Tim Golden added the comment: Tests failed on Windows probably because of NamedTemporaryFile ---------- nosy: +tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 20:50:52 2015 From: report at bugs.python.org (arachnegl) Date: Thu, 21 May 2015 18:50:52 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1432234252.09.0.717566488461.issue21916@psf.upfronthosting.co.za> arachnegl added the comment: Thanks Tim for testing on Windows and suggesting the change. ---------- nosy: +gregoryloyse at gmail.com versions: +Python 3.4 Added file: http://bugs.python.org/file39458/test_turtle.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 20:54:18 2015 From: report at bugs.python.org (Tim Golden) Date: Thu, 21 May 2015 18:54:18 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1432234458.26.0.201970012591.issue21916@psf.upfronthosting.co.za> Tim Golden added the comment: @RDM I'm sitting with Greg at a London Python session and we've run through these tests on 3.4/3.5. I know you were reviewing this code at PyCon. Are you happy for me to commit from here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 20:57:27 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 18:57:27 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1432234647.23.0.644998861536.issue20438@psf.upfronthosting.co.za> Yury Selivanov added the comment: Please see the new patch. So it's time to deprecate getargspec with a warning (was softly deprecated in 3.0). getfullargspec() and getcallargs() deprecation is documented. I also want to deprecate formatargspec() and formatargvalues(), but Signature does not provide equivalents. Should we add them? ---------- Added file: http://bugs.python.org/file39459/getargspec.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 21:26:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 May 2015 19:26:43 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1432236403.55.0.934440761701.issue21916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm making a review. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 21:29:18 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 May 2015 19:29:18 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1432236558.35.0.48974854119.issue21916@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, I don't need to be involved further (unless you need help from me on something :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 21:33:19 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 19:33:19 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1432236799.9.0.0197021197054.issue24056@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, Berker, please find an updated patch attached (with support for coroutines). Big +1 on the idea, BTW. ---------- Added file: http://bugs.python.org/file39460/issue24056_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 21:34:51 2015 From: report at bugs.python.org (Tim Golden) Date: Thu, 21 May 2015 19:34:51 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1432236558.35.0.48974854119.issue21916@psf.upfronthosting.co.za> Message-ID: <555E3358.3060509@timgolden.me.uk> Tim Golden added the comment: Serhiy's offered a review and we can take it from here. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 21:36:03 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 19:36:03 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1432236963.57.0.00465676086501.issue24004@psf.upfronthosting.co.za> Yury Selivanov added the comment: This issue was resolved in https://github.com/python/asyncio/commit/3a09a93277afc2cdb43badf92a2c85c2789813f6. ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 21:46:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 May 2015 19:46:19 +0000 Subject: [issue23898] inspect() changes in Python3.4 are not compatible with objects that implement special __bool__, __eq__ In-Reply-To: <1428590086.18.0.0932223784087.issue23898@psf.upfronthosting.co.za> Message-ID: <20150521194615.21172.21055@psf.io> Roundup Robot added the comment: New changeset fb9addfdfc35 by Yury Selivanov in branch '3.4': Issue 23898: Fix inspect.classify_class_attrs() to work with __eq__ https://hg.python.org/cpython/rev/fb9addfdfc35 New changeset d6a9d225413a by Yury Selivanov in branch 'default': Issue 23898: Fix inspect.classify_class_attrs() to work with __eq__ https://hg.python.org/cpython/rev/d6a9d225413a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 21:47:07 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 19:47:07 +0000 Subject: [issue23898] inspect() changes in Python3.4 are not compatible with objects that implement special __bool__, __eq__ In-Reply-To: <1428590086.18.0.0932223784087.issue23898@psf.upfronthosting.co.za> Message-ID: <1432237627.39.0.581928791033.issue23898@psf.upfronthosting.co.za> Yury Selivanov added the comment: Merged. Thanks for the bug report and patch, Mike! ---------- assignee: -> yselivanov resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 21:58:41 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 19:58:41 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1432238321.67.0.324449803947.issue24056@psf.upfronthosting.co.za> Changes by Yury Selivanov : Removed file: http://bugs.python.org/file39460/issue24056_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 22:00:37 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 20:00:37 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1432238437.03.0.270462001002.issue24056@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file39461/issue24056_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 22:05:39 2015 From: report at bugs.python.org (mike bayer) Date: Thu, 21 May 2015 20:05:39 +0000 Subject: [issue23898] inspect() changes in Python3.4 are not compatible with objects that implement special __bool__, __eq__ In-Reply-To: <1428590086.18.0.0932223784087.issue23898@psf.upfronthosting.co.za> Message-ID: <1432238739.47.0.124185384344.issue23898@psf.upfronthosting.co.za> mike bayer added the comment: thanks for the merge! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 22:15:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 May 2015 20:15:18 +0000 Subject: [issue21916] Create unit tests for turtle textonly In-Reply-To: <1404479564.66.0.23163619156.issue21916@psf.upfronthosting.co.za> Message-ID: <1432239318.71.0.976865895394.issue21916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added comments on Rietveld. It looks the patch includes changes for non-relevant files. ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 22:34:53 2015 From: report at bugs.python.org (Tim Golden) Date: Thu, 21 May 2015 20:34:53 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1432070672.59.0.100405300183.issue22107@psf.upfronthosting.co.za> Message-ID: <555E416A.1030004@timgolden.me.uk> Tim Golden added the comment: My reluctance to commit the os.access patch is because it will cause such a behaviour change in a function which has been pretty stable for a long while. It'll certainly be more correct, but at the undoubted expense of breaking someone's long-working code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 22:49:26 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 21 May 2015 20:49:26 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1432241366.56.0.602611249005.issue22107@psf.upfronthosting.co.za> Paul Moore added the comment: I'm not sure I follow. Isn't the point of this patch to try again in certain cases of a PermissionError, where currently the code breaks out of the loop early? How can the result be worse than the current behaviour? Suerly sometimes (maybe not always) it works now where it previously failed, but that's a good thing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 22:54:28 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 21 May 2015 20:54:28 +0000 Subject: [issue24180] PEP 492: Documentation In-Reply-To: <1432188222.61.0.941907273276.issue24180@psf.upfronthosting.co.za> Message-ID: <1432241668.25.0.94758187212.issue24180@psf.upfronthosting.co.za> Berker Peksag added the comment: Hi Yury, Here is a post commit review. I've mostly removed some additional PEP 492 mentions and made a couple of trivial changes. ---------- nosy: +berker.peksag Added file: http://bugs.python.org/file39462/issue24180.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 23:02:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 May 2015 21:02:44 +0000 Subject: [issue24180] PEP 492: Documentation In-Reply-To: <1432188222.61.0.941907273276.issue24180@psf.upfronthosting.co.za> Message-ID: <20150521210235.44695.96863@psf.io> Roundup Robot added the comment: New changeset 5691d2d2d0a4 by Yury Selivanov in branch 'default': Issue 24180: Fixes by Berker Peksag. https://hg.python.org/cpython/rev/5691d2d2d0a4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 23:03:37 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 May 2015 21:03:37 +0000 Subject: [issue24180] PEP 492: Documentation In-Reply-To: <1432188222.61.0.941907273276.issue24180@psf.upfronthosting.co.za> Message-ID: <1432242217.84.0.256219204533.issue24180@psf.upfronthosting.co.za> Yury Selivanov added the comment: Hi Berker, thanks for the review. I think all your edits are reasonable, so I've just committed your patch as is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 23:03:50 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 21 May 2015 21:03:50 +0000 Subject: [issue24250] Optimization for strcpy(..., "") in file 'install.c' In-Reply-To: <1432156989.27.0.220297051277.issue24250@psf.upfronthosting.co.za> Message-ID: <1432242230.46.0.940823277141.issue24250@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I agree with vadmium and also note that many compilers (though I don't know about MSVC) can optimize the strcpy call away. ---------- nosy: +benjamin.peterson resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 23:19:06 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 21 May 2015 21:19:06 +0000 Subject: [issue23973] PEP 484 implementation In-Reply-To: <1429209123.93.0.369207893318.issue23973@psf.upfronthosting.co.za> Message-ID: <1432243146.82.0.17779478791.issue23973@psf.upfronthosting.co.za> Guido van Rossum added the comment: New patch. ---------- Added file: http://bugs.python.org/file39463/pep484.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 23:23:57 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 21 May 2015 21:23:57 +0000 Subject: [issue24258] BZ2File objects do not have name attribute In-Reply-To: <1432199816.0.0.178283144298.issue24258@psf.upfronthosting.co.za> Message-ID: <1432243437.83.0.122572273984.issue24258@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 23:26:32 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 21 May 2015 21:26:32 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432243592.57.0.253989609749.issue24259@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 21 23:45:51 2015 From: report at bugs.python.org (Evgeny Kapun) Date: Thu, 21 May 2015 21:45:51 +0000 Subject: [issue24260] TabError behavior doesn't match documentation Message-ID: <1432244751.77.0.187754601995.issue24260@psf.upfronthosting.co.za> New submission from Evgeny Kapun: In the documentation, it is said: Indentation is rejected as inconsistent if a source file mixes tabs and spaces in a way that makes the meaning dependent on the worth of a tab in spaces; a TabError is raised in that case. But that's not true. For example, Python thinks that these two indentations are "consistent": <8 spaces> <8 spaces> However, their width would be different for any tab width except 1, 2, 4, and 8. Actually, it's not easy to check that indentation is "consistent" as it is defined currently, so I think that it is the documentation that should be changed. So, I think that the paragraph that I quoted above should be changed to match the actual behavior. ---------- components: Interpreter Core messages: 243794 nosy: abacabadabacaba priority: normal severity: normal status: open title: TabError behavior doesn't match documentation type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 00:14:39 2015 From: report at bugs.python.org (Evgeny Kapun) Date: Thu, 21 May 2015 22:14:39 +0000 Subject: [issue24261] Add a command line flag to suppress default signal handlers Message-ID: <1432246479.21.0.632354289175.issue24261@psf.upfronthosting.co.za> New submission from Evgeny Kapun: Currently, Python always changes handling of certain signals on startup: SIGPIPE is ignored, and SIGINT is handled by a function that raises KeyboardInterrupt exception. As a result, if the user presses Ctrl-C, a backtrace is printed to stderr. Some program may want to change this behavior. For example, they may want to print a user-friendly message, or to terminate without printing anything. They may do that by two means: either by installing their own handler for SIGINT, or by using a try..except block to handle the KeyboardInterrupt exception. However, they both have a flaw: if SIGINT is received during startup, before the program begins execution, the ugly KeyboardInterrupt backtrace is printed nevertheless. So, I propose to add a way to stop Python from installing this default SIGINT handler. I think that the most obvious way is to add a command line switch. This switch should prevent Python from installing its SIGINT handler. It may also prevent it from ignoring SIGPIPE, so that all signal actions would stay the same as when the program was executed. After that, programs may use signal module to set up their own handlers, if that is desired. ---------- components: Interpreter Core messages: 243795 nosy: abacabadabacaba priority: normal severity: normal status: open title: Add a command line flag to suppress default signal handlers type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 01:34:42 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 May 2015 23:34:42 +0000 Subject: [issue24261] Add a command line flag to suppress default signal handlers In-Reply-To: <1432246479.21.0.632354289175.issue24261@psf.upfronthosting.co.za> Message-ID: <1432251282.06.0.0872012837003.issue24261@psf.upfronthosting.co.za> R. David Murray added the comment: See also issue 14228. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 02:02:35 2015 From: report at bugs.python.org (Evgeny Kapun) Date: Fri, 22 May 2015 00:02:35 +0000 Subject: [issue14228] Don't display traceback when import site is interrupted by CTRL+c In-Reply-To: <1331197536.95.0.87995012042.issue14228@psf.upfronthosting.co.za> Message-ID: <1432252955.03.0.207886612248.issue14228@psf.upfronthosting.co.za> Changes by Evgeny Kapun : ---------- nosy: +abacabadabacaba _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 03:15:15 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 May 2015 01:15:15 +0000 Subject: [issue24257] Incorrect use of PyObject_IsInstance In-Reply-To: <1432197646.74.0.848752631202.issue24257@psf.upfronthosting.co.za> Message-ID: <1432257315.83.0.595760922031.issue24257@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Serhiy, go ahead and apply your patch. The existing code is clearly wrong. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 03:25:15 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 22 May 2015 01:25:15 +0000 Subject: [issue24261] Add a command line flag to suppress default signal handlers In-Reply-To: <1432246479.21.0.632354289175.issue24261@psf.upfronthosting.co.za> Message-ID: <1432257915.94.0.696716264964.issue24261@psf.upfronthosting.co.za> Martin Panter added the comment: I have often wished for Python to have two modes: 1. Programming development mode: something like ?python -b -Wdefault?, enabling warnings, printing full trackbacks for SIGINT and EPIPE errors, etc. Also possibly catching SystemExit() when raised inside the interactive interpreter. 2. End-user mode: hide deprecation warnings, no traceback for SIGINT and EPIPE errors (just set an exit status or maybe reraise using the default OS signal handler to set the right exit signal flag to the parent process). Among other things, this would allow easily switching between reporting KeyboardInterrupt tracebacks (whether triggered at startup or by the main code), and hiding them. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 03:37:55 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 22 May 2015 01:37:55 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432258675.78.0.482455834775.issue24259@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 04:41:03 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 22 May 2015 02:41:03 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432262463.37.0.35188015854.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: I've spent a bit of time exploring the segfault. Here's some data that might help relative to the configparser test. I put the following at the beginning of _odict_resize: Py_ssize_t len = PyObject_Size((PyObject *)od); if (len == 0) PySys_FormatStdout("."); else { if (((PyDictObject *)od)->ma_keys->dk_size < od->od_size) PySys_FormatStdout("-"); if (len < 10) PySys_FormatStdout("%d", len); else PySys_FormatStdout("+"); } if (len >= 10) PySys_FormatStdout("%d\n", len); If the current item count is 0 then it prints a dot. If the resize is shrinking then it prints a - (this did not happen). Otherwise the odict is growing and it prints the current item count. Multi-digit numbers are preceded by + and followed by a newline. I've included the results of different hash seeds (0/no randomization, 1, and 7). You'll notice how the results are subtly different. In the case of 7, it matches no randomization up to the point that it segfaults. I got the same results with 15. However, 35 fails right after the second +22. $ PYTHONHASHSEED=0 ./python -m test.regrtest -m test_basic test_configparser ...6+12 +22 ....6+12 +22 ........6.6........+10 ........6.6........+10 ........6.6........+10 ........6.6........+10 ........6.6........+10 .+10 ........6.6........+10 ........6.6........+10 ........6.6........+10 ........6.6...............6..6............+10 ....6.6.6.6.66.66.6.6.6.6.+12 6.+12 6.6.6.6.6.6.6.6.6.+22 6.+22 6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.+44 6.+44 6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.+86 6.+86 6.6.6.6.6.6.6.6.6.6.6.6.6.6.6........6.6........+10 ........6.6........+10 ........6.6........+10 ........6.6........+10 .6.. $ PYTHONHASHSEED=1 ./python -m test.regrtest -m test_basic test_configparser ...6+12 +22 ....6+12 +22 ........6.6................6.6................6.6................6.6................6.6.........+11 ........6.6................6.6................6.6................6.6...............6..6................6.6.6.6.66.66.6.6.6.6.+12 6.+12 6.6.6.6.6.6.6.6.6.+22 6.+22 6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.+44 6.+44 6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.6.+86 6.+86 6.6.6.6.6.6.6.6.6.6.6.6.6.6.6........6.6................6.6................6.6................6.6.........6.. $ PYTHONHASHSEED=7 ./python -m test.regrtest -m test_basic test_configparser ...6+12 +22 ....6+12 +22 ........6.6........+10 ........6.6........+10 ........6.6........+10 ........6.6........+10 ........6.6........+10 .+10 Fatal Python error: Segmentation fault ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 04:43:11 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 22 May 2015 02:43:11 +0000 Subject: [issue12319] [http.client] HTTPConnection.request not support "chunked" Transfer-Encoding to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1432262591.51.0.649354266235.issue12319@psf.upfronthosting.co.za> Martin Panter added the comment: This bug and Demian?s patch were originally about changing the low-level http.client.HTTPConnection class. I suggest opening a separate issue for changing urllib.request.urlopen() or similar, to avoid confusion. It should actually be possible to support chunking in urlopen() without any new support from HTTPConnection; just use the lower-level putrequest(), putheader(), endheader(), and send() methods. However, consideration should be given to how it interacts with handlers like HTTPBasicAuthHandler that resend POST data after getting 401 Unauthorized (similar scenario to Issue 5038). ---------- title: [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data -> [http.client] HTTPConnection.request not support "chunked" Transfer-Encoding to send data _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 05:53:21 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 22 May 2015 03:53:21 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432266801.18.0.366622806565.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: As far as I can tell there aren't any patterns that repeat across multiple seeds (which makes sense). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 06:00:12 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 22 May 2015 04:00:12 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432267212.05.0.0337243032014.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Here are the last 10 frames from the backtrace (gdb): #0 0x00000000005b15d0 in odictiter_iternext (di=) at Objects/odictobject.c:1888 #1 0x0000000000453179 in PyIter_Next (iter=) at Objects/abstract.c:2760 #2 0x00000000005881e7 in chain_next (lz=0x7ffff2b8d878) at ./Modules/itertoolsmodule.c:1866 #3 0x0000000000537db6 in PyEval_EvalFrameEx (f=f at entry=0xcab188, throwflag=throwflag at entry=0) at Python/ceval.c:2975 #4 0x000000000053afee in fast_function (func=func at entry=0x7ffff2bc88f8, pp_stack=pp_stack at entry=0x7fffffff99f8, n=n at entry=1, na=na at entry=1, nk=nk at entry=0) at Python/ceval.c:4752 #5 0x000000000053b655 in call_function (pp_stack=pp_stack at entry=0x7fffffff99f8, oparg=oparg at entry=0) at Python/ceval.c:4679 #6 0x000000000053891d in PyEval_EvalFrameEx (f=f at entry=0xcbd588, throwflag=throwflag at entry=0) at Python/ceval.c:3198 #7 0x000000000053afee in fast_function (func=func at entry=0x7ffff2bc8840, pp_stack=pp_stack at entry=0x7fffffff9bd8, n=n at entry=3, na=na at entry=3, nk=nk at entry=0) at Python/ceval.c:4752 #8 0x000000000053b655 in call_function (pp_stack=pp_stack at entry=0x7fffffff9bd8, oparg=oparg at entry=2) at Python/ceval.c:4679 #9 0x000000000053891d in PyEval_EvalFrameEx (f=f at entry=0xc7d458, throwflag=throwflag at entry=0) at Python/ceval.c:3198 and from Python: Current thread 0x00007f3ad9260740 (most recent call first): File "/home/esnow/projects/cordereddict/Lib/configparser.py", line 1115 in _join_multiline_values File "/home/esnow/projects/cordereddict/Lib/configparser.py", line 1109 in _read File "/home/esnow/projects/cordereddict/Lib/configparser.py", line 716 in read_file File "/home/esnow/projects/cordereddict/Lib/configparser.py", line 721 in read_string File "/home/esnow/projects/cordereddict/Lib/test/test_configparser.py", line 354 in test_basic File "/home/esnow/projects/cordereddict/Lib/unittest/case.py", line 597 in run ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 06:03:32 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 22 May 2015 04:03:32 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432267412.66.0.612985850304.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: The segfault happens at line 1888 of odictobject.c when it tries to Py_INCREF a NULL value. The problem is that the value that gets looked up for a presumably valid key is returned as NULL. So either the value is messed up, lookup is broken, or the wrong key is being used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 06:12:29 2015 From: report at bugs.python.org (Gleb Dubovik) Date: Fri, 22 May 2015 04:12:29 +0000 Subject: [issue24262] logging.FileHandler.close() is not thread-safe Message-ID: <1432267949.32.0.854494072121.issue24262@psf.upfronthosting.co.za> New submission from Gleb Dubovik: We're using FileHandler in combination with pytest plugin. Every time new test starts, new FileHandler is created and attached to the root logger, at the end of the test FileHandler is removed. This allows us to create per-test log files. There are some threads that persist throughout the test session. They may perform logging at about the same time when we remove FileHandler. Sometimes either thread that performs logging or the thread that closes the handler raise an exception: ValueError: I/O operation on closed file IOError: close() called during concurrent operation on the same file object. AttributeError: 'NoneType' object has no attribute 'write' Before closing the handler we do remove it from the logger. This happens because operations that access FileHandler.stream (like close() and flush()) do not acquire the handler lock that guards emit() method. As a result, one thread may start closing the stream while the other freely enters emit and tries to write to the file. The race may happen within the file object and on the stream field itself (the combination "if stream is not None: stream = None" is not thread-safe). This issue is related to two other bugs: https://bugs.python.org/issue1760556 https://bugs.python.org/issue11444 Repro code: Python 2.7.3 (default, Feb 27 2014, 19:58:35) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import threading >>> import time >>> import logging >>> >>> root_logger = logging.getLogger() >>> root_logger.addHandler(logging.NullHandler()) >>> >>> def do_logging(): ... for _ in xrange(1000000): ... logging.error("TEST!"*100) ... >>> threading.Thread(target=do_logging).start() >>> >>> for _ in xrange(100): ... handler = logging.FileHandler("/tmp/test") ... root_logger.addHandler(handler) ... time.sleep(6) ... root_logger.removeHandler(handler) ... handler.close() ... Traceback (most recent call last): File "/usr/lib/python2.7/logging/__init__.py", line 867, in emit stream.write(fs % msg) AttributeError: 'NoneType' object has no attribute 'write' Logged from file , line 3 Traceback (most recent call last): File "", line 6, in File "/usr/lib/python2.7/logging/__init__.py", line 906, in close self.stream.close() IOError: close() called during concurrent operation on the same file object. >>> exit() ---------- components: Library (Lib) messages: 243804 nosy: dubglan priority: normal severity: normal status: open title: logging.FileHandler.close() is not thread-safe type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 06:22:37 2015 From: report at bugs.python.org (eryksun) Date: Fri, 22 May 2015 04:22:37 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1432268557.03.0.564375193324.issue22107@psf.upfronthosting.co.za> eryksun added the comment: Shouldn't it be checking whether `file` (or `filename`) is a directory [1]? For example: except PermissionError: # This exception is thrown when a directory with # the chosen name already exists on windows. if _os.name == 'nt' and _os.path.isdir(file): continue # If the directory allows write access, continue # trying names. On Windows, currently this test # doesn't work. The implementation assumes all # directories allow write access, but it really # depends on the directory's discretionary and # system access control lists (DACL & SACL). elif _os.access(dir, _os.W_OK): continue else: raise --- [1]: Windows sets the last error to ERROR_ACCESS_DENIED when a system call returns the NTSTATUS code STATUS_FILE_IS_A_DIRECTORY. This status code is returned by NtCreateFile and NtOpenFile when the target file is a directory, but the caller asked for anything but a directory (i.e. CreateOptions contains FILE_NON_DIRECTORY_FILE). ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 07:11:07 2015 From: report at bugs.python.org (Matthew Barnett) Date: Fri, 22 May 2015 05:11:07 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432271466.99.0.644076443087.issue16991@psf.upfronthosting.co.za> Matthew Barnett added the comment: FTR, in "_odict_resize" there's this: size_t i = _odict_get_index(od, _odictnode_KEY(node)); if (i < 0) { Note that "i" is declared as unsigned and then tested whether it's negative. ---------- nosy: +mrabarnett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 07:26:42 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 22 May 2015 05:26:42 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432272402.08.0.537471075278.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Yeah, Ned pointed that one out. I fixed it but haven't pushed the change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 07:48:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 May 2015 05:48:34 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1432273714.26.0.464093355372.issue22107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is a risk of race condition. One process can create a directory `file`, then other process fails to create a file with the same name `file`, then the first process removes directory `file`, then the second process handles PermissionError. The same is possible also with threads. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 08:18:00 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 22 May 2015 06:18:00 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1432275480.16.0.880434658437.issue24230@psf.upfronthosting.co.za> Gregory P. Smith added the comment: code review comments addressed. ---------- Added file: http://bugs.python.org/file39464/issue24230-gps02.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 08:27:57 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 22 May 2015 06:27:57 +0000 Subject: [issue24262] logging.FileHandler.close() is not thread-safe In-Reply-To: <1432267949.32.0.854494072121.issue24262@psf.upfronthosting.co.za> Message-ID: <1432276077.47.0.656935285739.issue24262@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 08:33:48 2015 From: report at bugs.python.org (Gleb Dubovik) Date: Fri, 22 May 2015 06:33:48 +0000 Subject: [issue24262] logging.FileHandler.close() is not thread-safe In-Reply-To: <1432267949.32.0.854494072121.issue24262@psf.upfronthosting.co.za> Message-ID: <1432276428.09.0.0203021544239.issue24262@psf.upfronthosting.co.za> Gleb Dubovik added the comment: We used a very old version of python shipped with 12.04 LTS. The bug was fixed in 2.7.3 in 2ab3a97d544c by Vinay. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 08:46:56 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 22 May 2015 06:46:56 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <1432277216.64.0.164257319827.issue24237@psf.upfronthosting.co.za> Nick Coghlan added the comment: The patch mostly looks good to me, but I suggest using "test.support.check_warnings" for the cases where you're checking that the warning is raised as expected: https://docs.python.org/3/library/test.html#test.support.check_warnings It's slightly simpler than constructing the same logic yourself using warnings.catch_warnings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 08:49:00 2015 From: report at bugs.python.org (sih4sing5hong5) Date: Fri, 22 May 2015 06:49:00 +0000 Subject: [issue24263] Why VALID_MODULE_NAME in unittest/loader.py is r'[_a-z]\w*\.py$' not r'\w+\.py$' ? Message-ID: <1432277340.77.0.265185890941.issue24263@psf.upfronthosting.co.za> Changes by sih4sing5hong5 : ---------- components: Unicode nosy: ezio.melotti, haypo, sih4sing5hong5 priority: normal severity: normal status: open title: Why VALID_MODULE_NAME in unittest/loader.py is r'[_a-z]\w*\.py$' not r'\w+\.py$' ? type: behavior versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 08:58:55 2015 From: report at bugs.python.org (eryksun) Date: Fri, 22 May 2015 06:58:55 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1432277935.48.0.352888068847.issue22107@psf.upfronthosting.co.za> eryksun added the comment: Ok, I think I understand now. You chose an indirect check to avoid the race condition. If we have write access to the directory, then the PermissionError must be because a directory exists with the same name. Unfortunately os.access doesn't currently tell us this information. Moreover, checking `isdir(dir) and access(dir, W_OK)` is actually redundant as things currently stand. If `isdir` returns True that means GetFileAttributes didn't fail, which means `access` must return True as designed: return_value = (attr != INVALID_FILE_ATTRIBUTES) && ( !(mode & 2) || !(attr & FILE_ATTRIBUTE_READONLY) || (attr & FILE_ATTRIBUTE_DIRECTORY) ); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 09:01:03 2015 From: report at bugs.python.org (JohnLeitch) Date: Fri, 22 May 2015 07:01:03 +0000 Subject: [issue24264] imageop Unsafe Arithmetic Message-ID: <1432278063.26.0.673606816428.issue24264@psf.upfronthosting.co.za> New submission from JohnLeitch: Several functions within the imageop module are vulnerable to exploitable buffer overflows due to unsafe arithmetic in check_multiply_size(). The problem exists because the check to confirm that size == product / y / x does not take remainders into account. static int check_multiply_size(int product, int x, const char* xname, int y, const char* yname, int size) { if ( !check_coordonnate(x, xname) ) return 0; if ( !check_coordonnate(y, yname) ) return 0; if ( size == (product / y) / x ) return 1; PyErr_SetString(ImageopError, "String has incorrect length"); return 0; } Consider a call to check_multiply_size() where product is 16, x is 1, and y is 9. In the Windows x86 release of Python 2.7.9, the division is performed using the idiv instruction: 0:000> dV product = 0n16 x = 0n1 xname = 0x1e1205a4 "x" y = 0n9 yname = 0x1e127ab8 "y" size = 0n1 0:000> u eip python27!check_multiply_size+0x25 [c:\build27\cpython\modules\imageop.c @ 53]: 1e0330e5 f7ff idiv eax,edi 1e0330e7 99 cdq 1e0330e8 f7fe idiv eax,esi 1e0330ea 3944240c cmp dword ptr [esp+0Ch],eax 1e0330ee 7506 jne python27!check_multiply_size+0x36 (1e0330f6) 1e0330f0 b801000000 mov eax,1 1e0330f5 c3 ret 1e0330f6 8b15e47e241e mov edx,dword ptr [python27!ImageopError (1e247ee4)] 0:000> ?eax Evaluate expression: 16 = 00000010 0:000> ?edi Evaluate expression: 9 = 00000009 When the first idiv instruction is executed, the result (eax) is 1 with a remainder of 7 (edx): 0:000> p eax=00000001 ebx=00000000 ecx=1e127ab8 edx=00000007 esi=00000001 edi=00000009 eip=1e0330e7 esp=0027fcec ebp=00000001 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202 python27!check_multiply_size+0x27: 1e0330e7 99 cdq 0:000> ?eax Evaluate expression: 1 = 00000001 0:000> ?edx Evaluate expression: 7 = 00000007 Because size is 1, the check passes: Breakpoint 4 hit eax=00000001 ebx=00000000 ecx=1e127ab8 edx=00000000 esi=00000001 edi=00000009 eip=1e0330f0 esp=0027fcec ebp=00000001 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!check_multiply_size+0x30: 1e0330f0 b801000000 mov eax,1 This is problematic because some of the imageop functions, such as grey2rgb, utilize check_multiply_size() to check divisibility prior to copying data into a buffer. Consider a call to grey2rgb where x is 1, y is 9, and len is 16. static PyObject * imageop_grey2rgb(PyObject *self, PyObject *args) { int x, y, len, nlen; <<<<<<<< x = 1, y = 9, and len = 16. unsigned char *cp; unsigned char *ncp; PyObject *rv; int i; unsigned char value; int backward_compatible = imageop_backward_compatible(); if ( !PyArg_ParseTuple(args, "s#ii", &cp, &len, &x, &y) ) return 0; if ( !check_multiply(len, x, y) ) <<<<<<<< 16 != 1 * 9, but this check still passes. return 0; nlen = x*y*4; <<<<<<<< 1 * 9 * 4 == 36. if ( !check_multiply_size(nlen, x, "x", y, "y", 4) ) return 0; rv = PyString_FromStringAndSize(NULL, nlen); <<<<<<<< This creates a buffer of length 36. if ( rv == 0 ) return 0; ncp = (unsigned char *)PyString_AsString(rv); <<<<<<<< This retrieves the buffer of length 36. for ( i=0; i < len; i++ ) { <<<<<<<< This loop assumes that len * 4 == nlen, which is incorrect in this case. value = *cp++; if (backward_compatible) { VVVVVVVV Each iteration copies 4 bytes into the 36 byte buffer pointed to by ncp and advances the pointer by 4. Because len is 16, 64 bytes are ultimately copied into the buffer, leading to an exploitable buffer overflow condition. * (Py_UInt32 *) ncp = (Py_UInt32) value | ((Py_UInt32) value << 8 ) | ((Py_UInt32) value << 16); ncp += 4; } else { *ncp++ = 0; *ncp++ = value; *ncp++ = value; *ncp++ = value; } } return rv; } When the call completes, memory has been corrupted: 0:000> g (12f4.640): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00444444 ebx=00000001 ecx=1e201d98 edx=00303030 esi=1e201d98 edi=1e201d98 eip=1e031fc6 esp=0027fe7c ebp=00000002 iopl=0 nv up ei ng nz ac pe cy cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010297 python27!update_refs+0x6: 1e031fc6 8b5010 mov edx,dword ptr [eax+10h] ds:002b:00444454=???????? 0:000> g (12f4.640): Access violation - code c0000005 (!!! second chance !!!) eax=00444444 ebx=00000001 ecx=1e201d98 edx=00303030 esi=1e201d98 edi=1e201d98 eip=1e031fc6 esp=0027fe7c ebp=00000002 iopl=0 nv up ei ng nz ac pe cy cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010297 python27!update_refs+0x6: 1e031fc6 8b5010 mov edx,dword ptr [eax+10h] ds:002b:00444454=???????? During fuzzing, DEP access violations were encountered, so it should be assumed that this vulnerability can be exploited to achieve arbitrary code execution. To fix this vulnerability, it is recommended that check_multiply_size() confirm divisibility. ---------- components: Interpreter Core files: imageopBufferOverflow.py messages: 243813 nosy: JohnLeitch priority: normal severity: normal status: open title: imageop Unsafe Arithmetic type: security versions: Python 2.7 Added file: http://bugs.python.org/file39465/imageopBufferOverflow.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 09:07:35 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 22 May 2015 07:07:35 +0000 Subject: [issue24263] Why VALID_MODULE_NAME in unittest/loader.py is r'[_a-z]\w*\.py$' not r'\w+\.py$' ? Message-ID: <1432278455.96.0.186833178915.issue24263@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: -Unicode nosy: +rbcollins versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 09:16:42 2015 From: report at bugs.python.org (eryksun) Date: Fri, 22 May 2015 07:16:42 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za> Message-ID: <1432279002.35.0.911983177612.issue22107@psf.upfronthosting.co.za> eryksun added the comment: > My reluctance to commit the os.access patch is because it will > cause such a behaviour change in a function which has been > pretty stable for a long while. The original behavior could be preserved as the default. A keyword-only argument could enable checking access based on the file security and thread token. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 09:22:32 2015 From: report at bugs.python.org (Tim Golden) Date: Fri, 22 May 2015 07:22:32 +0000 Subject: [issue22107] tempfile module misinterprets access denied error on Windows In-Reply-To: <1432279002.35.0.911983177612.issue22107@psf.upfronthosting.co.za> Message-ID: <555ED934.7020105@timgolden.me.uk> Tim Golden added the comment: That is a possibility which hadn't occurred to me. @eryksun, would you mind eyeballing the patch over on issue2582? It almost certainly won't apply cleanly as it's been almost two years since I last refreshed it, but you can hopefully gauge the intent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 09:42:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 May 2015 07:42:12 +0000 Subject: [issue24221] Clean-up and optimization for heapq siftup() and siftdown() In-Reply-To: <1431911153.11.0.995728012143.issue24221@psf.upfronthosting.co.za> Message-ID: <20150522074209.70415.87832@psf.io> Roundup Robot added the comment: New changeset 490720fc1525 by Raymond Hettinger in branch 'default': Issue #24221: Small optimizations for heapq. https://hg.python.org/cpython/rev/490720fc1525 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 09:43:00 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 May 2015 07:43:00 +0000 Subject: [issue24221] Clean-up and optimization for heapq siftup() and siftdown() In-Reply-To: <1431911153.11.0.995728012143.issue24221@psf.upfronthosting.co.za> Message-ID: <1432280580.07.0.916738436476.issue24221@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 09:54:12 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 22 May 2015 07:54:12 +0000 Subject: [issue24221] Clean-up and optimization for heapq siftup() and siftdown() In-Reply-To: <1431911153.11.0.995728012143.issue24221@psf.upfronthosting.co.za> Message-ID: <1432281252.06.0.0282122525075.issue24221@psf.upfronthosting.co.za> Stefan Behnel added the comment: There are calls to PyObject_RichCompareBool() in the loops, which means that user code might get executed. What if that's evil code that modifies the heap list? Couldn't that lead to list resizing and thus invalidation of the list item pointer? ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 10:00:25 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Fri, 22 May 2015 08:00:25 +0000 Subject: [issue24219] Repeated integer in Lexical analysis/Integer literals section In-Reply-To: <1431886251.68.0.470371931129.issue24219@psf.upfronthosting.co.za> Message-ID: <1432281625.52.0.736482205445.issue24219@psf.upfronthosting.co.za> Dmitry Kazakov added the comment: Please, do tell me if I'm wrong deleting that literal and it actually serves some purpose... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 10:06:27 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 22 May 2015 08:06:27 +0000 Subject: [issue23969] please set a SOABI for MacOSX In-Reply-To: <1429125133.46.0.136772675069.issue23969@psf.upfronthosting.co.za> Message-ID: <1432281987.29.0.67263858151.issue23969@psf.upfronthosting.co.za> Ned Deily added the comment: Ronald, the change to set the SOABI was pushed several weeks ago (but, because I left out a #, the commit message did not also show up here as I intended): New changeset 32c24eec035f by Ned Deily in branch 'default': Issues #22980, 23969: For OS X, use PEP 3149-style file names for extension https://hg.python.org/cpython/rev/32c24eec035f As noted in the commit message, the names are now of the form: _ssl.cpython-35m-darwin.so As was extensively discussed in Issue22980, I chose to not try to add hardware architecture and deployment target to the file name as I think pip and friends are already managing this correctly (msg241254). We could change the name from -darwin to -macosx if you feel strongly about it but, if so, we should do that now, before beta1. I don't feel too strongly about it (e.g. "-darwin" vs "-macosx") but I would rather not re-open the discussion at this point if possible. Also, given the discussion there, I'd rather not attempt to change the extension from .so to something else; I think that is more likely to be disruptive to the external packaging ecosphere. So unless you *really* want it changed, I intend to let things stand for 3.5 as implemented in 32c24eec035f. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 10:08:41 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 22 May 2015 08:08:41 +0000 Subject: [issue24264] imageop Unsafe Arithmetic In-Reply-To: <1432278063.26.0.673606816428.issue24264@psf.upfronthosting.co.za> Message-ID: <1432282121.52.0.407189408433.issue24264@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 10:14:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 May 2015 08:14:05 +0000 Subject: [issue24257] Incorrect use of PyObject_IsInstance In-Reply-To: <1432197646.74.0.848752631202.issue24257@psf.upfronthosting.co.za> Message-ID: <20150522081403.70413.14882@psf.io> Roundup Robot added the comment: New changeset bccaba8a5482 by Serhiy Storchaka in branch '2.7': Issue #24257: Fixed segmentation fault in sqlite3.Row constructor with faked https://hg.python.org/cpython/rev/bccaba8a5482 New changeset c7b9645a6f35 by Serhiy Storchaka in branch '3.4': Issue #24257: Fixed incorrect uses of PyObject_IsInstance(). https://hg.python.org/cpython/rev/c7b9645a6f35 New changeset a5101529a8a9 by Serhiy Storchaka in branch 'default': Issue #24257: Fixed incorrect uses of PyObject_IsInstance(). https://hg.python.org/cpython/rev/a5101529a8a9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 10:22:56 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 22 May 2015 08:22:56 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1432282976.59.0.955886047748.issue24230@psf.upfronthosting.co.za> Martin Panter added the comment: Looks good in general. I think the signatures in Doc/library/tempfile.rst need updating for the following functions (possibly also version changed notices added somewhere): * NamedTemporaryFile * TemporaryFile * SpooledTemporaryFile * TemporaryDirectory ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 10:24:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 May 2015 08:24:25 +0000 Subject: [issue24257] Incorrect use of PyObject_IsInstance In-Reply-To: <1432197646.74.0.848752631202.issue24257@psf.upfronthosting.co.za> Message-ID: <1432283065.82.0.704291499133.issue24257@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 Fri May 22 10:44:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 May 2015 08:44:14 +0000 Subject: [issue24221] Clean-up and optimization for heapq siftup() and siftdown() In-Reply-To: <1431911153.11.0.995728012143.issue24221@psf.upfronthosting.co.za> Message-ID: <1432284254.08.0.326742622167.issue24221@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The list item pointer is updated just after calling PyObject_RichCompareBool(). The code LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 10:48:49 2015 From: report at bugs.python.org (Rolf Krahl) Date: Fri, 22 May 2015 08:48:49 +0000 Subject: [issue12319] [http.client] HTTPConnection.request not support "chunked" Transfer-Encoding to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1432284528.99.0.621618493238.issue12319@psf.upfronthosting.co.za> Rolf Krahl added the comment: I disagree. I believe that the suggested modification of AbstractHTTPHandler.do_request_() belongs into this change set for the following reasons: 1. "This module [http.client] defines classes which implement the client side of the HTTP and HTTPS protocols. It is normally not used directly ? the module urllib.request uses it to handle URLs that use HTTP and HTTPS." Quote from the http.client documentation. urllib.request is the high level API for HTTP requests. Both modules must fit together. Since urllib's HTTPHandler directly calls HTTPConnection, it can and should rely on the abilities of HTTPConnection. 2. The code in AbstractHTTPHandler is based on the assumption that each HTTP request having a non empty body must have a Content-length header set. The truth is that a HTTP request must either have a Content-length header or use chunked transfer encoding (and then must not have a Content-length header). As long as the underlying low level module did not support chunked transfer encoding anyway, this assumption might have been acceptable. Now that this change set introduces support for chunked transfer encoding, this assumption is plain wrong and the resulting code just faulty. 3. This change set introduces a sophisticated determination of the correct content length, covering several different cases, including file like objects and iterables. There is no need any more for the high level API to care about the content length, if this is already done in the low level method. But even worse, all the efforts of HTTPConnection to determine the proper content length is essentially overridden by the rather blunt method in the high level API that get priority and that essentially insists the body to be a buffer like object. This is strange. 4. The very purpose of this change set is to implement chunked transfer encoding. But this is essentially disabled by a high level API that insists a Content-length header to be set. This is plain silly. Just to illustrate the current situation, I attach the modified version of my old chunkedhttp.py module, adapted to Demian's patch that I have used to test it. It shows how a user would need to monkey patch the high level API in order to be able to use the features that is implemented by this change in the low level module. I wouldn't mind to file another issue against urllib.request.HTTPHandler if this makes things easier. But what I really would like to avoid, is to have any Python version in the wild that has this current issue fixed, but HTTPHandler still broken. Having to support a wide range of different Python versions is difficult enough for third party library authors like me. Adding a switch to distinguish between 3.6 (I can use the standard lib right away) and older (I need to replace it be my own old chunkedhttp implementation) is ok. But having to support a third case (the low level HTTPConnection module would work, but I need to monkey patch the high level API in order to be able to use it) in-between would make things awkward. That's why I would prefer to see the fix for HTTPHandler in the same change set. ---------- Added file: http://bugs.python.org/file39466/chunkedhttp-2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 15:16:16 2015 From: report at bugs.python.org (ppperry) Date: Fri, 22 May 2015 13:16:16 +0000 Subject: [issue24265] IDLE produces error message when run with both -s and -c. Message-ID: <1432300576.43.0.431930504874.issue24265@psf.upfronthosting.co.za> New submission from ppperry: When I run "python -m idlelib.idle -sc [command] from the command line, IDLE runs the startup file, but then pops up an error message saying "the Python Shell window is already executing a command;please wait until it is finished." When the error window is closed, the command executes, unless the main Python Shell has already been closed, in which case a traceback occurs: Traceback (most recent call last): File "C:\Python27\lib\runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "C:\Python27\lib\runpy.py", line 72, in _run_code exec code in run_globals File "C:\Python27\lib\idlelib\idle.py", line 11, in idlelib.PyShell.main() File "C:\Python27\lib\idlelib\PyShell.py", line 1602, in main shell.interp.execsource(cmd) AttributeError: 'NoneType' object has no attribute 'execsource' ---------- components: IDLE messages: 243824 nosy: kbk, ppperry, roger.serwy, terry.reedy priority: normal severity: normal status: open title: IDLE produces error message when run with both -s and -c. versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 15:41:33 2015 From: report at bugs.python.org (ppperry) Date: Fri, 22 May 2015 13:41:33 +0000 Subject: [issue24265] IDLE produces error message when run with both -s and -c. In-Reply-To: <1432300576.43.0.431930504874.issue24265@psf.upfronthosting.co.za> Message-ID: <1432302093.91.0.138747771169.issue24265@psf.upfronthosting.co.za> Changes by ppperry : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 15:46:52 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 May 2015 13:46:52 +0000 Subject: [issue24262] logging.FileHandler.close() is not thread-safe In-Reply-To: <1432267949.32.0.854494072121.issue24262@psf.upfronthosting.co.za> Message-ID: <1432302412.56.0.259237322627.issue24262@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: fixed -> out of date stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 15:53:52 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 May 2015 13:53:52 +0000 Subject: [issue24219] Repeated integer in Lexical analysis/Integer literals section In-Reply-To: <1431886251.68.0.470371931129.issue24219@psf.upfronthosting.co.za> Message-ID: <1432302832.77.0.617348761899.issue24219@psf.upfronthosting.co.za> R. David Murray added the comment: I believe you are correct. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 16:28:14 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 22 May 2015 14:28:14 +0000 Subject: [issue24221] Clean-up and optimization for heapq siftup() and siftdown() In-Reply-To: <1431911153.11.0.995728012143.issue24221@psf.upfronthosting.co.za> Message-ID: <1432304894.29.0.116623946794.issue24221@psf.upfronthosting.co.za> Stefan Behnel added the comment: Ah, sorry, yes. I somehow misread the arguments being passed *into* richcompare as subsequent array access. LGTM too. Sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 16:35:04 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 22 May 2015 14:35:04 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <1432305304.77.0.313279344232.issue24237@psf.upfronthosting.co.za> Berker Peksag added the comment: Another alternative is using assertWarnsRegex. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 16:58:03 2015 From: report at bugs.python.org (sping) Date: Fri, 22 May 2015 14:58:03 +0000 Subject: [issue24266] raw_input function (with readline): Ctrl+C (during search mode but not only) leaves readline in broken state Message-ID: <1432306683.9.0.470835567306.issue24266@psf.upfronthosting.co.za> New submission from sping: Hi! A college of mine ran into a bug with raw_input. We have a shell derived from stdlib module "cmd" here but the bug shows with plain raw_input, as well (see demo code). For the symptoms: the shell is executing commands from history that the user explicitly chose not to run. Since our shell does things like deallocation of LVM volumes, that behavior is rather troublesome :) How does it happen? * When pressing Ctrl+R, an incremental reverse history search is started. During that search, you normalled press Escape/Ctrl+J/Ctrl+G to end search or Return to pick a result. * When you press Ctrl+C though, the next call to the raw_input function believes to be in search mode still (while not showing "(reverse-i-search)" or indicating search some way). * Now when (entering some text and) pressing return now, the string last shown during incremental search is being return from raw_input (and executed in context of the cmd module). I have re-produced the issue with Python 2.7.3, 2.7.9, 3.2.3, 3.4.2. For a workaround, one can handle KeyboardInterrupt and internal adjust variable rl_readline_state of the C readline library. I'm attaching (a minimal bug demo and) the ctypes based workaround that works well over here. (The workaround demo also shows that readline state is not fully reset when Ctrl+C was pressed outside of search mode, since flag RL_STATE_DONE is not set after.) It would rock the house if this could be fixed in Python. I'm looking forward to your reply. Best, Sebastian ---------- components: Interpreter Core files: raw_input__workaround_demo.py messages: 243828 nosy: sping priority: normal severity: normal status: open title: raw_input function (with readline): Ctrl+C (during search mode but not only) leaves readline in broken state 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/file39467/raw_input__workaround_demo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 16:58:32 2015 From: report at bugs.python.org (sping) Date: Fri, 22 May 2015 14:58:32 +0000 Subject: [issue24266] raw_input function (with readline): Ctrl+C (during search mode but not only) leaves readline in broken state In-Reply-To: <1432306683.9.0.470835567306.issue24266@psf.upfronthosting.co.za> Message-ID: <1432306712.45.0.786435366496.issue24266@psf.upfronthosting.co.za> Changes by sping : Added file: http://bugs.python.org/file39468/raw_input__minimal.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 17:16:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 May 2015 15:16:57 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <20150522151653.27931.1390@psf.io> Roundup Robot added the comment: New changeset 2771a0ac806b by Yury Selivanov in branch 'default': Issue 24237: Raise PendingDeprecationWarning per PEP 479 https://hg.python.org/cpython/rev/2771a0ac806b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 17:16:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 May 2015 15:16:57 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <20150522151653.27931.62719@psf.io> Roundup Robot added the comment: New changeset 2771a0ac806b by Yury Selivanov in branch 'default': Issue 24237: Raise PendingDeprecationWarning per PEP 479 https://hg.python.org/cpython/rev/2771a0ac806b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 17:20:29 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 22 May 2015 15:20:29 +0000 Subject: [issue24237] PEP 479: missing DeprecationWarning when generator_stop is not used In-Reply-To: <1432034180.53.0.39436182939.issue24237@psf.upfronthosting.co.za> Message-ID: <1432308029.5.0.759374830244.issue24237@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, I updated the code to use assertWarnsRegex (thanks for suggestion, Berker!) Closing the issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 17:30:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 May 2015 15:30:53 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <20150522153050.27939.67546@psf.io> Roundup Robot added the comment: New changeset c8a3e49f35e7 by Yury Selivanov in branch 'default': docs: Mention PEP 479 in whatsnew. https://hg.python.org/cpython/rev/c8a3e49f35e7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 17:32:41 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 22 May 2015 15:32:41 +0000 Subject: [issue24180] PEP 492: Documentation In-Reply-To: <1432188222.61.0.941907273276.issue24180@psf.upfronthosting.co.za> Message-ID: <1432308761.29.0.903810607998.issue24180@psf.upfronthosting.co.za> Yury Selivanov added the comment: Closing this issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 17:35:30 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 22 May 2015 15:35:30 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1432308930.44.0.0821299850379.issue24056@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, Berker, a kind reminder -- please review the patch if we want to have it in 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 17:39:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 May 2015 15:39:03 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <20150522153900.16305.85699@psf.io> Roundup Robot added the comment: New changeset 3a5fec5e025d by Yury Selivanov in branch 'default': Issue 20438: Deprecate inspect.getargspec() and friends. https://hg.python.org/cpython/rev/3a5fec5e025d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 17:39:20 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 22 May 2015 15:39:20 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1432309160.12.0.26892778742.issue20438@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 18:13:37 2015 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 22 May 2015 16:13:37 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1432311217.61.0.465225082322.issue23699@psf.upfronthosting.co.za> Petr Viktorin added the comment: Just a reminder: if you want this to be in Python 3.5, please review the patch ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 18:27:23 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 22 May 2015 16:27:23 +0000 Subject: [issue12319] [http.client] HTTPConnection.request not support "chunked" Transfer-Encoding to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1432312043.77.0.851683409727.issue12319@psf.upfronthosting.co.za> Demian Brecht added the comment: FWIW, I was intending to address the issues Rolf raised. Also, I agree that a patch shouldn't knowingly have negative knock-on effects to dependents. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 18:33:53 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 22 May 2015 16:33:53 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1432312433.44.0.95690592902.issue24056@psf.upfronthosting.co.za> Berker Peksag added the comment: I'm not the ideal candidate to review the second patch since I'm not familiar with the best practices of C :) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 18:34:54 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 22 May 2015 16:34:54 +0000 Subject: [issue24204] string.strip() documentation is misleading In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za> Message-ID: <1432312494.36.0.540970719363.issue24204@psf.upfronthosting.co.za> Terry J. Reedy added the comment: With 'leading end' and 'trailing end' replaced by 'left and 'right', the addition looks good to me. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 18:37:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 May 2015 16:37:16 +0000 Subject: [issue20035] Clean up Tcl library discovery in Tkinter on Windows In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za> Message-ID: <20150522163713.21246.58629@psf.io> Roundup Robot added the comment: New changeset 951318b651be by Zachary Ware in branch 'default': Issue #20035: Reimplement tkinter._fix module as a C function. https://hg.python.org/cpython/rev/951318b651be ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 18:39:24 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 22 May 2015 16:39:24 +0000 Subject: [issue20035] Clean up Tcl library discovery in Tkinter on Windows In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za> Message-ID: <1432312764.58.0.839332716074.issue20035@psf.upfronthosting.co.za> Zachary Ware added the comment: Committed, thanks for the reviews, Serhiy and Steve! ---------- assignee: -> zach.ware resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 18:40:05 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 22 May 2015 16:40:05 +0000 Subject: [issue24209] Allow IPv6 bind in http.server In-Reply-To: <1431784485.93.0.0140060801451.issue24209@psf.upfronthosting.co.za> Message-ID: <1432312805.29.0.900082130309.issue24209@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 20:01:12 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 22 May 2015 18:01:12 +0000 Subject: [issue24234] Should we define complex.__complex__ and bytes.__bytes__? In-Reply-To: <1431985055.48.0.760233282847.issue24234@psf.upfronthosting.co.za> Message-ID: <1432317672.61.0.139250100153.issue24234@psf.upfronthosting.co.za> Terry J. Reedy added the comment: To my understanding, the presence of int.__int__ and float.__float__ are implementation issues. I presume that float(ob) just calls ob.__float__ without slowing down for an isinstance(ob, float) check. Ditto for int(ob). The processing for complex(args) and bytes(args) are more complex and currently neither call an eponyous method. Would either be improved if it did? One difference between int and complex, for instance, that might account for the internal implementation difference is that the second argument of int can only be used with a string first argument, while the second argument of complex cannot be used with a string first argument, and must support multiplication by 1j. So int.__int__(self) does not allow a second parameter and can (and does) just return self. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 20:05:01 2015 From: report at bugs.python.org (Jim Jewett) Date: Fri, 22 May 2015 18:05:01 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432317901.82.0.389291809448.issue16991@psf.upfronthosting.co.za> Jim Jewett added the comment: Why does generated file Include/opcode.h show up as changed? It looks like pure whitespace, but I wonder if a similar whitespace change might be making something a space too long somewhere. ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 20:37:42 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 22 May 2015 18:37:42 +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: <1432319862.36.0.665982035958.issue24266@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 3.2 and 3.3 only get security fixes. I condensed the title to be visible in display boxes. It would help if you signed the PSF Contributor Agreement https://www.python.org/psf/contrib/ https://www.python.org/psf/contrib/contrib-form/ and contributed a usable patch for test_readline under that agreement. ---------- nosy: +terry.reedy, twouters stage: -> test needed title: raw_input function (with readline): Ctrl+C (during search mode but not only) leaves readline in broken state -> raw_input + readline: Ctrl+C during search breaks readline versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 20:39:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 May 2015 18:39:12 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1432319952.32.0.94590958647.issue24056@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I like the look of the repr Terry proposes better. For generator objects the repr is either "" or "". "" and "" would be consistent with this. It also shows the relation and the difference between the generator function and the generator object. Yet one argument is that both terms "generator object" and "generator function" are searchable in the documentation. There are other precedences with exposing flags at the start of the repr. "" and "", "" and "". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 20:44:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 May 2015 18:44:26 +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: <1432320266.67.0.587907413376.issue24266@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This behavior annoyed me long time, but I had no idea how to fix this. ---------- nosy: +pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 21:12:38 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 22 May 2015 19:12:38 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1432321958.59.0.20396444.issue24230@psf.upfronthosting.co.za> Gregory P. Smith added the comment: updated, thanks for the great reviews. ---------- Added file: http://bugs.python.org/file39469/issue24230-gps03.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 21:42:13 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 22 May 2015 19:42:13 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1432323733.39.0.839480431919.issue20438@psf.upfronthosting.co.za> Berker Peksag added the comment: Just a minor comment on the patch: + warnings.warn("inspect.getargspec() is deprecated, " + "use inspect.signature() instead", DeprecationWarning) Can you also add "stacklevel=2"? ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 22:06:07 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 22 May 2015 20:06:07 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432325167.69.0.126770389976.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Include/opcode.h shouldn't be in the change (and won't be when committed). I'm guessing it being there is related to one of the recent merges I did from default into the feature branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 22:09:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 May 2015 20:09:59 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <20150522200954.96192.61155@psf.io> Roundup Robot added the comment: New changeset 666e5b554f32 by Yury Selivanov in branch 'default': Issue 20438: Adjust stacklevel of inspect.getargspec() warning. https://hg.python.org/cpython/rev/666e5b554f32 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 22:28:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 May 2015 20:28:16 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <20150522202813.17949.1591@psf.io> Roundup Robot added the comment: New changeset 621e98bfc74b by Yury Selivanov in branch 'default': Issue 20438: Add a note about deprecating old inspect APIs to whatsnew. https://hg.python.org/cpython/rev/621e98bfc74b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 22:28:39 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 22 May 2015 20:28:39 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1432326519.89.0.0306188096526.issue20438@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks Berker! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 22 22:30:40 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 22 May 2015 20:30:40 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1432326640.15.0.3623147319.issue20438@psf.upfronthosting.co.za> Yury Selivanov added the comment: I'm copying/pasting my latest commit message on this issue here: """Add a note about deprecating old inspect APIs to whatsnew. Also, deprecate formatargspec, formatargvalues, and getargvalues functions. Since we are deprecating 'getfullargspec' function in 3.5 (documentation only, no DeprecationWarning), it makes sense to also deprecate functions designed to be directly used with it. In 3.6 we will remove 'getargsspec' function (was deprecated since Python 3.0), and start raising DeprecationWarnings in other 'getarg*' family of functions. We can remove them in 3.7 or later. Also, it is worth noting, that Signature API does not provide 100% of functionality that deprecated APIs have. It is important to do a soft deprecation of outdated APIs in 3.5 to gather users feedback, and improve Signature object.""" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 00:00:49 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 May 2015 22:00:49 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <1432332049.45.0.358258447041.issue23509@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry, I don't want to any of these changes (though it is a close call on a couple of them). Before the particulars, here are some high-level thoughts (not definitive). I would like to confine the optimizations and complexities to the more important parts of the API (actually counting as opposed to counter-to-counter operations). Also, I don't want to preclude some of the future possibilities under consideration (for example, I am leaning toward guaranteeing the order of updates so that the OrderedCounter recipe has guaranteed behavior). Also, I'm considering removing the existing self.get(elem, 0) in update() and substract() so that subclassers can usefully override/extend the __missing__ method to return other types (like decimals, fractions, etc) or have other behaviors like logging missing entries, etc. And the self.get optimization doesn't seem to perform well under PyPy in contrast to an inherited __getitem__. The current code choices were biased towards simplicity, space-over-speed, and keeping a predictable operation order where possible. Particulars: 1) get() bound method optimization: This is a close call. We already use this in update() and subtract() though I'm thinking of removing those two cases. Switching from c[k] to c.get(k, 0) is a semantic change that affects subclasses that define, __getitem__(), get(), or __missing__(). Speedwise, c.get() is faster than a fallback to __missing__() for missing keys; conversely, the inherited __getitem__() is faster than c.get(k, 0) when the keys are present. There is some room for debate about which is the common case (it really depends on what your application is) and I would prefer at this point not to shift assumptions about is more common. Clarity-wise: The square brackets are clearer than the boundmethod trick which I would like to use only where it really matters. 2) The current _keep_positive() is shorter, clearer, maintains order for the OrderedCounter use case, and is more space-efficient (never using more space than the original counter and intentionally choosing to remove elements rather than building a new one from scratch). This is how it was done in setobject.c for the same reasons. 3) Other than brevity, I don't see any advantage to __add__ and __or__ being defined via inplace operations. That is a semantic change that can affect subclassers, violating the open-closed-principle (I want people to be able to override/extend the in-place methods without unintentionally breaking add/or methods). Also, the current approach has a space saving bias (not storing negative counts in the first place rather than using a follow-on call to _keep_positive pass to eliminate the negatives after they have been stored). 4) The code expansion for __pos__ and __neg__ grows the code and is less clear (IMO). The change for __pos__ scrambles the order, interfering with the OrderedCounter example. Also, I want the meaning of +c to be the same as c plus an empty counter (at least, that is how I think of the operation). FWIW, the unary plus operation was intended to be a trigger for _keep_positive. It was modeled after the unary plus in Decimal which serves the purpose of triggering rounding. I'm sure there is room for argument about any one of the points above, some are just judgment calls. I'm closing this because the OP's original concern about wanting an in-place operation was already solved and because the proposed optimizations slightly change semantics, aren't really the important part of the API, the snarl the code a bit, and they interfere with some future directions I want keep open. Also, I've already spent several hours to reviewing this patch and need to return attention to other matters. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 00:03:14 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 May 2015 22:03:14 +0000 Subject: [issue24204] string.strip() documentation is misleading In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za> Message-ID: <1432332194.86.0.178369623942.issue24204@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This patch looks reasonable. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 00:08:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 May 2015 22:08:59 +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: <20150522220856.21260.14208@psf.io> Roundup Robot added the comment: New changeset 254b8e68959e by Steve Dower in branch 'default': Issue 24244: Prevents termination when an invalid format string is encountered on Windows. https://hg.python.org/cpython/rev/254b8e68959e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 00:16:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 May 2015 22:16:52 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <20150522221649.45367.20869@psf.io> Roundup Robot added the comment: New changeset 620a247b4960 by Steve Dower in branch 'default': Issue #23955: Add pyvenv.cfg option to suppress registry/environment lookup for generating sys.path. https://hg.python.org/cpython/rev/620a247b4960 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 00:18:25 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 22 May 2015 22:18:25 +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: <1432333105.51.0.769314483044.issue24244@psf.upfronthosting.co.za> Steve Dower added the comment: That handles Python 3.5 and future versions, even if the supported formats change. Is there something that needs fixing in 3.4? I don't get a crash, just the ValueError... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 00:21:14 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 22 May 2015 22:21:14 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1432333274.34.0.350606440483.issue23955@psf.upfronthosting.co.za> Steve Dower added the comment: The support is in and the option remains named "applocal". Hopefully this (and the ZIP file version, which will include the preconfigured pyvenv.cfg) will help with app distributions, though I'm still open to make changes if it doesn't. ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 00:22:18 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 22 May 2015 22:22:18 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <1432333338.0.0.0555230358103.issue23970@psf.upfronthosting.co.za> Steve Dower added the comment: We don't strictly need this for beta 1, but I'd like to get it in. Final call for feedback (I'll probably hold off checking in until tomorrow morning, ~18 hours from now) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 00:34:00 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 May 2015 22:34:00 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1432334040.88.0.275910714166.issue24056@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > It's mostly pedagogical - similar to "normal functions" > vs "generator functions", I see a need for this but object to calling it a "generator" rather than a "function that makes a generator" or "generator creating function" or somesuch. There is a huge semantic difference between the two. Another thought this that I'm not sure that a __repr__ should try usurp something that is the primary responsibility of a docstring or function annotation here. Whether a function call runs code and returns a value or whether it returns a generator is fundamental to what the function does. The usual job of the __repr__ is to tell what the object is. The usual job of a docstring or type annotation to the describe what is returned. > Marking closure functions as such is a bit more subtle. > However, there ia a real point that closure functions > have a hidden input. I don't see a need for this and think it make cause more confusion than help. I try to teach that callables are all conceptually the same thing (something that has a __call__ method). It matters very little whether a callable is implemented as a closure or using a class with a __call__ method. So, put me down for -1 on this one. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 00:55:30 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 May 2015 22:55:30 +0000 Subject: [issue24199] Idle: remove idlelib.idlever.py and its use in About dialog In-Reply-To: <1431650285.59.0.600694723613.issue24199@psf.upfronthosting.co.za> Message-ID: <20150522225526.26096.87691@psf.io> Roundup Robot added the comment: New changeset 117af4bc0513 by Benjamin Peterson in branch '2.7': make idlever.py self-updating (closes #24199) https://hg.python.org/cpython/rev/117af4bc0513 ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 01:13:35 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 22 May 2015 23:13:35 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432336415.68.0.917954342366.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Just to narrow things down a bit further, the failure happens specifically under ConfigParserTestCaseNoValue: PYTHONHASHSEED=7 ./python -m unittest test.test_configparser.ConfigParserTestCaseNoValue.test_basic -v ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 01:15:10 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 22 May 2015 23:15:10 +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: <1432336510.62.0.477361420938.issue24266@psf.upfronthosting.co.za> Martin Panter added the comment: Also applies to the interactive interpreter mode. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 01:18:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 May 2015 23:18:32 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <20150522231830.16699.9000@psf.io> Roundup Robot added the comment: New changeset 870899ce71f4 by Gregory P. Smith in branch 'default': Issue 24230: The tempfile module now accepts bytes for prefix, suffix and dir https://hg.python.org/cpython/rev/870899ce71f4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 01:21:09 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 22 May 2015 23:21:09 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1432336869.44.0.0543552407197.issue24230@psf.upfronthosting.co.za> Gregory P. Smith added the comment: that should take care of it. if you see any other issues with this post commit, either raise them here or fix them directly. the reviews were helpful. ---------- resolution: -> fixed stage: patch review -> commit review status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 01:29:51 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 May 2015 23:29:51 +0000 Subject: [issue24219] Repeated integer in Lexical analysis/Integer literals section In-Reply-To: <1431886251.68.0.470371931129.issue24219@psf.upfronthosting.co.za> Message-ID: <1432337391.9.0.584655087504.issue24219@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 01:38:24 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 May 2015 23:38:24 +0000 Subject: [issue24219] Repeated integer in Lexical analysis/Integer literals section In-Reply-To: <1431886251.68.0.470371931129.issue24219@psf.upfronthosting.co.za> Message-ID: <20150522233821.45367.68685@psf.io> Roundup Robot added the comment: New changeset 645a03e93008 by Raymond Hettinger in branch '3.4': Issue #24219: Remove duplicate literal in docs. https://hg.python.org/cpython/rev/645a03e93008 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 01:38:31 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 22 May 2015 23:38:31 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432337911.26.0.269184613892.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: If I still the following at Lib/test/test_configparser.py:328: print(len(cf._proxies), len(list(cf._proxies)), list(cf._proxies)) print(len(cf._sections), len(list(cf._sections)), list(cf._sections)) I get unexpected results that are a clear indication of a problem: 9 8 ['DEFAULT', 'Foo Bar', 'Spacey Bar', 'Spacey Bar From The Beginning', 'Commented Bar', 'Long Line', 'Section\\with$weird%characters[\t', 'Internationalized Stuff'] 8 7 ['Foo Bar', 'Spacey Bar', 'Spacey Bar From The Beginning', 'Commented Bar', 'Long Line', 'Section\\with$weird%characters[\t', 'Internationalized Stuff'] Note that OrderedDict.__len__ is just dict.__len__, so the first number (the actual length) should be the same as the second number (the number of keys). Also note that OrderedDict.keys() is working (even if not exactly correct). Between the two observations, this implies that for this one test the keys are not only off, but at least one of the keys in the linked list is not in the underlying dict. I'm sure this is consequence of resizing. At the last point that we resize this is the state of the cf._proxies and cf._sections (ignore the trailing (?)): OrderedDict([('DEFAULT', ), ('Foo Bar', ), ('Spacey Bar', ), ('Spacey Bar From The Beginning', ), ('Commented Bar', ), ]) OrderedDict([('Foo Bar', OrderedDict([('foo', ['bar1'])])), ('Spacey Bar', OrderedDict([('foo', ['bar2'])])), ('Spacey Bar From The Beginning', OrderedDict([('foo', ['bar3']), ('baz', ['qwe'])])), ('Commented Bar', OrderedDict([('foo', ['bar4']), ('baz', ['qwe'])])), ('Long Line', OrderedDict([('foo', ['this line is much, much longer than my editor', 'likes it.'])])), ]) I haven't had time to analyze this but I'll be taking a closer look in later tonight. I'm not giving up on 3.5. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 01:40:53 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 May 2015 23:40:53 +0000 Subject: [issue24219] Repeated integer in Lexical analysis/Integer literals section In-Reply-To: <1431886251.68.0.470371931129.issue24219@psf.upfronthosting.co.za> Message-ID: <1432338053.14.0.732741882997.issue24219@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 01:56:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 May 2015 23:56:41 +0000 Subject: [issue22189] collections.UserString missing some str methods In-Reply-To: <1407908952.77.0.872981126645.issue22189@psf.upfronthosting.co.za> Message-ID: <20150522235638.45371.65392@psf.io> Roundup Robot added the comment: New changeset c06b2480766d by Raymond Hettinger in branch 'default': Issue 22189: Add missing methods to UserString https://hg.python.org/cpython/rev/c06b2480766d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 01:57:22 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 May 2015 23:57:22 +0000 Subject: [issue22189] collections.UserString missing some str methods In-Reply-To: <1407908952.77.0.872981126645.issue22189@psf.upfronthosting.co.za> Message-ID: <1432339042.81.0.00900723780761.issue22189@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Joe. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 02:03:00 2015 From: report at bugs.python.org (Brian Quinlan) Date: Sat, 23 May 2015 00:03:00 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1432339380.44.0.970976675763.issue24195@psf.upfronthosting.co.za> Brian Quinlan added the comment: Ethan: I'm -0 so I'd happily go with the consensus. Does anyone have a strong opinion? Ram: What did you mean by "Possible issues"? Did you mean that to be an example using the executor.map() technique? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 02:22:10 2015 From: report at bugs.python.org (Matthias Klose) Date: Sat, 23 May 2015 00:22:10 +0000 Subject: [issue23969] please set a SOABI for MacOSX In-Reply-To: <1429125133.46.0.136772675069.issue23969@psf.upfronthosting.co.za> Message-ID: <1432340530.33.0.350394025502.issue23969@psf.upfronthosting.co.za> Matthias Klose added the comment: so what you could do is to define more than one SOABI. The code in Python/dynload_shlib.c reads: "." SOABI ".so", ".abi" PYTHON_ABI_STRING ".so", ".so", so it still recognizes .so names. If you want to recognize architecture specific sonames, then you would need something like "." "cpython-35m--darwin" ".so", "." "cpython-35m-darwin" ".so", ".abi" PYTHON_ABI_STRING ".so", ".so", that would prefer to load the most specific so. Unfortunately that would be also seen as the visible soname to build extensions, which is probably not something like you want. I still would prefer to use darwin instead of macosx, because that's the way config.sub/config.guess recognizes this platform. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 02:23:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 May 2015 00:23:48 +0000 Subject: [issue21448] Email Parser use 100% CPU In-Reply-To: <1399404013.42.0.0957567548326.issue21448@psf.upfronthosting.co.za> Message-ID: <20150523002337.45387.25470@psf.io> Roundup Robot added the comment: New changeset 830bcf4fb29b by Raymond Hettinger in branch 'default': Issue #21448: Improve performance of the email feedparser https://hg.python.org/cpython/rev/830bcf4fb29b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 02:24:13 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 May 2015 00:24:13 +0000 Subject: [issue21448] Email Parser use 100% CPU In-Reply-To: <1399404013.42.0.0957567548326.issue21448@psf.upfronthosting.co.za> Message-ID: <1432340653.47.0.296478294792.issue21448@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 02:26:10 2015 From: report at bugs.python.org (Matthias Klose) Date: Sat, 23 May 2015 00:26:10 +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: <1432340770.53.0.926781231451.issue23968@psf.upfronthosting.co.za> Matthias Klose added the comment: ping? I would like to get this into 3.5. ---------- keywords: +needs review -patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 02:58:52 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 May 2015 00:58:52 +0000 Subject: [issue14132] Redirect is not working correctly in urllib2 In-Reply-To: <1330269331.97.0.613564747875.issue14132@psf.upfronthosting.co.za> Message-ID: <1432342732.98.0.74370467722.issue14132@psf.upfronthosting.co.za> Martin Panter added the comment: The proposed patch looks good to me. A test case would be nice though. Also I wonder why the ?malformed URL? logic needs to be in urllib.request. Surely it either belongs in urljoin(), or in the underlying http.client. That needs more thought, but either way the current patch is a definite improvement. ---------- nosy: +vadmium stage: -> test needed versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 03:20:59 2015 From: report at bugs.python.org (Augie Fackler) Date: Sat, 23 May 2015 01:20:59 +0000 Subject: [issue24230] tempfile.mkdtemp() doesn't work with bytes paths In-Reply-To: <1431968694.0.0.694998892664.issue24230@psf.upfronthosting.co.za> Message-ID: <1432344059.95.0.210340318309.issue24230@psf.upfronthosting.co.za> Augie Fackler added the comment: I just removed my hack that gave us unicode to hand to mkdtemp() and everything still passes with your new commit. Thanks much for the quick response! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 03:26:45 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 May 2015 01:26:45 +0000 Subject: [issue23712] Experiment: Assume that exact unicode hashes are perfect discriminators In-Reply-To: <1426795062.72.0.102774381262.issue23712@psf.upfronthosting.co.za> Message-ID: <1432344405.47.0.0248518852578.issue23712@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Closing this because it was never an active proposal, just more of a thought experiment that I didn't want to lose track of. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 03:38:36 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 May 2015 01:38:36 +0000 Subject: [issue12319] [http.client] HTTPConnection.request not support "chunked" Transfer-Encoding to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1432345116.01.0.136396027393.issue12319@psf.upfronthosting.co.za> Martin Panter added the comment: Okay perhaps a new issue at this stage isn?t the best idea, especially if you want both modules updated at the same time. With the urlopen() API, it currently has no explicit support for file objects. So you either have to make sure they get treated like any other iterable, or add in explicit support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 04:04:27 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 May 2015 02:04:27 +0000 Subject: [issue12849] Cannot override 'connection: close' in urllib2 headers In-Reply-To: <1314559168.55.0.630424901631.issue12849@psf.upfronthosting.co.za> Message-ID: <1432346667.74.0.649512366226.issue12849@psf.upfronthosting.co.za> Martin Panter added the comment: So far the only reasons that have been given to override this header (mine and the one in Issue 15943) seem to be to work around buggy servers. It is already documented that HTTP 1.1 and ?Connection: close? are used, so if this issue is only about working around buggy servers, the best thing might be to close this as being ?not a Python bug?. The user can always still use the low-level HTTP client, or make a custom urllib.request handler class (which is what I did). Shubhojeet: What was the reason you wanted to set a keep-alive header? If this is about proper keep-alive (a.k.a persistent) connection support in urllib.request, perhaps have a look at Issue 9740. ---------- resolution: -> not a bug status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 04:29:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 May 2015 02:29:35 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <20150523022932.27927.42462@psf.io> Roundup Robot added the comment: New changeset cabd7261ae80 by Raymond Hettinger in branch 'default': Issue #23086: Add start and stop arguments to the Sequence.index() mixin method. https://hg.python.org/cpython/rev/cabd7261ae80 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 04:31:23 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 May 2015 02:31:23 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <1432348283.21.0.623149309897.issue23086@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Devin, thanks for the patch. Serhiy, I added a performance note discussing the computational complexity. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 04:32:06 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 May 2015 02:32:06 +0000 Subject: [issue15535] Fix pickling efficiency of named tuples in 2.7.3 In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <1432348326.02.0.859883194448.issue15535@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > What is left to do with this issue? Nothing that I can see. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 05:53:05 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 May 2015 03:53:05 +0000 Subject: [issue24209] Allow IPv6 bind in http.server In-Reply-To: <1431784485.93.0.0140060801451.issue24209@psf.upfronthosting.co.za> Message-ID: <1432353185.84.0.458128967645.issue24209@psf.upfronthosting.co.za> Martin Panter added the comment: I am no IPv6 expert, but this looks like a reasonable first approximation. The ?http.server? module documentation should also be updated to say IPv6 addresses are supported on the command line, and I guess there should be a test case added. But maybe see Lib/smtpd.py line 657 for how this is done in a more general way for the SMTP server module (Issue 14758), using getaddrinfo(). There is also Issue 20215 proposing to do something equivalent in the lower level ?socketserver? module, which would probably make this change redundant. It would also be nice for it to bind to both IPv4 and IPv6 if possible, but that is apparently not easy to do cross platform; see Issue 3213. ---------- stage: -> test needed versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 06:01:34 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 May 2015 04:01:34 +0000 Subject: [issue20215] socketserver can not listen IPv6 address In-Reply-To: <1389319382.42.0.481013787618.issue20215@psf.upfronthosting.co.za> Message-ID: <1432353694.22.0.141735128294.issue20215@psf.upfronthosting.co.za> Martin Panter added the comment: I?m no IPv6 expert, but see Lib/smtpd.py:657 and Issue 14758 for how this sort of thing was done for the SMTP server using getaddrinfo(). I think it is similar to David?s suggestion. I also left a comment about the documentation. And it probably needs a test case as well. ---------- nosy: +vadmium title: Python2.7 socketserver can not listen IPv6 address -> socketserver can not listen IPv6 address _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 07:00:06 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 May 2015 05:00:06 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1432357206.68.0.237339273143.issue24056@psf.upfronthosting.co.za> Nick Coghlan added the comment: I don't think we should rush this one, especially as PEP 484 provides the possibility for tools (including educational tools) to infer the appropriate return types for generator and coroutine functions. Bumping the target version to 3.6 accordingly. ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 07:03:28 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 May 2015 05:03:28 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1432357408.03.0.22631375205.issue24195@psf.upfronthosting.co.za> Nick Coghlan added the comment: I vary between +0 and -0 for the addition of the concrete method. When I'm at +0, the main rationale is that we *don't* have the "Where do we stop?" risk here that itertools faces, as we're just replicating the synchronous builtins. When I'm at -0, the main rationale is that a recipe works with *any* version of Python that provides concurrent.futures (including any version of the PyPI backport), and is hence useful immediately, while a method would only work the version where we added it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 08:05:45 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 23 May 2015 06:05:45 +0000 Subject: [issue23969] please set a SOABI for MacOSX In-Reply-To: <1429125133.46.0.136772675069.issue23969@psf.upfronthosting.co.za> Message-ID: <1432361145.98.0.998862880615.issue23969@psf.upfronthosting.co.za> Ned Deily added the comment: "If you want to recognize architecture specific sonames" For OS X we don't have a need to recognize architecture specific sonames because we want to continue to defer to the operating system to make the decisions about which, if any, architecture binary to load from a single universal container ("fat") file. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 08:06:26 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 23 May 2015 06:06:26 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1432361186.66.0.305286481338.issue24195@psf.upfronthosting.co.za> Ethan Furman added the comment: It looks like we are pretty much neutral between the +1's and -1's. Antoine seems to be opposed on general principles against bloat, while I am for it on general principles of completeness. The recipe could still go in the docs for people to use on previous versions of Python. If I was a module maintainer, and the other maintainers were not opposed, I would add it. (So, Brian, care to have a co-maintainer? ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 08:40:02 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 May 2015 06:40:02 +0000 Subject: [issue24267] test_venv.EnsurePipTest.test_with_pip version conflict Message-ID: <1432363202.9.0.592751761498.issue24267@psf.upfronthosting.co.za> New submission from Martin Panter: Recently when running the test suite on the code from the default Mercuiral branch, I have been seeing following failure. This only started happening in the last week or two. $ ./python -bWall -m test -v test_venv [. . .] test_with_pip (test.test_venv.EnsurePipTest) ... FAIL ====================================================================== FAIL: test_with_pip (test.test_venv.EnsurePipTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/media/disk/home/proj/python/cpython/Lib/test/test_venv.py", line 390, in test_with_pip self.assertEqual(err, "") AssertionError: "You are using pip version 6.1.1, however[102 chars]d.\n" != '' - You are using pip version 6.1.1, however version 7.0.1 is available. - You should consider upgrading via the 'pip install --upgrade pip' command. ---------------------------------------------------------------------- Ran 13 tests in 13.388s FAILED (failures=1) ---------- components: Tests messages: 243889 nosy: vadmium priority: normal severity: normal status: open title: test_venv.EnsurePipTest.test_with_pip version conflict type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 08:49:49 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 23 May 2015 06:49:49 +0000 Subject: [issue24267] test_venv.EnsurePipTest.test_with_pip version conflict In-Reply-To: <1432363202.9.0.592751761498.issue24267@psf.upfronthosting.co.za> Message-ID: <1432363789.26.0.635534392308.issue24267@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +dstufft, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 08:53:18 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 May 2015 06:53:18 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1432363998.49.0.453159969561.issue24195@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I would like to tip the balance in favor of the -1. Antoine is right about this one. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 09:25:14 2015 From: report at bugs.python.org (Ram Rachum) Date: Sat, 23 May 2015 07:25:14 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1432365914.84.0.723328294564.issue24195@psf.upfronthosting.co.za> Ram Rachum added the comment: Raymond: Thank you. So the discussion is back on adding a recipe to the docs. Brian: When I said "possible issues", I followed that with a couple of issues with the example I uploaded (filter_example.py). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 09:25:43 2015 From: report at bugs.python.org (eryksun) Date: Sat, 23 May 2015 07:25:43 +0000 Subject: [issue2528] Change os.access to check ACLs under Windows In-Reply-To: <1207059558.9.0.891835325783.issue2528@psf.upfronthosting.co.za> Message-ID: <1432365943.75.0.0208142654146.issue2528@psf.upfronthosting.co.za> eryksun added the comment: In msg243815 you asked me to look over this patch. I hope this helps. For GetFileSecurity you need to also request LABEL_SECURITY_INFORMATION. To test this in Vista+, use a file in the root directory of the system drive. This will inherit a high integrity level w/ no write up, which denies write access to a medium integrity (non-elevated) process. If you don't include the label information, the check will erroneously claim a non-elevated token has write access. You can set a file's integrity level to high using `icacls filename /setintegritylevel High`. This prevents write up. You can prevent read up and execute up by using the Windows API directly, or with other administration tools such as chml. As a performance tweak you could get the file security with an initial buffer of 512 bytes. That should be big enough for most file security descriptors. I'd use PyMem_RawRealloc in a do loop (i.e. starting with pSD == NULL and cbSD == 512). It should set PyExc_MemoryError on failure. Regarding ImpersonateSelf, what if the thread is already impersonating? That's the token the kernel will actually use when checking access. Given that, I'd try OpenThreadToken, and only if it fails call ImpersonateSelf. Then RevertToSelf immediately after the 2nd OpenThreadToken call. Reverting doesn't have to be delayed until after the check. An alternative to ImpersonateSelf is to manually duplicate the process token as an impersonation token (i.e. OpenProcessToken; DuplicateToken). The benefit of this approach is that the duplicated token can be cached in a static variable. For the access check itself, use the FILE_GENERIC_* / FILE_ALL_ACCESS constants, which are the standard and specific rights for the corresponding GENERIC_* rights. These include the standard READ_CONTROL and SYNCHRONIZE rights that are required for accessing files. Also, there's no need to call MapGenericMask here, since you know that access_desired doesn't contain any generic rights. Finally, for backward compatibility this new implementation should default to using only the old file-attribute check. Chaining to the ACL-based check should require a keyword-only argument such as "use_acl". ---------- nosy: +eryksun versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 09:37:47 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 May 2015 07:37:47 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1432366667.62.0.62100087619.issue24195@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 09:53:44 2015 From: report at bugs.python.org (Petr Viktorin) Date: Sat, 23 May 2015 07:53:44 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization Message-ID: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> New submission from Petr Viktorin: Here is the implementation for the recently accepted PEP 489. Tested on Linux. ---------- files: pep0489.patches messages: 243893 nosy: encukou, eric.snow, ncoghlan priority: normal severity: normal status: open title: PEP 489 -- Multi-phase extension module initialization Added file: http://bugs.python.org/file39470/pep0489.patches _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 09:58:06 2015 From: report at bugs.python.org (Petr Viktorin) Date: Sat, 23 May 2015 07:58:06 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432367886.52.0.745365951696.issue24268@psf.upfronthosting.co.za> Petr Viktorin added the comment: And here are all changes in a single patch. ---------- keywords: +patch Added file: http://bugs.python.org/file39471/pep0489.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 10:03:43 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 May 2015 08:03:43 +0000 Subject: [issue24056] Better expose closure, generator & coroutine status of functions In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1432368223.39.0.4524901628.issue24056@psf.upfronthosting.co.za> Nick Coghlan added the comment: I've also come to agree with Raymond that the repr may not be the best place for this additional information, and have updated the issue title accordingly. For example, as one possible alternative, we might be able to put something in the inspect module (e.g. "inspect.callable_info()") that's a higher level alternative to "dis.code_info()". The information displayed could potentially include: - the object's repr - the str() of the callable's signature (presented with the name or qualname if it has one) - the names and current repr of any captured closure variables More controversially, it might include an inferred return type annotation when there's no explicit annotation to display (defaulting to "typing.Any", but potentially more explicit if it's possible to tell from the code object flags that calling it will return a Coroutine or Generator) ---------- title: Expose closure & generator status in function repr() -> Better expose closure, generator & coroutine status of functions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 10:17:59 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 May 2015 08:17:59 +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: <1432369079.92.0.707261857199.issue23968@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 from me. ---------- nosy: +larry, rkuska _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 10:22:53 2015 From: report at bugs.python.org (Tim Golden) Date: Sat, 23 May 2015 08:22:53 +0000 Subject: [issue2528] Change os.access to check ACLs under Windows In-Reply-To: <1432365943.75.0.0208142654146.issue2528@psf.upfronthosting.co.za> Message-ID: <556038D7.1070504@timgolden.me.uk> Tim Golden added the comment: Thanks for the very thorough review. This isn't going to make it into 3.5, but I'll rework it in the light of your comments and see if people are happy with it in the optional argument variation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 10:24:03 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 May 2015 08:24:03 +0000 Subject: [issue24267] test_venv.EnsurePipTest.test_with_pip version conflict In-Reply-To: <1432363202.9.0.592751761498.issue24267@psf.upfronthosting.co.za> Message-ID: <1432369443.02.0.741311528089.issue24267@psf.upfronthosting.co.za> Nick Coghlan added the comment: There's two issues here: 1. The bundled pip should be upgraded to the recently released 7.0 (I believe we can do that after beta 1, due to the different-from-normal guidelines set up in PEP 453) 2. Neither the tests nor ensurepip itself should be touching the network by default, so we need to change the way we implicitly invoke pip to ensure the "up to date" check is disabled (it will still get triggered the first time a user invokes pip normally) ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 10:28:44 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 May 2015 08:28:44 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432369724.56.0.0807162122235.issue24268@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'll get this merged tonight so we make the beta1 deadline, but I expect the initial docs to be fairly rudimentary and requiring further updates. ---------- assignee: -> ncoghlan versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 10:30:15 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 May 2015 08:30:15 +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: <1432369815.63.0.526637369665.issue24267@psf.upfronthosting.co.za> Martin Panter added the comment: Actually looks like I should have updated before I opened this bug. I just updated and I suspect revision 29b95625a07c (?Merge 3.4 into default, upgrading pip to 7.0.1?, a large binary change) fixed it for me. But I did wonder why removing -unetwork didn?t affect the result, so perhaps we can leave this bug open to address that aspect. Feel free to clarify if I got the title wrong. ---------- title: test_venv.EnsurePipTest.test_with_pip version conflict -> test_venv.EnsurePipTest.test_with_pip triggers version check over network _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 11:03:47 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 May 2015 09:03:47 +0000 Subject: [issue23377] HTTPResponse may drop buffer holding next response In-Reply-To: <1422881776.12.0.998068930599.issue23377@psf.upfronthosting.co.za> Message-ID: <1432371827.52.0.364856305158.issue23377@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the reviewing. Here is http-buffer.v3.patch: * Merged with current code * Better HTTPResponse(sock) compatibility suggested by Demian * New HTTPConnection.request(close=True) feature also suggested by Demian. This sends ?Connection: close? in the request, and arranges for the response to be detached from the HTTPConnection instance, making some hacks in urllib.request redundant. ---------- Added file: http://bugs.python.org/file39472/http-buffer.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 11:10:00 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 May 2015 09:10:00 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1432372200.41.0.50482221536.issue24254@psf.upfronthosting.co.za> Nick Coghlan added the comment: types.prepare_class() also needs to be updated to use OrderedDict() by default. ---------- dependencies: +Add OrderedDict written in C _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 11:17:00 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 May 2015 09:17:00 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432372620.37.0.509660031133.issue16991@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'd suggest also taking a look into whether or not the PEP 412 keysharing might be causing problems. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 11:46:17 2015 From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Hees?=) Date: Sat, 23 May 2015 09:46:17 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <1432374377.36.0.269010737779.issue23509@psf.upfronthosting.co.za> J?rn Hees added the comment: > I'm closing this because the OP's original concern about wanting an in-place operation was already solved Was it? Are you referring to http://bugs.python.org/issue13121 ? My main concern was that += is considerably slower than .update(), kind of catching me off-guard. As you closed this, i'd be very happy if you could maybe add a note to the docs https://docs.python.org/3/_sources/library/collections.txt that points this behavior out. Maybe by changing this: * The multiset methods are designed only for use cases with positive values. The inputs may be negative or zero, but only outputs with positive values are created. There are no type restrictions, but the value type needs to support addition, subtraction, and comparison. * The :meth:`elements` method requires integer counts. It ignores zero and negative counts. to this: * The multiset methods (``+``, ``-`` and ``+=``, ``-=``) are designed only for use cases with positive values. The inputs may be negative or zero, but only outputs with positive values are created. There are no type restrictions, but the value type needs to support addition, subtraction, and comparison. * Because of the necessary additional checks for positive values, a ``c += d`` can be considerably slower than a ``c.update(d)``. * The :meth:`elements` method requires integer counts. It ignores zero and negative counts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 12:02:16 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 May 2015 10:02:16 +0000 Subject: [issue23965] test_ssl failure on Fedora 22 In-Reply-To: <1429109042.15.0.0394513301498.issue23965@psf.upfronthosting.co.za> Message-ID: <1432375336.18.0.292902088419.issue23965@psf.upfronthosting.co.za> Nick Coghlan added the comment: Digging into the test_options failure suggests Christian is right (although I think it has more to do with https://fedoraproject.org/wiki/Changes/CryptoPolicy than it does with FIPS): >>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1) >>> bin(ctx.options) '0b10000011000000000000001111111111' >>> bin(ssl.OP_ALL | ssl.OP_NO_SSLv2) '0b10000001000000000000001111111111' >>> bin(ssl.OP_ALL | ssl.OP_NO_SSLv2 | ssl.OP_NO_SSLv3) '0b10000011000000000000001111111111' The tests' assumptions about the default SSL configuration are out of date, so the tests have started failing on F22. We should like check the default options to see if they turn off SSLv3 when test_ssl is imported, and use that as a check to skip affected tests (as well as to adjust what test_options checks for as the default state) ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 12:16:19 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 23 May 2015 10:16:19 +0000 Subject: [issue24260] TabError behavior doesn't match documentation In-Reply-To: <1432244751.77.0.187754601995.issue24260@psf.upfronthosting.co.za> Message-ID: <1432376179.95.0.711661844728.issue24260@psf.upfronthosting.co.za> Stefan Krah added the comment: I would go further and forbid tabs after spaces entirely. Tabs used for indentation with spaces following for formatting are okay (though unusual in Python). ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 12:26:04 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 23 May 2015 10:26:04 +0000 Subject: [issue24260] TabError behavior doesn't match documentation In-Reply-To: <1432244751.77.0.187754601995.issue24260@psf.upfronthosting.co.za> Message-ID: <1432376764.79.0.401896055258.issue24260@psf.upfronthosting.co.za> Mark Lawrence added the comment: >From https://www.python.org/dev/peps/pep-0008/ Tabs or Spaces? Spaces are the preferred indentation method. Tabs should be used solely to remain consistent with code that is already indented with tabs. Python 3 disallows mixing the use of tabs and spaces for indentation. Python 2 code indented with a mixture of tabs and spaces should be converted to using spaces exclusively. When invoking the Python 2 command line interpreter with the -t option, it issues warnings about code that illegally mixes tabs and spaces. When using -tt these warnings become errors. These options are highly recommended! ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 12:40:08 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 23 May 2015 10:40:08 +0000 Subject: [issue24260] TabError behavior doesn't match documentation In-Reply-To: <1432244751.77.0.187754601995.issue24260@psf.upfronthosting.co.za> Message-ID: <1432377608.36.0.831157142118.issue24260@psf.upfronthosting.co.za> Stefan Krah added the comment: Then pep-008 is wrong, too, since the implementation *does* allow Evgeny's example. The current implementation just checks if the same INDENT/DEDENT tokens are generated for tab widths 1 and 8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 13:23:23 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Sat, 23 May 2015 11:23:23 +0000 Subject: [issue24269] Few improvements to the collections documentation Message-ID: <1432380203.09.0.901272885626.issue24269@psf.upfronthosting.co.za> New submission from Dmitry Kazakov: collections.Counter: Formatted the code in the "See also" section. collections.deque.remove: "Removed the first occurrence of value." -> "Remove ..." collections.deque.index (a followup from issue23704): Changed [, end] to [, stop] in the signature, because the implementation and the docstring of deque.index use 'stop'. Also, adapted the brief explanation from the Common Sequence Operations table. https://docs.python.org/3/library/stdtypes.html#common-sequence-operations ---------- assignee: docs at python components: Documentation files: collections_doc.diff keywords: patch messages: 243909 nosy: docs at python, vlth priority: normal severity: normal status: open title: Few improvements to the collections documentation type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39473/collections_doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 13:45:09 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 May 2015 11:45:09 +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: <1432381509.81.0.491464402523.issue23237@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 14:29:59 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 May 2015 12:29:59 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432384199.64.0.722637184348.issue24268@psf.upfronthosting.co.za> Nick Coghlan added the comment: Attached patch is the one I'm looking to commit, but -R 3:3 shows significant reference leaks in test_importlib, and possible problems in other tests as well. I'm about to revert it to see if there were any pre-existing refleak issues before applying this. ---------- Added file: http://bugs.python.org/file39474/pep0489-multiphase-extension-module-import-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 15:08:38 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 May 2015 13:08:38 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432386518.22.0.150699442437.issue24268@psf.upfronthosting.co.za> Nick Coghlan added the comment: Initial implementation checked in at https://hg.python.org/cpython/rev/e729b946cc03 Larry, FYI regarding the refleak in test_importlib I just committed: as described in the commit message, I'm pretty sure it's a real refleak in the current PEP 489 implementation, it's just a beast to track down because there are a lot of moving parts when it comes to module cleanup, especially for extension modules. Aside from that, the tests all pass, so I hope you're OK with my checking it in its current state for beta 1, with the aim of fixing the bug for beta 2 (I would have asked first, but time zones intervened - I'm about to head to bed, and I expect you'll have closed 3.5 to new features by the time I get up) ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 15:12:02 2015 From: report at bugs.python.org (Donald Stufft) Date: Sat, 23 May 2015 13:12:02 +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: <1432386722.45.0.908137246195.issue24267@psf.upfronthosting.co.za> Donald Stufft added the comment: Yea, I already upgraded pip. I did forget that we'll want to add --disable-pip-version-check to the pip invocation inside of ensurepip. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 15:12:10 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 May 2015 13:12:10 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432386730.65.0.426048925702.issue24268@psf.upfronthosting.co.za> Nick Coghlan added the comment: Regarding the extraneous whitespace changes in modsupport.h, those are courtesy of running "make patchcheck" as part of preparing the commit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 15:18:03 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 May 2015 13:18:03 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation Message-ID: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> New submission from Nick Coghlan: Tracking issue for the PEP 485 math.isclose() implementation: https://www.python.org/dev/peps/pep-0485/ Chris's implementation review request to python-dev: https://mail.python.org/pipermail/python-dev/2015-May/140031.html Working repo: https://github.com/PythonCHB/close_pep ---------- messages: 243914 nosy: ncoghlan priority: normal severity: normal status: open title: PEP 485 (math.isclose) implementation versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 16:38:54 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 23 May 2015 14:38:54 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432391934.45.0.636086062006.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Good point, Nick. I'd checked that earlier but did not see any relationship. At this point it's worth checking again. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 16:49:40 2015 From: report at bugs.python.org (Petr Viktorin) Date: Sat, 23 May 2015 14:49:40 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432392580.12.0.268801943851.issue24268@psf.upfronthosting.co.za> Petr Viktorin added the comment: Fix some refleaks - one in PyModule_FromDefAndSpec2 - this is my fault - one in PyType_FromSpecWithBases - I guess this is the first time PEP-384 built-in types are GC'd - one in the new PEP 489 tests There's still one more in the new testing module, _testmultiphase. I'm working on it. ---------- Added file: http://bugs.python.org/file39475/refleak-fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 17:03:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 May 2015 15:03:59 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <20150523150357.27931.94867@psf.io> Roundup Robot added the comment: New changeset 7f2e6f236202 by Nick Coghlan in branch 'default': Issue #24268: Address some PEP 489 refleaks https://hg.python.org/cpython/rev/7f2e6f236202 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 17:07:45 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 May 2015 15:07: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: <1432393665.0.0.908701437653.issue24268@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks, that reduces the refleaks shown for "./python -m test -R3:3 test_importlib" from 102 to 50 for me. However, I suspect there may still be a leak in the machinery, as I'm still seeing the total number of objects growing when importing the array module and then dropping the references to it: $ ./python -X showrefcount Python 3.5.0a4+ (default:e729b946cc03+, May 24 2015, 00:58:18) [GCC 5.1.1 20150422 (Red Hat 5.1.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys [54384 refs, 15894 blocks] >>> import array; del array; del sys.modules['array'] [54654 refs, 15974 blocks] >>> import array; del array; del sys.modules['array'] [54695 refs, 15986 blocks] >>> import array; del array; del sys.modules['array'] [54736 refs, 15997 blocks] >>> import array; del array; del sys.modules['array'] [54777 refs, 16008 blocks] >>> import array; del array; del sys.modules['array'] [54818 refs, 16019 blocks] >>> import array; del array; del sys.modules['array'] [54859 refs, 16030 blocks] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 17:12:16 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 23 May 2015 15:12:16 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432393936.48.0.668880705778.issue24268@psf.upfronthosting.co.za> Nick Coghlan added the comment: Once we sort these out, any that impact Python 3.4 (like the PyType_FromSpecAndBases one) should be backported to the maintenance branch. I wouldn't assume the one you found in PyType_FromSpecAndBases is the only one, though - I believe the tests for this PEP are managing to exercise parts of the module cleanup machinery that it's never been practical to properly test in the past. And now I really am heading to bed :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 17:20:10 2015 From: report at bugs.python.org (Petr Viktorin) Date: Sat, 23 May 2015 15:20:10 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432394410.48.0.666390634825.issue24268@psf.upfronthosting.co.za> Petr Viktorin added the comment: The array module is good if you *really* drop references: $ ./python -X showrefcount Python 3.5.0a4+ (default, May 23 2015, 16:44:38) [GCC 4.9.2 20150212 (Red Hat 4.9.2-6)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys, gc [54618 refs, 15960 blocks] >>> import array; del array; del sys.modules['array']; gc.collect() 6 [54851 refs, 15973 blocks] >>> import array; del array; del sys.modules['array']; gc.collect() 6 [54851 refs, 15973 blocks] >>> import array; del array; del sys.modules['array']; gc.collect() 6 [54851 refs, 15973 blocks] There is a cycle between a each built-in function and its module. Modules aren't optimized for being unloaded. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 17:24:27 2015 From: report at bugs.python.org (Petr Viktorin) Date: Sat, 23 May 2015 15:24:27 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432394667.17.0.169724173559.issue24268@psf.upfronthosting.co.za> Petr Viktorin added the comment: FWIW, the remaining refleak occurs when unloading an extension module object. This is something that wasn't possible before PEP 489 -- extension modules were never deleted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 17:36:53 2015 From: report at bugs.python.org (Ram Rachum) Date: Sat, 23 May 2015 15:36:53 +0000 Subject: [issue24271] Python site randomly scrolls up when on mobile. Message-ID: <1432395413.21.0.942984421958.issue24271@psf.upfronthosting.co.za> New submission from Ram Rachum: I was trying to read this page: https://www.python.org/dev/peps/pep-0492/#acceptance On my mobile. (Nexus 5, chrome.) But when scrolling down the page, the browser sometimes scrolls up to the top of the page. This makes reading very annoying because I have to find the place I was reading at every time it does that. ---------- assignee: docs at python components: Documentation messages: 243922 nosy: cool-RR, docs at python priority: normal severity: normal status: open title: Python site randomly scrolls up when on mobile. type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 17:37:46 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 May 2015 15:37:46 +0000 Subject: [issue24269] Few improvements to the collections documentation In-Reply-To: <1432380203.09.0.901272885626.issue24269@psf.upfronthosting.co.za> Message-ID: <1432395466.11.0.784962281261.issue24269@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 17:43:01 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 23 May 2015 15:43:01 +0000 Subject: [issue24271] Python site randomly scrolls up when on mobile. In-Reply-To: <1432395413.21.0.942984421958.issue24271@psf.upfronthosting.co.za> Message-ID: <1432395781.77.0.121182493306.issue24271@psf.upfronthosting.co.za> Ned Deily added the comment: Problems with the python.org website are tracked at https://github.com/python/pythondotorg/issues. This is a duplicate of https://github.com/python/pythondotorg/issues/531. ---------- nosy: +ned.deily resolution: -> third party stage: -> resolved status: open -> closed type: behavior -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 17:48:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 May 2015 15:48:16 +0000 Subject: [issue22931] cookies with square brackets in value In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za> Message-ID: <20150523154813.27945.99601@psf.io> Roundup Robot added the comment: New changeset 710cdba13323 by Benjamin Peterson in branch '3.2': allow square brackets in cookie values (closes #22931) https://hg.python.org/cpython/rev/710cdba13323 New changeset c7b3a50a2f01 by Benjamin Peterson in branch '3.3': merge 3.2 (#22931) https://hg.python.org/cpython/rev/c7b3a50a2f01 New changeset a43f5515e3a2 by Benjamin Peterson in branch '3.4': merge 3.3 (#22931) https://hg.python.org/cpython/rev/a43f5515e3a2 New changeset c58f3e76dc6c by Benjamin Peterson in branch 'default': merge 3.4 (#22931) https://hg.python.org/cpython/rev/c58f3e76dc6c New changeset 2a7b0e145945 by Benjamin Peterson in branch '2.7': allow square brackets in cookie values (#22931) https://hg.python.org/cpython/rev/2a7b0e145945 ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 17:57:46 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 May 2015 15:57:46 +0000 Subject: [issue24269] Few improvements to the collections documentation In-Reply-To: <1432380203.09.0.901272885626.issue24269@psf.upfronthosting.co.za> Message-ID: <1432396666.7.0.416709703647.issue24269@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for the patch. I've applied all of it except for the expansion of code in the multiset example where I've keep the style of the itertools recipes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 17:58:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 May 2015 15:58:12 +0000 Subject: [issue24269] Few improvements to the collections documentation In-Reply-To: <1432380203.09.0.901272885626.issue24269@psf.upfronthosting.co.za> Message-ID: <20150523155809.17927.88223@psf.io> Roundup Robot added the comment: New changeset 4d92ce08de6a by Raymond Hettinger in branch 'default': Issue #24269: Minor doc fixups. https://hg.python.org/cpython/rev/4d92ce08de6a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 17:58:50 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 May 2015 15:58:50 +0000 Subject: [issue24269] Few improvements to the collections documentation In-Reply-To: <1432380203.09.0.901272885626.issue24269@psf.upfronthosting.co.za> Message-ID: <1432396730.53.0.300682951194.issue24269@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 18:00:06 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 May 2015 16:00:06 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <20150523160005.27949.55137@psf.io> Roundup Robot added the comment: New changeset a811f5561c99 by Steve Dower in branch 'default': Issue #24268: Fixes generation of init import name on Windows. https://hg.python.org/cpython/rev/a811f5561c99 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 18:01:14 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 23 May 2015 16:01:14 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432396874.22.0.0323558870986.issue24268@psf.upfronthosting.co.za> Steve Dower added the comment: For the sake of getting things running again, I went ahead and fixed the format string in dynload_win.c. Feel free to change it again if that isn't what was intended. ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 18:04:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 May 2015 16:04:49 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <20150523160446.70425.75760@psf.io> Roundup Robot added the comment: New changeset b2ee6206fa5e by Steve Dower in branch 'default': Issue #23970: Adds distutils._msvccompiler for new Visual Studio versions. https://hg.python.org/cpython/rev/b2ee6206fa5e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 18:05:32 2015 From: report at bugs.python.org (Carol Willing) Date: Sat, 23 May 2015 16:05:32 +0000 Subject: [issue24204] string.strip() documentation is misleading In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za> Message-ID: <1432397132.73.0.685591537668.issue24204@psf.upfronthosting.co.za> Carol Willing added the comment: Updated patch with Terry's suggested changes. Thanks Terry and Raymond for the review of the initial patch. ---------- Added file: http://bugs.python.org/file39476/iss24204b.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 18:05:55 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 23 May 2015 16:05:55 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <1432397155.17.0.170941339452.issue23970@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 Sat May 23 18:12:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 May 2015 16:12:04 +0000 Subject: [issue24204] string.strip() documentation is misleading In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za> Message-ID: <20150523161200.96200.95797@psf.io> Roundup Robot added the comment: New changeset 367e3923532f by Raymond Hettinger in branch 'default': Issue #24204: Elaborate of the str.strip() documentation. https://hg.python.org/cpython/rev/367e3923532f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 18:12:26 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 May 2015 16:12:26 +0000 Subject: [issue24204] string.strip() documentation is misleading In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za> Message-ID: <1432397546.97.0.177205230866.issue24204@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger resolution: -> fixed stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 18:12:53 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 May 2015 16:12:53 +0000 Subject: [issue24204] string.strip() documentation is misleading In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za> Message-ID: <1432397573.2.0.44356982648.issue24204@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 19:15:17 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 May 2015 17:15:17 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1432401317.2.0.666230202539.issue14373@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Serhiy, go ahead and apply your patch, lru_cache2.patch. I'll fix-up the make_key() code after the beta1 (like the pure python version, it needs to guarantee that hash is called no more than once per key). ---------- assignee: rhettinger -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 19:26:25 2015 From: report at bugs.python.org (Tom Tanner) Date: Sat, 23 May 2015 17:26:25 +0000 Subject: [issue21718] sqlite3 cursor.description seems to rely on incomplete statement parsing for detection In-Reply-To: <1402492269.75.0.610341668437.issue21718@psf.upfronthosting.co.za> Message-ID: <1432401985.76.0.738658093054.issue21718@psf.upfronthosting.co.za> Tom Tanner added the comment: is this going to be fixed in 2.7.10? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 19:27:18 2015 From: report at bugs.python.org (Tom Tanner) Date: Sat, 23 May 2015 17:27:18 +0000 Subject: [issue21114] wsgiref.simple_server doesn't handle multi-line headers correctly In-Reply-To: <1396285351.75.0.166007035179.issue21114@psf.upfronthosting.co.za> Message-ID: <1432402038.1.0.447798086296.issue21114@psf.upfronthosting.co.za> Tom Tanner added the comment: The patch is waiting for inclusion in 2.7.10 :/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 20:44:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 May 2015 18:44:35 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <1432406675.55.0.272780321774.issue23509@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The OrderedCounter recipe doesn't support well multiset operations, because the result type is hardcoded to Counter. The order is already scrambled. update() and substract() don't work well with overloaded __missing__(). Proposed implementations of __add__ and __or__ simplify the code. If you don't want that overloaded inplace operation affect non-inplace operations (I consider this rather as a benefit), Counter.__iadd__(result, other) can be used instead of result += other. Optimized __neg__ just contains inlined substraction (note that current implementation of __neg__ and __pos__ violate the open-closed-principle), with removed no-op code. My second step would be to add C implementation of _keep_positive(), because this function is used in a number of multiset methods. It could be more efficient and preserve the order. In any case thank you for spending your time Raymond. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 21:00:28 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 23 May 2015 19:00:28 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <1432407628.31.0.489263325806.issue23970@psf.upfronthosting.co.za> Benjamin Peterson added the comment: b2ee6206fa5e broke every non-Windows buildbot. http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/3229/steps/test/logs/stdio ---------- nosy: +benjamin.peterson resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 21:01:22 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 23 May 2015 19:01:22 +0000 Subject: [issue24209] Allow IPv6 bind in http.server In-Reply-To: <1431784485.93.0.0140060801451.issue24209@psf.upfronthosting.co.za> Message-ID: <1432407682.64.0.258414956754.issue24209@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 21:16:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 May 2015 19:16:13 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <20150523191610.17925.1054@psf.io> Roundup Robot added the comment: New changeset 32e6123f9f8c by Steve Dower in branch 'default': Issue #23970: Fixes bdist_wininst not working on non-Windows platform. https://hg.python.org/cpython/rev/32e6123f9f8c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 21:35:27 2015 From: report at bugs.python.org (Petr Viktorin) Date: Sat, 23 May 2015 19:35:27 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432409727.63.0.725428186991.issue24268@psf.upfronthosting.co.za> Petr Viktorin added the comment: Thank you, Steve. A similar problem is on other platforms as well. This patch should fix it; could someone look at it? ---------- Added file: http://bugs.python.org/file39477/fix-dynload-init-name.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 21:43:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 May 2015 19:43:16 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <20150523194313.17951.25696@psf.io> Roundup Robot added the comment: New changeset 57776eee74f2 by Serhiy Storchaka in branch 'default': Issue #14373: Added C implementation of functools.lru_cache(). Based on https://hg.python.org/cpython/rev/57776eee74f2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 21:48:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 May 2015 19:48:36 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1432410516.66.0.541338690556.issue14373@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Raymond. I tried to write an implementation with locking, but it would be too complicated (much more complex than all proposed before patches), because recursive locks are needed. In any case I think that GIL is enough here. Locking in Python implementation is needed for atomic modifying linked list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 22:17:48 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 23 May 2015 20:17:48 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432412268.0.0.182311015417.issue24268@psf.upfronthosting.co.za> Steve Dower added the comment: That patch looks good to me. Totally didn't think to look for copy-paste issues... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 22:20:10 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 23 May 2015 20:20:10 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432412410.77.0.649528894826.issue24268@psf.upfronthosting.co.za> Larry Hastings added the comment: If it makes sense, can you guys check it in soon, like in real-time here? I tag 3.5 beta 1 in about an hour, and since this is a "bug-fix" it's legitimate to go in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 22:27:20 2015 From: report at bugs.python.org (Paul Moore) Date: Sat, 23 May 2015 20:27:20 +0000 Subject: [issue2528] Change os.access to check ACLs under Windows In-Reply-To: <1207059558.9.0.891835325783.issue2528@psf.upfronthosting.co.za> Message-ID: <1432412840.82.0.618225865664.issue2528@psf.upfronthosting.co.za> Changes by Paul Moore : ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 23:01:18 2015 From: report at bugs.python.org (Petr Viktorin) Date: Sat, 23 May 2015 21:01:18 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432414878.25.0.485265801837.issue24268@psf.upfronthosting.co.za> Petr Viktorin added the comment: Steve, could you please merge it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 23:07:26 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 23 May 2015 21:07:26 +0000 Subject: [issue23973] PEP 484 implementation In-Reply-To: <1429209123.93.0.369207893318.issue23973@psf.upfronthosting.co.za> Message-ID: <1432415246.31.0.648997792533.issue23973@psf.upfronthosting.co.za> Guido van Rossum added the comment: This was committed (rev 3e96d7ca3f51). I'm keeping this open because there is more to do (see https://github.com/ambv/typehinting/labels/bug). ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 23:09:28 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 23 May 2015 21:09:28 +0000 Subject: [issue24272] PEP 484 docs Message-ID: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za> New submission from Guido van Rossum: Would be nice if there were more docs for the typing module (PEP 484). Looking for volunteers. (There's stuff in the PEP that can serve as a starting point.) Note: support for isinstance() and issubclass() will be withdrawn in beta 2. ---------- assignee: docs at python components: Documentation messages: 243945 nosy: docs at python, gvanrossum priority: normal severity: normal status: open title: PEP 484 docs versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 23:10:00 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 23 May 2015 21:10:00 +0000 Subject: [issue24272] PEP 484 docs In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za> Message-ID: <1432415400.25.0.883835053934.issue24272@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 23:10:40 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 23 May 2015 21:10:40 +0000 Subject: [issue23973] PEP 484 implementation In-Reply-To: <1429209123.93.0.369207893318.issue23973@psf.upfronthosting.co.za> Message-ID: <1432415440.77.0.421302100196.issue23973@psf.upfronthosting.co.za> Guido van Rossum added the comment: I've opened a separate bug (http://bugs.python.org/issue24272) for docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 23:14:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 May 2015 21:14:19 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <20150523211416.16283.6611@psf.io> Roundup Robot added the comment: New changeset 7b5f5f8b26a6 by Steve Dower in branch 'default': Issue #24268: Fix import naming when loading extension modules. Patch by Petr Viktorin. https://hg.python.org/cpython/rev/7b5f5f8b26a6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 23:14:48 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 23 May 2015 21:14:48 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432415688.82.0.479739991258.issue24268@psf.upfronthosting.co.za> Mark Lawrence added the comment: error C2079: 'PyModuleDef_Type' uses undefined struct '_typeobject' c:\cpython\include\moduleobject.h is occurring on both 32 and 64 bit release builds on Windows 8.1 VS2015. I don't know what is causing it but figured I'd better flag it up pronto, and as you guys are here... ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 23:27:35 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 23 May 2015 21:27:35 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432416455.39.0.30979292457.issue24268@psf.upfronthosting.co.za> Steve Dower added the comment: I think it's missing PyAPI_DATA, as it's probably supposed to be an external reference than a declaration. If it builds fine now, I'll commit that, but whoever made the change should confirm that's what it is supposed to be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 23:37:00 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 23 May 2015 21:37:00 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432417020.15.0.161618689701.issue24268@psf.upfronthosting.co.za> Steve Dower added the comment: It also required updating PC/python3.def to put the new functions into the stable API. This is the reason we should auto-gen that file (+Zach), to make sure that anything people can #include under the limited ABI can actually be used. Just double checking all the build configurations and then I'll push. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 23 23:44:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 May 2015 21:44:50 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <20150523214448.126956.20100@psf.io> Roundup Robot added the comment: New changeset af167a62e2a3 by Steve Dower in branch 'default': Issue #24268: Adds PyModuleDef_Init and PyModuleDef_Type to python3.def (stable ABI) https://hg.python.org/cpython/rev/af167a62e2a3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 00:31:03 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 May 2015 22:31:03 +0000 Subject: [issue21961] Add What's New for Idle. In-Reply-To: <1405108568.05.0.859499936838.issue21961@psf.upfronthosting.co.za> Message-ID: <1432420263.36.0.741954016749.issue21961@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I just added a generic entry to the 3.4 and 3.5 What's New docs pointing people to idlelib/NEWS.txt. + idlelib and IDLE +---------------- + +Since idlelib implements the IDLE shell and editor and is not intended for +import by other programs, it gets improvements with every release. See +:file:`Lib/idlelib/NEWS.txt` for a cumulative list of changes since 3.4.0, +as well as changes made in future 3.5.x releases. This file is also available +from the IDLE Help -> About Idle dialog. + ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 00:31:07 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 23 May 2015 22:31:07 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432420267.11.0.398712331554.issue24268@psf.upfronthosting.co.za> Mark Lawrence added the comment: FTR I've now built everything successfully. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 02:17:47 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 24 May 2015 00:17:47 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432420267.11.0.398712331554.issue24268@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Thanks for getting the Windows side sorted out folks, and my apologies for the breakage. The overlap between the current import system maintainers and Windows developers is unfortunately the null set :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 02:38:25 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 24 May 2015 00:38:25 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432427905.32.0.368771878839.issue24268@psf.upfronthosting.co.za> Steve Dower added the comment: Since you're up, any chance you can help diagnose these test failures: Traceback (most recent call last): File "D:\buildarea\3.x.bolen-windows8\build\lib\test\test_importlib\extension\test_loader.py", line 93, in setUp assert self.spec AssertionError >From http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x/builds/925/steps/test/logs/stdio It happens for 22 tests in test.test_importlib.extension.test_loader.Frozen_MultiPhaseExtensionModuleTests ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 02:39:52 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 24 May 2015 00:39:52 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432427992.61.0.754210936842.issue24268@psf.upfronthosting.co.za> Steve Dower added the comment: Actually, that probably means we're not building a new extension module on Windows, right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 02:52:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 May 2015 00:52:32 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <20150524005228.70417.21733@psf.io> Roundup Robot added the comment: New changeset 42ec976f627e by Steve Dower in branch 'default': Issue #24268: Adds PCBuild project to build _testmultiphase module. https://hg.python.org/cpython/rev/42ec976f627e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 03:01:39 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 24 May 2015 01:01:39 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432429299.86.0.97968273922.issue24268@psf.upfronthosting.co.za> Steve Dower added the comment: Confirmed that when we build the module needed by the test, the test works fine :) Unfortunately, I think it missed the branch for b1, so people who install and run the test suite will see failures there. I'll make sure it gets into the 3.5 branch once that opens up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 03:53:49 2015 From: report at bugs.python.org (Matthew Barnett) Date: Sun, 24 May 2015 01:53:49 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432432429.79.0.867941800626.issue16991@psf.upfronthosting.co.za> Matthew Barnett added the comment: In "odict_new", if "_odict_initialize" fails, will the dict pointed to by "od_inst_dict" be deallocated? In "odictiter_new", there's "Py_INCREF(od);". If "di->di_result == NULL" fails, "od" isn't DECREFed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 04:14:53 2015 From: report at bugs.python.org (Eric Snow) Date: Sun, 24 May 2015 02:14:53 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432433693.86.0.77602607772.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Good catch. I've fixed odictiter_new in the feature branch. However, I'm not sure there's anything to be fixed in odict_new. It follows the same pattern as dict_new (over in Objects/dictobject.c). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 04:17:36 2015 From: report at bugs.python.org (Eric Snow) Date: Sun, 24 May 2015 02:17:36 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432433856.77.0.19406027602.issue16991@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- hgrepos: +309 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 04:17:57 2015 From: report at bugs.python.org (Eric Snow) Date: Sun, 24 May 2015 02:17:57 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1432433877.66.0.342542480011.issue24254@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- hgrepos: +310 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 04:36:13 2015 From: report at bugs.python.org (Jacob) Date: Sun, 24 May 2015 02:36:13 +0000 Subject: [issue24273] _scproxy.so causes EXC_BAD_ACCESS (SIGSEGV) Message-ID: <1432434972.57.0.149064186697.issue24273@psf.upfronthosting.co.za> New submission from Jacob: This looks very related to: http://bugs.python.org/issue13829 I have very simple test code that looks like this: import requests r = requests.get('http://www.google.com') print('requests.get() succeeded') The above code works fine. However, when: requests.get('http://www.google.com') is run inside an rq Queue (redis queue) worker I see this problem. Any fixes or known workarounds for this? Process: Python [34628] Path: /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: 3.4.3 (3.4.3) Code Type: X86-64 (Native) Parent Process: Python [34626] Responsible: Terminal [333] User ID: 501 Date/Time: 2015-05-24 08:57:29.055 +0700 OS Version: Mac OS X 10.10.3 (14D136) Report Version: 11 Anonymous UUID: 341D1B65-8C01-92A4-0CB5-DC7470E594BF Sleep/Wake UUID: 5DCBEBD5-671C-48C9-8402-765FABE76C61 Time Awake Since Boot: 230000 seconds Time Since Wake: 4700 seconds Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000110 VM Regions Near 0x110: --> __TEXT 0000000100239000-000000010023b000 [ 8K] r-x/rwx SM=COW /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/Resources/Python.app/Contents/MacOS/Python Application Specific Information: *** multi-threaded process forked *** crashed on child side of fork pre-exec Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libdispatch.dylib 0x00007fff80f9616f _dispatch_async_f_slow + 395 1 com.apple.CoreFoundation 0x00007fff8c571541 _CFPrefsWithDaemonConnection + 305 2 com.apple.CoreFoundation 0x00007fff8c540ac6 __80-[CFPrefsSearchListSource generationCountFromListOfSources:count:allowFetching:]_block_invoke + 150 3 com.apple.CoreFoundation 0x00007fff8c5409d2 -[CFPrefsSearchListSource generationCountFromListOfSources:count:allowFetching:] + 258 4 com.apple.CoreFoundation 0x00007fff8c3fcea5 -[CFPrefsSearchListSource alreadylocked_copyDictionary] + 133 5 com.apple.CoreFoundation 0x00007fff8c3f7dba -[CFPrefsSearchListSource alreadylocked_copyValueForKey:] + 42 6 com.apple.CoreFoundation 0x00007fff8c57211c ___CFPreferencesCopyAppValueWithContainer_block_invoke + 60 7 com.apple.CoreFoundation 0x00007fff8c53f979 +[CFPrefsSearchListSource withSearchListForIdentifier:container:perform:] + 729 8 com.apple.CoreFoundation 0x00007fff8c572097 _CFPreferencesCopyAppValueWithContainer + 183 9 com.apple.SystemConfiguration 0x00007fff8c989dd4 SCDynamicStoreCopyProxiesWithOptions + 153 10 _scproxy.so 0x0000000100fea8f2 get_proxy_settings + 24 11 org.python.python 0x00000001002e0c87 PyEval_EvalFrameEx + 18047 12 org.python.python 0x00000001002e3e8d fast_function + 203 13 org.python.python 0x00000001002e0b2a PyEval_EvalFrameEx + 17698 14 org.python.python 0x00000001002e3e8d fast_function + 203 15 org.python.python 0x00000001002e0b2a PyEval_EvalFrameEx + 17698 16 org.python.python 0x00000001002e3e8d fast_function + 203 17 org.python.python 0x00000001002e0b2a PyEval_EvalFrameEx + 17698 18 org.python.python 0x00000001002e3e8d fast_function + 203 19 org.python.python 0x00000001002e0b2a PyEval_EvalFrameEx + 17698 20 org.python.python 0x00000001002e3e8d fast_function + 203 21 org.python.python 0x00000001002e0b2a PyEval_EvalFrameEx + 17698 22 org.python.python 0x00000001002dc459 PyEval_EvalCodeEx + 1593 23 org.python.python 0x000000010026b562 function_call + 372 24 org.python.python 0x000000010024b12e PyObject_Call + 103 25 org.python.python 0x00000001002e12d5 PyEval_EvalFrameEx + 19661 26 org.python.python 0x00000001002dc459 PyEval_EvalCodeEx + 1593 27 org.python.python 0x000000010026b562 function_call + 372 28 org.python.python 0x000000010024b12e PyObject_Call + 103 29 org.python.python 0x00000001002e12d5 PyEval_EvalFrameEx + 19661 30 org.python.python 0x00000001002dc459 PyEval_EvalCodeEx + 1593 31 org.python.python 0x00000001002e3f03 fast_function + 321 32 org.python.python 0x00000001002e0b2a PyEval_EvalFrameEx + 17698 33 org.python.python 0x00000001002dc459 PyEval_EvalCodeEx + 1593 34 org.python.python 0x000000010026b562 function_call + 372 35 org.python.python 0x000000010024b12e PyObject_Call + 103 36 org.python.python 0x00000001002e12d5 PyEval_EvalFrameEx + 19661 37 org.python.python 0x00000001002e3e8d fast_function + 203 38 org.python.python 0x00000001002e0b2a PyEval_EvalFrameEx + 17698 39 org.python.python 0x00000001002e3e8d fast_function + 203 40 org.python.python 0x00000001002e0b2a PyEval_EvalFrameEx + 17698 41 org.python.python 0x00000001002e3e8d fast_function + 203 42 org.python.python 0x00000001002e0b2a PyEval_EvalFrameEx + 17698 43 org.python.python 0x00000001002e3e8d fast_function + 203 44 org.python.python 0x00000001002e0b2a PyEval_EvalFrameEx + 17698 45 org.python.python 0x00000001002dc459 PyEval_EvalCodeEx + 1593 46 org.python.python 0x00000001002e3f03 fast_function + 321 47 org.python.python 0x00000001002e0b2a PyEval_EvalFrameEx + 17698 48 org.python.python 0x00000001002dc459 PyEval_EvalCodeEx + 1593 49 org.python.python 0x00000001002dbe1a PyEval_EvalCode + 63 50 org.python.python 0x00000001002fec3d run_mod + 58 51 org.python.python 0x00000001002feedc PyRun_FileExFlags + 178 52 org.python.python 0x00000001002fe6e6 PyRun_SimpleFileExFlags + 865 53 org.python.python 0x0000000100311856 Py_Main + 3130 54 org.python.python 0x000000010023ae27 0x100239000 + 7719 55 libdyld.dylib 0x00007fff830f35c9 start + 1 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000101c01080 rbx: 0x0000000000000001 rcx: 0x0000000000000000 rdx: 0x0000000000000100 rdi: 0x0000000101c00000 rsi: 0x0000000004000000 rbp: 0x00007fff5f9c43d0 rsp: 0x00007fff5f9c43a0 r8: 0x0000000101c01080 r9: 0x0000000101c00000 r10: 0x0000000000000001 r11: 0x0000000000000202 r12: 0x00007fff8501347a r13: 0x00007fe581f208c0 r14: 0x00007fff70d23bc0 r15: 0x0000000000001000 rip: 0x00007fff80f9616f rfl: 0x0000000000010206 cr2: 0x0000000000000110 Logical CPU: 3 Error Code: 0x00000006 Trap Number: 14 Binary Images: 0x100239000 - 0x10023afff +org.python.python (3.4.3 - 3.4.3) <23324E85-29B4-3292-8E7C-6DA1F9A7E6A6> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/Resources/Python.app/Contents/MacOS/Python 0x100241000 - 0x100393fff +org.python.python (3.4.3, [c] 2001-2015 Python Software Foundation. - 3.4.3) /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/Python 0x10071f000 - 0x100720fff +_heapq.so (0) <27F8105B-B721-37FB-8C85-F263A2CFA462> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_heapq.so 0x1007a4000 - 0x1007a6fff +time.so (0) /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/time.so 0x10090e000 - 0x100912fff +math.so (0) /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/math.so 0x100917000 - 0x100920fff +_datetime.so (0) <4D823640-2BA0-3583-A0E4-1E02F080B2B9> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_datetime.so 0x100968000 - 0x10096afff +select.so (0) <134D2656-0A42-3788-942D-76404857D11E> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/select.so 0x10096f000 - 0x100977ff7 +_socket.so (0) /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_socket.so 0x100981000 - 0x10098bfff +_ssl.so (0) <10210A6E-8ED2-372E-B0A0-3ABE05B67810> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_ssl.so 0x100995000 - 0x1009d2fff +libssl.1.0.0.dylib (0) /usr/local/opt/openssl/lib/libssl.1.0.0.dylib 0x1009ee000 - 0x100b5e47f +libcrypto.1.0.0.dylib (0) /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib 0x100c15000 - 0x100c18fff +_struct.so (0) <6B8C7ACB-72B8-3AF7-9E03-3A153BFC9934> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_struct.so 0x100c1f000 - 0x100c22fff +binascii.so (0) /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/binascii.so 0x100c25000 - 0x100c34fff +_ctypes.so (0) /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_ctypes.so 0x100c80000 - 0x100c81fff +_posixsubprocess.so (0) <7732BBB0-E68B-3977-B337-F03C53307F31> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_posixsubprocess.so 0x100d04000 - 0x100d04fff +_opcode.so (0) /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_opcode.so 0x100d87000 - 0x100d92fff +_pickle.so (0) <6AF728DA-6898-38B1-9FA6-F4A1864CE598> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_pickle.so 0x100d9c000 - 0x100d9ffff +_hashlib.so (0) /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_hashlib.so 0x100da3000 - 0x100da4ff7 +_random.so (0) /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_random.so 0x100e27000 - 0x100e2dfff +_elementtree.so (0) <456D6939-9F47-3D1F-B524-B3C9308C35C6> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_elementtree.so 0x100e33000 - 0x100e52ff7 +pyexpat.so (0) /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/pyexpat.so 0x100f1e000 - 0x100f1efff +_bisect.so (0) <95B6F1C8-C373-3910-8D09-A6BDEB1355C6> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_bisect.so 0x100fe1000 - 0x100fe2fff +grp.so (0) <79B1F535-F66D-3E27-9542-8040919218AB> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/grp.so 0x100fe5000 - 0x100fe6fff +_bz2.so (0) /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_bz2.so 0x100fe9000 - 0x100feafff +_scproxy.so (0) /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_scproxy.so 0x100fed000 - 0x1010a3ff7 +unicodedata.so (0) <8121F180-50ED-30D5-AC56-83A813404930> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/unicodedata.so 0x1010e8000 - 0x1010edfff +array.so (0) <81FD7ACD-202B-3E1E-AE01-789D12335231> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/array.so 0x101324000 - 0x10132bfff +_tkinter.so (0) <3E8A3E52-D076-3CDE-BD9A-15E740701EDA> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_tkinter.so 0x101331000 - 0x1013fefff Tcl (8.5.9 - 8.5.9) <7C2A7E71-4614-3716-B87F-00FCC6A58D8E> /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl 0x10141d000 - 0x101507fff Tk (8.5.9 - 8.5.9) /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk 0x1015d0000 - 0x1015d4fff +_json.so (0) <98CEC151-157F-3A5E-A7C8-6A583AF3DD46> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_json.so 0x1015d8000 - 0x1015dbfff +zlib.so (0) <0BF28DFE-298B-396F-9DC7-469AB661AF2D> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/zlib.so 0x1015e0000 - 0x1015e3fff +_lzma.so (0) <522FF411-322C-351B-B33E-C6341D5DA625> /usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload/_lzma.so 0x101e80000 - 0x101e9cff7 +liblzma.5.dylib (0) <8CD2A0DF-4B4E-3C7B-AF46-B8C07555596B> /usr/local/lib/liblzma.5.dylib 0x7fff6310f000 - 0x7fff63145837 dyld (353.2.1) <65DCCB06-339C-3E25-9702-600A28291D0E> /usr/lib/dyld 0x7fff80c69000 - 0x7fff80c85fff com.apple.GenerationalStorage (2.0 - 209.11) <9FF8DD11-25FB-3047-A5BF-9415339B3EEC> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage 0x7fff80c86000 - 0x7fff80ca0fff com.apple.AppleVPAFramework (1.4.3 - 1.4.3) /System/Library/PrivateFrameworks/AppleVPA.framework/Versions/A/AppleVPA 0x7fff80caa000 - 0x7fff80f79ff3 com.apple.CoreImage (10.3.4) /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage 0x7fff80f90000 - 0x7fff80fbaff7 libdispatch.dylib (442.1.4) <502CF32B-669B-3709-8862-08188225E4F0> /usr/lib/system/libdispatch.dylib 0x7fff81848000 - 0x7fff8184dfff com.apple.DiskArbitration (2.6 - 2.6) <0DFF4D9B-2AC3-3B82-B5C5-30F4EFBD2DB9> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x7fff8184e000 - 0x7fff81b81ff7 libmecabra.dylib (666.7) <0ED8AE5E-7A5B-34A6-A2EE-2B852E60E1E2> /usr/lib/libmecabra.dylib 0x7fff81d55000 - 0x7fff82086fff com.apple.Foundation (6.9 - 1153.20) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x7fff82087000 - 0x7fff8209dff7 libsystem_asl.dylib (267) /usr/lib/system/libsystem_asl.dylib 0x7fff82116000 - 0x7fff82185fff com.apple.SearchKit (1.4.0 - 1.4.0) <80883BD1-C9BA-3794-A20E-476F94DD89A9> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit 0x7fff82186000 - 0x7fff821a6fff com.apple.IconServices (47.1 - 47.1) /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices 0x7fff821a7000 - 0x7fff8230effb com.apple.audio.toolbox.AudioToolbox (1.12 - 1.12) <5678FC94-456A-3F5F-BA9A-10EB6E462997> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 0x7fff82555000 - 0x7fff82566ff7 libz.1.dylib (55) <88C7C7DE-04B8-316F-8B74-ACD9F3DE1AA1> /usr/lib/libz.1.dylib 0x7fff82567000 - 0x7fff82569fff libsystem_configuration.dylib (699.1.5) <20F3B077-179D-3CB0-A3C1-C8602D53B4DB> /usr/lib/system/libsystem_configuration.dylib 0x7fff82baf000 - 0x7fff82ca3fff libFontParser.dylib (134.2) <9F57B025-AB9C-31DD-9D54-2D7AB1298885> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib 0x7fff82caa000 - 0x7fff82caefff libcache.dylib (69) <45E9A2E7-99C4-36B2-BEE3-0C4E11614AD1> /usr/lib/system/libcache.dylib 0x7fff82cfc000 - 0x7fff82cfcfff com.apple.Accelerate (1.10 - Accelerate 1.10) <2C8AF258-4F11-3BEC-A826-22D7199B3975> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 0x7fff82cfd000 - 0x7fff82dbdff7 com.apple.backup.framework (1.6.4 - 1.6.4) /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup 0x7fff82dbe000 - 0x7fff82de4fff com.apple.ChunkingLibrary (2.1 - 163.6) <29D4CB95-42EF-34C6-8182-BDB6F7BB1E79> /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary 0x7fff82e6e000 - 0x7fff82e77ff7 libsystem_notify.dylib (133.1.1) <61147800-F320-3DAA-850C-BADF33855F29> /usr/lib/system/libsystem_notify.dylib 0x7fff82e78000 - 0x7fff82e78fff com.apple.ApplicationServices (48 - 48) <5BF7910B-C328-3BF8-BA4F-CE52B574CE01> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 0x7fff82eab000 - 0x7fff82ebdff7 com.apple.ImageCapture (9.0 - 9.0) <7FB65DD4-56B5-35C4-862C-7A2DED991D1F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x7fff82ec1000 - 0x7fff82ed2fff libsystem_coretls.dylib (35.20.2) <6084A531-2523-39F8-B030-811FA1A32FB5> /usr/lib/system/libsystem_coretls.dylib 0x7fff82f92000 - 0x7fff82fccffb com.apple.DebugSymbols (115 - 115) <6F03761D-7C3A-3C80-8031-AA1C1AD7C706> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols 0x7fff82fd6000 - 0x7fff8303dff7 com.apple.framework.CoreWiFi (3.0 - 300.4) <19269C1D-EB29-384A-83F3-7DDDEB7D9DAD> /System/Library/PrivateFrameworks/CoreWiFi.framework/Versions/A/CoreWiFi 0x7fff8303e000 - 0x7fff8303efff com.apple.CoreServices (62 - 62) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x7fff8303f000 - 0x7fff83040ff7 libsystem_blocks.dylib (65) <9615D10A-FCA7-3BE4-AA1A-1B195DACE1A1> /usr/lib/system/libsystem_blocks.dylib 0x7fff830f0000 - 0x7fff830f3ff7 libdyld.dylib (353.2.1) <9EACCA38-291D-38CC-811F-7E9D1451E2D3> /usr/lib/system/libdyld.dylib 0x7fff83655000 - 0x7fff83661ff7 com.apple.OpenDirectory (10.10 - 187) <1E07769D-68DE-3BF2-8E9E-A1E98BF70D1B> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory 0x7fff8374a000 - 0x7fff8374efff libpam.2.dylib (20) /usr/lib/libpam.2.dylib 0x7fff83767000 - 0x7fff837fcff7 com.apple.ColorSync (4.9.0 - 4.9.0) <9150C2B7-2E6E-3509-96EA-7B3F959F049E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync 0x7fff83822000 - 0x7fff83822ff7 libunc.dylib (29) <5676F7EA-C1DF-329F-B006-D2C3022B7D70> /usr/lib/system/libunc.dylib 0x7fff83823000 - 0x7fff8382bffb libcopyfile.dylib (118.1.2) <0C68D3A6-ACDD-3EF3-991A-CC82C32AB836> /usr/lib/system/libcopyfile.dylib 0x7fff8389c000 - 0x7fff8390affb com.apple.Heimdal (4.0 - 2.0) <7697A837-98B8-3BDB-A7D2-8ED4C9ABC510> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal 0x7fff839fc000 - 0x7fff83a25ffb libxslt.1.dylib (13) /usr/lib/libxslt.1.dylib 0x7fff83acb000 - 0x7fff83acffff com.apple.CommonPanels (1.2.6 - 96) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x7fff83ad0000 - 0x7fff83ad8fff libsystem_platform.dylib (63) <64E34079-D712-3D66-9CE2-418624A5C040> /usr/lib/system/libsystem_platform.dylib 0x7fff83ad9000 - 0x7fff83b1fff7 libauto.dylib (186) /usr/lib/libauto.dylib 0x7fff83b20000 - 0x7fff83b25ff7 libunwind.dylib (35.3) /usr/lib/system/libunwind.dylib 0x7fff83b31000 - 0x7fff83b32ffb libremovefile.dylib (35) <3485B5F4-6CE8-3C62-8DFD-8736ED6E8531> /usr/lib/system/libremovefile.dylib 0x7fff83b70000 - 0x7fff83c0efff com.apple.Metadata (10.7.0 - 917.35) <8CBD1D32-4F4B-3F9A-AC65-76F2B5376FBF> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata 0x7fff83dd9000 - 0x7fff84043ff7 com.apple.security (7.0 - 57031.20.26) <6568520A-587D-3167-BB79-60CE6FEADC64> /System/Library/Frameworks/Security.framework/Versions/A/Security 0x7fff8406d000 - 0x7fff840f6ff7 com.apple.CoreSymbolication (3.1 - 57020.1) <85707039-0C8A-3409-B0B5-153431CC1841> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication 0x7fff840f7000 - 0x7fff8417bfff com.apple.PerformanceAnalysis (1.0 - 1) <599AED3E-B689-3C40-8B91-93AD36C97658> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis 0x7fff8417c000 - 0x7fff84cfdff7 com.apple.AppKit (6.9 - 1347.57) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x7fff84cfe000 - 0x7fff84e8cfff libBLAS.dylib (1128) <497912C1-A98E-3281-BED7-E9C751552F61> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 0x7fff84e8d000 - 0x7fff84ef4ffb com.apple.datadetectorscore (6.0 - 396.1.1) <9B0B3198-DDBE-36C0-8BA9-3EC89C725282> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore 0x7fff84fd8000 - 0x7fff84fddffb libheimdal-asn1.dylib (398.10.1) /usr/lib/libheimdal-asn1.dylib 0x7fff8500e000 - 0x7fff85036fff libxpc.dylib (559.20.9) /usr/lib/system/libxpc.dylib 0x7fff850e4000 - 0x7fff850f1ff7 com.apple.SpeechRecognitionCore (2.1.2 - 2.1.2) <551322E2-C1E4-3378-A218-F362985E3E3C> /System/Library/PrivateFrameworks/SpeechRecognitionCore.framework/Versions/A/SpeechRecognitionCore 0x7fff85263000 - 0x7fff85264ff3 libSystem.B.dylib (1213) /usr/lib/libSystem.B.dylib 0x7fff85265000 - 0x7fff85aa1fe3 com.apple.CoreGraphics (1.600.0 - 779.11) /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x7fff85b23000 - 0x7fff85bb7fff com.apple.ink.framework (10.9 - 213) <8E029630-1530-3734-A446-13353F0E7AC5> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink 0x7fff86222000 - 0x7fff86229ff7 libcompiler_rt.dylib (35) /usr/lib/system/libcompiler_rt.dylib 0x7fff8622a000 - 0x7fff8626bfff libGLU.dylib (11.1.2) <4C54F0D1-2ADC-38A0-92D1-F479E9B99355> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib 0x7fff8626c000 - 0x7fff86288ff7 libsystem_malloc.dylib (53.1.1) <19BCC257-5717-3502-A71F-95D65AFA861B> /usr/lib/system/libsystem_malloc.dylib 0x7fff863ce000 - 0x7fff863cefff com.apple.Cocoa (6.8 - 21) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 0x7fff863cf000 - 0x7fff863ecfff libsystem_kernel.dylib (2782.20.48) /usr/lib/system/libsystem_kernel.dylib 0x7fff863ed000 - 0x7fff86463fe7 libcorecrypto.dylib (233.1.2) /usr/lib/system/libcorecrypto.dylib 0x7fff86464000 - 0x7fff86466fff libquarantine.dylib (76.20.1) <7AF90041-2768-378A-925A-D83161863642> /usr/lib/system/libquarantine.dylib 0x7fff8672d000 - 0x7fff8673efff libcmph.dylib (1) <46EC3997-DB5E-38AE-BBBB-A035A54AD3C0> /usr/lib/libcmph.dylib 0x7fff867cb000 - 0x7fff8697bff3 com.apple.QuartzCore (1.10 - 361.18) /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore 0x7fff869fa000 - 0x7fff86a02fff libsystem_dnssd.dylib (561.1.1) <62B70ECA-E40D-3C63-896E-7F00EC386DDB> /usr/lib/system/libsystem_dnssd.dylib 0x7fff86a03000 - 0x7fff86a05fff libsystem_sandbox.dylib (358.20.5) <4CF77128-6BE0-3958-B646-707FA9CE61B2> /usr/lib/system/libsystem_sandbox.dylib 0x7fff86c0f000 - 0x7fff86c17ff3 com.apple.CoreServices.FSEvents (1210.20.1 - 1210.20.1) <84F79D3E-7B5E-3C93-8479-35794A3F125E> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents 0x7fff871a8000 - 0x7fff871a8fff com.apple.audio.units.AudioUnit (1.12 - 1.12) /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit 0x7fff871d8000 - 0x7fff87237fff com.apple.AE (681.2 - 681.2) <181B3B06-2DC6-3E4D-B44A-2551C5E9CF6F> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE 0x7fff87238000 - 0x7fff87645ff7 libLAPACK.dylib (1128) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 0x7fff87646000 - 0x7fff87647fff liblangid.dylib (117) /usr/lib/liblangid.dylib 0x7fff8831a000 - 0x7fff88324ff7 com.apple.NetAuth (5.2 - 5.2) <2BBD749A-8E18-35B8-8E48-A90347C1CCA7> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth 0x7fff8844a000 - 0x7fff88464ff7 libextension.dylib (55.2) <3BB019CA-199A-36AC-AA22-14B562138545> /usr/lib/libextension.dylib 0x7fff88768000 - 0x7fff887a0fff com.apple.RemoteViewServices (2.0 - 99) /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices 0x7fff88ea5000 - 0x7fff88f31ff7 libsystem_c.dylib (1044.10.1) <86FBED7A-F2C8-3591-AD6F-486DD57E6B6A> /usr/lib/system/libsystem_c.dylib 0x7fff88fc1000 - 0x7fff892c6ff3 com.apple.HIToolbox (2.1.1 - 758.7) <6711FAA9-904A-3B49-9665-FC8D13B93C42> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x7fff892c7000 - 0x7fff894acff7 libicucore.A.dylib (531.48) <3CD34752-B1F9-31D2-865D-B5B0F0BE3111> /usr/lib/libicucore.A.dylib 0x7fff894ad000 - 0x7fff89794ffb com.apple.CoreServices.CarbonCore (1108.6 - 1108.6) <8953580E-7857-33B2-AA64-98296830D3A8> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x7fff89795000 - 0x7fff898aeffb com.apple.CoreText (352.0 - 454.6) /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText 0x7fff898af000 - 0x7fff898c6ff7 libLinearAlgebra.dylib (1128) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib 0x7fff898c7000 - 0x7fff898e1ff7 liblzma.5.dylib (7) <1D03E875-A7C0-3028-814C-3C27F7B7C079> /usr/lib/liblzma.5.dylib 0x7fff89a28000 - 0x7fff89a58fff com.apple.GSS (4.0 - 2.0) /System/Library/Frameworks/GSS.framework/Versions/A/GSS 0x7fff89a59000 - 0x7fff89ab4fe7 libTIFF.dylib (1237) <6C8BBCA3-C233-3941-ACF9-F06C5E6EE2E6> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib 0x7fff89b27000 - 0x7fff89c19ff7 libiconv.2.dylib (42) <2A06D02F-8B76-3864-8D96-64EF5B40BC6C> /usr/lib/libiconv.2.dylib 0x7fff89c1a000 - 0x7fff8a04afff com.apple.vision.FaceCore (3.1.6 - 3.1.6) /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore 0x7fff8a30f000 - 0x7fff8a51cff3 com.apple.CFNetwork (720.3.13 - 720.3.13) <69E15385-5784-3912-88F6-03B16F1C1A5C> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x7fff8a51d000 - 0x7fff8a537ff3 com.apple.Ubiquity (1.3 - 313) /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity 0x7fff8a5c6000 - 0x7fff8a6f6fff com.apple.UIFoundation (1.0 - 1) <466BDFA8-0B9F-3AB0-989D-F9779422926A> /System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation 0x7fff8a75b000 - 0x7fff8a788fff com.apple.CoreVideo (1.8 - 145.1) <18DB07E0-B927-3260-A234-636F298D1917> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo 0x7fff8a90e000 - 0x7fff8a913ff7 libmacho.dylib (862) <126CA2ED-DE91-308F-8881-B9DAEC3C63B6> /usr/lib/system/libmacho.dylib 0x7fff8a95b000 - 0x7fff8a968fff libxar.1.dylib (255) <7CD69BB5-97BA-3858-8A8B-2F33F129E6E7> /usr/lib/libxar.1.dylib 0x7fff8aa29000 - 0x7fff8aa83ff7 com.apple.LanguageModeling (1.0 - 1) /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling 0x7fff8adf0000 - 0x7fff8adfbfff libGL.dylib (11.1.2) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib 0x7fff8adfe000 - 0x7fff8adfefff com.apple.Accelerate.vecLib (3.10 - vecLib 3.10) <9D749502-A228-3BF1-B52F-A182DEEB2C4D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib 0x7fff8ae5a000 - 0x7fff8afa0fef libsqlite3.dylib (168) <8B78BED1-7B9B-3943-80DC-0871015AEAC4> /usr/lib/libsqlite3.dylib 0x7fff8afa1000 - 0x7fff8afccff3 libarchive.2.dylib (30) <8CBB4416-EBE9-3574-8ADC-44655D245F39> /usr/lib/libarchive.2.dylib 0x7fff8b936000 - 0x7fff8b937ff7 com.apple.print.framework.Print (10.0 - 265) <3BC4FE7F-78A0-3E57-8F4C-520E7EFD36FA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print 0x7fff8b938000 - 0x7fff8b938fff libOpenScriptingUtil.dylib (162.1) /usr/lib/libOpenScriptingUtil.dylib 0x7fff8b939000 - 0x7fff8b985ff7 libcups.2.dylib (408.2) /usr/lib/libcups.2.dylib 0x7fff8ba72000 - 0x7fff8ba72ff7 liblaunch.dylib (559.20.9) /usr/lib/system/liblaunch.dylib 0x7fff8ba73000 - 0x7fff8ba86ff7 com.apple.CoreBluetooth (1.0 - 1) <8D7BA9BA-EB36-307A-9119-0B3D9732C953> /System/Library/Frameworks/CoreBluetooth.framework/Versions/A/CoreBluetooth 0x7fff8bd36000 - 0x7fff8bd76ff7 libGLImage.dylib (11.1.2) <260A4BF3-DC45-369C-A0CD-B667F9D17179> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib 0x7fff8bd77000 - 0x7fff8bd94fff com.apple.MultitouchSupport.framework (263.9.1 - 263.9.1) <6ABD3AE2-DF6A-3AB2-994B-9C0FB42CE2B7> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport 0x7fff8bd95000 - 0x7fff8bd9efff libGFXShared.dylib (11.1.2) <0BAF2EA8-3BC4-3BF4-ABB6-A6E0A1F3F6A5> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib 0x7fff8be34000 - 0x7fff8be59fff libPng.dylib (1237) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib 0x7fff8be5a000 - 0x7fff8be65fff libcommonCrypto.dylib (60061) /usr/lib/system/libcommonCrypto.dylib 0x7fff8be66000 - 0x7fff8be67fff libDiagnosticMessagesClient.dylib (100) <2EE8E436-5CDC-34C5-9959-5BA218D507FB> /usr/lib/libDiagnosticMessagesClient.dylib 0x7fff8bfd0000 - 0x7fff8bfd7fff com.apple.NetFS (6.0 - 4.0) <1581D25F-CC07-39B0-90E8-5D4F3CF84EBA> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS 0x7fff8bfd8000 - 0x7fff8c013fff com.apple.Symbolication (1.4 - 56045) /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication 0x7fff8c074000 - 0x7fff8c09cfff libsystem_info.dylib (459.20.1) /usr/lib/system/libsystem_info.dylib 0x7fff8c0d9000 - 0x7fff8c1e8ff3 com.apple.desktopservices (1.9.3 - 1.9.3) /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv 0x7fff8c1e9000 - 0x7fff8c1f2fff libsystem_pthread.dylib (105.10.1) <3103AA7F-3BAE-3673-9649-47FFD7E15C97> /usr/lib/system/libsystem_pthread.dylib 0x7fff8c200000 - 0x7fff8c21dffb libresolv.9.dylib (57) <26B38E61-298A-3C3A-82C1-3B5E98AD5E29> /usr/lib/libresolv.9.dylib 0x7fff8c21e000 - 0x7fff8c2c0fff com.apple.Bluetooth (4.3.4 - 4.3.4f4) /System/Library/Frameworks/IOBluetooth.framework/Versions/A/IOBluetooth 0x7fff8c2fe000 - 0x7fff8c304ff7 libsystem_networkextension.dylib (167.1.10) <29AB225B-D7FB-30ED-9600-65D44B9A9442> /usr/lib/system/libsystem_networkextension.dylib 0x7fff8c30b000 - 0x7fff8c32ffef libJPEG.dylib (1237) <6DB10054-5C64-32FB-83FD-E102A8F73258> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib 0x7fff8c34c000 - 0x7fff8c34efff com.apple.loginsupport (1.0 - 1) /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport 0x7fff8c357000 - 0x7fff8c37bff7 com.apple.Sharing (328.16 - 328.16) /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing 0x7fff8c395000 - 0x7fff8c397fff libCVMSPluginSupport.dylib (11.1.2) <6EFEC4A6-2EAC-3C27-820E-C28BE71B9FCB> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib 0x7fff8c3b5000 - 0x7fff8c74dff7 com.apple.CoreFoundation (6.9 - 1153.18) <5C0892B8-9691-341F-9279-CA3A74D59AA0> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff8c761000 - 0x7fff8c800e27 com.apple.AppleJPEG (1.0 - 1) <6627DDD9-A8FE-3968-B23A-B6A29AA3919A> /System/Library/PrivateFrameworks/AppleJPEG.framework/Versions/A/AppleJPEG 0x7fff8c8a1000 - 0x7fff8c8eeff7 com.apple.print.framework.PrintCore (10.3 - 451.1) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x7fff8c8ef000 - 0x7fff8c960ffb com.apple.ApplicationServices.ATS (360 - 375.2) <2338AF23-528F-359A-847F-8B04E49E2B84> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x7fff8c974000 - 0x7fff8c982ff7 com.apple.opengl (11.1.2 - 11.1.2) <864B35BF-1E76-382B-8D5F-38C7282621E6> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 0x7fff8c983000 - 0x7fff8c9fbff7 com.apple.SystemConfiguration (1.14 - 1.14) <06A8405D-53BA-30A9-BA8A-222099176091> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x7fff8c9fc000 - 0x7fff8ca2cfff libsystem_m.dylib (3086.1) <1E12AB45-6D96-36D0-A226-F24D9FB0D9D6> /usr/lib/system/libsystem_m.dylib 0x7fff8ca2d000 - 0x7fff8ca32fff libsystem_stats.dylib (163.20.16) /usr/lib/system/libsystem_stats.dylib 0x7fff8ca63000 - 0x7fff8ca9bfff libsystem_network.dylib (412.20.3) <589A5F67-BE2A-3245-A181-0ECC9B53EB00> /usr/lib/system/libsystem_network.dylib 0x7fff8ce36000 - 0x7fff8ce8afff libc++.1.dylib (120) <1B9530FD-989B-3174-BB1C-BDC159501710> /usr/lib/libc++.1.dylib 0x7fff8ce8b000 - 0x7fff8d08546f libobjc.A.dylib (647) <759E155D-BC42-3D4E-869B-6F57D477177C> /usr/lib/libobjc.A.dylib 0x7fff8d086000 - 0x7fff8d3a1fcf com.apple.vImage (8.0 - 8.0) <1183FE6A-FDB6-3B3B-928D-50C7909F2308> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage 0x7fff8d3a2000 - 0x7fff8d3f3fff com.apple.audio.CoreAudio (4.3.0 - 4.3.0) <450293F7-DAE7-3DD0-8F7C-71FC2FD72627> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x7fff8d451000 - 0x7fff8d45eff7 libbz2.1.0.dylib (36) <2DF83FBC-5C08-39E1-94F5-C28653791B5F> /usr/lib/libbz2.1.0.dylib 0x7fff8d49f000 - 0x7fff8d71eff7 com.apple.CoreData (111 - 526.3) <5A27E0D8-5E5A-335B-B3F6-2601C7B976FA> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData 0x7fff8d721000 - 0x7fff8d767ff7 libFontRegistry.dylib (134.1) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib 0x7fff8d769000 - 0x7fff8d7b8ff7 com.apple.opencl (2.4.2 - 2.4.2) <4A9574ED-15CF-3EBB-B4C0-D30F644D6C74> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL 0x7fff8d7b9000 - 0x7fff8d7c4ff7 com.apple.CrashReporterSupport (10.10 - 631) /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport 0x7fff8da62000 - 0x7fff8da65fff com.apple.xpc.ServiceManagement (1.0 - 1) <9E025823-660A-30C5-A568-223BD595B6F7> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement 0x7fff8da85000 - 0x7fff8daa6fff com.apple.framework.Apple80211 (10.3 - 1030.71.6) /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Apple80211 0x7fff8daa7000 - 0x7fff8dbcfff7 com.apple.coreui (2.1 - 308.6) /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI 0x7fff8dd37000 - 0x7fff8dda3fff com.apple.framework.CoreWLAN (5.0 - 500.35.2) <5E228544-77A9-3AA5-8355-E8F6626F50E7> /System/Library/Frameworks/CoreWLAN.framework/Versions/A/CoreWLAN 0x7fff8dda4000 - 0x7fff8deb6ff7 libvDSP.dylib (516) <151B3CCB-77D3-3715-A3D0-7C74CD5C7FFC> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib 0x7fff8deca000 - 0x7fff8decdfff com.apple.help (1.3.3 - 46) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help 0x7fff8dfdb000 - 0x7fff8e0cbfef libJP2.dylib (1237) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib 0x7fff8e0cc000 - 0x7fff8e14afff com.apple.CoreServices.OSServices (640.4 - 640.4) <20121A5E-7AB5-3624-8CF0-3562F97C8A95> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x7fff8e3bc000 - 0x7fff8e3bffff com.apple.IOSurface (97.4 - 97.4) /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface 0x7fff8e3c3000 - 0x7fff8e3eefff libc++abi.dylib (125) <88A22A0F-87C6-3002-BFBA-AC0F2808B8B9> /usr/lib/libc++abi.dylib 0x7fff8e4f2000 - 0x7fff8e616ff7 com.apple.LaunchServices (644.56 - 644.56) <20AABB1C-9319-3E4D-A024-51B0DD5FCD3B> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices 0x7fff8e620000 - 0x7fff8e694ffb com.apple.securityfoundation (6.0 - 55126) <42589E18-D38C-3E25-B638-6E29740C224C> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation 0x7fff8e695000 - 0x7fff8e6a0ff7 libkxld.dylib (2782.20.48) <28EF8328-E3E2-336A-974B-FB1BF119D55A> /usr/lib/system/libkxld.dylib 0x7fff8e723000 - 0x7fff8e73cff7 com.apple.CFOpenDirectory (10.10 - 187) <790ED527-EFD2-3EA6-8C97-A8C04E96EBA7> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory 0x7fff8e745000 - 0x7fff8e74eff3 com.apple.CommonAuth (4.0 - 2.0) /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth 0x7fff8e7c3000 - 0x7fff8e7d2fff com.apple.LangAnalysis (1.7.0 - 1.7.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x7fff8e7d3000 - 0x7fff8e7d5ff7 libsystem_coreservices.dylib (9) <41B7C578-5A53-31C8-A96F-C73E030B0938> /usr/lib/system/libsystem_coreservices.dylib 0x7fff8e7fc000 - 0x7fff8e7fcff7 libkeymgr.dylib (28) <77845842-DE70-3CC5-BD01-C3D14227CED5> /usr/lib/system/libkeymgr.dylib 0x7fff8eb0e000 - 0x7fff8eb10fff libRadiance.dylib (1237) <9B048776-53BB-3947-8ECE-9DDA804C86B2> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib 0x7fff8eb1a000 - 0x7fff8ec0cfff libxml2.2.dylib (26) /usr/lib/libxml2.2.dylib 0x7fff8ec0d000 - 0x7fff8ec27ff7 com.apple.Kerberos (3.0 - 1) <7760E0C2-A222-3709-B2A6-B692D900CEB1> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos 0x7fff8eeea000 - 0x7fff8eeeafff com.apple.Carbon (154 - 157) <9BF51672-1684-3FDE-A561-FC59A2864EF8> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0x7fff8eeeb000 - 0x7fff8ef04ffb com.apple.openscripting (1.4 - 162.1) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x7fff8ef05000 - 0x7fff8ef09fff libCoreVMClient.dylib (79.1) <201EF6DF-5074-3CB7-A361-398CF957A264> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib 0x7fff8ef0a000 - 0x7fff8efb9fe7 libvMisc.dylib (516) <6739E390-46E7-3BFA-9B69-B278562326E6> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib 0x7fff8f00e000 - 0x7fff8f039fff com.apple.DictionaryServices (1.2 - 229) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices 0x7fff8f06a000 - 0x7fff8f085ff7 libCRFSuite.dylib (34) /usr/lib/libCRFSuite.dylib 0x7fff8f216000 - 0x7fff8f260ff7 com.apple.HIServices (1.22 - 522.1) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x7fff8f261000 - 0x7fff8f262fff libsystem_secinit.dylib (18) <581DAD0F-6B63-3A48-B63B-917AF799ABAA> /usr/lib/system/libsystem_secinit.dylib 0x7fff8f263000 - 0x7fff8f26eff7 com.apple.speech.synthesis.framework (5.3.3 - 5.3.3) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x7fff8f2fc000 - 0x7fff8f302fff com.apple.speech.recognition.framework (5.0.9 - 5.0.9) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition 0x7fff8f35e000 - 0x7fff8f3d0fff com.apple.framework.IOKit (2.0.2 - 1050.20.2) <09C0518C-90DF-3FC3-96D6-34D35F72C8EF> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x7fff90514000 - 0x7fff9064efff com.apple.ImageIO.framework (3.3.0 - 1237) <3C06213D-847A-3C7B-843E-6EC37113965D> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x7fff9064f000 - 0x7fff9065fff7 libbsm.0.dylib (34) /usr/lib/libbsm.0.dylib 0x7fff90660000 - 0x7fff90666fff libsystem_trace.dylib (72.20.1) <840F5301-B55A-3078-90B9-FEFFD6CD741A> /usr/lib/system/libsystem_trace.dylib 0x7fff90747000 - 0x7fff9074bfff com.apple.TCC (1.0 - 1) /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC 0x7fff9074c000 - 0x7fff9074eff7 com.apple.securityhi (9.0 - 55006) <5DB5773C-FC07-302C-98FE-4B80D88D481A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI 0x7fff9075a000 - 0x7fff90795fff com.apple.QD (301 - 301) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD 0x7fff90796000 - 0x7fff9079aff7 libGIF.dylib (1237) <8A40FED5-FA90-3E76-A359-CD974C43A962> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 133049 thread_create: 0 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=179.0M resident=138.8M(78%) swapped_out_or_unallocated=40.2M(22%) Writable regions: Total=82.6M written=5000K(6%) resident=27.3M(33%) swapped_out=0K(0%) unallocated=55.3M(67%) REGION TYPE VIRTUAL =========== ======= Dispatch continuations 8192K Kernel Alloc Once 4K MALLOC 57.2M MALLOC (admin) 32K MALLOC_LARGE (reserved) 384K reserved VM address space (unallocated) STACK GUARD 4K Stack 16.1M VM_ALLOCATE 32K __DATA 14.7M __IMAGE 528K __LINKEDIT 71.9M __TEXT 107.1M __UNICODE 552K shared memory 4K =========== ======= TOTAL 276.5M TOTAL, minus reserved VM space 276.2M Model: MacBookPro12,1, BootROM MBP121.0167.B02, 2 processors, Intel Core i7, 3.1 GHz, 16 GB, SMC 2.28f6 Graphics: Intel Iris Graphics 6100, Intel Iris Graphics 6100, Built-In Memory Module: BANK 0/DIMM0, 8 GB, DDR3, 1867 MHz, 0x02FE, 0x4544464232333241314D412D4A442D460000 Memory Module: BANK 1/DIMM0, 8 GB, DDR3, 1867 MHz, 0x02FE, 0x4544464232333241314D412D4A442D460000 AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x133), Broadcom BCM43xx 1.0 (7.15.166.24.3) Bluetooth: Version 4.3.4f4 15601, 3 services, 27 devices, 1 incoming serial ports Network Service: Wi-Fi, AirPort, en0 Serial ATA Device: APPLE SSD SM1024G, 1 TB USB Device: Hub USB Device: Hub USB Device: Internal Memory Card Reader USB Device: Hub USB Device: Hub USB Device: Bluetooth USB Host Controller Thunderbolt Bus: MacBook Pro, Apple Inc., 27.1 ---------- components: Macintosh messages: 243961 nosy: jrhite, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: _scproxy.so causes EXC_BAD_ACCESS (SIGSEGV) type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 04:41:24 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 May 2015 02:41:24 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1432435283.99.0.808592835194.issue14373@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Serhiy. I'll work on the next steps after the beta. ---------- assignee: serhiy.storchaka -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 05:01:35 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 May 2015 03:01:35 +0000 Subject: [issue24273] _scproxy.so causes EXC_BAD_ACCESS (SIGSEGV) In-Reply-To: <1432434972.57.0.149064186697.issue24273@psf.upfronthosting.co.za> Message-ID: <1432436495.28.0.249189113919.issue24273@psf.upfronthosting.co.za> Ned Deily added the comment: One workaround should be to disable network proxy lookups by defining the environment variable 'no_proxy' with value '*' in the Python process, for example: env no_proxy='*' python3.4 ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 05:18:09 2015 From: report at bugs.python.org (Jim Jewett) Date: Sun, 24 May 2015 03:18:09 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432437489.48.0.719124044668.issue16991@psf.upfronthosting.co.za> Jim Jewett added the comment: Eric, unless I'm misreading your debugging info, it is the other way around -- something is in the dict, but not in the list that you iterate over. And since the list that you iterate over looks right, I have to wonder if it was something internal-to-configparser (or its various converters and proxies). Perhaps the __root used by the collections.OrderedDict that it uses by default? Can you iterate over it as a dict, instead of as an ordered dict, to find the discrepancy? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 05:21:34 2015 From: report at bugs.python.org (Jim Jewett) Date: Sun, 24 May 2015 03:21:34 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432437694.78.0.999900807186.issue16991@psf.upfronthosting.co.za> Jim Jewett added the comment: (Just putting my review summary in the main ticket) I'm going to echo the previous comment that maybe trying to emulate the existing dict implementation too carefully just adds complexity. The split-keys implementation shows that there is at least some flexibility to the implementation. Enough that the keys could map to an array offset, rather than directly to the values? A simple array of key/value pairs (hashing only to ensure hashability, but ignoring it otherwise) should be faster for the really small dicts you care about, like keyword dicts. (Admittedly, those timing data are fairly out of date, but I would be surprised if it weren't still true.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 05:53:49 2015 From: report at bugs.python.org (Jim Jewett) Date: Sun, 24 May 2015 03:53:49 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432439629.61.0.544912035278.issue16991@psf.upfronthosting.co.za> Jim Jewett added the comment: Should dictobject.h get a bit more changes? In particular, should the following be expanded? #define PyDictKeys_Check(op) (Py_TYPE(op) == &PyDictKeys_Type) #define PyDictItems_Check(op) (Py_TYPE(op) == &PyDictItems_Type) #define PyDictValues_Check(op) (Py_TYPE(op) == &PyDictValues_Type) /* This excludes Values, since they are not sets. */ # define PyDictViewSet_Check(op) \ (PyDictKeys_Check(op) || PyDictItems_Check(op)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 06:21:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 May 2015 04:21:35 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1432441295.08.0.0977338900276.issue14373@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Unfortunately the patch caused a crash in test_ipaddress. Larry granted special exclusion for adding this feature after feature freeze if it will be fixed before beta 2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 06:49:12 2015 From: report at bugs.python.org (Jim Jewett) Date: Sun, 24 May 2015 04:49:12 +0000 Subject: [issue24274] erroneous comments in dictobject.c Message-ID: <1432442952.38.0.376658937682.issue24274@psf.upfronthosting.co.za> New submission from Jim Jewett: https://hg.python.org/cpython/file/2df7c958974e/Objects/dictobject.c#l451 The comments near lookdict suggest that specialized versions such as lookdict_unicode and lookdict_unicode_nodummy cannot return NULL, as that would indicate an Exception was raised during comparison. They can return NULL, because if the *search* key is not unicode, they replace themselves with the generic lookdict and then return its result, which may be NULL. ---------- components: Interpreter Core messages: 243968 nosy: Jim.Jewett priority: normal severity: normal status: open title: erroneous comments in dictobject.c type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 07:08:29 2015 From: report at bugs.python.org (Jim Jewett) Date: Sun, 24 May 2015 05:08:29 +0000 Subject: [issue24275] lookdict_* give up too soon Message-ID: <1432444109.96.0.971324850141.issue24275@psf.upfronthosting.co.za> New submission from Jim Jewett: The specialized lookdict_* variants replace themselves with the generic lookdict as soon as a non-unicode key is looked up. They could reasonably leave the replacement to insertdict (line 819, currently assert rather than a replacement), when a non-unicode key is actually inserted into the dict. While inserts are less common than (all lookups including insert), I see the main advantage as reducing the number of duplications of the replacement logic. ---------- components: Interpreter Core messages: 243969 nosy: Jim.Jewett priority: normal severity: normal status: open title: lookdict_* give up too soon type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 08:08:44 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Sun, 24 May 2015 06:08:44 +0000 Subject: [issue24275] lookdict_* give up too soon In-Reply-To: <1432444109.96.0.971324850141.issue24275@psf.upfronthosting.co.za> Message-ID: <1432447724.64.0.89917210352.issue24275@psf.upfronthosting.co.za> Changes by Dmitry Kazakov : ---------- nosy: +vlth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 09:13:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 May 2015 07:13:31 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1432441295.08.0.0977338900276.issue14373@psf.upfronthosting.co.za> Message-ID: <1885551.CatOf084sx@raxxla> Serhiy Storchaka added the comment: Here are the recent version of the patch and minimal crash reproducer. ---------- Added file: http://bugs.python.org/file39478/clru_cache_3.patch Added file: http://bugs.python.org/file39479/clru_cache_crasher.py _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 2df7c958974e Lib/functools.py --- a/Lib/functools.py Sat May 23 18:08:55 2015 -0700 +++ b/Lib/functools.py Sun May 24 10:11:21 2015 +0300 @@ -419,120 +419,129 @@ def lru_cache(maxsize=128, typed=False): if maxsize is not None and not isinstance(maxsize, int): raise TypeError('Expected maxsize to be an integer or None') + def decorating_function(user_function): + wrapper = _lru_cache_wrapper(user_function, maxsize, typed, _CacheInfo) + return update_wrapper(wrapper, user_function) + + return decorating_function + +def _lru_cache_wrapper(user_function, maxsize, typed, _CacheInfo): # Constants shared by all lru cache instances: sentinel = object() # unique object used to signal cache misses make_key = _make_key # build a key from the function arguments PREV, NEXT, KEY, RESULT = 0, 1, 2, 3 # names for the link fields - def decorating_function(user_function): - cache = {} - hits = misses = 0 - full = False - cache_get = cache.get # bound method to lookup a key or return None - lock = RLock() # because linkedlist updates aren't threadsafe - root = [] # root of the circular doubly linked list - root[:] = [root, root, None, None] # initialize by pointing to self + cache = {} + hits = misses = 0 + full = False + cache_get = cache.get # bound method to lookup a key or return None + lock = RLock() # because linkedlist updates aren't threadsafe + root = [] # root of the circular doubly linked list + root[:] = [root, root, None, None] # initialize by pointing to self - if maxsize == 0: + if maxsize == 0: - def wrapper(*args, **kwds): - # No caching -- just a statistics update after a successful call - nonlocal misses - result = user_function(*args, **kwds) - misses += 1 + def wrapper(*args, **kwds): + # No caching -- just a statistics update after a successful call + nonlocal misses + result = user_function(*args, **kwds) + misses += 1 + return result + + elif maxsize is None: + + def wrapper(*args, **kwds): + # Simple caching without ordering or size limit + nonlocal hits, misses + key = make_key(args, kwds, typed) + result = cache_get(key, sentinel) + if result is not sentinel: + hits += 1 return result + result = user_function(*args, **kwds) + cache[key] = result + misses += 1 + return result - elif maxsize is None: + else: - def wrapper(*args, **kwds): - # Simple caching without ordering or size limit - nonlocal hits, misses - key = make_key(args, kwds, typed) - result = cache_get(key, sentinel) - if result is not sentinel: + def wrapper(*args, **kwds): + # Size limited caching that tracks accesses by recency + nonlocal root, hits, misses, full + key = make_key(args, kwds, typed) + with lock: + link = cache_get(key) + if link is not None: + # Move the link to the front of the circular queue + link_prev, link_next, _key, result = link + link_prev[NEXT] = link_next + link_next[PREV] = link_prev + last = root[PREV] + last[NEXT] = root[PREV] = link + link[PREV] = last + link[NEXT] = root hits += 1 return result - result = user_function(*args, **kwds) - cache[key] = result + result = user_function(*args, **kwds) + with lock: + if key in cache: + # Getting here means that this same key was added to the + # cache while the lock was released. Since the link + # update is already done, we need only return the + # computed result and update the count of misses. + pass + elif full: + # Use the old root to store the new key and result. + oldroot = root + oldroot[KEY] = key + oldroot[RESULT] = result + # Empty the oldest link and make it the new root. + # Keep a reference to the old key and old result to + # prevent their ref counts from going to zero during the + # update. That will prevent potentially arbitrary object + # clean-up code (i.e. __del__) from running while we're + # still adjusting the links. + root = oldroot[NEXT] + oldkey = root[KEY] + oldresult = root[RESULT] + root[KEY] = root[RESULT] = None + # Now update the cache dictionary. + del cache[oldkey] + # Save the potentially reentrant cache[key] assignment + # for last, after the root and links have been put in + # a consistent state. + cache[key] = oldroot + else: + # Put result in a new link at the front of the queue. + last = root[PREV] + link = [last, root, key, result] + last[NEXT] = root[PREV] = cache[key] = link + full = (len(cache) >= maxsize) misses += 1 - return result + return result - else: + def cache_info(): + """Report cache statistics""" + with lock: + return _CacheInfo(hits, misses, maxsize, len(cache)) - def wrapper(*args, **kwds): - # Size limited caching that tracks accesses by recency - nonlocal root, hits, misses, full - key = make_key(args, kwds, typed) - with lock: - link = cache_get(key) - if link is not None: - # Move the link to the front of the circular queue - link_prev, link_next, _key, result = link - link_prev[NEXT] = link_next - link_next[PREV] = link_prev - last = root[PREV] - last[NEXT] = root[PREV] = link - link[PREV] = last - link[NEXT] = root - hits += 1 - return result - result = user_function(*args, **kwds) - with lock: - if key in cache: - # Getting here means that this same key was added to the - # cache while the lock was released. Since the link - # update is already done, we need only return the - # computed result and update the count of misses. - pass - elif full: - # Use the old root to store the new key and result. - oldroot = root - oldroot[KEY] = key - oldroot[RESULT] = result - # Empty the oldest link and make it the new root. - # Keep a reference to the old key and old result to - # prevent their ref counts from going to zero during the - # update. That will prevent potentially arbitrary object - # clean-up code (i.e. __del__) from running while we're - # still adjusting the links. - root = oldroot[NEXT] - oldkey = root[KEY] - oldresult = root[RESULT] - root[KEY] = root[RESULT] = None - # Now update the cache dictionary. - del cache[oldkey] - # Save the potentially reentrant cache[key] assignment - # for last, after the root and links have been put in - # a consistent state. - cache[key] = oldroot - else: - # Put result in a new link at the front of the queue. - last = root[PREV] - link = [last, root, key, result] - last[NEXT] = root[PREV] = cache[key] = link - full = (len(cache) >= maxsize) - misses += 1 - return result + def cache_clear(): + """Clear the cache and cache statistics""" + nonlocal hits, misses, full + with lock: + cache.clear() + root[:] = [root, root, None, None] + hits = misses = 0 + full = False - def cache_info(): - """Report cache statistics""" - with lock: - return _CacheInfo(hits, misses, maxsize, len(cache)) + wrapper.cache_info = cache_info + wrapper.cache_clear = cache_clear + return update_wrapper(wrapper, user_function) - def cache_clear(): - """Clear the cache and cache statistics""" - nonlocal hits, misses, full - with lock: - cache.clear() - root[:] = [root, root, None, None] - hits = misses = 0 - full = False - - wrapper.cache_info = cache_info - wrapper.cache_clear = cache_clear - return update_wrapper(wrapper, user_function) - - return decorating_function +try: + from _functools import _lru_cache_wrapper +except ImportError: + pass ################################################################################ diff -r 2df7c958974e Lib/test/test_functools.py --- a/Lib/test/test_functools.py Sat May 23 18:08:55 2015 -0700 +++ b/Lib/test/test_functools.py Sun May 24 10:11:21 2015 +0300 @@ -7,6 +7,10 @@ import sys from test import support import unittest from weakref import proxy +try: + import threading +except ImportError: + threading = None import functools @@ -912,12 +916,12 @@ class Orderable_LT: return self.value == other.value -class TestLRU(unittest.TestCase): +class TestLRU: def test_lru(self): def orig(x, y): return 3 * x + y - f = functools.lru_cache(maxsize=20)(orig) + f = self.module.lru_cache(maxsize=20)(orig) hits, misses, maxsize, currsize = f.cache_info() self.assertEqual(maxsize, 20) self.assertEqual(currsize, 0) @@ -955,7 +959,7 @@ class TestLRU(unittest.TestCase): self.assertEqual(currsize, 1) # test size zero (which means "never-cache") - @functools.lru_cache(0) + @self.module.lru_cache(0) def f(): nonlocal f_cnt f_cnt += 1 @@ -971,7 +975,7 @@ class TestLRU(unittest.TestCase): self.assertEqual(currsize, 0) # test size one - @functools.lru_cache(1) + @self.module.lru_cache(1) def f(): nonlocal f_cnt f_cnt += 1 @@ -987,7 +991,7 @@ class TestLRU(unittest.TestCase): self.assertEqual(currsize, 1) # test size two - @functools.lru_cache(2) + @self.module.lru_cache(2) def f(x): nonlocal f_cnt f_cnt += 1 @@ -1004,7 +1008,7 @@ class TestLRU(unittest.TestCase): self.assertEqual(currsize, 2) def test_lru_with_maxsize_none(self): - @functools.lru_cache(maxsize=None) + @self.module.lru_cache(maxsize=None) def fib(n): if n < 2: return n @@ -1012,17 +1016,26 @@ class TestLRU(unittest.TestCase): self.assertEqual([fib(n) for n in range(16)], [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610]) self.assertEqual(fib.cache_info(), - functools._CacheInfo(hits=28, misses=16, maxsize=None, currsize=16)) + self.module._CacheInfo(hits=28, misses=16, maxsize=None, currsize=16)) fib.cache_clear() self.assertEqual(fib.cache_info(), - functools._CacheInfo(hits=0, misses=0, maxsize=None, currsize=0)) + self.module._CacheInfo(hits=0, misses=0, maxsize=None, currsize=0)) + + def test_lru_with_maxsize_negative(self): + @self.module.lru_cache(maxsize=-10) + def eq(n): + return n + for i in (0, 1): + self.assertEqual([eq(n) for n in range(150)], list(range(150))) + self.assertEqual(eq.cache_info(), + self.module._CacheInfo(hits=0, misses=300, maxsize=-10, currsize=1)) def test_lru_with_exceptions(self): # Verify that user_function exceptions get passed through without # creating a hard-to-read chained exception. # http://bugs.python.org/issue13177 for maxsize in (None, 128): - @functools.lru_cache(maxsize) + @self.module.lru_cache(maxsize) def func(i): return 'abc'[i] self.assertEqual(func(0), 'a') @@ -1035,7 +1048,7 @@ class TestLRU(unittest.TestCase): def test_lru_with_types(self): for maxsize in (None, 128): - @functools.lru_cache(maxsize=maxsize, typed=True) + @self.module.lru_cache(maxsize=maxsize, typed=True) def square(x): return x * x self.assertEqual(square(3), 9) @@ -1050,7 +1063,7 @@ class TestLRU(unittest.TestCase): self.assertEqual(square.cache_info().misses, 4) def test_lru_with_keyword_args(self): - @functools.lru_cache() + @self.module.lru_cache() def fib(n): if n < 2: return n @@ -1060,13 +1073,13 @@ class TestLRU(unittest.TestCase): [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610] ) self.assertEqual(fib.cache_info(), - functools._CacheInfo(hits=28, misses=16, maxsize=128, currsize=16)) + self.module._CacheInfo(hits=28, misses=16, maxsize=128, currsize=16)) fib.cache_clear() self.assertEqual(fib.cache_info(), - functools._CacheInfo(hits=0, misses=0, maxsize=128, currsize=0)) + self.module._CacheInfo(hits=0, misses=0, maxsize=128, currsize=0)) def test_lru_with_keyword_args_maxsize_none(self): - @functools.lru_cache(maxsize=None) + @self.module.lru_cache(maxsize=None) def fib(n): if n < 2: return n @@ -1074,15 +1087,71 @@ class TestLRU(unittest.TestCase): self.assertEqual([fib(n=number) for number in range(16)], [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610]) self.assertEqual(fib.cache_info(), - functools._CacheInfo(hits=28, misses=16, maxsize=None, currsize=16)) + self.module._CacheInfo(hits=28, misses=16, maxsize=None, currsize=16)) fib.cache_clear() self.assertEqual(fib.cache_info(), - functools._CacheInfo(hits=0, misses=0, maxsize=None, currsize=0)) + self.module._CacheInfo(hits=0, misses=0, maxsize=None, currsize=0)) + + def test_lru_cache_decoration(self): + def f(zomg: 'zomg_annotation'): + """f doc string""" + return 42 + g = self.module.lru_cache()(f) + for attr in self.module.WRAPPER_ASSIGNMENTS: + self.assertEqual(getattr(g, attr), getattr(f, attr)) + + @unittest.skipUnless(threading, 'This test requires threading.') + def test_lru_cache_threaded(self): + def orig(x, y): + return 3 * x + y + f = self.module.lru_cache(maxsize=20)(orig) + hits, misses, maxsize, currsize = f.cache_info() + self.assertEqual(currsize, 0) + + def full(f, *args): + for _ in range(10): + f(*args) + + def clear(f): + for _ in range(10): + f.cache_clear() + + orig_si = sys.getswitchinterval() + sys.setswitchinterval(1e-6) + try: + # create 5 threads in order to fill cache + threads = [] + for k in range(5): + t = threading.Thread(target=full, args=[f, k, k]) + t.start() + threads.append(t) + + for t in threads: + t.join() + + hits, misses, maxsize, currsize = f.cache_info() + self.assertEqual(hits, 45) + self.assertEqual(misses, 5) + self.assertEqual(currsize, 5) + + # create 5 threads in order to fill cache and 1 to clear it + cleaner = threading.Thread(target=clear, args=[f]) + cleaner.start() + threads = [cleaner] + for k in range(5): + t = threading.Thread(target=full, args=[f, k, k]) + t.start() + threads.append(t) + + for t in threads: + t.join() + finally: + sys.setswitchinterval(orig_si) def test_need_for_rlock(self): # This will deadlock on an LRU cache that uses a regular lock - @functools.lru_cache(maxsize=10) + @self.module.lru_cache(maxsize=10) def test_func(x): 'Used to demonstrate a reentrant lru_cache call within a single thread' return x @@ -1110,6 +1179,12 @@ class TestLRU(unittest.TestCase): def f(): pass +class TestLRUC(TestLRU, unittest.TestCase): + module = c_functools + +class TestLRUPy(TestLRU, unittest.TestCase): + module = py_functools + class TestSingleDispatch(unittest.TestCase): def test_simple_overloads(self): diff -r 2df7c958974e Misc/NEWS --- a/Misc/NEWS Sat May 23 18:08:55 2015 -0700 +++ b/Misc/NEWS Sun May 24 10:11:21 2015 +0300 @@ -63,6 +63,9 @@ Core and Builtins Library ------- +- Issue #14373: Added C implementation of functools.lru_cache(). Based on + patches by Matt Joiner and Alexey Kachayev. + - Issue 24230: The tempfile module now accepts bytes for prefix, suffix and dir parameters and returns bytes in such situations (matching the os module APIs). diff -r 2df7c958974e Modules/_functoolsmodule.c --- a/Modules/_functoolsmodule.c Sat May 23 18:08:55 2015 -0700 +++ b/Modules/_functoolsmodule.c Sun May 24 10:11:21 2015 +0300 @@ -590,6 +590,539 @@ For example, reduce(lambda x, y: x+y, [1 of the sequence in the calculation, and serves as a default when the\n\ sequence is empty."); +/* lru_cache object **********************************************************/ + +/* this object is used delimit args and keywords in the cache keys */ +static PyObject *kwd_mark = NULL; + +struct lru_list_elem; +struct lru_cache_object; + +typedef struct lru_list_elem { + PyObject_HEAD + struct lru_list_elem *prev, *next; /* borrowed links */ + PyObject *key, *result; +} lru_list_elem; + +static void +lru_list_elem_dealloc(lru_list_elem *link) +{ + _PyObject_GC_UNTRACK(link); + Py_XDECREF(link->key); + Py_XDECREF(link->result); + PyObject_GC_Del(link); +} + +static int +lru_list_elem_traverse(lru_list_elem *link, visitproc visit, void *arg) +{ + Py_VISIT(link->key); + Py_VISIT(link->result); + return 0; +} + +static int +lru_list_elem_clear(lru_list_elem *link) +{ + Py_CLEAR(link->key); + Py_CLEAR(link->result); + return 0; +} + +static PyTypeObject lru_list_elem_type = { + PyVarObject_HEAD_INIT(&PyType_Type, 0) + "functools._lru_list_elem", /* tp_name */ + sizeof(lru_list_elem), /* tp_basicsize */ + 0, /* tp_itemsize */ + /* methods */ + (destructor)lru_list_elem_dealloc, /* tp_dealloc */ + 0, /* tp_print */ + 0, /* tp_getattr */ + 0, /* tp_setattr */ + 0, /* tp_reserved */ + 0, /* tp_repr */ + 0, /* tp_as_number */ + 0, /* tp_as_sequence */ + 0, /* tp_as_mapping */ + 0, /* tp_hash */ + 0, /* tp_call */ + 0, /* tp_str */ + 0, /* tp_getattro */ + 0, /* tp_setattro */ + 0, /* tp_as_buffer */ + Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC, /* tp_flags */ + 0, /* tp_doc */ + (traverseproc)lru_list_elem_traverse, /* tp_traverse */ + (inquiry)lru_list_elem_clear, /* tp_clear */ +}; + + +typedef PyObject *(*lru_cache_ternaryfunc)(struct lru_cache_object *, PyObject *, PyObject *); + +typedef struct lru_cache_object { + lru_list_elem root; /* includes PyObject_HEAD */ + Py_ssize_t maxsize; + PyObject *maxsize_O; + PyObject *func; + lru_cache_ternaryfunc wrapper; + PyObject *cache; + PyObject *cache_info_type; + Py_ssize_t misses, hits; + int typed; + PyObject *dict; + int full; +} lru_cache_object; + +static PyTypeObject lru_cache_type; + +static PyObject * +lru_cache_make_key(PyObject *args, PyObject *kwds, int typed) +{ + PyObject *key, *sorted_items; + Py_ssize_t key_size, pos, key_pos; + + /* short path, key will match args anyway, which is a tuple */ + if (!typed && !kwds) { + Py_INCREF(args); + return args; + } + + if (kwds && PyDict_Size(kwds) > 0) { + sorted_items = PyDict_Items(kwds); + if (!sorted_items) + return NULL; + if (PyList_Sort(sorted_items) < 0) { + Py_DECREF(sorted_items); + return NULL; + } + } else + sorted_items = NULL; + + key_size = PyTuple_GET_SIZE(args); + if (sorted_items) + key_size += PyList_GET_SIZE(sorted_items); + if (typed) + key_size *= 2; + if (sorted_items) + key_size++; + + key = PyTuple_New(key_size); + if (key == NULL) + goto done; + + key_pos = 0; + for (pos = 0; pos < PyTuple_GET_SIZE(args); ++pos) { + PyObject *item = PyTuple_GET_ITEM(args, pos); + Py_INCREF(item); + PyTuple_SET_ITEM(key, key_pos++, item); + } + if (sorted_items) { + Py_INCREF(kwd_mark); + PyTuple_SET_ITEM(key, key_pos++, kwd_mark); + for (pos = 0; pos < PyList_GET_SIZE(sorted_items); ++pos) { + PyObject *item = PyList_GET_ITEM(sorted_items, pos); + Py_INCREF(item); + PyTuple_SET_ITEM(key, key_pos++, item); + } + } + if (typed) { + for (pos = 0; pos < PyTuple_GET_SIZE(args); ++pos) { + PyObject *item = (PyObject *)Py_TYPE(PyTuple_GET_ITEM(args, pos)); + Py_INCREF(item); + PyTuple_SET_ITEM(key, key_pos++, item); + } + if (sorted_items) { + for (pos = 0; pos < PyList_GET_SIZE(sorted_items); ++pos) { + PyObject *tp_items = PyList_GET_ITEM(sorted_items, pos); + PyObject *item = (PyObject *)Py_TYPE(PyTuple_GET_ITEM(tp_items, 1)); + Py_INCREF(item); + PyTuple_SET_ITEM(key, key_pos++, item); + } + } + } + assert(key_pos == key_size); + +done: + if (sorted_items) + Py_DECREF(sorted_items); + return key; +} + +static PyObject * +uncached_lru_cache_wrapper(lru_cache_object *self, PyObject *args, PyObject *kwds) +{ + PyObject *result = PyObject_Call(self->func, args, kwds); + if (!result) + return NULL; + self->misses++; + return result; +} + +static PyObject * +infinite_lru_cache_wrapper(lru_cache_object *self, PyObject *args, PyObject *kwds) +{ + PyObject *result; + PyObject *key = lru_cache_make_key(args, kwds, self->typed); + if (!key) + return NULL; + result = PyDict_GetItemWithError(self->cache, key); + if (result) { + Py_INCREF(result); + self->hits++; + Py_DECREF(key); + return result; + } + if (PyErr_Occurred()) { + Py_DECREF(key); + return NULL; + } + result = PyObject_Call(self->func, args, kwds); + if (!result) { + Py_DECREF(key); + return NULL; + } + if (PyDict_SetItem(self->cache, key, result) < 0) { + Py_DECREF(result); + Py_DECREF(key); + return NULL; + } + Py_DECREF(key); + self->misses++; + return result; +} + +static void +lru_cache_extricate_link(lru_list_elem *link) +{ + link->prev->next = link->next; + link->next->prev = link->prev; +} + +static void +lru_cache_append_link(lru_cache_object *self, lru_list_elem *link) +{ + lru_list_elem *root = &self->root; + lru_list_elem *last = root->prev; + last->next = root->prev = link; + link->prev = last; + link->next = root; +} + +static PyObject * +bounded_lru_cache_wrapper(lru_cache_object *self, PyObject *args, PyObject *kwds) +{ + lru_list_elem *link; + PyObject *key, *result; + + key = lru_cache_make_key(args, kwds, self->typed); + if (!key) + return NULL; + link = (lru_list_elem *)PyDict_GetItemWithError(self->cache, key); + if (link) { + lru_cache_extricate_link(link); + lru_cache_append_link(self, link); + self->hits++; + result = link->result; + Py_INCREF(result); + Py_DECREF(key); + return result; + } + if (PyErr_Occurred()) { + Py_DECREF(key); + return NULL; + } + result = PyObject_Call(self->func, args, kwds); + if (!result) { + Py_DECREF(key); + return NULL; + } + if (self->full && self->root.next != &self->root) { + /* Use the oldest item to store the new key and result. */ + PyObject *oldkey, *oldresult; + /* Extricate the oldest item. */ + link = self->root.next; + lru_cache_extricate_link(link); + /* Remove it from the cache. + The cache dict holds one reference to the link, + and the linked list holds yet one reference to it. */ + if (PyDict_DelItem(self->cache, link->key) < 0) { + lru_cache_append_link(self, link); + Py_DECREF(key); + Py_DECREF(result); + return NULL; + } + /* Keep a reference to the old key and old result to + prevent their ref counts from going to zero during the + update. That will prevent potentially arbitrary object + clean-up code (i.e. __del__) from running while we're + still adjusting the links. */ + oldkey = link->key; + oldresult = link->result; + + link->key = key; + link->result = result; + if (PyDict_SetItem(self->cache, key, (PyObject *)link) < 0) { + Py_DECREF(link); + Py_DECREF(oldkey); + Py_DECREF(oldresult); + return NULL; + } + lru_cache_append_link(self, link); + Py_INCREF(result); /* for return */ + Py_DECREF(oldkey); + Py_DECREF(oldresult); + } else { + /* Put result in a new link at the front of the queue. */ + link = (lru_list_elem *)PyObject_GC_New(lru_list_elem, + &lru_list_elem_type); + if (link == NULL) { + Py_DECREF(key); + Py_DECREF(result); + return NULL; + } + + link->key = key; + link->result = result; + _PyObject_GC_TRACK(link); + if (PyDict_SetItem(self->cache, key, (PyObject *)link) < 0) { + Py_DECREF(link); + return NULL; + } + lru_cache_append_link(self, link); + Py_INCREF(result); /* for return */ + self->full = (PyDict_Size(self->cache) >= self->maxsize); + } + self->misses++; + return result; +} + +static PyObject * +lru_cache_new(PyTypeObject *type, PyObject *args, PyObject *kw) +{ + PyObject *func, *maxsize_O, *cache_info_type; + int typed; + lru_cache_object *obj; + Py_ssize_t maxsize; + PyObject *(*wrapper)(lru_cache_object *, PyObject *, PyObject *); + static char *keywords[] = {"user_function", "maxsize", "typed", + "cache_info_type", NULL}; + + if (!PyArg_ParseTupleAndKeywords(args, kw, "OOpO:lru_cache", keywords, + &func, &maxsize_O, &typed, + &cache_info_type)) { + return NULL; + } + + if (!PyCallable_Check(func)) { + PyErr_SetString(PyExc_TypeError, + "the first argument must be callable"); + return NULL; + } + + /* select the caching function, and make/inc maxsize_O */ + if (maxsize_O == Py_None) { + wrapper = infinite_lru_cache_wrapper; + /* use this only to initialize lru_cache_object attribute maxsize */ + maxsize = -1; + } else if (PyIndex_Check(maxsize_O)) { + maxsize = PyNumber_AsSsize_t(maxsize_O, PyExc_OverflowError); + if (maxsize == -1 && PyErr_Occurred()) + return NULL; + if (maxsize == 0) + wrapper = uncached_lru_cache_wrapper; + else + wrapper = bounded_lru_cache_wrapper; + } else { + PyErr_SetString(PyExc_TypeError, "maxsize should be integer or None"); + return NULL; + } + + obj = (lru_cache_object *)type->tp_alloc(type, 0); + if (obj == NULL) + return NULL; + + if (!(obj->cache = PyDict_New())) { + Py_DECREF(obj); + return NULL; + } + + obj->root.prev = &obj->root; + obj->root.next = &obj->root; + obj->maxsize = maxsize; + Py_INCREF(maxsize_O); + obj->maxsize_O = maxsize_O; + Py_INCREF(func); + obj->func = func; + obj->wrapper = wrapper; + obj->misses = obj->hits = 0; + obj->typed = typed; + Py_INCREF(cache_info_type); + obj->cache_info_type = cache_info_type; + + return (PyObject *)obj; +} + +static lru_list_elem * +lru_cache_unlink_list(lru_cache_object *self) +{ + lru_list_elem *root = &self->root; + lru_list_elem *link = root->next; + if (link == root) + return NULL; + root->prev->next = NULL; + root->next = root->prev = root; + return link; +} + +static void +lru_cache_clear_list(lru_list_elem *link) +{ + while (link != NULL) { + lru_list_elem *next = link->next; + Py_DECREF(link); + link = next; + } +} + +static void +lru_cache_dealloc(lru_cache_object *obj) +{ + lru_list_elem *list = lru_cache_unlink_list(obj); + Py_XDECREF(obj->maxsize_O); + Py_XDECREF(obj->func); + Py_XDECREF(obj->cache); + Py_XDECREF(obj->dict); + Py_XDECREF(obj->cache_info_type); + lru_cache_clear_list(list); + Py_TYPE(obj)->tp_free(obj); +} + +static PyObject * +lru_cache_call(lru_cache_object *self, PyObject *args, PyObject *kwds) +{ + return self->wrapper(self, args, kwds); +} + +static PyObject * +lru_cache_cache_info(lru_cache_object *self, PyObject *unused) +{ + return PyObject_CallFunction(self->cache_info_type, "nnOn", + self->hits, self->misses, self->maxsize_O, + PyDict_Size(self->cache)); +} + +static PyObject * +lru_cache_cache_clear(lru_cache_object *self, PyObject *unused) +{ + lru_list_elem *list = lru_cache_unlink_list(self); + self->hits = self->misses = 0; + self->full = 0; + PyDict_Clear(self->cache); + lru_cache_clear_list(list); + Py_RETURN_NONE; +} + +static int +lru_cache_tp_traverse(lru_cache_object *self, visitproc visit, void *arg) +{ + lru_list_elem *link = self->root.next; + while (link != &self->root) { + lru_list_elem *next = link->next; + Py_VISIT(link); + link = next; + } + Py_VISIT(self->maxsize_O); + Py_VISIT(self->func); + Py_VISIT(self->cache); + Py_VISIT(self->cache_info_type); + Py_VISIT(self->dict); + return 0; +} + +static int +lru_cache_tp_clear(lru_cache_object *self) +{ + lru_list_elem *list = lru_cache_unlink_list(self); + Py_CLEAR(self->maxsize_O); + Py_CLEAR(self->func); + Py_CLEAR(self->cache); + Py_CLEAR(self->cache_info_type); + Py_CLEAR(self->dict); + lru_cache_clear_list(list); + return 0; +} + + +PyDoc_STRVAR(lru_cache_doc, +"Create a cached callable that wraps another function.\n\ +\n\ +user_function: the function being cached\n\ +\n\ +maxsize: 0 for no caching\n\ + None for unlimited cache size\n\ + n for a bounded cache\n\ +\n\ +typed: False cache f(3) and f(3.0) as identical calls\n\ + True cache f(3) and f(3.0) as distinct calls\n\ +\n\ +cache_info_type: namedtuple class with the fields:\n\ + hits misses currsize maxsize\n" +); + +static PyMethodDef lru_cache_methods[] = { + {"cache_info", (PyCFunction)lru_cache_cache_info, METH_NOARGS}, + {"cache_clear", (PyCFunction)lru_cache_cache_clear, METH_NOARGS}, + {NULL} +}; + +static PyGetSetDef lru_cache_getsetlist[] = { + {"__dict__", PyObject_GenericGetDict, PyObject_GenericSetDict}, + {NULL} +}; + +static PyTypeObject lru_cache_type = { + PyVarObject_HEAD_INIT(NULL, 0) + "functools._lru_cache_wrapper", /* tp_name */ + sizeof(lru_cache_object), /* tp_basicsize */ + 0, /* tp_itemsize */ + /* methods */ + (destructor)lru_cache_dealloc, /* tp_dealloc */ + 0, /* tp_print */ + 0, /* tp_getattr */ + 0, /* tp_setattr */ + 0, /* tp_reserved */ + 0, /* tp_repr */ + 0, /* tp_as_number */ + 0, /* tp_as_sequence */ + 0, /* tp_as_mapping */ + 0, /* tp_hash */ + (ternaryfunc)lru_cache_call, /* tp_call */ + 0, /* tp_str */ + 0, /* tp_getattro */ + 0, /* tp_setattro */ + 0, /* tp_as_buffer */ + Py_TPFLAGS_DEFAULT|Py_TPFLAGS_BASETYPE|Py_TPFLAGS_HAVE_GC, + /* tp_flags */ + lru_cache_doc, /* tp_doc */ + (traverseproc)lru_cache_tp_traverse,/* tp_traverse */ + (inquiry)lru_cache_tp_clear, /* tp_clear */ + 0, /* tp_richcompare */ + 0, /* tp_weaklistoffset */ + 0, /* tp_iter */ + 0, /* tp_iternext */ + lru_cache_methods, /* tp_methods */ + 0, /* tp_members */ + lru_cache_getsetlist, /* tp_getset */ + 0, /* tp_base */ + 0, /* tp_dict */ + 0, /* tp_descr_get */ + 0, /* tp_descr_set */ + offsetof(lru_cache_object, dict), /* tp_dictoffset */ + 0, /* tp_init */ + 0, /* tp_alloc */ + lru_cache_new, /* tp_new */ +}; + /* module level code ********************************************************/ PyDoc_STRVAR(module_doc, @@ -602,6 +1135,11 @@ static PyMethodDef module_methods[] = { {NULL, NULL} /* sentinel */ }; +static void +module_free(void *m) +{ + Py_CLEAR(kwd_mark); +} static struct PyModuleDef _functoolsmodule = { PyModuleDef_HEAD_INIT, @@ -612,7 +1150,7 @@ static struct PyModuleDef _functoolsmodu NULL, NULL, NULL, - NULL + module_free, }; PyMODINIT_FUNC @@ -623,6 +1161,7 @@ PyInit__functools(void) char *name; PyTypeObject *typelist[] = { &partial_type, + &lru_cache_type, NULL }; @@ -630,6 +1169,12 @@ PyInit__functools(void) if (m == NULL) return NULL; + kwd_mark = PyObject_CallObject((PyObject *)&PyBaseObject_Type, NULL); + if (!kwd_mark) { + Py_DECREF(m); + return NULL; + } + for (i=0 ; typelist[i] != NULL ; i++) { if (PyType_Ready(typelist[i]) < 0) { Py_DECREF(m); -------------- next part -------------- import functools class A: @property def x(self): pass @property @functools.lru_cache() def y(self): self.x A().y From report at bugs.python.org Sun May 24 09:50:01 2015 From: report at bugs.python.org (Jacob) Date: Sun, 24 May 2015 07:50:01 +0000 Subject: [issue24273] _scproxy.so causes EXC_BAD_ACCESS (SIGSEGV) In-Reply-To: <1432434972.57.0.149064186697.issue24273@psf.upfronthosting.co.za> Message-ID: <1432453801.13.0.973183830823.issue24273@psf.upfronthosting.co.za> Jacob added the comment: Thanks! That does work. I'm concerned there may be unintended or undesired consequences of this. Hope the bug gets fixed, but will use the workaround for now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 09:53:27 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 May 2015 07:53:27 +0000 Subject: [issue24273] _scproxy.so causes EXC_BAD_ACCESS (SIGSEGV) In-Reply-To: <1432434972.57.0.149064186697.issue24273@psf.upfronthosting.co.za> Message-ID: <1432454007.5.0.954760825777.issue24273@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> exception error in _scproxy.so _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 10:36:04 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 24 May 2015 08:36:04 +0000 Subject: [issue17239] XML vulnerabilities in Python In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za> Message-ID: <1432456564.17.0.48474773326.issue17239@psf.upfronthosting.co.za> Changes by Stefan Behnel : ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 10:45:30 2015 From: report at bugs.python.org (Tal Einat) Date: Sun, 24 May 2015 08:45:30 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432457130.12.0.846311498442.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: I'm now working this into a patch against current default. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 11:46:19 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 May 2015 09:46:19 +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: <1432460779.43.0.600510647432.issue13501@psf.upfronthosting.co.za> Martin Panter added the comment: Garrett Cooper: If you are still around, you might want to review the following three changes in this new patch. I suspect they were mistakes in your version, but I cannot be 100 percent sure. * Restoring length - 1 subtraction in call_readline() at line 1239 * Change #if __APPLE__ back to #ifdef * Gnu Readline requires to be included first, so I fixed the configure.ac script Other changes in this new patch: * Merged with current code * Remove outdated comment about using a runtime library check * Couple minor corrections to comments, conditional variable declarations, etc * Fixed wrong HIST_ENTRY pointer type used in a Gnu Readline conditional branch * Changed double single quote sign back to single single quote. I am no Autocrap expert, but it screwed up the generated comment in pyconfig.h.in. * Add ability to include with Tested on Arch Linux with both Gnu Readline 6.3.008 and Editline 20150325-3.1 available: No readline argument: Uses Gnu Readline --with-readline=editline: Uses Editline --with-readline=readline: Gnu Readline --with-readline=yes: Gnu Readline --with-readline: Gnu Readline --with-readline=no: No ?readline? module --without-readline: No ?readline? module --without-readline=no: error: invalid package name: readline=no However after successfully compiling with Editline, there are a couple bugs with keystrokes or output not being synchronized. I do not think I will spent much more effort on it. But perhaps other people are interested in taking this further. ---------- components: +Extension Modules -Library (Lib) nosy: +vadmium stage: patch review -> needs patch versions: +Python 3.6 -Python 3.3 Added file: http://bugs.python.org/file39480/editline.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 11:47:31 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 May 2015 09:47:31 +0000 Subject: [issue18459] readline: libedit support on non-apple platforms In-Reply-To: <1373891820.19.0.984276620623.issue18459@psf.upfronthosting.co.za> Message-ID: <1432460851.66.0.897343724837.issue18459@psf.upfronthosting.co.za> Martin Panter added the comment: There was already a potential patch in Issue 13501. ---------- nosy: +vadmium resolution: -> duplicate superseder: -> Make libedit support more generic; port readline / libedit to FreeBSD _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 11:54:16 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 May 2015 09:54:16 +0000 Subject: [issue18459] readline: libedit support on non-apple platforms In-Reply-To: <1373891820.19.0.984276620623.issue18459@psf.upfronthosting.co.za> Message-ID: <1432461256.04.0.738258962466.issue18459@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 12:05:37 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 May 2015 10:05:37 +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: <1432461937.77.0.413036135018.issue24266@psf.upfronthosting.co.za> Martin Panter added the comment: I suspect this is actually a bug with Gnu Readline. The same issue exists in GDB. When a signal handler (such as SIGINT) raises an exception to abort the input, Python calls rl_free_line_state(). The documentation for that function, says Readline?s own SIGINT handler (which Python doesn?t normally actually use) also calls it to abort the current line. It lists various states that are ?freed?. Although the search state is not in the list, it seems like it should be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 13:05:22 2015 From: report at bugs.python.org (Tal Einat) Date: Sun, 24 May 2015 11:05:22 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432465522.83.0.525955931664.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: Attached is a patch based on Chris Barker's implementation on github[1]. This includes only the C implementation, as well as tests, documentation and entries in NEWS and whatsnew. I had to keep the (PyCFunction) cast in the module method list in Modules/mathmodule.c. That part should certainly be reviewed. As for documentation etc., I took the best wording I could find from the PEP and the docs in the github repo, and made very slight changes only where I though they made things significantly clearer. .. [1]: https://github.com/PythonCHB/close_pep ---------- keywords: +patch Added file: http://bugs.python.org/file39481/math_isclose.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 13:47:37 2015 From: report at bugs.python.org (Mark Daoust) Date: Sun, 24 May 2015 11:47:37 +0000 Subject: [issue23965] test_ssl failure on Fedora 22 In-Reply-To: <1429109042.15.0.0394513301498.issue23965@psf.upfronthosting.co.za> Message-ID: <1432468057.87.0.970693302783.issue23965@psf.upfronthosting.co.za> Mark Daoust added the comment: I think I might have found a related/real world example. I'm on a mac with OSX-10.10.3 and "test_ssl" passes, but when I try to install jupyter_notebook it attempts to download some css, and gives what looks like an identical error to the first one, in the initial report (test_protocol_sslv23). The download works fine in 2.7 and 3.4: >>> sys.version '3.5.0a4 (v3.5.0a4:413e0e0004f4, Apr 19 2015, 14:19:25) \n[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]' >>> ssl.OPENSSL_VERSION 'OpenSSL 0.9.8zd 8 Jan 2015' >>> urllib.request.urlopen("https://cdn.jupyter.org/notebook/4.0.0-dev/style/style.min.css") Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/urllib/request.py", line 1239, in do_open h.request(req.get_method(), req.selector, req.data, headers) File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/http/client.py", line 1083, in request self._send_request(method, url, body, headers) File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/http/client.py", line 1128, in _send_request self.endheaders(body) File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/http/client.py", line 1079, in endheaders self._send_output(message_body) File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/http/client.py", line 911, in _send_output self.send(msg) File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/http/client.py", line 854, in send self.connect() File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/http/client.py", line 1237, in connect server_hostname=server_hostname) File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/ssl.py", line 376, in wrap_socket _context=self) File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/ssl.py", line 747, in __init__ self.do_handshake() File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/ssl.py", line 983, in do_handshake self._sslobj.do_handshake() File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/ssl.py", line 628, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:634) ---------- nosy: +suki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 13:57:35 2015 From: report at bugs.python.org (Jackmoo) Date: Sun, 24 May 2015 11:57:35 +0000 Subject: [issue11029] Crash, 2.7.1, Tkinter and threads and line drawing In-Reply-To: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za> Message-ID: <1432468655.17.0.675376900407.issue11029@psf.upfronthosting.co.za> Jackmoo added the comment: Hi there, recently I also encounter this in windows(7), and my python program occasionally crash and the windows pops 'appcrash' message with tcl8.5.dll error c000005 (access violation). And this end up related to thread safe problem described as above. Since in my program, I have to build the tkinter UI in another thread (main thread was occupied by other module which blocking), so I can't follow the 'build UI in main thread' solution. My work around is, add a handler which using .after() and get_nowait() to call itself periodically to handle the command in queue. def commandQueueHandler(self): try: while 1: your_command = self.textCommandQueue.get_nowait() if your_command is not None: # execute the command .... self.Text.update_idletasks() except Queue.Empty: pass self.Text.after(100, self.commandQueueHandler) Once this method is triggered, just build another thread to put() command in textCommandQueue, then it will be executed periodically. One thing that should mention is the update_idletasks() should be added after each command execution, otherwise the UI refresh will be slower then expected. (in my case, the scrolling of Text widge is a bit 'sticky' when I pull it. After adding update_idletasks(), it becomes smoother.) TL:DR, If you have to run tkinter UI in another thread, add a queue and self-called method with after() and get_nowait() in UI thread to handle the queue. If you want to send command to UI at other thread, just put() the command in the queue of UI thread. ---------- nosy: +Jackmoo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 14:41:57 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 24 May 2015 12:41:57 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432471317.17.0.217806224302.issue24270@psf.upfronthosting.co.za> Stefan Behnel added the comment: The cast is correct and required (the actual signature is determined by the METH_* flags). Patch LGTM, FWIW. ---------- components: +Library (Lib) nosy: +scoder type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 15:11:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 May 2015 13:11:49 +0000 Subject: [issue24276] Correct reuse argument tuple in property descriptor Message-ID: <1432473109.86.0.717855032887.issue24276@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Property descriptor getter uses cached tuple for args (issue23910). This can cause problems when called function use args after reading other property or save args. For now I know only one example - clru_cache_3.patch in issue14373. Proposed patch use cached tuple in more robust manner. ---------- components: Interpreter Core files: property_cached_args.patch keywords: patch messages: 243980 nosy: barry, eric.smith, eric.snow, llllllllll, python-dev, rhettinger, serhiy.storchaka priority: high severity: normal stage: patch review status: open title: Correct reuse argument tuple in property descriptor type: crash versions: Python 3.5 Added file: http://bugs.python.org/file39482/property_cached_args.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 15:12:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 May 2015 13:12:40 +0000 Subject: [issue23910] property_descr_get reuse argument tuple In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1432473160.36.0.667607196058.issue23910@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This patch caused crash with C implementation of lru_cache (issue14373). Opened issue24276 for fixing this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 15:18:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 May 2015 13:18:47 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1432473527.13.0.89675971569.issue14373@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The problem is in property descriptor getter. It uses cached tuple for args and can unexpectedly modify it. Opened issue24276 for fixing this bug. Another way is to remove fast path in lru_cache_make_key() and always copy args tuple. ---------- Added file: http://bugs.python.org/file39483/clru_cache_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 15:26:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 May 2015 13:26:31 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1432473991.02.0.948313450642.issue14373@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Correct reuse argument tuple in property descriptor _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 15:30:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 May 2015 13:30:32 +0000 Subject: [issue24276] Correct reuse argument tuple in property descriptor In-Reply-To: <1432473109.86.0.717855032887.issue24276@psf.upfronthosting.co.za> Message-ID: <1432474232.66.0.0406367358345.issue24276@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Affect on performance: $ ./python -m timeit -r 11 -s "from collections import namedtuple as n;a = n('n', 'a b c')(1, 2, 3)" Unpatched: 10000000 loops, best of 11: 0.0567 usec per loop Patched : 10000000 loops, best of 11: 0.0567 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 15:42:34 2015 From: report at bugs.python.org (Tal Einat) Date: Sun, 24 May 2015 13:42:34 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432474954.14.0.517672431145.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: I have a question regarding complex values. The code (from Chris Barker) doesn't support complex values (only things that can be converted into doubles). However, the PEP states the following under "Non-float types": "complex : for complex, the absolute value of the complex values will be used for scaling and comparison. If a complex tolerance is passed in, the absolute value will be used as the tolerance." Should math.isclose() support complex values? Should an equivalent function be added to cmath? Should we just leave things as they are and remove mention of complex values from the PEP (it isn't mentioned in the docs)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 15:45:37 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 24 May 2015 13:45:37 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432475137.97.0.262405757487.issue24270@psf.upfronthosting.co.za> Stefan Behnel added the comment: Eventually, I think a corresponding function should be added to cmath. math.isclose() shouldn't deal with complex values by itself (other than rejecting them as non-floatish input). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 15:49:05 2015 From: report at bugs.python.org (Tal Einat) Date: Sun, 24 May 2015 13:49:05 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432475345.34.0.230538273916.issue24270@psf.upfronthosting.co.za> Changes by Tal Einat : ---------- nosy: +mark.dickinson, rhettinger, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 16:10:33 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 24 May 2015 14:10:33 +0000 Subject: [issue24277] Take the new email package features out of provisional status Message-ID: <1432476633.37.0.892331041879.issue24277@psf.upfronthosting.co.za> New submission from R. David Murray: I plan to remove the provisional status of the new email features in 3.5. This is a documentation only change, but the documentation change is extensive (pretty much a complete rewrite of the package docs). ---------- assignee: r.david.murray components: Documentation messages: 243986 nosy: r.david.murray priority: normal severity: normal stage: needs patch status: open title: Take the new email package features out of provisional status type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 17:27:38 2015 From: report at bugs.python.org (Martin Blais) Date: Sun, 24 May 2015 15:27:38 +0000 Subject: [issue24278] Docs on Parsing arguments should say something about mem mgmt for formatters returning C strings Message-ID: <1432481258.46.0.49462668629.issue24278@psf.upfronthosting.co.za> New submission from Martin Blais: Functions that parse arguments like PyArg_ParseTupleAndKeywords() have several formatters that fill in C strings, e.g. "s". In the C API doc: https://docs.python.org/3.5/c-api/arg.html#c.PyArg_ParseTupleAndKeywords There should be an explicit mention of whether this memory needs to be free (in this case: No) and if not, how this memory is managed (in this case: This refers to a buffer managed by the string object itself). Because of questions of encoding, it raises questions where this memory lies, and what its lifetime is (in this case: That of the owning string object from the caller). This deserves an explicit mention, even if brief. ---------- assignee: docs at python components: Documentation messages: 243987 nosy: blais, docs at python priority: normal severity: normal status: open title: Docs on Parsing arguments should say something about mem mgmt for formatters returning C strings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 17:31:13 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 24 May 2015 15:31:13 +0000 Subject: [issue11029] Crash, 2.7.1, Tkinter and threads and line drawing In-Reply-To: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za> Message-ID: <1432481473.25.0.877765880303.issue11029@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks for the report. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 17:35:55 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 24 May 2015 15:35:55 +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: <1432481755.98.0.169533819705.issue24278@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Would you propose a patch for docs? ---------- nosy: +asvetlov stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 18:07:56 2015 From: report at bugs.python.org (Martin Blais) Date: Sun, 24 May 2015 16:07:56 +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: <1432483676.1.0.622223022423.issue24278@psf.upfronthosting.co.za> Martin Blais added the comment: I don't think I'm the right person to propose a patch for this; I'm just guessing how it works so far, I haven't had time to look into the source code in detail, I'm sure there's a lot more context to it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 18:41:34 2015 From: report at bugs.python.org (Evgeny Kapun) Date: Sun, 24 May 2015 16:41:34 +0000 Subject: [issue24260] TabError behavior doesn't match documentation In-Reply-To: <1432244751.77.0.187754601995.issue24260@psf.upfronthosting.co.za> Message-ID: <1432485694.35.0.0829751691726.issue24260@psf.upfronthosting.co.za> Evgeny Kapun added the comment: Prohibiting tabs after spaces is not enough. For example, Python rejects this code: if 1: if 1: pass because its indentation is invalid if tab width is 1. However, it accepts this code: if 1: if 1: <10 spaces>pass despite its indentation being invalid if tab width is 10 or more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 18:53:30 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 May 2015 16:53:30 +0000 Subject: [issue24276] Correct reuse argument tuple in property descriptor In-Reply-To: <1432473109.86.0.717855032887.issue24276@psf.upfronthosting.co.za> Message-ID: <1432486410.35.0.873956462106.issue24276@psf.upfronthosting.co.za> Raymond Hettinger added the comment: LGTM, go ahead and apply. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 19:15:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 May 2015 17:15:39 +0000 Subject: [issue24276] Correct reuse argument tuple in property descriptor In-Reply-To: <1432473109.86.0.717855032887.issue24276@psf.upfronthosting.co.za> Message-ID: <1432487739.92.0.708626472117.issue24276@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, it was incorrect microbenchmark. Correct is: $ ./python -m timeit -r 11 -s "from collections import namedtuple as n;a = n('n', 'a b c')(1, 2, 3)" -- "a.a" 3.4 : 1000000 loops, best of 11: 0.601 usec per loop 3.5 unpatched: 1000000 loops, best of 11: 0.445 usec per loop 3.5 patched : 1000000 loops, best of 11: 0.454 usec per loop There is small slowdown (2%), but it is only small part of the gain of the optimization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 19:54:48 2015 From: report at bugs.python.org (Zachary Ware) Date: Sun, 24 May 2015 17:54:48 +0000 Subject: [issue23903] Generate PC/python3.def by scraping headers In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za> Message-ID: <1432490088.57.0.429500772336.issue23903@psf.upfronthosting.co.za> Zachary Ware added the comment: What about including this in Tools/scripts/patchcheck.py? I think that might strike a good enough balance between making changes noticeable and not automatically changing the def file. As far as all the differences this has uncovered, I'll try to make a patch to #ifdef them in/out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 20:27:10 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 24 May 2015 18:27:10 +0000 Subject: [issue24260] TabError behavior doesn't match documentation In-Reply-To: <1432244751.77.0.187754601995.issue24260@psf.upfronthosting.co.za> Message-ID: <1432492030.5.0.681426513825.issue24260@psf.upfronthosting.co.za> R. David Murray added the comment: We should probably just introduce a new error mode (-ttt?) that makes it an error to use tabs at all for semantic indentation. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 20:30:48 2015 From: report at bugs.python.org (Daniel Andrade Groppe) Date: Sun, 24 May 2015 18:30:48 +0000 Subject: [issue24272] PEP 484 docs In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za> Message-ID: <1432492248.25.0.787140968179.issue24272@psf.upfronthosting.co.za> Daniel Andrade Groppe added the comment: A first iteration of the documentation based on the PEP and the module source. This still needs a lot of work. ---------- keywords: +patch nosy: +Daniel.Andrade.Groppe Added file: http://bugs.python.org/file39484/typing_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 20:31:34 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 24 May 2015 18:31:34 +0000 Subject: [issue23903] Generate PC/python3.def by scraping headers In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za> Message-ID: <1432492294.13.0.0534221700361.issue23903@psf.upfronthosting.co.za> Steve Dower added the comment: Could the latter break people already using the stable ABI on other platforms? Does it even work for others? I don't know what the equivalent of python3.dll would be. If it doesn't exist outside of Windows, then assuming that everything not in python3.def isn't stable is fine. Otherwise I think we need to go the other way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 20:38:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 May 2015 18:38:44 +0000 Subject: [issue24276] Correct reuse argument tuple in property descriptor In-Reply-To: <1432473109.86.0.717855032887.issue24276@psf.upfronthosting.co.za> Message-ID: <20150524183841.126974.28380@psf.io> Roundup Robot added the comment: New changeset 5dbf3d932a59 by Serhiy Storchaka in branch 'default': Issue #24276: Fixed optimization of property descriptor getter. https://hg.python.org/cpython/rev/5dbf3d932a59 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 22:13:11 2015 From: report at bugs.python.org (Christie) Date: Sun, 24 May 2015 20:13:11 +0000 Subject: [issue24279] Update test_base64 to use test.support.script_helper Message-ID: <1432498391.21.0.154907178378.issue24279@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_base64.py to use script_helpers.py. ---------- messages: 243999 nosy: bobcatfish priority: normal severity: normal status: open title: Update test_base64 to use test.support.script_helper versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 22:16:57 2015 From: report at bugs.python.org (Christie) Date: Sun, 24 May 2015 20:16:57 +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: <1432498617.1.0.538166320404.issue24279@psf.upfronthosting.co.za> Christie added the comment: Updated TestMain in test_base64 to use test.support.script_helpers. Split `test_encode_file` into two tests. ---------- keywords: +patch Added file: http://bugs.python.org/file39485/issue24279_base64.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 22:17:46 2015 From: report at bugs.python.org (Christie) Date: Sun, 24 May 2015 20:17:46 +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: <1432498666.46.0.690008271527.issue9517@psf.upfronthosting.co.za> Christie added the comment: Created Issue24279 for updating test_base64. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 22:32:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 May 2015 20:32:03 +0000 Subject: [issue24276] Correct reuse argument tuple in property descriptor In-Reply-To: <1432473109.86.0.717855032887.issue24276@psf.upfronthosting.co.za> Message-ID: <1432499523.66.0.191457395586.issue24276@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 May 24 22:33:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 May 2015 20:33:07 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1432499587.6.0.0539602226384.issue14373@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Backed out the backout in cb30db9cc029. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 23:38:54 2015 From: report at bugs.python.org (Jeff Ding) Date: Sun, 24 May 2015 21:38:54 +0000 Subject: [issue24280] Unable to install Python Message-ID: <1432503534.56.0.662288156195.issue24280@psf.upfronthosting.co.za> New submission from Jeff Ding: After uninstalling old versions of Python: Python is unable to install unless I disable pip. Once python installs, python immediately crashes due to Py_Initialize ---------- components: Windows files: python_crash.png messages: 244003 nosy: Jeff77789, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Unable to install Python type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39486/python_crash.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 24 23:59:37 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 24 May 2015 21:59:37 +0000 Subject: [issue23965] test_ssl failure on Fedora 22 In-Reply-To: <1429109042.15.0.0394513301498.issue23965@psf.upfronthosting.co.za> Message-ID: <1432504777.87.0.256305227346.issue23965@psf.upfronthosting.co.za> Ned Deily added the comment: (@suki, I assume this is the issue reported here: https://github.com/jupyter/notebook/issues/111 ?) ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 00:03:49 2015 From: report at bugs.python.org (Matthew Barnett) Date: Sun, 24 May 2015 22:03:49 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432505029.79.0.553966520901.issue16991@psf.upfronthosting.co.za> Matthew Barnett added the comment: First some background: when you put a new entry into a dict, it looks for an empty slot, the key's hash determining the initial choice, but if that slot's occupied, it picks another, etc, so the key might not be in the slot of first choice. In "PyODict_DelItem", it deletes the key from the dict and then calls "_odict_clear_node" to delete the node. If the key that it's looking for wasn't in the slot of first choice, but that slot is empty, that'll be the one it'll return, ie, the wrong one. The solution, therefore, is to delete the node _before_ deleting the key from the dict. When I tried that, the test ran to completion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 00:40:22 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 May 2015 22:40:22 +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: <1432507222.22.0.193457881846.issue24278@psf.upfronthosting.co.za> Martin Panter added the comment: At the top of the list , it says which cases have to be freed or not, and also mentions releasing buffers. Are you proposing to add this information to each entry in the list as well? Or just mention how the pointer lifetime relates to the Python object lifetime at the top? I think you will find most of the cases are the same, except for the ones that explicitly allocate extra memory. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 01:27:49 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 May 2015 23:27:49 +0000 Subject: [issue24260] TabError behavior doesn't match documentation In-Reply-To: <1432244751.77.0.187754601995.issue24260@psf.upfronthosting.co.za> Message-ID: <1432510069.79.0.103932821529.issue24260@psf.upfronthosting.co.za> Martin Panter added the comment: I would be in favour of making the existing indentation behaviour more strict by default, or at least outputting some sort of warning for Evgeny?s examples. I.e. no reason to supply a special -ttt option. But prohibiting tabs entirely might not go down well. I never use tabs in my own code, but I wouldn?t want to convert other people?s code to spaces just to run it in a future Python release, especially when the tab usage is universal. I don?t exactly know Python?s rules for intentation, but my model for ?consistent indentation? would work something like: * Remember the exact sequence of spaces and tabs for each level of indentation * Ignore blank and commented lines, even if their indentation is inconsistent * If a line begins with the highest level of indentation, but continues with more spaces or tabs, it starts a new indentation level * If a line?s indentation exactly matches any of the saved sequences, it jumps back to that level (or stays at the highest level) * Otherwise, the indentation is inconsistent, and it should be an error or warning Yet another option could be to say indentation is allowed to be only tabs or only spaces, and the use of tabs or spaces must match the rest of the file, or at least the rest of the indented block. But I still prefer my model above :) ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 01:36:15 2015 From: report at bugs.python.org (Matthias Bussonnier) Date: Sun, 24 May 2015 23:36:15 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432510575.59.0.605854932086.issue24268@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: Hi, Since the last few patches related to this, I seem to have an issue with `Python/importdl.c:get_encoded_name` (I guess) sometime returning the name with a leading dot. This lead to `PyInit_.modulename` being searched which fails. My C-foo is extremely low, but changing [1] to `lastdot+1` seem to do the trick for me (hence above supposition). More especially in my case compiling Cython `failed to import Cython: dynamic module does not define module export function (PyInit_.Scanning)`, from `import Cython.Compiler.Scanning` I suppose. While it seem to does that ok with the `+1`. I haven't found any related issues, and my read of pep 489 made me think this was not meant to change, Though I doubt my fix is correct. Sorry if duplicate or already fixed, I searched as I could but did not found anything. Thanks. [1] https://hg.python.org/cpython/rev/e729b946cc03#l29.59 ---------- nosy: +mbussonn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 01:37:51 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 24 May 2015 23:37:51 +0000 Subject: [issue24260] TabError behavior doesn't match documentation In-Reply-To: <1432244751.77.0.187754601995.issue24260@psf.upfronthosting.co.za> Message-ID: <1432510671.82.0.304708924133.issue24260@psf.upfronthosting.co.za> Mark Lawrence added the comment: So when does Python 3 generate this "TabError: inconsistent use of tabs and spaces in indentation" and when doesn't it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 05:47:04 2015 From: report at bugs.python.org (Daniel Andrade Groppe) Date: Mon, 25 May 2015 03:47:04 +0000 Subject: [issue24272] PEP 484 docs In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za> Message-ID: <1432525624.44.0.241771403449.issue24272@psf.upfronthosting.co.za> Daniel Andrade Groppe added the comment: Addressing comments from the review. Here is an updated patch. ---------- Added file: http://bugs.python.org/file39487/typing_doc_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 05:47:41 2015 From: report at bugs.python.org (James Luscher) Date: Mon, 25 May 2015 03:47:41 +0000 Subject: [issue24281] String formatting: incorrect number of decimal places Message-ID: <1432525661.76.0.778289488929.issue24281@psf.upfronthosting.co.za> New submission from James Luscher: Doc for 3.4: at 6.1.3.1. Format Specification Mini-Language indicates that: "The precision is a decimal number indicating how many digits should be displayed after the decimal point for a floating point value" Yet I find that I get this behavior: 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. >>> '{:08.3}'.format(12.34) '000012.3' When what I am expecting is: '0012.340' ---------- assignee: docs at python components: Documentation messages: 244011 nosy: docs at python, jluscher priority: normal severity: normal status: open title: String formatting: incorrect number of decimal places type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 05:53:51 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 25 May 2015 03:53:51 +0000 Subject: [issue24281] String formatting: incorrect number of decimal places In-Reply-To: <1432525661.76.0.778289488929.issue24281@psf.upfronthosting.co.za> Message-ID: <1432526031.1.0.231121410177.issue24281@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 06:02:58 2015 From: report at bugs.python.org (Christopher Welborn) Date: Mon, 25 May 2015 04:02:58 +0000 Subject: [issue24281] String formatting: incorrect number of decimal places In-Reply-To: <1432525661.76.0.778289488929.issue24281@psf.upfronthosting.co.za> Message-ID: <1432526578.0.0.445211038392.issue24281@psf.upfronthosting.co.za> Christopher Welborn added the comment: You forgot the 'f' to specify that you want float formatting: ``` >>> '{:08.3f}'.format(12.34) '0012.340' ``` ---------- nosy: +cjwelborn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 06:22:09 2015 From: report at bugs.python.org (Daniel Andrade Groppe) Date: Mon, 25 May 2015 04:22:09 +0000 Subject: [issue24021] Add docstring to urllib.urlretrieve In-Reply-To: <1429673026.41.0.442066158913.issue24021@psf.upfronthosting.co.za> Message-ID: <1432527729.36.0.891629883783.issue24021@psf.upfronthosting.co.za> Daniel Andrade Groppe added the comment: Adding docstrings for urllib.urlretrieve() and urlib.cleanup() for Python 2.7. ---------- keywords: +patch nosy: +Daniel.Andrade.Groppe Added file: http://bugs.python.org/file39488/urllib_2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 06:27:09 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 May 2015 04:27:09 +0000 Subject: [issue24281] String formatting: incorrect number of decimal places In-Reply-To: <1432525661.76.0.778289488929.issue24281@psf.upfronthosting.co.za> Message-ID: <1432528029.15.0.406865030032.issue24281@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 06:31:18 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 25 May 2015 04:31:18 +0000 Subject: [issue24275] lookdict_* give up too soon In-Reply-To: <1432444109.96.0.971324850141.issue24275@psf.upfronthosting.co.za> Message-ID: <1432528278.18.0.914948252776.issue24275@psf.upfronthosting.co.za> Benjamin Peterson added the comment: You could have a non-unicode key that compares equal to a unicode string. ---------- nosy: +benjamin.peterson resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 07:25:12 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Mon, 25 May 2015 05:25:12 +0000 Subject: [issue5315] signal handler never gets called In-Reply-To: <1235051228.14.0.0909837566577.issue5315@psf.upfronthosting.co.za> Message-ID: <1432531512.2.0.671066613974.issue5315@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: Agree with Charles-Fran?ois's second explanation. This makes it very hard to reliably handle signals -- basically everyone has to remember to use set_wakeup_fd, and most people don't. For example, gunicorn is likely vulnerable to this because it doesn't use set_wakeup_fd. I suspect most code using select + signals is wrong. I've attached a patch which fixes the issue for select(), but not any other functions. If it's considered a good patch, I can work on the rest of the functions in the select module. (Also, tests for the details of the behavior.) Also the patch is pretty hokey, so I'd appreciate feedback if it's going to go in. :) ---------- keywords: +patch nosy: +Devin Jeanpierre Added file: http://bugs.python.org/file39489/select_select.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 09:28:45 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 May 2015 07:28:45 +0000 Subject: [issue22350] nntplib file write failure causes exception from QUIT command In-Reply-To: <1410061219.03.0.0230581897355.issue22350@psf.upfronthosting.co.za> Message-ID: <1432538925.77.0.116646998626.issue22350@psf.upfronthosting.co.za> Martin Panter added the comment: For the record, the SMTP scenario was Issue 17498, where code that is about to raise an exception attempts an RSET command that could also fail. I do think each change in my patch is essentially the same case: restoring the invariant expected by the __exit__() method, that either the protocol state allows QUIT, or there is no connection. But I agree it may help divide this into smaller pieces. I am uploading getlongresp-loop.patch, which fixes just the receiving loop in _getlongresp(). I have also added some logic to avoid errors raised when flushing and closing the socket do not mask the original exception, which I understand David was concerned about. I guess it is possible (though unlikely) that an EPIPE or ECONNRESET flushing the send buffer could mask a KeyboardInterrupt raised inside the loop. Sorry I took a while to follow up on this, but please have a look and let me know if this simplified patch makes any sense. ---------- Added file: http://bugs.python.org/file39490/getlongresp-loop.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 09:30:57 2015 From: report at bugs.python.org (Jyrki Wahlstedt) Date: Mon, 25 May 2015 07:30:57 +0000 Subject: [issue24282] 3.5 gdbm extension build fails with "'clinic/_gdbmmodule.c.h' file not found" Message-ID: <1432539057.02.0.42349410577.issue24282@psf.upfronthosting.co.za> New submission from Jyrki Wahlstedt: On OS X (with MacPorts) the following happens: === DEBUG: Environment: CC='/usr/bin/clang' CC_PRINT_OPTIONS='YES' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Users_jwa_work_macports-trunk_dports_python_py-gdbm/py35-gdbm/work/.CC_PRINT_OPTIONS' CFLAGS='-arch x86_64' CPATH='/opt/local/include' CXX='/usr/bin/clang++' CXXFLAGS='-arch x86_64' F90FLAGS='-m64' FCFLAGS='-m64' FFLAGS='-m64' LDFLAGS='-arch x86_64' LIBRARY_PATH='/opt/local/lib' MACOSX_DEPLOYMENT_TARGET='10.10' OBJC='/usr/bin/clang' OBJCFLAGS='-arch x86_64' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_Users_jwa_work_macports-trunk_dports_python_py-gdbm/py35-gdbm/work/Python-3.5.0b1/Modules" && /opt/local/Library/Frameworks/Python.framework/Versions/3.5/bin/python3.5 setup.py --no-user-cfg build' DEBUG: Executing command line: cd "/opt/local/var/macports/build/_Users_jwa_work_macports-trunk_dports_python_py-gdbm/py35-gdbm/work/Python-3.5.0b1/Modules" && /opt/local/Library/Frameworks/Python.framework/Versions/3.5/bin/python3.5 setup.py --no-user-cfg build running build running build_ext building '_gdbm' extension creating build creating build/temp.macosx-10.10-x86_64-3.5 /usr/bin/clang -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -arch x86_64 -I/opt/local/include -I/opt/local/Library/Frameworks/Python.framework/Versions/3.5/include/python3.5m -c _gdbmmodule.c -o build/temp.macosx-10.10-x86_64-3.5/_gdbmmodule.o _gdbmmodule.c:45:10: fatal error: 'clinic/_gdbmmodule.c.h' file not found #include "clinic/_gdbmmodule.c.h" ^ 1 error generated. error: command '/usr/bin/clang' failed with exit status 1 === ---------- components: Extension Modules messages: 244017 nosy: jwa priority: normal severity: normal status: open title: 3.5 gdbm extension build fails with "'clinic/_gdbmmodule.c.h' file not found" type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 09:36:52 2015 From: report at bugs.python.org (Jyrki Wahlstedt) Date: Mon, 25 May 2015 07:36:52 +0000 Subject: [issue24282] 3.5 gdbm extension build fails with "'clinic/_gdbmmodule.c.h' file not found" In-Reply-To: <1432539057.02.0.42349410577.issue24282@psf.upfronthosting.co.za> Message-ID: <1432539412.8.0.4840529303.issue24282@psf.upfronthosting.co.za> Jyrki Wahlstedt added the comment: This worked ok in a3? (not in a4 anymore) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 10:31:44 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Mon, 25 May 2015 08:31:44 +0000 Subject: [issue5315] signal handler never gets called In-Reply-To: <1235051228.14.0.0909837566577.issue5315@psf.upfronthosting.co.za> Message-ID: <1432542704.72.0.569015057829.issue5315@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: Adding haypo since apparently he's been touching signals stuff a lot lately, maybe has some useful thoughts / review? :) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 10:37:41 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Mon, 25 May 2015 08:37:41 +0000 Subject: [issue24283] Print not safe in signal handlers Message-ID: <1432543061.46.0.0919733214048.issue24283@psf.upfronthosting.co.za> New submission from Devin Jeanpierre: The code attached runs a while loop that prints, and has a signal handler that also prints. There is a thread that constantly fires off signals, but this is just to ensure the condition for the bug happens -- this is a bug with signal handling, not threads -- I can trigger a RuntimeError (... with a missing message?) by commenting out the threading lines and instead running a separate process "while true; do kill -s SIGUSR1 4687; done". Traceback: $ python3 threading_print_test.py hello world Traceback (most recent call last): File "/usr/local/google/home/devinj/Downloads/threading_print_test.py", line 36, in main() File "/usr/local/google/home/devinj/Downloads/threading_print_test.py", line 30, in main print("world") File "/usr/local/google/home/devinj/Downloads/threading_print_test.py", line 13, in print_hello print("hello") RuntimeError: reentrant call inside <_io.BufferedWriter name=''> ---------- files: threading_print_test.py messages: 244020 nosy: Devin Jeanpierre, haypo priority: normal severity: normal status: open title: Print not safe in signal handlers Added file: http://bugs.python.org/file39491/threading_print_test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 11:04:39 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 May 2015 09:04:39 +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: <1432544679.3.0.321384809601.issue23237@psf.upfronthosting.co.za> Martin Panter added the comment: I left a couple comments on Reitveld. The main question is: is there any reason why we can?t poll PyErr_CheckSignals() directly the tkinter EventHook loop, rather than juggling a new SIGINT handler then reraising it? That way we might trigger other Python signal handlers properly as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 11:27:00 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 25 May 2015 09:27:00 +0000 Subject: [issue24282] 3.5 gdbm extension build fails with "'clinic/_gdbmmodule.c.h' file not found" In-Reply-To: <1432539057.02.0.42349410577.issue24282@psf.upfronthosting.co.za> Message-ID: <1432546020.31.0.0131179381141.issue24282@psf.upfronthosting.co.za> Ned Deily added the comment: The problem you are seeing is due to MacPort's non-standard method of building the gdbm module separately in a stand-alone build instead of during the normal building of the complete Python standard library. As of 3.5.0a4 with 49910ff21ba5 for Issue20184, Modules/_gdbmmodule.c was converted to use the Argument Clinic DSL feature (PEP 436). For each converted .c module in Modules, Argument Clinic creates a corresponding new header file in the clinic subdirectory, in this case, Modules/clinic/_gdbmmodule.c.h. I believe you will need to modify the py3x-gdbm portfiles to also extract the contents of Modules/clinic into the build source directory. Note, you may need to do this for any other similar portfiles. ---------- nosy: +ned.deily resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 11:30:17 2015 From: report at bugs.python.org (Jyrki Wahlstedt) Date: Mon, 25 May 2015 09:30:17 +0000 Subject: [issue24282] 3.5 gdbm extension build fails with "'clinic/_gdbmmodule.c.h' file not found" In-Reply-To: <1432539057.02.0.42349410577.issue24282@psf.upfronthosting.co.za> Message-ID: <1432546217.66.0.994338384395.issue24282@psf.upfronthosting.co.za> Jyrki Wahlstedt added the comment: Thanks for the quick follow-up! I'll get the work done at our end:) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 11:50:23 2015 From: report at bugs.python.org (Mark Shannon) Date: Mon, 25 May 2015 09:50:23 +0000 Subject: [issue24275] lookdict_* give up too soon In-Reply-To: <1432444109.96.0.971324850141.issue24275@psf.upfronthosting.co.za> Message-ID: <1432547423.06.0.373406595769.issue24275@psf.upfronthosting.co.za> Mark Shannon added the comment: I don't understand why this has been closed. I agree with Jim's analysis. Lookups do not change the dict and the choice of lookdict_* variant depends solely on the set of keys. In fact, lookdict_split *doesn't* replace itself, it merely calls look_dict, leaving maintaining the invariant to insertdict. Benjamin, could you please reopen this and mark it as needing a patch. ---------- nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 12:05:00 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 25 May 2015 10:05:00 +0000 Subject: [issue23969] please set a SOABI for MacOSX In-Reply-To: <1429125133.46.0.136772675069.issue23969@psf.upfronthosting.co.za> Message-ID: <1432548300.54.0.0403566384365.issue23969@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Ned: Keeping "darwin" as the platform tag is fine with me. It is slightly ugly because it doesn't match the platform tag used by distutils/setuptools, but is also something that most users won't use directly. That said: there was some talk about supporting iOS on python-ideas a while back, and using "darwin" as the platform tag for both would mean that you couldn't have a tree with extensions for both at the same time (assuming you can have extensions on iOS in the first place, I haven't kept track about the possibilities for shared libraries on iOS and it wasn't possible in the past) The suffix change would be nice to have, but I haven't thought about the implications for 3th-party tools at all. I agree that this could cause problems for them, and that's not worth the very minor improvement in nameing. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 12:09:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 May 2015 10:09:46 +0000 Subject: [issue24275] lookdict_* give up too soon In-Reply-To: <1432444109.96.0.971324850141.issue24275@psf.upfronthosting.co.za> Message-ID: <1432548586.27.0.739748792209.issue24275@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is not obvious that the patch is needed. If you have ready patch and good benchmark results, you could reopen the issue. Otherwise status quo wins. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 13:41:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 May 2015 11:41:27 +0000 Subject: [issue24284] Inconsistency in startswith/endswith Message-ID: <1432554087.61.0.0896292215981.issue24284@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The behavior of startswith in corner case is inconsistent between str and bytes in Python 3, str and unicode in Python 2, and between str in Python 2 and Python 3. Python 3: >>> ''.startswith('', 1, 0) True >>> b''.startswith(b'', 1, 0) False Python 2: >>> ''.startswith('', 1, 0) False >>> u''.startswith(u'', 1, 0) True If define s1.startswith(s2, start, end) for non-negative indices and non-tuple s2 as an equivalent to the expression `start + len(s2) <= end and s2[start: start + len(s2)] == s2` or to `s1.find(s2, start, end) == start`, "".startswith("", 1, 0) should be False. The same issue exists for endswith. See issue24243 for more detailed discussion. Proposed patch fixes str.startswith and str.endswith. ---------- components: Interpreter Core files: str_tailmatch.patch keywords: patch messages: 244027 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Inconsistency in startswith/endswith type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39492/str_tailmatch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 13:42:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 May 2015 11:42:16 +0000 Subject: [issue24243] behavior for finding an empty string is inconsistent with documentation In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za> Message-ID: <1432554136.94.0.126987247718.issue24243@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Opened separate issue24284 for inconsistency in startswith/endswith. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 13:45:41 2015 From: report at bugs.python.org (Petr Viktorin) Date: Mon, 25 May 2015 11:45:41 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432554341.98.0.524790977677.issue24268@psf.upfronthosting.co.za> Petr Viktorin added the comment: Yes, you did find an error. Thanks for reporting it! Here is a fix with a test case. ---------- Added file: http://bugs.python.org/file39493/fix-pep489-submodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 14:04:49 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 25 May 2015 12:04:49 +0000 Subject: [issue24285] regression for importing extensions in packages Message-ID: <1432555489.93.0.956031853564.issue24285@psf.upfronthosting.co.za> New submission from Ronald Oussoren: PyObjC has an extension that's imported as "objc._objc". This works fine on version upto the 3.5 beta (checkout from earlier today). With that I get the following exception: Python 3.5.0b1+ (default:7255af1a1c50+, May 25 2015, 11:46:18) [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import objc Traceback (most recent call last): File "", line 1, in File "/Users/ronald/Projects/pyobjc-hg/pyobjc/pyobjc-core/Lib/objc/__init__.py", line 18, in _update() File "/Users/ronald/Projects/pyobjc-hg/pyobjc/pyobjc-core/Lib/objc/__init__.py", line 15, in _update import objc._objc as _objc ImportError: dynamic module does not define module export function (PyInit_._objc) ---------- messages: 244030 nosy: brett.cannon, eric.snow, ncoghlan, ronaldoussoren priority: high severity: normal status: open title: regression for importing extensions in packages versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 14:07:21 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 25 May 2015 12:07:21 +0000 Subject: [issue24285] regression for importing extensions in packages In-Reply-To: <1432555489.93.0.956031853564.issue24285@psf.upfronthosting.co.za> Message-ID: <1432555641.71.0.140526544751.issue24285@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The attached patch appears to fix the issue. This appears to be an off-by-one error. ---------- stage: -> needs patch type: -> behavior Added file: http://bugs.python.org/file39494/issue-24285.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 14:32:10 2015 From: report at bugs.python.org (Martin Blais) Date: Mon, 25 May 2015 12:32:10 +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: <1432557130.2.0.785067063599.issue24278@psf.upfronthosting.co.za> Martin Blais added the comment: Adding information that tells developers where the memory for those returned areas is stored and as you mention, its lifetime guarantees w.r.t. to the Python object, would go a long way towards making this more clear. The questions that immediately came to my mind were: - Is this memory attached to the object? - What if there is a conversion... is it still attached to the object? The converter for "s" says "Unicode objects are converted to C strings using 'utf-8' encoding." Where is the output of this conversion stored? Does it have the same lifetime as its PyObject as well or does it use a cache of recent conversions (e.g. like re/struct), or just static storage? And if so, is it thread-safe? I can find all these answers by looking at the source code for C/Python, or I can _guess_ that extra data is attached to some sort of 'extra' field in a PyObject (which would be a sensible thing to do), but my point is that an API user shouldn't have to dig in the source or have to guess for such important concerns. I think we should be a bit more transparent in the docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 15:05:35 2015 From: report at bugs.python.org (Martin Blais) Date: Mon, 25 May 2015 13:05:35 +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: <1432559135.55.0.321270392953.issue24278@psf.upfronthosting.co.za> Martin Blais added the comment: Oh, and yes, just adding this info at the top would be fine IMO. It shouldn't have to be repeated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 15:37:53 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 25 May 2015 13:37:53 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432561073.39.0.277137122661.issue24268@psf.upfronthosting.co.za> Ronald Oussoren added the comment: See issue 24285, I ran into the same issue as mention in msg244008. That issue has a patch. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 15:47:52 2015 From: report at bugs.python.org (Petr Viktorin) Date: Mon, 25 May 2015 13:47:52 +0000 Subject: [issue24285] regression for importing extensions in packages In-Reply-To: <1432555489.93.0.956031853564.issue24285@psf.upfronthosting.co.za> Message-ID: <1432561672.65.0.0707673292196.issue24285@psf.upfronthosting.co.za> Petr Viktorin added the comment: issue 24268 has a patch with a test case. ---------- nosy: +encukou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 15:55:46 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 May 2015 13:55:46 +0000 Subject: [issue24283] Print not safe in signal handlers In-Reply-To: <1432543061.46.0.0919733214048.issue24283@psf.upfronthosting.co.za> Message-ID: <1432562146.2.0.236434359947.issue24283@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 16:02:32 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 May 2015 14:02:32 +0000 Subject: [issue24284] Inconsistency in startswith/endswith In-Reply-To: <1432554087.61.0.0896292215981.issue24284@psf.upfronthosting.co.za> Message-ID: <1432562552.37.0.832631924953.issue24284@psf.upfronthosting.co.za> R. David Murray added the comment: I think this can only be applied in a feature release (and I think it should be, because of the backward-compatibility-with-python2 issue). However, since this is potentially controversial, we need some more opinions. ---------- nosy: +r.david.murray versions: -Python 2.7, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 16:03:24 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 25 May 2015 14:03:24 +0000 Subject: [issue24283] Print not safe in signal handlers In-Reply-To: <1432543061.46.0.0919733214048.issue24283@psf.upfronthosting.co.za> Message-ID: <1432562604.44.0.312126764964.issue24283@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > RuntimeError: reentrant call inside <_io.BufferedWriter name=''> As the exception message suggests: the IO stack is not reentrant. If an ongoing IO call is interrupted by a signal, and the signal handler calls again into the IO stack, this situation is detected and an error is raised. If instead we allowed the IO call to continue, all sorts of problems could ensue (data loss, crashes...). So, indeed, print() is not safe in signal handlers. Though the fact that it raises an exception, rather than crashes, makes things easier for the developer ;) ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 16:45:50 2015 From: report at bugs.python.org (Matthias Bussonnier) Date: Mon, 25 May 2015 14:45:50 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432565150.17.0.813139985283.issue24268@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: > Yes, you did find an error. Thanks for reporting it! > Here is a fix with a test case. Thanks, I was unsure if there would have been side effect or other things to fix. I would have submitted a patch otherwise. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 17:46:20 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 25 May 2015 15:46:20 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432568780.15.0.578011021206.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: @mrab gah! I could swear I originally had the _odict_clear_node first and had switched them due to a segfault. It even crossed my mind on Friday but I didn't pursue it. I'm guessing I did put the _odict_clear_node call first at some point but lost that fix along the way. :( That's the "benefit" of having a patch languish for so long; you end up working on it from multiple hosts and sometimes lose bits and pieces. Unfortunately only recently did I think to create a feature repo on which to track the on-going work. Anyway, thanks for helping with the investigation. The patch should be just about ready to commit at this point. :) I'm going to give it a once over, check for any lingering ref leaks, and double-check with Raymond. So I'm hopeful we can land this in the next few days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 17:47:04 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 25 May 2015 15:47:04 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432568824.32.0.0438065446841.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: @Jim, You've got some good questions. I'll look into them today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 17:59:26 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Mon, 25 May 2015 15:59:26 +0000 Subject: [issue24283] Print not safe in signal handlers In-Reply-To: <1432543061.46.0.0919733214048.issue24283@psf.upfronthosting.co.za> Message-ID: <1432569566.63.0.957445522092.issue24283@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: It doesn't do any of those things in Python 2, to my knowledge. Why aren't we willing to make this work? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 18:05:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 May 2015 16:05:11 +0000 Subject: [issue24283] Print not safe in signal handlers In-Reply-To: <1432543061.46.0.0919733214048.issue24283@psf.upfronthosting.co.za> Message-ID: <1432569911.39.0.41920907607.issue24283@psf.upfronthosting.co.za> STINNER Victor added the comment: > It doesn't do any of those things in Python 2, to my knowledge. Well, even if Python 2 doesn't warn you, threading_print_test.py is also wrong on Python 2. Python 3 is better because it warns you :-) > Why aren't we willing to make this work? It would be very complex to support reentrant calls in the io stack. It's much easier to redesign your application to defer the work of the signal handler outside the signal handler. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 20:08:54 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 25 May 2015 18:08:54 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1432577334.53.0.263618655259.issue23996@psf.upfronthosting.co.za> Stefan Behnel added the comment: I noticed that my patch isn't entirely correct. If the exception value is a tuple, both PyErr_SetObject() and PyErr_NormalizeException() use it directly as *argument tuple* for the exception instantiation call, i.e. they essentially unpack it into separate arguments. The StopIteration value is then only the first item of that tuple. I wonder if it's worth repeating this, uhm, surprising special case in yet another place, or if we should just always instantiate the exception. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 20:40:05 2015 From: report at bugs.python.org (Mark Shannon) Date: Mon, 25 May 2015 18:40:05 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432579205.44.0.380544389572.issue16991@psf.upfronthosting.co.za> Mark Shannon added the comment: I realise that I am bit late to the party, but I would like to point out that a smaller, arguably simpler, and almost certainly faster alternative design exists. This design simply consists of an array of (prev, next, key) nodes attached to the base dict. The linked list is maintained using the prev & next pointers of the nodes as normal. The mapping of keys to nodes is maintained by ensuring that the index of the node in the node array matches the index of the key in dict-key table. When the size of the array matches that of the keys table, this should be a very fast operation. When the dict is resized, the array will need to resized. (Possibly lazily if PyDict_* functions are used directly on the ordered dict.) Size analysis ------------- For an an occupancy of X, Eric's design takes 7/X + 3 slots per key/value pair. The alternative design takes 6/X slots per key/value pair. For an occupancy of 50%, half way between the minimum of 1/3 and maximum of 2/3, on a 64bit machine: The design proposed in this issue takes 17 slots or 136 bytes per key/value pair. The alternative would take 12 slots or 96 bytes per pair, about 70% of the size. ---------- nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 20:40:43 2015 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 25 May 2015 18:40:43 +0000 Subject: [issue24281] String formatting: incorrect number of decimal places In-Reply-To: <1432525661.76.0.778289488929.issue24281@psf.upfronthosting.co.za> Message-ID: <1432579243.47.0.0930994529891.issue24281@psf.upfronthosting.co.za> Eric V. Smith added the comment: Just to clarify: If not specified, the default "presentation type" for floats is "g". Since you didn't specify "f" in your example, it's using "g". For presentation type "g", the precision (3 in your case) is the total number of significant digits. So 12.34 first becomes 12.3, then that's displayed in a field 8 characters wide, which gives you the 4 leading zeros. See the section of presentation types for floating point at the end of this section: https://docs.python.org/2/library/string.html#format-specification-mini-language ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 20:52:54 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 25 May 2015 18:52:54 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1432437694.78.0.999900807186.issue16991@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: > I'm going to echo the previous comment that maybe trying to emulate the existing dict implementation too carefully just adds complexity. The whole dance with _odict_get_index and _odict_resize is due to the requirement that OrderedDict maintain O(1) operation for deletion operations. Due to using a linked list, we needed a secondary mechanism for efficiently indexing into the list. There is a note at the top of the file explaining the alternatives I considered and the rationale for mirroring dict's hash table. > > The split-keys implementation shows that there is at least some flexibility to the implementation. Enough that the keys could map to an array offset, rather than directly to the values? What do you mean by this? If you are suggesting changes to dict or its accessory types then it is something I considered and rejected. Personally I don't want to change anything on dict itself for the sake of OrderedDict. If others would like to pursue that they're welcome to do so. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 20:53:53 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 25 May 2015 18:53:53 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1432439629.61.0.544912035278.issue16991@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: > Should dictobject.h get a bit more changes? In particular, should the following be expanded? > > #define PyDictKeys_Check(op) (Py_TYPE(op) == &PyDictKeys_Type) > #define PyDictItems_Check(op) (Py_TYPE(op) == &PyDictItems_Type) > #define PyDictValues_Check(op) (Py_TYPE(op) == &PyDictValues_Type) > /* This excludes Values, since they are not sets. */ > # define PyDictViewSet_Check(op) \ > (PyDictKeys_Check(op) || PyDictItems_Check(op)) I'm missing some context here. I'm not sure how this relates to OrderedDict. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 20:58:49 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 25 May 2015 18:58:49 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432580329.35.0.97763559291.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: @Mark, great idea. I wish we'd discussed it more at PyCon 2013 when I was working on preserving OrderedDict's O(1) deletion. :) TBH, I don't have any problems with improvements. In fact, I'd be quite happy if folks jumped in and improved what I've done or even replaced it entirely. But at the point (with the feature freeze exception Larry gave) we should land what I have in 3.5 and then target 3.6 for any improvements. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 21:54:11 2015 From: report at bugs.python.org (Tal Einat) Date: Mon, 25 May 2015 19:54:11 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432583651.73.0.93840510912.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: Attached is a slightly revised patch. This mostly fixes minor documentation wording and formatting issues, including those pointed out by Chris Barker on the python-dev mailing list. Also, since it has been decided to support complex values only in a separate cmath.isclose() function, the previously included commented-out complex test cases have been removed. ---------- Added file: http://bugs.python.org/file39495/math_isclose_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 25 23:22:20 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 25 May 2015 21:22:20 +0000 Subject: [issue24285] regression for importing extensions in packages In-Reply-To: <1432555489.93.0.956031853564.issue24285@psf.upfronthosting.co.za> Message-ID: <1432588940.22.0.243187099675.issue24285@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> PEP 489 -- Multi-phase extension module initialization _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:01:43 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 25 May 2015 22:01:43 +0000 Subject: [issue24284] Inconsistency in startswith/endswith In-Reply-To: <1432554087.61.0.0896292215981.issue24284@psf.upfronthosting.co.za> Message-ID: <1432591303.87.0.50303994286.issue24284@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:03:43 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 25 May 2015 22:03:43 +0000 Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za> Message-ID: <1432591423.86.0.744499589043.issue23488@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Should this be backported? IMO, it is a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:24:18 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 25 May 2015 22:24:18 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432592658.66.0.242582090741.issue16991@psf.upfronthosting.co.za> Changes by Eric Snow : Added file: http://bugs.python.org/file39496/3b2a9026d48e.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:32:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 May 2015 22:32:58 +0000 Subject: [issue23993] Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup In-Reply-To: <1429349151.1.0.641370404.issue23993@psf.upfronthosting.co.za> Message-ID: <1432593178.62.0.711561373851.issue23993@psf.upfronthosting.co.za> STINNER Victor added the comment: Without a strong support, I don't want to put this in Python 3.5. It's too late (we reached the feature freeze). For Python 3.6, we may experiment using UTF-8 for Python filesystem encoding when the LC_CTYPE locale is POSIX ("C"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:33:08 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 May 2015 22:33:08 +0000 Subject: [issue23993] Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup In-Reply-To: <1429349151.1.0.641370404.issue23993@psf.upfronthosting.co.za> Message-ID: <1432593188.66.0.168345801044.issue23993@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:37:16 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 May 2015 22:37:16 +0000 Subject: [issue23763] Chain exceptions in C In-Reply-To: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za> Message-ID: <1432593436.02.0.870703404624.issue23763@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:37:17 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 25 May 2015 22:37:17 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <1432593437.48.0.166839052894.issue23509@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The change to __neg__ looked like a nice improvement and the same should technique can be done to __pos__. Attaching a patch for those two. ---------- versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file39497/counter_pos_neg.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:38:37 2015 From: report at bugs.python.org (Jim Jewett) Date: Mon, 25 May 2015 22:38:37 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432593517.64.0.594669513833.issue16991@psf.upfronthosting.co.za> Jim Jewett added the comment: Eric .... I realize that O (1) deletion is hard, and don't see a good way around it without changing the implementation ... I just think that the preserving the current C layout may be forcing an even more complicated solution than neccessary. I am nervous about pushing this to 3.5 because of the complexity. I agree that a simpler solution should (also?) wait for 3.6. The question about dictheaher.h boils down to: if someone asks whether something is a dictview (not even using "exact", though that isn't an option), an odictview will say false ... is that really what you want? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:44:21 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 25 May 2015 22:44:21 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432593861.35.0.543764009008.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: At present the only remaining issues with the patch are: * 10 leaked refs in test_collections * a failing test in test_enum =========================================================================== key: __members__ result: OrderedDict([('red', ), ('green', ), ('blue', )]) expected: OrderedDict([('red', ), ('green', ), ('blue', )]) =========================================================================== test test_enum failed -- Traceback (most recent call last): File "/home/esnow/projects/cordereddict/Lib/test/test_enum.py", line 1668, in test_inspect_getmembers self.fail("result does not equal expected, see print above") AssertionError: result does not equal expected, see print above I'm not sure what to make of that test. By all appearances it should be passing. My guess is that there's some wackiness afoot over in Enum, but I'll take a closer look after I get the ref counts sorted out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:44:43 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 25 May 2015 22:44:43 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1432593883.0.0.361619641985.issue24254@psf.upfronthosting.co.za> Eric Snow added the comment: Per discussion on python-dev, I'm tabling the __definition_order__ part to 3.6. I'll open a thread on python-ideas on it later and open a new issue here if I get a positive response. So this issue is just about making OrderedDict the default namespace type for class definitions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:44:53 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 25 May 2015 22:44:53 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1432593892.99.0.958139135754.issue24254@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:48:22 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 May 2015 22:48:22 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1432594102.63.0.584489304742.issue24254@psf.upfronthosting.co.za> STINNER Victor added the comment: > It may be a stretch to get this into 3.5, but the final change should be pretty small. Changing the default type of class dictionaries is a huge change. IMO it should be deferred to Python 3.6. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:49:34 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 May 2015 22:49:34 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <20150525224931.17925.13546@psf.io> Roundup Robot added the comment: New changeset 623e07ea43df by Victor Stinner in branch '3.4': Issue #23840: tokenize.open() now closes the temporary binary file on error to https://hg.python.org/cpython/rev/623e07ea43df New changeset a640d268ba97 by Victor Stinner in branch '3.5': (Merge 3.5) Issue #23840: tokenize.open() now closes the temporary binary file https://hg.python.org/cpython/rev/a640d268ba97 New changeset c5cfd6353b4b by Victor Stinner in branch 'default': (Merge 3.6) Issue #23840: tokenize.open() now closes the temporary binary file https://hg.python.org/cpython/rev/c5cfd6353b4b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:50:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 May 2015 22:50:49 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1432594249.81.0.111143679303.issue23840@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry for not being more available for feedback on patches. I chose to write the final patch because patches were not updated to take in account my latest comments. I hope that this issue helps you at least the process for reviewing patches ;-) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:51:43 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 May 2015 22:51:43 +0000 Subject: [issue23754] Add a new os.read_into() function to avoid memory copies In-Reply-To: <1427145371.9.0.485193711036.issue23754@psf.upfronthosting.co.za> Message-ID: <1432594303.59.0.0491630721129.issue23754@psf.upfronthosting.co.za> STINNER Victor added the comment: Without more interested, I chose to defer this issue. Feel free to reopen it if you need it for more use cases, or if you are interested to implement it. ---------- resolution: -> postponed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:51:55 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 25 May 2015 22:51:55 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1432594315.84.0.147637283078.issue24254@psf.upfronthosting.co.za> Eric Snow added the comment: This is not about changing the default type for class dictionaries. It is only for changing the default type used during class definition. Essentially, we are just changing the type of what is returned from `type.__prepare__`. cls.__dict__ will remain a dict. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:52:31 2015 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 25 May 2015 22:52:31 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432594102.63.0.584489304742.issue24254@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: This is *not* about changing the default type of class dictionaries (which I agree would be far too large a change to make without a PEP), it's only about changing the ephemeral evaluation namespace used to execute the class body. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:55:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 May 2015 22:55:42 +0000 Subject: [issue23648] PEP 475 meta issue In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za> Message-ID: <1432594542.71.0.964003522536.issue23648@psf.upfronthosting.co.za> STINNER Victor added the comment: I updated the list of modified functions in the PEP 475. Except of the issue #23719, all other issues related to the PEP 475 have been fixed. It's time to close this meta issue. ---------- dependencies: -PEP 475: port test_eintr to Windows resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:58:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 May 2015 22:58:18 +0000 Subject: [issue23574] datetime: support leap seconds In-Reply-To: <1425393743.39.0.519990063132.issue23574@psf.upfronthosting.co.za> Message-ID: <1432594698.26.0.414901620524.issue23574@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry, I give up on this issue. I don't know how to fix it, nor if it's possible to fix it. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 00:59:31 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 May 2015 22:59:31 +0000 Subject: [issue23270] Use the new __builtin_mul_overflow() of Clang and GCC 5 to check for integer overflow In-Reply-To: <1421661010.06.0.656712864154.issue23270@psf.upfronthosting.co.za> Message-ID: <1432594771.07.0.118678627881.issue23270@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm no more interested to work on this issue, so I just close it. It was more a reminder for myself than a real issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 01:28:07 2015 From: report at bugs.python.org (Joshua Bronson) Date: Mon, 25 May 2015 23:28:07 +0000 Subject: [issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal? Message-ID: <1432596487.8.0.280829225775.issue24286@psf.upfronthosting.co.za> New submission from Joshua Bronson: Is it intentional that the second assertion in the following code fails? ``` from collections import OrderedDict d = dict(C='carbon') o = OrderedDict(d) assert d == o assert d.viewitems() == o.viewitems() ``` Since d == o, I'm surprised that d.viewitems() != o.viewitems(). If that's intentional, I'd love to understand the rationale. Note: I hit this while testing a library I authored, https://pypi.python.org/pypi/bidict, which provides a https://en.wikipedia.org/wiki/Bidirectional_map implementation for Python, so I'm especially keen to understand all the subtleties in this area. Thanks in advance. ---------- messages: 244066 nosy: jab priority: normal severity: normal status: open title: Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal? versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 01:41:56 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 25 May 2015 23:41:56 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432597316.96.0.515822455383.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: I've cleaned up all the ref leaks so now just the failing test_enum test remains to be resolved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 02:19:28 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 May 2015 00:19:28 +0000 Subject: [issue24284] Inconsistency in startswith/endswith In-Reply-To: <1432554087.61.0.0896292215981.issue24284@psf.upfronthosting.co.za> Message-ID: <1432599568.34.0.541829412806.issue24284@psf.upfronthosting.co.za> Martin Panter added the comment: I can?t imagine much code would rely on either old or new behaviour. If you only put it into a feature release, would you have to document it as a change in behaviour? ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 02:54:10 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 May 2015 00:54:10 +0000 Subject: [issue24287] Let ElementTree prolog include comments and processing instructions Message-ID: <1432601650.19.0.16515305979.issue24287@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Currently, ElementTree doesn't support comments and processing instructions in the prolog. That is the typical place to put style-sheets and document type definitions. It would be used like this: from xml.etree.ElementTree import ElementTree, Element, Comment, ProcessingInstruction r = Element('current_observation', version='1.0') r.text = 'Nothing to see here. Move along.' t = ElementTree(r) t.append(ProcessingInstruction('xml-stylesheet', 'href="latest_ob.xsl" type="text/xsl"')) t.append(Comment('Published at: http://w1.weather.gov/xml/current_obs/KSJC.xml')) That creates output like this: Nothing to see here. Move along. ---------- files: xml_prolog.diff keywords: patch messages: 244069 nosy: eli.bendersky, rhettinger, scoder priority: normal severity: normal status: open title: Let ElementTree prolog include comments and processing instructions type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file39498/xml_prolog.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 02:55:23 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 May 2015 00:55:23 +0000 Subject: [issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal? In-Reply-To: <1432596487.8.0.280829225775.issue24286@psf.upfronthosting.co.za> Message-ID: <1432601723.29.0.837722118419.issue24286@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 03:11:19 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 May 2015 01:11:19 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432602679.82.0.482834439208.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: The failing test is not passing so I don't see any further blockers to committing this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 03:12:05 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 May 2015 01:12:05 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432602725.27.0.576835867623.issue16991@psf.upfronthosting.co.za> Changes by Eric Snow : Added file: http://bugs.python.org/file39499/c3fab329aa7f.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 03:12:26 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 May 2015 01:12:26 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432602746.14.0.848196953211.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: rather, it *is* passing now :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 03:25:51 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 May 2015 01:25:51 +0000 Subject: [issue24287] Let ElementTree prolog include comments and processing instructions In-Reply-To: <1432601650.19.0.16515305979.issue24287@psf.upfronthosting.co.za> Message-ID: <1432603551.88.0.633431579804.issue24287@psf.upfronthosting.co.za> Martin Panter added the comment: The ElementTree class imitates or wraps many methods of the Element class. Since Element.append() and remove() already exist and act on children of the element, I think the new ElementTree methods should be named differently. Maybe something like prolog_append() and prolog_remove()? Or prologue_append() depending on your spelling preferences :P Also, maybe the new write() calls should add newlines. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 03:28:45 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 26 May 2015 01:28:45 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432603725.69.0.305084122914.issue16991@psf.upfronthosting.co.za> Yury Selivanov added the comment: > rather, it *is* passing now :) Eric, thanks for working on this! Could you please go through your patch and replace "//" comments with "/* .. */" ones? It would also be great if you can clean-up XXX comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 03:29:43 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 May 2015 01:29:43 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432603783.61.0.79787138278.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Ah, good point. I'll take care of all those. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 03:34:06 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 May 2015 01:34:06 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1432604046.49.0.170654459167.issue24254@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks for pointing out types.prepare_class. I've updated it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 03:52:49 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 May 2015 01:52:49 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432605169.85.0.77532026625.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: I've cleaned up the patch. I still want to make one last pass to check re-entrancy concerns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 03:53:20 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 May 2015 01:53:20 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432605200.66.0.433104477387.issue16991@psf.upfronthosting.co.za> Changes by Eric Snow : Added file: http://bugs.python.org/file39500/ba1c6d40ca63.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 04:00:57 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 May 2015 02:00:57 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1432605657.84.0.676128443368.issue24254@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- priority: release blocker -> stage: -> patch review versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 04:03:17 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 May 2015 02:03:17 +0000 Subject: [issue24254] Make class definition namespace ordered by default In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za> Message-ID: <1432605797.42.0.862621909393.issue24254@psf.upfronthosting.co.za> Eric Snow added the comment: I've moved this to 3.6. Small as the patch might be, there just isn't enough urgency to warrant making use of an exception to get it into 3.5. If __definition_order__ were still on the table then I'd probably still push for 3.5. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 05:07:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 May 2015 03:07:24 +0000 Subject: [issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal? In-Reply-To: <1432596487.8.0.280829225775.issue24286@psf.upfronthosting.co.za> Message-ID: <1432609644.7.0.378607656259.issue24286@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This question looks similar to: Should list compare equal to set when the items are equal? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 05:21:43 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 May 2015 03:21:43 +0000 Subject: [issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal? In-Reply-To: <1432596487.8.0.280829225775.issue24286@psf.upfronthosting.co.za> Message-ID: <1432610503.67.0.349249464143.issue24286@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This looks like a bug in Python 2.7: # Python2.7 >>> from collections import Set >>> isinstance({1:2}.viewitems(), Set) False # Python3.5 >>> from collections import Set >>> isinstance({1:2}.items(), Set) True I think the dictitems object needs to be registered as a Set. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 05:29:03 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 26 May 2015 03:29:03 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1432610943.45.0.577654965114.issue21998@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- priority: normal -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 05:55:01 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 May 2015 03:55:01 +0000 Subject: [issue14132] Redirect is not working correctly in urllib2 In-Reply-To: <1330269331.97.0.613564747875.issue14132@psf.upfronthosting.co.za> Message-ID: <1432612501.82.0.622842125145.issue14132@psf.upfronthosting.co.za> Martin Panter added the comment: urllib2_redirect_fix.2.patch adds a test. I was tempted to remove the whole block of code setting the path to ?/?, but there is one minor disadvantage: if a redirect points to a so-called ?malformed? URL without any path component, like ?http://example.net? or ?http://example.net?query?, geturl() would return this URL verbatim. ---------- stage: test needed -> patch review versions: +Python 3.6 Added file: http://bugs.python.org/file39501/urllib2_redirect_fix.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 05:57:27 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 May 2015 03:57:27 +0000 Subject: [issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal? In-Reply-To: <1432596487.8.0.280829225775.issue24286@psf.upfronthosting.co.za> Message-ID: <1432612647.17.0.595306679288.issue24286@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The fix looks something like this: diff --git a/Lib/_abcoll.py b/Lib/_abcoll.py --- a/Lib/_abcoll.py +++ b/Lib/_abcoll.py @@ -473,6 +473,7 @@ for key in self._mapping: yield (key, self._mapping[key]) +ItemsView.register(type({}.viewitems())) Will add a more thorough patch with tests later. ---------- components: +Library (Lib) type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 06:23:35 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 May 2015 04:23:35 +0000 Subject: [issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal? In-Reply-To: <1432596487.8.0.280829225775.issue24286@psf.upfronthosting.co.za> Message-ID: <1432614215.25.0.38567969877.issue24286@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +patch Added file: http://bugs.python.org/file39502/fix_view_registry.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 06:53:51 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 26 May 2015 04:53:51 +0000 Subject: [issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal? In-Reply-To: <1432596487.8.0.280829225775.issue24286@psf.upfronthosting.co.za> Message-ID: <1432616031.12.0.622107487617.issue24286@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 07:22:24 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 May 2015 05:22:24 +0000 Subject: [issue13341] Incorrect documentation for "u" PyArg_Parse format unit In-Reply-To: <1320412814.48.0.657162308895.issue13341@psf.upfronthosting.co.za> Message-ID: <1432617744.43.0.18548108642.issue13341@psf.upfronthosting.co.za> Martin Panter added the comment: The Python 3 documentation was updated in Issue 8593 (revision 5d4a5655575f). Perhaps some of the wording also applies to Python 2 and you can just copy it. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 07:53:04 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 May 2015 05:53:04 +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: <1432619584.65.0.186032371362.issue24278@psf.upfronthosting.co.za> Martin Panter added the comment: This is my understanding of where the buffers would be managed and what governs their lifetimes, though I haven?t analyzed the code to verify: s, z: str -> UTF-8 cache -> pointer for object lifetime s*, z*: str -> UTF-8 cache -> buffer; bytes-like -> buffer; until release y*: bytes-like -> buffer until release S: bytes borrowed object Y: bytearray borrowed object u, u#, Z, Z#: str -> Py_UNICODE cache -> pointer for object lifetime U: str borrowed object w*: writable bytes-like -> buffer until release es, es#: str -> encoded -> pointer until free (or pre-allocated for es#) et, et#: str -> encoded -> pointer; bytes, bytearray -> pointer; until free (or pre-allocated for et#) One open question that has worried me a bit is the ?s#?, ?z#?, ?y?, ?y#? codes, which are documented as requiring immutable bytes-like objects, but do not return a buffer structure. I guess this is designed for objects like bytes(), where the pointer would remain valid for the object?s lifetime, even if it has been released according to the buffer protocol. But how is this guaranteed for arbitrary buffer objects? Some undocumented requirement of the buffer?s ?readonly? flag perhaps? So I propose to add: * Lifetime of all Py_buffer return values is until PyBuffer_Release() is called * Unless otherwise documented, for conversions that return pointers to buffers, the buffer is managed or cached inside the Python object, and the lifetime of that buffer is the same as the whole Python object * Unconverted Python objects are borrowed references * For the four immutable bytes-like conversions I mentioned that return pointers, the buffer management and lifetime is not documented (unless somebody comes up with a better explanation) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 08:04:29 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 May 2015 06:04:29 +0000 Subject: [issue24009] Get rid of rare format units in PyArg_Parse* In-Reply-To: <1429470884.11.0.538472438707.issue24009@psf.upfronthosting.co.za> Message-ID: <1432620269.64.0.101788528361.issue24009@psf.upfronthosting.co.za> Martin Panter added the comment: ?u#? should not be deprecated without first deprecating ?u?, which is less useful due to not returning a buffer length. Also, I have always been mystified about how ?s#?, ?z#?, ?y? and ?y#? can properly to return a pointer into a buffer for arbitrary immutable bytes-like objects, without requiring PyBuffer_Release() to be called. Perhaps this is bad design to be discouraged. Or maybe a documentation oversight somewhere. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 08:43:55 2015 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 26 May 2015 06:43:55 +0000 Subject: [issue24287] Let ElementTree prolog include comments and processing instructions In-Reply-To: <1432601650.19.0.16515305979.issue24287@psf.upfronthosting.co.za> Message-ID: <1432622635.16.0.669981065753.issue24287@psf.upfronthosting.co.za> Stefan Behnel added the comment: FTR, lxml's Element class has addnext() and addprevious() methods which are commonly used for this purpose. But ET can't adopt those due to its different tree model. I second Martin's comment that ET.append() is a misleading name. It suggests adding stuff to the end, whereas things are actually being inserted before the root element here. I do agree, however, that this is a helpful feature and that the ElementTree class is a good place to expose it. I propose to provide a "prolog" (that's the spec's spelling) property holding a list that users can fill and modify any way they wish. The serialiser would then validate that all content is proper XML prologue content, and would serialise it in order. My guess is that lxml would eventually use a MutableSequence here that maps changes directly to the underlying tree (and would thus validate them during modification), but ET can be more lenient, just like it allows arbitrary objects in the text and tail properties which only the serialiser rejects. Note that newlines can easily be generated on user side by setting the tail of a PI/Comment to "\n". (The serialiser must also validate that the tail text is only allowed whitespace.) For reference: http://www.w3.org/TR/REC-xml/#sec-prolog-dtd ---------- components: +XML _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 09:24:52 2015 From: report at bugs.python.org (Tom Hines) Date: Tue, 26 May 2015 07:24:52 +0000 Subject: [issue10685] trace does not ignore --ignore-module In-Reply-To: <1292157270.73.0.200325030661.issue10685@psf.upfronthosting.co.za> Message-ID: <1432625092.77.0.322820547649.issue10685@psf.upfronthosting.co.za> Tom Hines added the comment: Test attached. Paste into test/test_trace.py. I tested in 2.7 and 3.4. Feel free to modify it. ---------- Added file: http://bugs.python.org/file39503/test_ignoredir.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 09:39:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 May 2015 07:39:46 +0000 Subject: [issue24009] Get rid of rare format units in PyArg_Parse* In-Reply-To: <1429470884.11.0.538472438707.issue24009@psf.upfronthosting.co.za> Message-ID: <1432625986.63.0.149824623455.issue24009@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: ?s#?, ?z#?, ?y? and ?y#? work only with read-only buffers, for which PyBuffer_Release() is no-op operation. Initially they was designed for work with old buffer protocol that doesn't support releasing a buffer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 09:46:11 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 May 2015 07:46:11 +0000 Subject: [issue24009] Get rid of rare format units in PyArg_Parse* In-Reply-To: <1429470884.11.0.538472438707.issue24009@psf.upfronthosting.co.za> Message-ID: <1432626371.71.0.381741465459.issue24009@psf.upfronthosting.co.za> Martin Panter added the comment: Yes I just figured out that myself. Specifically, PyBufferProcs.bf_releasebuffer has to be NULL, and the buffer stays alive as long as the object stays alive. Also it looks like I was wrong about ?u? being useless. I was tricked by a contradiction in the documentation, but I will try to fix this in a patch to Issue 24278. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 09:47:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 May 2015 07:47:55 +0000 Subject: [issue24288] Include/opcode.h is modified during building Message-ID: <1432626475.52.0.752359380395.issue24288@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Changeset eeeb666a5365 in issue24017 unintentionally changed formatting of generated file Include/opcode.h. Now clean building CPython modifies Include/opcode.h. One solution is to restore formatting of Include/opcode.h (regenerate it and commit). Other solution is to change Tools/scripts/generate_opcode_h.py to generate a file without trailing spaces. ---------- components: Build messages: 244089 nosy: asvetlov, gvanrossum, haypo, ncoghlan, python-dev, scoder, serhiy.storchaka, yselivanov priority: normal severity: normal stage: needs patch status: open title: Include/opcode.h is modified during building type: compile error versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 10:09:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 May 2015 08:09:30 +0000 Subject: [issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal? In-Reply-To: <1432596487.8.0.280829225775.issue24286@psf.upfronthosting.co.za> Message-ID: <1432627770.93.0.730668522081.issue24286@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't know if it is worth to backport this feature (dict views were registered in 1f024a95e9d9), but the patch itself LGTM. I think tests should be foreported to 3.x (if they don't exist in 3.x). Are there generic set tests similar to mapping_tests and seq_tests? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 10:10:40 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 May 2015 08:10:40 +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: <1432627840.71.0.125332969671.issue24278@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch. Looking at the code, s#, z#, y and y# are the conversions that call convertbuffer(). These require that the object does not have a PyBufferProcs.bf_releasebuffer() method, which guarantees that the buffer?s lifetime is the same as the underlying object. In the patch I also removed a contradictory notice about nulls with the ?u? conversion. ---------- keywords: +patch stage: needs patch -> patch review versions: +Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39504/buffer-convert.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 10:29:07 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 May 2015 08:29:07 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <1432628947.38.0.470754180873.issue23359@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file39505/nd_lookkey_insertkey3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 10:36:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 May 2015 08:36:25 +0000 Subject: [issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal? In-Reply-To: <1432596487.8.0.280829225775.issue24286@psf.upfronthosting.co.za> Message-ID: <20150526083621.45377.7794@psf.io> Roundup Robot added the comment: New changeset 9213c70c67d2 by Raymond Hettinger in branch '2.7': Issue #24286: Register dict views with the MappingView ABCs. https://hg.python.org/cpython/rev/9213c70c67d2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 10:48:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 May 2015 08:48:09 +0000 Subject: [issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal? In-Reply-To: <1432596487.8.0.280829225775.issue24286@psf.upfronthosting.co.za> Message-ID: <20150526084806.16283.92112@psf.io> Roundup Robot added the comment: New changeset ff8b603ee51e by Raymond Hettinger in branch 'default': Issue #24286: Forward port dict view abstract base class tests. https://hg.python.org/cpython/rev/ff8b603ee51e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 10:50:04 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 May 2015 08:50:04 +0000 Subject: [issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal? In-Reply-To: <1432596487.8.0.280829225775.issue24286@psf.upfronthosting.co.za> Message-ID: <1432630204.73.0.776093253148.issue24286@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I don't know if it is worth to backport this feature I don't think so either. The Iterator registry is a bit of a waste. > Are there generic set tests similar to mapping_tests and seq_tests? Not that I know of. Also, I don't see the need. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 10:50:42 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 May 2015 08:50:42 +0000 Subject: [issue24286] Should OrderedDict.viewitems compare equal to dict.viewitems when the items are equal? In-Reply-To: <1432596487.8.0.280829225775.issue24286@psf.upfronthosting.co.za> Message-ID: <1432630242.89.0.344997067293.issue24286@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 11:31:03 2015 From: report at bugs.python.org (Cliff Dyer) Date: Tue, 26 May 2015 09:31:03 +0000 Subject: [issue24258] BZ2File objects do not have name attribute In-Reply-To: <1432199816.0.0.178283144298.issue24258@psf.upfronthosting.co.za> Message-ID: <1432632663.42.0.279973863428.issue24258@psf.upfronthosting.co.za> Cliff Dyer added the comment: I'd be happy to take a look at this one, if no one else is working on it. ---------- nosy: +jcd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 11:52:17 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 May 2015 09:52:17 +0000 Subject: [issue16927] Separate built-in types from functions and group similar functions in functions.rst In-Reply-To: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za> Message-ID: <1432633937.36.0.920740715722.issue16927@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 13:03:22 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 26 May 2015 11:03:22 +0000 Subject: [issue24281] String formatting: incorrect number of decimal places In-Reply-To: <1432525661.76.0.778289488929.issue24281@psf.upfronthosting.co.za> Message-ID: <1432638202.31.0.0277599276803.issue24281@psf.upfronthosting.co.za> Eric V. Smith added the comment: And I just double checked: the entirety of the sentence you quoted is: The precision is a decimal number indicating how many digits should be displayed after the decimal point for a floating point value formatted with 'f' and 'F', or before and after the decimal point for a floating point value formatted with 'g' or 'G'. I think that's reasonably clear for 'g' and 'G', but if you think it could be improved, I'm open to suggestions. Maybe the disconnect is that 'g' is the default? The only reason I'm following up on this is that I'm familiar with all of this, yet it still took me some experimenting to remember what the issue is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 13:10:51 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 26 May 2015 11:10:51 +0000 Subject: [issue24260] TabError behavior doesn't match documentation In-Reply-To: <1432244751.77.0.187754601995.issue24260@psf.upfronthosting.co.za> Message-ID: <1432638651.3.0.042028361703.issue24260@psf.upfronthosting.co.za> Stefan Krah added the comment: > Prohibiting tabs after spaces is not enough. No, I really meant that once a new block is started with tabs, all following nested blocks must use tabs for indentation. The only place where spaces would be allowed is for aligment in logical lines that extend over multiple physical lines. Basically, just tab-oblivious formatting (which is generally nice for other languages). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 13:57:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 May 2015 11:57:42 +0000 Subject: [issue24285] regression for importing extensions in packages In-Reply-To: <1432555489.93.0.956031853564.issue24285@psf.upfronthosting.co.za> Message-ID: <20150526115739.126974.22491@psf.io> Roundup Robot added the comment: New changeset 55e6f3f94b99 by Nick Coghlan in branch '3.5': Issue #24285: fix importing extensions from packages https://hg.python.org/cpython/rev/55e6f3f94b99 New changeset 32ee7b9d58c9 by Nick Coghlan in branch 'default': Merge fix for issue #24285 from 3.5 https://hg.python.org/cpython/rev/32ee7b9d58c9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 13:58:35 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 May 2015 11:58:35 +0000 Subject: [issue24285] regression for importing extensions in packages In-Reply-To: <1432555489.93.0.956031853564.issue24285@psf.upfronthosting.co.za> Message-ID: <1432641515.77.0.73476263906.issue24285@psf.upfronthosting.co.za> Nick Coghlan added the comment: Since this error was in the beta release, I used this issue reference in the NEWS file, rather than the original implementation issue. ---------- resolution: duplicate -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 14:00:28 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 May 2015 12:00:28 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432641628.76.0.342312190131.issue24268@psf.upfronthosting.co.za> Nick Coghlan added the comment: I registered the fix for importing extension modules from packages against issue 24285 in the commit and NEWS file rather than against this original implementation RFE. Commit references in http://bugs.python.org/issue24285#msg244098 ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 15:10:17 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 May 2015 13:10:17 +0000 Subject: [issue23560] Group the docs of similar methods in stdtypes.rst In-Reply-To: <1425288490.4.0.288876913126.issue23560@psf.upfronthosting.co.za> Message-ID: <1432645817.29.0.652214354593.issue23560@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch that groups similar methods of the str() class together at various levels. I added an alphabetical index of the methods, currently as a big paragraph of hyperlinks in the existing String Methods section. Then I added the following seven new sections. Ideally they would be ordered from important to obscure. * String Formatting * Searching and Replacing * Splitting and Joining * String Classification * Case Manipulation * Padding and Stripping * Translation and Encoding Within each section, most methods remain separate with no change to their descriptions. Some are grouped under a single description, where a there is an obvious pattern. I have tried put closely related methods nearby, while putting important and simple methods higher up, and moving their obscure and complex counterparts lower down. Depending on outcome of these changes to the string methods, I may also be interested in doing a similar job to the bytes() and bytearray() methods. ---------- keywords: +patch stage: needs patch -> patch review versions: +Python 3.6 Added file: http://bugs.python.org/file39506/str-groups.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 15:24:10 2015 From: report at bugs.python.org (James Luscher) Date: Tue, 26 May 2015 13:24:10 +0000 Subject: [issue24281] String formatting: incorrect number of decimal places In-Reply-To: <1432525661.76.0.778289488929.issue24281@psf.upfronthosting.co.za> Message-ID: <1432646650.61.0.401745099966.issue24281@psf.upfronthosting.co.za> James Luscher added the comment: Eric, I am not familiar with the 'g' format and did not know it was the default, but the documentation, read fully, is correct. It just took the response of Christopher Welborn to "wake me up" (it was a LONG day and I was "struggling" to understand the problem - I would hate to tell you how long I worked on this problem ! {embarrassment!!}). My programming usually involves text manipulation, data structures and GUIs. The am familiar with the use of 'precision' as length of the decimal fraction but was thrown by (the equally valid) use of 'precision' as the mathematical idea referring to 'significant digits'. Counting BOTH sides of decimal point was a difficult switch of word meaning to get my head around. Just because "I" have never(!) used the 'g' format doesn't mean it isn't the proper choice for 'default'. Language is often a challenge and 'precision' with two meanings (# of digits to right of decimal AND total # of digits {right and left of decimal)) does present a linguistic challenge to one's ability to comprehend what the word means ;-) I wish I could give you the solution but at least I (finally !) understand the mental issue involved. Thanks to both of you for your help getting me past my 'mental fugue' ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 15:44:56 2015 From: report at bugs.python.org (Tal Einat) Date: Tue, 26 May 2015 13:44:56 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432647896.56.0.321548252868.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: Significant questions brought up by Berker Peksa? in his review of the latest patch (thanks for the review!): 1. Should the tolerance parameters be keyword-only? Berker suggests that they should be. I agree. 2. Should the math.isclose() tests be split into a separate TestCase class with many separate methods? It is currently a single method which does all of the testing for math.isclose(). (Chris's original code has it separated into several TestCase classes; I consolidated it into a single method to keep in line with the current structure of the math module's tests.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 15:56:49 2015 From: report at bugs.python.org (Tal Einat) Date: Tue, 26 May 2015 13:56:49 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432648609.97.0.99209006615.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: Regarding the tests, I now realize that most of them should be reused for testing cmath.isclose(), which means they'll have to be defined outside of test_math.MathTests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 16:04:46 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 26 May 2015 14:04:46 +0000 Subject: [issue24288] Include/opcode.h is modified during building In-Reply-To: <1432626475.52.0.752359380395.issue24288@psf.upfronthosting.co.za> Message-ID: <1432649086.27.0.732265083174.issue24288@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Other solution is to change Tools/scripts/generate_opcode_h.py to generate a file without trailing spaces. I like this option. I saw the whitespace, but I usually don't touch autogenerated files, so I naturally thought that someone has modified the tooling before my commit and it's fine. Anyways, please see the attached patch. ---------- keywords: +patch Added file: http://bugs.python.org/file39507/opcodes_ws.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 16:43:20 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 May 2015 14:43:20 +0000 Subject: [issue24284] Inconsistency in startswith/endswith In-Reply-To: <1432554087.61.0.0896292215981.issue24284@psf.upfronthosting.co.za> Message-ID: <1432651400.38.0.732865670264.issue24284@psf.upfronthosting.co.za> R. David Murray added the comment: Just in the what's new porting section, I think. The fact that there "should" be very little to no code that relies on this is why I'd like to see it fixed. The fact that the report was a theoretical one, and not one that broke code, is why I think we should fix it only in 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 16:55:39 2015 From: report at bugs.python.org (Mike Basca) Date: Tue, 26 May 2015 14:55:39 +0000 Subject: [issue24289] can't start Python3 due to ImportError of copy_reg Message-ID: <1432652139.86.0.658792169733.issue24289@psf.upfronthosting.co.za> New submission from Mike Basca: Hello, I recently upgraded pip and pip3 and now I can't start python3. This is the Traceback I receive when I started python 3.4.3 (python2.7.10 is fine). localhost:PP4E Mike$ python3 Failed to import the site module Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site.py", line 562, in main() File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site.py", line 548, in main known_paths = addusersitepackages(known_paths) File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site.py", line 281, in addusersitepackages user_site = getusersitepackages() File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site.py", line 257, in getusersitepackages user_base = getuserbase() # this will also set USER_BASE File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site.py", line 247, in getuserbase USER_BASE = get_config_var('userbase') File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/sysconfig.py", line 589, in get_config_var return get_config_vars().get(name) File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/sysconfig.py", line 568, in get_config_vars import _osx_support File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/_osx_support.py", line 4, in import re File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/re.py", line 336, in import copyreg File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/copyreg.py", line 3, in from copy_reg import * ImportError: No module named 'copy_reg' Any help would be appreciated. ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 244107 nosy: abaskm priority: normal severity: normal status: open title: can't start Python3 due to ImportError of copy_reg type: compile error versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 17:00:52 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 26 May 2015 15:00:52 +0000 Subject: [issue24289] can't start Python3 due to ImportError of copy_reg In-Reply-To: <1432652139.86.0.658792169733.issue24289@psf.upfronthosting.co.za> Message-ID: <1432652452.89.0.0492313570197.issue24289@psf.upfronthosting.co.za> R. David Murray added the comment: copyreg.py is part of the standard library, but you obviously have a file shadowing it in your site-packages. If this is a result of the pip upgrade, you should report this to the pip tracker. ---------- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 17:34:54 2015 From: report at bugs.python.org (Dimitri John Ledkov) Date: Tue, 26 May 2015 15:34:54 +0000 Subject: [issue1322] Deprecate platform.dist() and platform.linux_distribution() functions In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> Message-ID: <1432654494.31.0.152923845658.issue1322@psf.upfronthosting.co.za> Dimitri John Ledkov added the comment: Why not change them to parse os-release files as defined by http://www.freedesktop.org/software/systemd/man/os-release.html A lot of things use these functions to check what one is running on, despite the problems, and do different things at install time. This deprecation and eventual removal, will result in a pypi module created with such functionality anyway, that everyone will try to pull in.... or falling that copying in. Here in https://clearlinux.org team we have patches to switch these to parse /etc/os-release;/usr/lib/os-release files instead. Would you be open to deprecate parsing any other files but os-release going forward? As that is standard across all linux distributions for quite some time now. Regards, Dimitri. Debian Developer, Ubuntu Core Developer, Clear Linux* Project Developer. ---------- nosy: +xnox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 17:36:05 2015 From: report at bugs.python.org (Dimitri John Ledkov) Date: Tue, 26 May 2015 15:36:05 +0000 Subject: [issue1322] Deprecate platform.dist() and platform.linux_distribution() functions In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> Message-ID: <1432654565.8.0.435524904119.issue1322@psf.upfronthosting.co.za> Dimitri John Ledkov added the comment: Note that things have changed in this space, since the issue was opened in 2007. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 18:14:34 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 26 May 2015 16:14:34 +0000 Subject: [issue24289] can't start Python3 due to ImportError of copy_reg In-Reply-To: <1432652139.86.0.658792169733.issue24289@psf.upfronthosting.co.za> Message-ID: <1432656874.27.0.72018136939.issue24289@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: -2to3 (2.x to 3.x conversion tool) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 18:20:12 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 26 May 2015 16:20:12 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1432657212.39.0.74192376237.issue21998@psf.upfronthosting.co.za> Yury Selivanov added the comment: > How do other event loops handle fork? Twisted, Tornado, libuv, libev, libevent, etc. It looks like using fork() while an event loop is running isn't recommended in any of the above. If I understand the code correctly, libev & gevent reinitialize loops in the forked process (essentially, you have a new loop). I think we have the following options: 1. Document that using fork() is not recommended. 2. Detect fork() and re-initialize event loop in the child process (cleaning-up callback queues, re-initializing selectors, creating new self-pipe). 3. Detect fork() and raise a RuntimeError. Document that asyncio event loop does not support forking at all. 4. The most recent patch by Martin detects the fork() and reinitializes self-pipe and selector (although all FDs are kept in the new selector). I'm not sure I understand this option. I'm torn between 2 & 3. Guido, Victor, Martin, what do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 18:49:32 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 26 May 2015 16:49:32 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1432658972.03.0.408560515652.issue21998@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think only (3) is reasonable -- raise RuntimeError. There are too many use cases to consider and the behavior of the selectors seems to vary as well. Apps should ideally not fork with an event loop open; the only reasonable thing to do after a fork with an event loop open is to exec another binary (hopefully closing FDs using close-on-exec). *Perhaps* it's possible to safely release some resources used by a loop after a fork but I'm skeptical even of that. Opportunistically closing the FDs used for the self-pipe and the selector seems fine (whatever is safe could be done the first time the loop is touched after the fork, just before raising RuntimeError). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 19:08:47 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 26 May 2015 17:08:47 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1432660127.58.0.209185039408.issue21998@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I think only (3) is reasonable -- raise RuntimeError. Just to be clear -- do we want to raise a RuntimeError in the parent, in the child, or both processes? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 19:23:26 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 26 May 2015 17:23:26 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1432661006.64.0.0508667950033.issue21998@psf.upfronthosting.co.za> Guido van Rossum added the comment: I was thinking only in the child. The parent should be able to continue to use the loop as if the fork didn't happen, right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 19:27:25 2015 From: report at bugs.python.org (Christian Heimes) Date: Tue, 26 May 2015 17:27:25 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1432661245.54.0.470030342019.issue21998@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 19:35:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 May 2015 17:35:25 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <20150526173522.16305.40971@psf.io> Roundup Robot added the comment: New changeset 5780ee2c18e1 by Raymond Hettinger in branch 'default': Issue #23509: Speed up Counter operators https://hg.python.org/cpython/rev/5780ee2c18e1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 19:51:24 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 26 May 2015 17:51:24 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1432662684.39.0.34715023867.issue21998@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I was thinking only in the child. The parent should be able to continue to use the loop as if the fork didn't happen, right? Yes, everything should be fine. I'll rephrase my question: do you think there is a way (and need) to at least throw a warning in the master process that the fork has failed (without monkey patching os.fork() which is not an option)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 19:55:12 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 26 May 2015 17:55:12 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1432662912.52.0.255179680574.issue21998@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't understand. If the fork fails nothing changes right? I guess I'm missing some context or use case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 20:01:08 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 26 May 2015 18:01:08 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1432663268.89.0.615264296464.issue21998@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I don't understand. If the fork fails nothing changes right? I guess I'm missing some context or use case. Maybe I'm wrong about this. My line of thoughts is: a failed fork() call is a bug in the program. Now, the master process will continue operating as it was, no warnings, no errors. The child process will crash with a RuntimeError exception. Will it be properly reported/logged? I guess the forked child will share the stderr, so the exception won't pass completely unnoticed, right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 20:03:16 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 26 May 2015 18:03:16 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1432663268.89.0.615264296464.issue21998@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: That's really the problem of the code that calls fork(), not directly of the event loop. There are some very solid patterns around that (I've written several in the distant past, and Unix hasn't changed that much :-). On Tue, May 26, 2015 at 11:01 AM, Yury Selivanov wrote: > > Yury Selivanov added the comment: > > > I don't understand. If the fork fails nothing changes right? I guess I'm > missing some context or use case. > > Maybe I'm wrong about this. My line of thoughts is: a failed fork() call > is a bug in the program. Now, the master process will continue operating > as it was, no warnings, no errors. The child process will crash with a > RuntimeError exception. Will it be properly reported/logged? > > I guess the forked child will share the stderr, so the exception won't > pass completely unnoticed, right? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 20:05:44 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 26 May 2015 18:05:44 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1432663544.27.0.892368255671.issue21998@psf.upfronthosting.co.za> Yury Selivanov added the comment: > That's really the problem of the code that calls fork(), not directly of > the event loop. There are some very solid patterns around that (I've > written several in the distant past, and Unix hasn't changed that much :-). Alright ;) I'll draft a patch sometime soon. ---------- assignee: -> yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 20:23:46 2015 From: report at bugs.python.org (Martin Richard) Date: Tue, 26 May 2015 18:23:46 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1432657212.39.0.74192376237.issue21998@psf.upfronthosting.co.za> Message-ID: Martin Richard added the comment: Hi, My patch was a variation of haypo's patch. The goal was to duplicate the loop and its internal objects (loop and self pipes) without changing much to its state from the outside (keeping callbacks and active tasks). I wanted to be conservative with this patch, but it is not the option I prefer. I think that raising a RuntimeError in the child is fine, but may not be enough: Imho, saying "the loop can't be used anymore in the child" is fine, but "a process in which lives an asyncio loop must not be forked" is too restrictive (I'm not thinking of the fork+exec case, which is probably fine anyway) because a library may rely on child processes, for instance. Hence, we should allow a program to fork and eventually dispose the resources of the loop by calling loop.close() - or any other mechanism that you see fit (clearing all references to the loop is tedious because of the global default event loop and the cycles between futures/tasks and the loop). However, the normal loop.close() sequence will unregister all the fds registered to the selector, which will impact the parent. Under Linux with epoll, it's fine if we only close the selector. I would therefore, in the child after a fork, close the loop without breaking the selector state (closing without unregister()'ing fds), unset the default loop so get_event_loop() would create a new loop, then raise RuntimeError. I can elaborate on the use case I care about, but in a nutshell, doing so would allow to spawn worker processes able to create their own loop without requiring an idle "blank" child process that would be used as a base for the workers. It adds the benefit, for instance, of allowing to share data between the parent and the child leveraging OS copy-on-write. 2015-05-26 18:20 GMT+02:00 Yury Selivanov : > > Yury Selivanov added the comment: > > > How do other event loops handle fork? Twisted, Tornado, libuv, libev, > libevent, etc. > > It looks like using fork() while an event loop is running isn't > recommended in any of the above. If I understand the code correctly, libev > & gevent reinitialize loops in the forked process (essentially, you have a > new loop). > > I think we have the following options: > > 1. Document that using fork() is not recommended. > > 2. Detect fork() and re-initialize event loop in the child process > (cleaning-up callback queues, re-initializing selectors, creating new > self-pipe). > > 3. Detect fork() and raise a RuntimeError. Document that asyncio event > loop does not support forking at all. > > 4. The most recent patch by Martin detects the fork() and reinitializes > self-pipe and selector (although all FDs are kept in the new selector). > I'm not sure I understand this option. > > I'm torn between 2 & 3. Guido, Victor, Martin, what do you think? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 20:40:31 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 26 May 2015 18:40:31 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1432593517.64.0.594669513833.issue16991@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: > Eric .... I realize that O (1) deletion is hard, and don't see a good way around it without changing the implementation ... I just think that the preserving the current C layout may be forcing an even more complicated solution than neccessary. I am nervous about pushing this to 3.5 because of the complexity. I agree that a simpler solution should (also?) wait for 3.6. Noted (and thanks for the feedback). I'm still comfortable with moving ahead for 3.5 with what we have. The code is documented and structured in such a way that it should be clear what's going on and relatively straightforward to adjust. There's a decent chance we will find a bug or two in corner cases, but nothing at a scale that would give me pause for a 3.5 release. Furthermore, the test suite for OrderedDict is pretty thorough so strict compatibility with the pure Python OrderedDict allows us to derive a lot of confidence about the C implementation. > > The question about dictheaher.h boils down to: if someone asks whether something is a dictview (not even using "exact", though that isn't an option), an odictview will say false ... is that really what you want? Ah. I misunderstood your question to imply what should be added. Instead, you were just indicating what is already there. I don't think anything needs to be changed though. Those checks don't pass for the pure Python OrderedDict so I would not expect them to do so for the C implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 20:40:52 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 26 May 2015 18:40:52 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1432665652.48.0.414557073893.issue21998@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I would therefore, in the child after a fork, close the loop without > breaking the selector state (closing without unregister()'ing fds), unset > the default loop so get_event_loop() would create a new loop, then raise > RuntimeError. > > I can elaborate on the use case I care about, but in a nutshell, doing so > would allow to spawn worker processes able to create their own loop without > requiring an idle "blank" child process that would be used as a base for > the workers. It adds the benefit, for instance, of allowing to share data > between the parent and the child leveraging OS copy-on-write. The only solution to safely fork a process is to fix loop.close() to check if it's called from a forked process and to close the loop in a safe way (to avoid breaking the master process). In this case we don't even need to throw a RuntimeError. But we won't have a chance to guarantee that all resources will be freed correctly (right?) So the idea is (I guess it's the 5th option): 1. If the forked child doesn't call loop.close() immediately after forking we raise RuntimeError on first loop operation. 2. If the forked child calls (explicitly) loop.close() -- it's fine, we just close it, the error won't be raised. When we close we only close the selector (without unregistering or re-regestering any FDs), we cleanup callback queues without trying to close anything). Guido, do you still think that raising a "RuntimeError" in a child process in an unavoidable way is a better option? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 20:56:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 May 2015 18:56:46 +0000 Subject: [issue24284] Inconsistency in startswith/endswith In-Reply-To: <1432554087.61.0.0896292215981.issue24284@psf.upfronthosting.co.za> Message-ID: <1432666606.54.0.000761270844716.issue24284@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please help me with wording? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 21:02:48 2015 From: report at bugs.python.org (Rony Batista) Date: Tue, 26 May 2015 19:02:48 +0000 Subject: [issue24290] c_uint32 bitfields break structures Message-ID: <1432666968.74.0.708060722657.issue24290@psf.upfronthosting.co.za> New submission from Rony Batista: ctypes Structures with c_uint32 bitfields have strange behaviour on OS X. In the attached code when the field "number" is set, it changes the whole 32 bits, even thou its meant to be 23 bits. The behavior is unexpected in: OS X: Python 2.7.9 The behavior is as expected in the following environments: Windows: python 2.7.9 Ubuntu: python 2.7.6 ---------- components: ctypes messages: 244125 nosy: Rony Batista priority: normal severity: normal status: open title: c_uint32 bitfields break structures type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 21:04:35 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 26 May 2015 19:04:35 +0000 Subject: [issue24290] c_uint32 bitfields break structures In-Reply-To: <1432666968.74.0.708060722657.issue24290@psf.upfronthosting.co.za> Message-ID: <1432667075.27.0.902380166813.issue24290@psf.upfronthosting.co.za> Ronald Oussoren added the comment: You forgot to actually attach the code. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 21:06:18 2015 From: report at bugs.python.org (Rony Batista) Date: Tue, 26 May 2015 19:06:18 +0000 Subject: [issue24290] c_uint32 bitfields break structures In-Reply-To: <1432666968.74.0.708060722657.issue24290@psf.upfronthosting.co.za> Message-ID: <1432667178.32.0.0937679196718.issue24290@psf.upfronthosting.co.za> Rony Batista added the comment: Silly me, Heres the code. ---------- Added file: http://bugs.python.org/file39508/ctypesBug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 21:16:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 May 2015 19:16:56 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <1432667816.03.0.843941539993.issue23509@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Perhaps correct __pos__ docstring? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 21:20:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 May 2015 19:20:44 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <1432668044.85.0.910825075467.issue23509@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Perhaps update __pos__ docstring? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 21:21:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 May 2015 19:21:12 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <1432668072.38.0.549739869021.issue23509@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- Removed message: http://bugs.python.org/msg244128 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 21:28:19 2015 From: report at bugs.python.org (Martin Richard) Date: Tue, 26 May 2015 19:28:19 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1432665652.48.0.414557073893.issue21998@psf.upfronthosting.co.za> Message-ID: Martin Richard added the comment: 015-05-26 20:40 GMT+02:00 Yury Selivanov : > > Yury Selivanov added the comment: > The only solution to safely fork a process is to fix loop.close() to > check if it's called from a forked process and to close the loop in > a safe way (to avoid breaking the master process). In this case > we don't even need to throw a RuntimeError. But we won't have a > chance to guarantee that all resources will be freed correctly (right?) > If all the tasks are cancelled and loop's internal structures (callback lists, tasks sets, etc) are cleared, I believe that the garbage collector will eventually be able to dispose everything. However, it's indeed not enough: resources created by other parts of asyncio may leak (transports, subprocess). For instance, I proposed to add a "detach()" method for SubprocessTransport here: http://bugs.python.org/issue23540 : in this case, I need to close stdin, stdout, stderr pipes without killing the subprocess. > So the idea is (I guess it's the 5th option): > > 1. If the forked child doesn't call loop.close() immediately after > forking we raise RuntimeError on first loop operation. > > 2. If the forked child calls (explicitly) loop.close() -- it's fine, > we just close it, the error won't be raised. When we close we only > close the selector (without unregistering or re-regestering any FDs), > we cleanup callback queues without trying to close anything). > > Guido, do you still think that raising a "RuntimeError" in a child > process in an unavoidable way is a better option? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 21:38:54 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 26 May 2015 19:38:54 +0000 Subject: [issue16500] Add an 'atfork' module In-Reply-To: <1353252005.31.0.454056781872.issue16500@psf.upfronthosting.co.za> Message-ID: <1432669134.39.0.713925952456.issue16500@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 22:18:01 2015 From: report at bugs.python.org (Jonathan Kamens) Date: Tue, 26 May 2015 20:18:01 +0000 Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs Message-ID: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za> New submission from Jonathan Kamens: The _write method of wsgiref.handlers.SimpleHandler reads as follows: def _write(self,data): self.stdout.write(data) The problem here is that calling write() on a socket is not actually guaranteed to write all of the data in the buffer. If the length of data is large enough, then the kernel will take only part of it. In that case, the rest of the response data will be silently discarded by wsgiref. _write needs to check the return value of self.stdout.write(data), and if it is less than the length of data, repeat the write from the middle of the data buffer, etc., until all the data has been written. ---------- components: Library (Lib) messages: 244131 nosy: Jonathan Kamens priority: normal severity: normal status: open title: wsgiref.handlers.SimpleHandler truncates large output blobs type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 22:22:05 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 26 May 2015 20:22:05 +0000 Subject: [issue24290] c_uint32 bitfields break structures In-Reply-To: <1432666968.74.0.708060722657.issue24290@psf.upfronthosting.co.za> Message-ID: <1432671725.51.0.645414863368.issue24290@psf.upfronthosting.co.za> Ned Deily added the comment: Without diving into the details of your test program, I get the same results on a 64-bit Debian Python 2.7.9 as with a 64-bit OS X 2.7.10: c_uint32 TESTS: Class Name exponent number Sign float binary repr IEEE754Float_u ('-0x7b', '0xbeb2aL', 0L, 69.95930480957031, ['0x42', '0x8b', '0xeb', '0x2a']) IEEE754Float_u ('-0x7b', '0xbeb2aL', 0L, 69.95930480957031, ['0x42', '0x8b', '0xeb', '0x2a']) AN575Float_uint ('0x0', '0xbeb2a', 0L, 1.094551427887186e-39, ['0x0', '0xb', '0xeb', '0x2a']) AN575Float_uint ('0x0', '0xbeb2a', 0L, 1.094551427887186e-39, ['0x0', '0xb', '0xeb', '0x2a']) AN575Float_uint ('-0x7b', '0xbeb2a', 0L, 1.094551427887186e-39, ['0x85', '0xb', '0xeb', '0x2a']) IEEE754Float_u ('-0x7b', '0xbeb2aL', 1L, -69.95930480957031, ['0xc2', '0x8b', '0xeb', '0x2a']) AN575Float_uint ('-0x7b', '0xbeb2a', 1L, 1.094551427887186e-39, ['0x85', '0x8b', '0xeb', '0x2a']) But using the same OS X 2.7.10 in 32-bit mode, I get: c_uint32 TESTS: Class Name exponent number Sign float binary repr IEEE754Float_u ('-0x7b', '0xbeb2aL', 0L, 69.95930480957031, ['0x42', '0x8b', '0xeb', '0x2a']) IEEE754Float_u ('-0x7b', '0xbeb2aL', 0L, 69.95930480957031, ['0x42', '0x8b', '0xeb', '0x2a']) AN575Float_uint ('-0x7b', '0xbeb2a', 0L, 69.95930480957031, ['0x85', '0xb', '0xeb', '0x2a']) AN575Float_uint ('-0x7b', '0xbeb2a', 0L, 69.95930480957031, ['0x85', '0xb', '0xeb', '0x2a']) AN575Float_uint ('-0x7b', '0xbeb2a', 0L, 69.95930480957031, ['0x85', '0xb', '0xeb', '0x2a']) IEEE754Float_u ('-0x7b', '0xbeb2aL', 1L, -69.95930480957031, ['0xc2', '0x8b', '0xeb', '0x2a']) AN575Float_uint ('-0x7b', '0xbeb2a', 1L, -69.95930480957031, ['0x85', '0x8b', '0xeb', '0x2a']) ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 22:28:30 2015 From: report at bugs.python.org (Tal Einat) Date: Tue, 26 May 2015 20:28:30 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432672110.38.0.556079919721.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: Attached is a revised patch including changed due to the reviews by Berker and Yuri. The significant changes from the previous patch are: 1. The "rel_tol" and "abs_tol" parameters have been made keyword-only. 2. The tests have been extracted into a separate TestCase sub-class. They are now better organized and will be easy to re-use for testing cmath.isclose when it is added (hopefully soon). ---------- Added file: http://bugs.python.org/file39509/math_isclose_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 22:28:40 2015 From: report at bugs.python.org (Jonathan Kamens) Date: Tue, 26 May 2015 20:28:40 +0000 Subject: [issue24292] wsgiref.simple_server.WSGIRequestHandler doesn't log request timeouts Message-ID: <1432672120.91.0.975009053361.issue24292@psf.upfronthosting.co.za> New submission from Jonathan Kamens: http.BaseHTTPRequestHandler logs request timeouts. In handle_one_request(): except socket.timeout as e: #a read or a write timed out. Discard this connection self.log_error("Request timed out: %r", e) self.close_connection = 1 return Unfortunately, wsgiref.simple_server.WSGIRequestHandler, which overrides BaseHTTPRequestHandler's handle() method, does _not_ catch and log request timeouts. Fixing this is a simple matter of wrapping the entire body of its handle() function in a try with this except clause: except socket.timeout as e: self.log_error("Request timed out: %r", e) raise ---------- components: Library (Lib) messages: 244134 nosy: Jonathan Kamens priority: normal severity: normal status: open title: wsgiref.simple_server.WSGIRequestHandler doesn't log request timeouts type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 22:30:26 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 26 May 2015 20:30:26 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1432672226.19.0.474389697549.issue21998@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't actually know if the 5th option is possible. My strong requirement is that no matter what the child process does, the parent should still be able to continue using the loop. IMO it's better to leak a FD in the child than to close a resource owned by the parent. Within those constraints I'm okay with various solutions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 22:52:02 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 26 May 2015 20:52:02 +0000 Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za> Message-ID: <1432673522.58.0.653015797387.issue24291@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +pje versions: +Python 3.6 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 22:52:31 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 26 May 2015 20:52:31 +0000 Subject: [issue24292] wsgiref.simple_server.WSGIRequestHandler doesn't log request timeouts In-Reply-To: <1432672120.91.0.975009053361.issue24292@psf.upfronthosting.co.za> Message-ID: <1432673551.39.0.258675631416.issue24292@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +pje versions: +Python 3.6 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 26 23:12:27 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 May 2015 21:12:27 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <1432674747.9.0.611128213837.issue23359@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file39510/new_set_timings.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 00:01:09 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 May 2015 22:01:09 +0000 Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za> Message-ID: <1432677669.14.0.201650936871.issue24291@psf.upfronthosting.co.za> Martin Panter added the comment: [UTF-8 error workaround] What kind of object is ?stdout?? Plain Python socket objects don?t have a write() method. Perhaps ?stdout? is meant to implement the BufferedIOBase.write() interface, which guarantees everything is written, even if it takes multiple raw calls. Wrapping your output stream in BufferedWriter might be a solution. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 00:14:53 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 May 2015 22:14:53 +0000 Subject: [issue24284] Inconsistency in startswith/endswith In-Reply-To: <1432554087.61.0.0896292215981.issue24284@psf.upfronthosting.co.za> Message-ID: <1432678493.77.0.425161429296.issue24284@psf.upfronthosting.co.za> Martin Panter added the comment: How about this for What?s New: * The :meth:`str.startswith` and :meth:`str.endswith` methods no longer return ``True`` when finding the empty string and the indexes are completely out of range. See :issue:`24284`. Perhaps that is good enough, but if you wanted to be more precise, I think the actual condition is if the *start* index is beyond the end of the string, or *end* is before *start*. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 01:20:49 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 May 2015 23:20:49 +0000 Subject: [issue23756] Tighten definition of bytes-like objects In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za> Message-ID: <1432682449.72.0.5483637244.issue23756@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 01:33:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 May 2015 23:33:13 +0000 Subject: [issue23648] PEP 475 meta issue In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za> Message-ID: <1432683193.3.0.555394550584.issue23648@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 01:59:01 2015 From: report at bugs.python.org (Mike Miller) Date: Tue, 26 May 2015 23:59:01 +0000 Subject: [issue24293] Windows installer unreadable with std/custom themes Message-ID: <1432684740.9.0.578796945246.issue24293@psf.upfronthosting.co.za> New submission from Mike Miller: The new Windows installer displays itself with an HTML (or perhaps skinned) interface with hard-coded white background which does not adhere to the desktop GUI color scheme chosen by the user. Many times this is only an aesthetic problem, but it may cause the window to be unreadable if the user is using a darker, custom color scheme, or one of the standard Accessible themes such as "High Contrast". Invariably the developer/framework sets only one out of two of the background/foreground pair, which I believe happened here. See attached, the white text is lost on a white background. Please set both the background/foreground to "system colors" to avoid this issue. These are available in CSS as well, though not commonly known. ---------- components: Installation, Windows files: pywin_setup.png messages: 244140 nosy: mixmastamyk, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows installer unreadable with std/custom themes type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file39511/pywin_setup.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 02:35:57 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 27 May 2015 00:35:57 +0000 Subject: [issue23560] Group the docs of similar methods in stdtypes.rst In-Reply-To: <1425288490.4.0.288876913126.issue23560@psf.upfronthosting.co.za> Message-ID: <1432686957.54.0.0967337680901.issue23560@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 02:43:35 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 27 May 2015 00:43:35 +0000 Subject: [issue24292] wsgiref.simple_server.WSGIRequestHandler doesn't log request timeouts In-Reply-To: <1432672120.91.0.975009053361.issue24292@psf.upfronthosting.co.za> Message-ID: <1432687415.24.0.345998798455.issue24292@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 03:02:41 2015 From: report at bugs.python.org (Tim Graham) Date: Wed, 27 May 2015 01:02:41 +0000 Subject: [issue22758] Regression in Python 3.2 cookie parsing In-Reply-To: <1414577677.93.0.364604019199.issue22758@psf.upfronthosting.co.za> Message-ID: <1432688561.76.0.0587494964285.issue22758@psf.upfronthosting.co.za> Changes by Tim Graham : Added file: http://bugs.python.org/file39512/secure-httponly-3.2-backport.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 03:03:39 2015 From: report at bugs.python.org (Tim Graham) Date: Wed, 27 May 2015 01:03:39 +0000 Subject: [issue22758] Regression in Python 3.2 cookie parsing In-Reply-To: <1414577677.93.0.364604019199.issue22758@psf.upfronthosting.co.za> Message-ID: <1432688619.82.0.100524912307.issue22758@psf.upfronthosting.co.za> Tim Graham added the comment: Patch rebased again after cookie fix from #22931. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 05:15:22 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 27 May 2015 03:15:22 +0000 Subject: [issue24293] Windows installer unreadable with std/custom themes In-Reply-To: <1432684740.9.0.578796945246.issue24293@psf.upfronthosting.co.za> Message-ID: <1432696522.03.0.12791354274.issue24293@psf.upfronthosting.co.za> Steve Dower added the comment: Thanks, good catch. I'm not entirely sure how we ended up in this state, since the background is actually the system colour and the text is currently hardcoded, but I'll go through and make sure that the system colour indexes are used throughout. FWIW, it's just plain Win32 UI, nothing special, but it does use some controls that were added in Windows XP and don't get used very often. ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 05:46:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 27 May 2015 03:46:46 +0000 Subject: [issue24293] Windows installer unreadable with std/custom themes In-Reply-To: <1432684740.9.0.578796945246.issue24293@psf.upfronthosting.co.za> Message-ID: <20150527034643.5091.9237@psf.io> Roundup Robot added the comment: New changeset a77214dbf1f3 by Steve Dower in branch '3.5': Issue #24293: Fixes installer colors to use system settings throughout. https://hg.python.org/cpython/rev/a77214dbf1f3 New changeset 37ed61b1234a by Steve Dower in branch 'default': Issue #24293: Fixes installer colors to use system settings throughout. https://hg.python.org/cpython/rev/37ed61b1234a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 05:47:19 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 27 May 2015 03:47: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: <1432698439.51.0.943100640999.issue24293@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 07:31:43 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 May 2015 05:31:43 +0000 Subject: [issue21970] Broken code for handling file://host in urllib.request.FileHandler.file_open In-Reply-To: <1405216161.05.0.3363234179.issue21970@psf.upfronthosting.co.za> Message-ID: <1432704703.18.0.256209299196.issue21970@psf.upfronthosting.co.za> Martin Panter added the comment: I do not believe the change fixes anything on its own. It essentially just changed the error message to something even worse, and the added test case already passes without the change. I am posting a patch which cleans up the code and related tests. It also fixes three minor theoretical bugs: >>> urlopen("file://127.0.0.1//dev/null") # Should succeed urllib.error.URLError: >>> urlopen("file://127.1//dev/null") # 127.1 is localhost; should succeed urllib.error.URLError: >>> urlopen("file://remote/missing") # Should not try to access local file urllib.error.URLError: The localhost check in file_open() was added by revision 982c8ec73ae3 for Issue 10063. But notice how all the test cases involve strange URLs like file://ftp.example.com//foo.txt, with second extra double slash. I removed the check, because it is redundant with the more thorough and correct check that has existed since 1994 (revision 020d8c2d9d3c) in open_local_file(). For cases like file://remote/nonlocal-file, I think it is better to raise the correct error, even if that requires a DNS check, rather than raising a faster error with a misleading message. So I moved the check before the stat() call inside open_local_file(). ---------- keywords: +patch stage: -> patch review type: -> behavior versions: +Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39513/file-handler.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 08:43:37 2015 From: report at bugs.python.org (Frank Schaefer) Date: Wed, 27 May 2015 06:43:37 +0000 Subject: [issue23575] MIPS64 needs ffi's n32.S In-Reply-To: <1425400037.86.0.872792301422.issue23575@psf.upfronthosting.co.za> Message-ID: <1432709017.55.0.797258753642.issue23575@psf.upfronthosting.co.za> Frank Schaefer added the comment: This patch alone is apparently not enough. When this is enabled, and python 2.7.10 is built with -mabi=n32, make test segfaults on test_ctypes. Using --with(out)-system-ffi does not make a difference. When I run the test by itself, it specifically fails at: test_pyobject (ctypes.test.test_callbacks.Callbacks) ... Segmentation fault (core dumped) I'm guessing Python is doing something bogus with libffi that kills it specifically on mips n32. ---------- nosy: +kelledin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 09:08:58 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 May 2015 07:08:58 +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: <1432710538.32.0.581306990082.issue24266@psf.upfronthosting.co.za> Martin Panter added the comment: I reported this to Gnu Readline: . So far it sounds like there is no general solution. I am posting a patch implementing Sebastian?s workaround. But my personal philosophy is to leave Python alone if it is not doing anything wrong and this is indeed a Readline bug. Chet also pointed out that there are other modes in addition to incremental search that are not cancelled. For instance, the ?argument? mode where you press Alt+ etc. ---------- keywords: +patch Added file: http://bugs.python.org/file39514/readline-cancel.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 10:06:30 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Wed, 27 May 2015 08:06:30 +0000 Subject: [issue24294] DeprecationWarnings should be visible by default in the interactive REPL Message-ID: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za> New submission from Nathaniel Smith: DeprecationWarning and PendingDeprecationWarning are invisible by default. The rationale for this is that they are only useful to people who are writing code, so they should not be shown to end-users who are merely running code. If someone is typing stuff into the interactive REPL, though, and the code they type uses some deprecated functionality, then we should actually show them this warning. We know that the author is sitting right there. And they're probably going to take whatever they tested interactively and move it into a more permanent form and ugh. This problem is particularly acute for packages that are primarily used through the interactive prompt, like numpy. I am tired of getting bugs like this: https://github.com/numpy/numpy/issues/5919 The solution is simple: when entering interactive mode, the REPL should do something like: warnings.filterwarnings("default", category=DeprecationWarning, module="__main__") warnings.filterwarnings("default", category=PendingDeprecationWarning, module="__main__") ---------- messages: 244147 nosy: njs priority: normal severity: normal status: open title: DeprecationWarnings should be visible by default in the interactive REPL type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 10:10:38 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Wed, 27 May 2015 08:10:38 +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: <1432714238.14.0.41752430531.issue24294@psf.upfronthosting.co.za> Nathaniel Smith added the comment: I also filed a similar bug with ipython: https://github.com/ipython/ipython/issues/8478 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 10:48:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 May 2015 08:48:21 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling In-Reply-To: <1368071216.78.0.0822877752405.issue17941@psf.upfronthosting.co.za> Message-ID: <1432716501.34.0.928506326459.issue17941@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > That will not work correctly if the module name has a dot in it. Pickling qualified names with arbitrary number of dots is supported in 3.4 with protocol 4 and in 3.5 with all protocols (backward compatibly). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 10:49:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 May 2015 08:49:19 +0000 Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za> Message-ID: <1432716559.22.0.639696879334.issue22955@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 Wed May 27 10:56:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 May 2015 08:56:04 +0000 Subject: [issue23914] pickle fails with SystemError In-Reply-To: <1428756762.72.0.925495036586.issue23914@psf.upfronthosting.co.za> Message-ID: <1432716964.02.0.516748442624.issue23914@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 10:58:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 May 2015 08:58:31 +0000 Subject: [issue23790] When xdrlib.Packer().pack_string() fails, the Packer is corrupted In-Reply-To: <1427461510.09.0.808726067558.issue23790@psf.upfronthosting.co.za> Message-ID: <1432717111.58.0.172404662815.issue23790@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> rejected stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 11:06:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 May 2015 09:06:35 +0000 Subject: [issue23513] Add support for classes/object model in multiprocessing/pickle In-Reply-To: <1424797303.36.0.545069200968.issue23513@psf.upfronthosting.co.za> Message-ID: <1432717595.1.0.809199512858.issue23513@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please provide full example that you want to work and test it in Python 3.5? I suppose your issue is fixed in 3.5. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 11:12:20 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 27 May 2015 09:12:20 +0000 Subject: [issue23574] datetime: support leap seconds In-Reply-To: <1425393743.39.0.519990063132.issue23574@psf.upfronthosting.co.za> Message-ID: <1432717940.06.0.148867122247.issue23574@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Here's what mxDateTime uses: >>> import mx.DateTime >>> >>> t1 = mx.DateTime.DateTime(2012,6,30,23,59,60) >>> t2 = mx.DateTime.DateTime(2012,7,1,0,0,0) >>> >>> t1 >>> t2 >>> >>> t2-t1 >>> (t2-t1).seconds 0.0 >>> >>> t1 + mx.DateTime.oneSecond It preserves the broken down values, but uses POSIX days of 86400 seconds per day to calculate time deltas. It's a compromise, not a perfect solution, but it prevents applications from failing for that one second every now and then. I don't believe there is a perfect solution, since what your application or users expect may well be different. All I can say is that raising exceptions in these rare cases is not what your users typically want :-) ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 11:12:24 2015 From: report at bugs.python.org (Thomas Guettler) Date: Wed, 27 May 2015 09:12:24 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432717944.19.0.885021932571.issue24259@psf.upfronthosting.co.za> Thomas Guettler added the comment: Who has enough knowledge of the tarfile module to create a good patch? ---------- nosy: +guettli _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 11:53:30 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 27 May 2015 09:53:30 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <1432720410.05.0.105336227318.issue23970@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I was away the last few days, so just found the changes now. IMO, it's a good idea to use a new module for the new compiler, but don't think it's a good idea to make the whole module private, since this implicitly disallows sub-classing the compiler class going forward, which people will need to do sooner or later. Why not rename the module to msvc14compiler (or some other public name) instead ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 12:36:54 2015 From: report at bugs.python.org (Moritz Sichert) Date: Wed, 27 May 2015 10:36:54 +0000 Subject: [issue24295] Backport of #17086 causes regression in setup.py Message-ID: <1432723014.0.0.831198232873.issue24295@psf.upfronthosting.co.za> New submission from Moritz Sichert: In 7955d769fdf5 a bug of #14330 got fixed and it got backported for 2.7. But these changes were reverted by another backport in 8ee6d96a1019 (which was a backport for #17086). The issue here is that right know setup.py looks for ssl and other libs' headers in /usr/include *first* before it searches in /usr/local/include. That makes it really hard to compile python with a setup where you have a newer version of openssl in /usr/local than the one in /usr. ---------- components: Build files: setup_regression.patch keywords: patch messages: 244154 nosy: moritzs priority: normal severity: normal status: open title: Backport of #17086 causes regression in setup.py type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file39515/setup_regression.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 12:44:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 May 2015 10:44:58 +0000 Subject: [issue18032] Optimization for set/frozenset.issubset() In-Reply-To: <1369223923.83.0.620034016791.issue18032@psf.upfronthosting.co.za> Message-ID: <1432723498.42.0.923554163407.issue18032@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In C implementation no need to create set object seen. More efficient way is to use bit array. Here is a patch that uses this approach. ./python -m timeit -s "s1 = set(range(1000))" "s1.issubset(range(1000))" Unpatched : 10000 loops, best of 3: 115 usec per loop bru's patch: 10000 loops, best of 3: 114 usec per loop My patch : 10000 loops, best of 3: 92.6 usec per loop ./python -m timeit -s "s1 = set(range(1000))" "s1.issubset(range(1, 1000))" Unpatched : 10000 loops, best of 3: 73.4 usec per loop bru's patch: 10000 loops, best of 3: 114 usec per loop My patch : 10000 loops, best of 3: 93 usec per loop ./python -m timeit -s "s1 = set(range(100))" "s1.issubset(range(1, 1000))" Unpatched : 10000 loops, best of 3: 73.6 usec per loop bru's patch: 10000 loops, best of 3: 89 usec per loop My patch : 10000 loops, best of 3: 62.4 usec per loop ./python -m timeit -s "s1 = set(range(100))" "s1.issubset(range(1000))" Unpatched : 10000 loops, best of 3: 75.5 usec per loop bru's patch: 100000 loops, best of 3: 8.77 usec per loop My patch : 100000 loops, best of 3: 5.34 usec per loop ./python -m timeit -s "s1 = set('a'); s2 = ['a'] + ['b'] * 10000" "s1.issubset(s2)" Unpatched : 1000 loops, best of 3: 326 usec per loop bru's patch: 1000000 loops, best of 3: 0.394 usec per loop My patch : 1000000 loops, best of 3: 0.409 usec per loop ./python -m timeit -s "s1 = set('a'); from itertools import repeat" "s1.issubset(repeat('a'))" Unpatched : NEVER FINISHES bru's patch: 1000000 loops, best of 3: 0.794 usec per loop My patch : 1000000 loops, best of 3: 0.725 usec per loop ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 14:08:20 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Wed, 27 May 2015 12:08:20 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1432728500.97.0.715596675671.issue23275@psf.upfronthosting.co.za> Changes by Ionel Cristian M?rie? : ---------- nosy: +ionelmc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 14:22:01 2015 From: report at bugs.python.org (Sandy Chapman) Date: Wed, 27 May 2015 12:22:01 +0000 Subject: [issue24296] Queue documentation note needed Message-ID: <1432729321.3.0.0746320695027.issue24296@psf.upfronthosting.co.za> New submission from Sandy Chapman: The example at the bottom of the following page should have a warning added: https://docs.python.org/2/library/queue.html The warning should be such that the user is informed that the threads in the example are not cleaned up and will continue to run. Any future additions to the queue will then be processed immediately by those threads. ---------- assignee: docs at python components: Documentation messages: 244156 nosy: Sandy Chapman, docs at python priority: normal severity: normal status: open title: Queue documentation note needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 14:28:34 2015 From: report at bugs.python.org (Rahul Gupta) Date: Wed, 27 May 2015 12:28:34 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1432729714.91.0.143520429848.issue23275@psf.upfronthosting.co.za> Rahul Gupta added the comment: isn't it logical? [] is a mutable data structure while () is a immutable data structure (b, a) = [1, 2] is fine because a and b are mutable ---------- nosy: +Rahul Gupta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 14:38:52 2015 From: report at bugs.python.org (Bruno Cauet) Date: Wed, 27 May 2015 12:38:52 +0000 Subject: [issue18032] Optimization for set/frozenset.issubset() In-Reply-To: <1369223923.83.0.620034016791.issue18032@psf.upfronthosting.co.za> Message-ID: <1432730332.68.0.380056323844.issue18032@psf.upfronthosting.co.za> Bruno Cauet added the comment: Serhiy, that sounds good but I think that you have forgotten to attach the mentioned patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 14:42:47 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Wed, 27 May 2015 12:42:47 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1432730567.25.0.556355917879.issue23275@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: [a, b] = (1, 2) is also fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 14:51:14 2015 From: report at bugs.python.org (Marius Gedminas) Date: Wed, 27 May 2015 12:51:14 +0000 Subject: [issue24297] Lib/symbol.py is out of sync with Grammar/Grammar Message-ID: <1432731074.7.0.288731701326.issue24297@psf.upfronthosting.co.za> New submission from Marius Gedminas: While investigating https://bitbucket.org/pypa/setuptools/issue/388/install-from-sdist-fails-on-python-350b1 I noticed that Grammar/Grammar changed in 3.5, but Lib/symbol.py wasn't updated. I'm not familiar with the CPython parser, but I suspect that adding/removing/splitting grammar rules causes the nonterminal symbol IDs to shift, which ought to require an update in symbol.py. Huh. Now I see a comment in the file says it is automatically generated, but in that case why wasn't that done when I did 'hg pull -u && make && make install'? Why is it checked into source control? ---------- components: Library (Lib) messages: 244160 nosy: mgedmin priority: normal severity: normal status: open title: Lib/symbol.py is out of sync with Grammar/Grammar versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 14:53:23 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 May 2015 12:53:23 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1432731203.28.5.52233799311e-05.issue23275@psf.upfronthosting.co.za> Martin Panter added the comment: I prefer to unpack into square brackets in general because it is a mnemonic for the star argument being a list: >>> (a, *b) = range(3) >>> a 0 >>> b # A list, even though it was unpacked using tuple-like syntax [1, 2] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 14:56:14 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 May 2015 12:56:14 +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: <1432731374.14.0.883384022136.issue24294@psf.upfronthosting.co.za> Martin Panter added the comment: I have learnt to run the interactive interpeter (and also most of my own scripts) with the -b -Wall options. But having these switched on automatically may not be a bad thing. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 15:00:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 May 2015 13:00:14 +0000 Subject: [issue18032] Optimization for set/frozenset.issubset() In-Reply-To: <1369223923.83.0.620034016791.issue18032@psf.upfronthosting.co.za> Message-ID: <1432731614.24.0.45109734964.issue18032@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, sorry. Here is it. ---------- Added file: http://bugs.python.org/file39516/set_issubset_bitarray.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 15:13:37 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 27 May 2015 13:13:37 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <1432732417.65.0.27836749318.issue23970@psf.upfronthosting.co.za> Steve Dower added the comment: I understood it only disallowed complaining about breaking changes without a deprecation cycle :) I'm sorry I didn't realize you were away. If you have examples of how subclassing this class (and not just CCompiler) is useful and does something that can't be done through the existing interface, then we'll have something to discuss. From past experiences, I now prefer to default to "disallow" inheritance by default, as it isn't a breaking change to allow it again in the future but you can't go the other way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 15:16:56 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 27 May 2015 13:16:56 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <1432732616.63.0.668494499523.issue23970@psf.upfronthosting.co.za> Mark Lawrence added the comment: If the name is changed I'd like to see something that doesn't reflect the msvc version, as my understanding is that from now on the old compatibility issues are gone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 15:26:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 May 2015 13:26:50 +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: <1432733210.0.0.431572155467.issue24294@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See discussion on Python-Ideas [1]. [1] http://comments.gmane.org/gmane.comp.python.ideas/32191 ---------- components: +Interpreter Core nosy: +serhiy.storchaka versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 15:27:30 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 May 2015 13:27:30 +0000 Subject: [issue24296] Queue documentation note needed In-Reply-To: <1432729321.3.0.0746320695027.issue24296@psf.upfronthosting.co.za> Message-ID: <1432733250.84.0.270504940836.issue24296@psf.upfronthosting.co.za> R. David Murray added the comment: If you know anything about threads you can see that the threads are not explicitly shut down. As a standalone example it is "correct", in that they get shut down at interpreter shutdown. I'm not sure it is appropriate to include what is essentially a thread tutorial note in the queue docs. A crosslink to threading would certainly be a good idea; perhaps the introductory sentence could be tweaked to point people who don't already know threads in the correct direction for enlightenment. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 15:28:10 2015 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 27 May 2015 13:28:10 +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: <1432733290.3.0.182171431546.issue24294@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 15:39:20 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 May 2015 13:39:20 +0000 Subject: [issue24297] Lib/symbol.py is out of sync with Grammar/Grammar In-Reply-To: <1432731074.7.0.288731701326.issue24297@psf.upfronthosting.co.za> Message-ID: <1432733960.78.0.751464523534.issue24297@psf.upfronthosting.co.za> R. David Murray added the comment: It is "automatically generated" in that it isn't hand-written. On the other hand, it isn't "automatically generated" in the sense of being part of the make process, ./python symbol.py is supposed to be run by hand when it is appropriate. A bit ago someone wrote tests for keyword.py that among other things made sure we didn't forget to update it when needed. Someone needs to write a similar test for symbol, it looks like. Whether or not one or both of these could be/should be incorporated into make (now that we have 'make touch' to deal with the consequences) is a separate question. As to why it is checked in, we check in almost all the build artifacts previous to the compile stage, so that there is no need to have an already-built python to build python from source. ---------- nosy: +benjamin.peterson, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 16:12:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 May 2015 14:12:13 +0000 Subject: [issue24288] Include/opcode.h is modified during building In-Reply-To: <1432626475.52.0.752359380395.issue24288@psf.upfronthosting.co.za> Message-ID: <1432735933.45.0.489503286968.issue24288@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think the intension was to produce aligned data, but the alignment of the second column was wrong. Here is a patch that corrects formatting. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file39517/generate_opcode_h_align.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 16:47:40 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 27 May 2015 14:47:40 +0000 Subject: [issue24297] Lib/symbol.py is out of sync with Grammar/Grammar In-Reply-To: <1432731074.7.0.288731701326.issue24297@psf.upfronthosting.co.za> Message-ID: <1432738060.01.0.616715895935.issue24297@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 16:49:02 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 14:49:02 +0000 Subject: [issue24288] Include/opcode.h is modified during building In-Reply-To: <1432626475.52.0.752359380395.issue24288@psf.upfronthosting.co.za> Message-ID: <1432738141.99.0.992778313998.issue24288@psf.upfronthosting.co.za> Yury Selivanov added the comment: lgtm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 16:54:44 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 27 May 2015 14:54:44 +0000 Subject: [issue24296] Queue documentation note needed In-Reply-To: <1432729321.3.0.0746320695027.issue24296@psf.upfronthosting.co.za> Message-ID: <1432738484.69.0.669994528186.issue24296@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:02:02 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 27 May 2015 15:02:02 +0000 Subject: [issue24296] Queue documentation note needed In-Reply-To: <1432729321.3.0.0746320695027.issue24296@psf.upfronthosting.co.za> Message-ID: <1432738922.48.0.00525454748975.issue24296@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It is normal for daemon threads to not be shut down. That is why they exist. The purpose of Queue.join() is to give other threads a way to know when daemons have finished doing their work (i.e. a print manager thread to indicate that it is done printing). If the worker threads were actually going to terminate, you wouldn't need Queue.join(), you would use a Thread.join(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:04:50 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 15:04:50 +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: <1432739090.78.0.759327247498.issue24244@psf.upfronthosting.co.za> Yury Selivanov added the comment: timemodule.c no longer compiles on MacOSX: gcc -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/yury/dev/py/cpython/Include -I/Users/yury/dev/py/cpython -c /Users/yury/dev/py/cpython/Modules/timemodule.c -o build/temp.macosx-10.10-x86_64-3.5/Users/yury/dev/py/cpython/Modules/timemodule.o /Users/yury/dev/py/cpython/Modules/timemodule.c:656:9: error: use of undeclared identifier '_Py_BEGIN_SUPPRESS_IPH' _Py_BEGIN_SUPPRESS_IPH ^ /Users/yury/dev/py/cpython/Modules/timemodule.c:658:9: error: use of undeclared identifier '_Py_END_SUPPRESS_IPH' _Py_END_SUPPRESS_IPH ^ 2 errors generated. ---------- nosy: +yselivanov priority: normal -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:09:32 2015 From: report at bugs.python.org (Tal Einat) Date: Wed, 27 May 2015 15:09:32 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432739372.29.0.145498014794.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: Attached yet another revised version of the math.isclose() patch. This patch fixes a problem with the tests in the previous patch which causes them to fail when the full test suite is run. I've also slightly reworded the doc-string. Hopefully this is ready to go in! ---------- Added file: http://bugs.python.org/file39518/math_isclose_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:10:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 27 May 2015 15:10:14 +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: <20150527151011.17103.21747@psf.io> Roundup Robot added the comment: New changeset 843fe7e831a8 by Yury Selivanov in branch '3.5': Issue 24297: Update symbol.py. See also issue 24017. https://hg.python.org/cpython/rev/843fe7e831a8 New changeset 87509d71653b by Yury Selivanov in branch 'default': Issue 24297: Update symbol.py. See also issue 24017. https://hg.python.org/cpython/rev/87509d71653b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:10:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 27 May 2015 15:10:14 +0000 Subject: [issue24297] Lib/symbol.py is out of sync with Grammar/Grammar In-Reply-To: <1432731074.7.0.288731701326.issue24297@psf.upfronthosting.co.za> Message-ID: <20150527151011.17103.56073@psf.io> Roundup Robot added the comment: New changeset 843fe7e831a8 by Yury Selivanov in branch '3.5': Issue 24297: Update symbol.py. See also issue 24017. https://hg.python.org/cpython/rev/843fe7e831a8 New changeset 87509d71653b by Yury Selivanov in branch 'default': Issue 24297: Update symbol.py. See also issue 24017. https://hg.python.org/cpython/rev/87509d71653b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:18:52 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 27 May 2015 15:18:52 +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: <1432739932.78.0.484653253969.issue24244@psf.upfronthosting.co.za> Steve Dower added the comment: That change was in for beta 1, so we would have noticed if we didn't get Mac builds. Something else has changed, probably some headers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:26:10 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 15:26:10 +0000 Subject: [issue24297] Lib/symbol.py is out of sync with Grammar/Grammar In-Reply-To: <1432731074.7.0.288731701326.issue24297@psf.upfronthosting.co.za> Message-ID: <1432740370.39.0.708577569292.issue24297@psf.upfronthosting.co.za> Yury Selivanov added the comment: Attached is a new unittest to make sure that symbol.py is always updated. Essentially it's the same test that we have for keywords.py. Please review. ---------- assignee: -> yselivanov keywords: +patch nosy: +yselivanov stage: -> patch review versions: +Python 3.6 Added file: http://bugs.python.org/file39519/test_symbol.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:33:36 2015 From: report at bugs.python.org (Petr Viktorin) Date: Wed, 27 May 2015 15:33:36 +0000 Subject: [issue24298] inspect.signature includes bound argument for wrappers around bound methods Message-ID: <1432740816.68.0.329507187443.issue24298@psf.upfronthosting.co.za> New submission from Petr Viktorin: When obtaining the signature of a bound method, inspect.signature, by default, omits the "self" argument to the method, since it is already specified in the bound method. However, if you create a wrapper around a bound method with functools.update_wrapper() or @functools.wraps, calling inspect.signature on the wrapper will return a signature which includes the "self" argument. Reproducer: import inspect import functools class Foo(object): def bar(self, testarg): pass f = Foo() @functools.wraps(f.bar) def baz(*args): f.bar(*args) assert inspect.signature(baz) == inspect.signature(f.bar) The program will fail with an assertion error. Examining inspect.signature(baz) shows: >>> print(inspect.signature(baz)) (self, testarg) >>> print(inspect.signature(f.bar)) (testarg) Looking at the code in inspect.py: The handling of bound methods appears at the top of inspect._signature_internal(). Since baz is not itself a bound method, it doesn't trigger this case. Instead inspect.unwrap is called, returning f.bar. inspect._signature_is_functionlike(f.bar) returns True, causing Signature.from_function to be called. Unlike the direct bound method case, this includes the bound method's "self" argument. ---------- messages: 244178 nosy: encukou priority: normal severity: normal status: open title: inspect.signature includes bound argument for wrappers around bound methods versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:33:45 2015 From: report at bugs.python.org (Petr Viktorin) Date: Wed, 27 May 2015 15:33:45 +0000 Subject: [issue24298] inspect.signature includes bound argument for wrappers around bound methods In-Reply-To: <1432740816.68.0.329507187443.issue24298@psf.upfronthosting.co.za> Message-ID: <1432740825.14.0.0438667200335.issue24298@psf.upfronthosting.co.za> Petr Viktorin added the comment: Reported by David Gibson here: https://bugzilla.redhat.com/show_bug.cgi?id=1201990 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:42:03 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 May 2015 15:42:03 +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: <1432741323.12.0.553159311275.issue24244@psf.upfronthosting.co.za> Ned Deily added the comment: Yury, I'm not seeing that compile error with current head of default on OS X. Try a clean build, perhaps? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:43:31 2015 From: report at bugs.python.org (John Beck) Date: Wed, 27 May 2015 15:43:31 +0000 Subject: [issue24299] 2.7.10 test__locale.py change breaks on Solaris Message-ID: <1432741411.37.0.656292350471.issue24299@psf.upfronthosting.co.za> New submission from John Beck: The upgrade from 2.7.9 to 2.7.10 resulted in test__locale failing. This test had previously succeeded. The difference is that the thousands-separator for the fr_FR locale in known_numerics was changed from '' (i.e., unknown) to ' ' (i.e. space). But on Solaris, '\xa0' (i.e., non-break space in ISO8859-1) is what the fr_FR locale returns for LC_NUMERIC's thousands-separator. I inquired with our Globalization experts, who replied: --- The short answer is that CLDR defines the group separator as no-break space (U+00A0): http://st.unicode.org/cldr-apps/v#/fr/Symbols/ so the solaris locale fr_FR (=fr_FR.ISO8859-1) is correct. The long answer is that the situation is confusing, the fr_FR.ISO8859-1 defines the thousands_sep as no-break space, but fr_FR.UTF-8 defines the thousands_sep as space (U+0020). There is no technical limit, but combination of POSIX [1] and C language [2] limits the thousands_sep to single byte character. The no-break space is single byte character in ISO8859-1, but multibyte in UTF-8. [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html#tag_07_03_04 [2] http://en.cppreference.com/w/c/locale/lconv && http://en.cppreference.com/w/c/language/character_constant --- The attached patch fixes the test on Solaris. It is not clear if this is the Right Answer for all platforms, but I offer the attached patch in case it helps anyone else. ---------- components: Library (Lib) files: 25-test__locale.patch keywords: patch messages: 244181 nosy: jbeck priority: normal severity: normal status: open title: 2.7.10 test__locale.py change breaks on Solaris type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file39520/25-test__locale.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:45:16 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 15:45:16 +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: <1432741516.54.0.124908589143.issue24244@psf.upfronthosting.co.za> Yury Selivanov added the comment: This exact sequence of commands $ make clean $ ./configure $ make -j8 does not build. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:48:01 2015 From: report at bugs.python.org (pankaj.s01) Date: Wed, 27 May 2015 15:48:01 +0000 Subject: [issue24300] Code Refactoring in function nis_mapname() Message-ID: <1432741681.07.0.0289282459532.issue24300@psf.upfronthosting.co.za> New submission from pankaj.s01: Hi, Here , A code refactoring patch have been submitted for Function: nis_mapname() and File: Python-3.4.3/Modules/nismodule.c Please Review it, Thanks, Pankaj ---------- components: Extension Modules files: Python-3.4.3-nismodule.patch keywords: patch messages: 244183 nosy: pankaj.s01 priority: normal severity: normal status: open title: Code Refactoring in function nis_mapname() type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file39521/Python-3.4.3-nismodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:49:38 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 15:49:38 +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: <1432741778.82.0.936313163556.issue24244@psf.upfronthosting.co.za> Yury Selivanov added the comment: $ hg status shows nothing, branch is default (but 3.5 doesn't get built either) etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:56:00 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 May 2015 15:56:00 +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: <1432742160.89.0.16622907022.issue24244@psf.upfronthosting.co.za> Ned Deily added the comment: I think you have a Python installed in /usr/local that is interfering. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:56:50 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 15:56:50 +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: <1432742210.77.0.273780758342.issue24244@psf.upfronthosting.co.za> Yury Selivanov added the comment: But why was it building just fine before this commit? I haven't updated my system packages in a while. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:56:55 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 27 May 2015 15:56:55 +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: <1432742215.65.0.586543382652.issue24244@psf.upfronthosting.co.za> Steve Dower added the comment: Those macros are only included if Py_BUILD_CORE is defined, regardless of platform (see Include/pyport.h). Is it possible that's being undefined somehow? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 17:59:03 2015 From: report at bugs.python.org (Eric Gorr) Date: Wed, 27 May 2015 15:59:03 +0000 Subject: [issue24301] gzip module failing to decompress valid compressed file Message-ID: <1432742343.38.0.978535326882.issue24301@psf.upfronthosting.co.za> New submission from Eric Gorr: I have a file whose first four bytes are 1F 8B 08 00 and if I use gunzip from the command line, it outputs: gzip: zImage_extracted.gz: decompression OK, trailing garbage ignored and correctly decompresses the file. However, if I use the gzip module to read and decompress the data, I get the following exception thrown: File "/usr/lib/python3.4/gzip.py", line 360, in read while self._read(readsize): File "/usr/lib/python3.4/gzip.py", line 433, in _read if not self._read_gzip_header(): File "/usr/lib/python3.4/gzip.py", line 297, in _read_gzip_header raise OSError('Not a gzipped file') I believe the problem I am facing is the same one described here in this SO question and answer: http://stackoverflow.com/questions/4928560/how-can-i-work-with-gzip-files-which-contain-extra-data This would appear to be serious bug in the gzip module that needs to be fixed. ---------- components: Extension Modules messages: 244188 nosy: Eric Gorr priority: normal severity: normal status: open title: gzip module failing to decompress valid compressed file type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 18:02:32 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 May 2015 16:02:32 +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: <1432742552.12.0.176572170032.issue24244@psf.upfronthosting.co.za> Ned Deily added the comment: Wild guess: perhaps you did a ./configure or the Makefile did an implicit call to configure recently and/or you did a make install (to /usr/local) before? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 18:04:06 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 16:04:06 +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: <1432742646.71.0.488859189959.issue24244@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Wild guess: perhaps you did a ./configure or the Makefile did an implicit call to configure recently and/or you did a make install (to /usr/local) before? I don't have 'python' in /usr/local and /usr/local/bin ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 18:05:40 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 May 2015 16:05:40 +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: <1432742740.5.0.323616659348.issue24244@psf.upfronthosting.co.za> Ned Deily added the comment: But do you have any Python header files in /usr/local/include? The gcc command you pasted shows -I/usr/local/include? Mine don't show that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 18:07:25 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 16:07:25 +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: <1432742845.83.0.328006619186.issue24244@psf.upfronthosting.co.za> Yury Selivanov added the comment: yury at ysmac ~/dev/py/cpython (HG: default?) $ ls /usr/local/include/ librtmp osxfuse pycairo ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 18:11:48 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 16:11:48 +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: <1432743108.47.0.751511205289.issue24244@psf.upfronthosting.co.za> Yury Selivanov added the comment: FWIW, I think that in order to use _Py_BEGIN_SUPPRESS_IPH timemodule.c should be compiled with PY_CORE_CFLAGS, and that should be reflected in the Makefile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 18:16:19 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 27 May 2015 16:16:19 +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: <1432743379.29.0.193239197372.issue24244@psf.upfronthosting.co.za> Steve Dower added the comment: Looking at a `grep PY_CORE_CFLAGS`, that sounds reasonable to me. I assumed that all core files were already being compiled with Py_BUILD_CORE (they certainly are for Windows), so this seems to be an oversight for timemodule.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 18:30:45 2015 From: report at bugs.python.org (pankaj.s01) Date: Wed, 27 May 2015 16:30:45 +0000 Subject: [issue24302] Dead Code of Handler check in function faulthandler_fatal_error() Message-ID: <1432744245.29.0.369253683429.issue24302@psf.upfronthosting.co.za> New submission from pankaj.s01: Hi, There is dead code reported in this issue and I think no need to check for NULL of 'handler' in function faulthandler_fatal_error() and file Python-3.4.3/Modules/faulthandler.c . where 'handler' is pointed to staic array faulthandler_handlers[] which never will be null inside loop with faulthandler_nsignals value and doesn't means to check for NULL outside of loop. but if there is possibility of 'handler' to be NULL then it should be check inside the loop until handler->signum is not equal to signum and then break; ---------- components: Extension Modules files: Python-3.4.3-faulthandler.patch keywords: patch messages: 244195 nosy: pankaj.s01 priority: normal severity: normal status: open title: Dead Code of Handler check in function faulthandler_fatal_error() type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file39522/Python-3.4.3-faulthandler.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 18:33:02 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 16:33:02 +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: <1432744382.38.0.261651826533.issue24244@psf.upfronthosting.co.za> Yury Selivanov added the comment: Steve, maybe you can surround "_Py_BEGIN_SUPPRESS_IPH" with "#ifdef Py_BUILD_CORE"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 18:34:25 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 16:34:25 +0000 Subject: [issue24298] inspect.signature includes bound argument for wrappers around bound methods In-Reply-To: <1432740816.68.0.329507187443.issue24298@psf.upfronthosting.co.za> Message-ID: <1432744465.8.0.903901787058.issue24298@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 18:34:40 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 16:34:40 +0000 Subject: [issue24298] inspect.signature includes bound argument for wrappers around bound methods In-Reply-To: <1432740816.68.0.329507187443.issue24298@psf.upfronthosting.co.za> Message-ID: <1432744480.65.0.0834395991683.issue24298@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 18:51:29 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 May 2015 16:51:29 +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: <1432745489.55.0.477394722178.issue24244@psf.upfronthosting.co.za> Ned Deily added the comment: Yury, another (less) wild guess: do you have an out-of-date Modules/Setup or Setup.local? timemodule is defined in Setup.dist but that will be overridden by a locally modified copy in the Modules directory. Towards the end of the configured top-level Makefile, you should see: # Rules appended by makedepend [...] Modules/timemodule.o: $(srcdir)/Modules/timemodule.c; $(CC) $(PY_CORE_CFLAGS) -c $(srcdir)/Modules/timemodule.c -o Modules/timemodule.o ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 18:51:43 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 27 May 2015 16:51:43 +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: <1432745503.36.0.860788510809.issue24244@psf.upfronthosting.co.za> Steve Dower added the comment: When do we build timemodule.c outside of core? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 18:54:53 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 16:54:53 +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: <1432745693.72.0.435760596574.issue24244@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Towards the end of the configured top-level Makefile, you should see: Yes, I don't see that line. What should I do to regenerate it? And another question: what did go wrong with my checkout? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 18:55:43 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 May 2015 16:55:43 +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: <1432745743.33.0.904683572726.issue24244@psf.upfronthosting.co.za> Ned Deily added the comment: Check the times and contents on all of your Modules/Setup* files. Try deleting Setup.local for one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 19:07:28 2015 From: report at bugs.python.org (Majeed Arni) Date: Wed, 27 May 2015 17:07:28 +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: <1432746448.86.0.702137572784.issue24244@psf.upfronthosting.co.za> Majeed Arni added the comment: Though %f is a valid format from Python's doc https://docs.python.org/2/library/datetime.html, the fix just ignores it on Windows? can we atleast get milliseconds on Windows and Micro on Linux? %f Microsecond as a decimal number, zero-padded on the left. 000000, 000001, ..., 999999 (4) %f is an extension to the set of format characters in the C standard (but implemented separately in datetime objects, and therefore always available). When used with the strptime() method, the %f directive accepts from one to six digits and zero pads on the right. New in version 2.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 19:12:39 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 17:12:39 +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: <1432746759.85.0.83466757247.issue24244@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Check the times and contents on all of your Modules/Setup* files. Try deleting Setup.local for one. I just made a clean checkout and that helped. I have no idea what caused this. Thank you, Ned, for troubleshooting this with me! ---------- priority: critical -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 19:26:56 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 May 2015 17:26:56 +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: <1432747616.07.0.679099318303.issue24244@psf.upfronthosting.co.za> R. David Murray added the comment: Note that when I run into build problems after an update, I generally run 'make distclean' and then redo the configure/make. This generally cleans up any problems like this (and I don't find that I need to do it very often.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 19:34:50 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 May 2015 17:34:50 +0000 Subject: [issue24302] Dead Code of Handler check in function faulthandler_fatal_error() In-Reply-To: <1432744245.29.0.369253683429.issue24302@psf.upfronthosting.co.za> Message-ID: <1432748090.21.0.702301260895.issue24302@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 19:35:40 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 May 2015 17:35:40 +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: <1432748140.0.0.185515587539.issue24244@psf.upfronthosting.co.za> Ned Deily added the comment: > Note that when I run into build problems after an update, I generally > run 'make distclean' and then redo the configure/make. Yes, but I believe that won't help with changed Modules/Setup* files and, because it is needed in the core interpreter executable, timemodule.c is supposed to be built using Setup and not setup.py. Setup and Setup.local are designed to be locally modified and thus not revision controlled nor cleaned by make clean: $ cat Modules/Setup.dist # The file Setup is used by the makesetup script to construct the files # Makefile and config.c, from Makefile.pre and config.c.in, # respectively. The file Setup itself is initially copied from # Setup.dist; once it exists it will not be overwritten, so you can edit # Setup to your heart's content. Note that Makefile.pre is created # from Makefile.pre.in by the toplevel configure script. [...] $ hg stat --all Modules I Modules/Setup I Modules/Setup.config I Modules/Setup.local ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 19:37:29 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 27 May 2015 17:37:29 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <20150527173726.16461.33413@psf.io> Roundup Robot added the comment: New changeset cd1e1715becd by Raymond Hettinger in branch 'default': Issue #23359: Specialize set_lookkey intoa lookup function and an insert function. https://hg.python.org/cpython/rev/cd1e1715becd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 19:37:50 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 27 May 2015 17:37:50 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <1432748270.31.0.883533389725.issue23359@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 19:41:02 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 May 2015 17:41:02 +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: <1432748462.25.0.235970092539.issue24244@psf.upfronthosting.co.za> R. David Murray added the comment: Right, that's why I said make *dist*clean. That does delete any existing Setup file(s), which is what you want when working with a checkout for Python development purposes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 19:44:03 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 May 2015 17:44:03 +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: <1432748643.36.0.0659541746949.issue24244@psf.upfronthosting.co.za> Ned Deily added the comment: So you did, sorry! Another, perhaps evan more reliable option is (requires enabling the purge extension in hg): hg purge --all ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 19:47:39 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 27 May 2015 17:47:39 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1432748859.49.0.419771343335.issue23275@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Berker's patch looks good. It has several virtues: * the error message is reasonable and clear * it makes the language more consistent * it doesn't break any existing code. * it makes the AST a little simpler and faster by removing a special case The patch needs to updated: * remove the whatsnew entry * fix test_codeop which expects "del ()" to raise SyntaxError * fix test_syntax which fails on "() = 1" and "del ()" * fix test_with which fails on "with mock as ()" ---------- assignee: -> rhettinger versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 19:52:24 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Wed, 27 May 2015 17:52:24 +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: <1432749144.4.0.837752899467.issue24294@psf.upfronthosting.co.za> Changes by Thomas Kluyver : ---------- nosy: +takluyver _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 19:53:33 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 May 2015 17:53:33 +0000 Subject: [issue24295] Backport of #17086 causes regression in setup.py In-Reply-To: <1432723014.0.0.831198232873.issue24295@psf.upfronthosting.co.za> Message-ID: <1432749213.37.0.220080329966.issue24295@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +doko priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 20:07:07 2015 From: report at bugs.python.org (Matthias Klose) Date: Wed, 27 May 2015 18:07:07 +0000 Subject: [issue24295] Backport of #17086 causes regression in setup.py In-Reply-To: <1432723014.0.0.831198232873.issue24295@psf.upfronthosting.co.za> Message-ID: <1432750027.84.0.103710868812.issue24295@psf.upfronthosting.co.za> Matthias Klose added the comment: I'll look at this in June. I don't think that reverting is the right choice here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 20:12:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 May 2015 18:12:06 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <1432750326.3.0.487672049975.issue23359@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why you have added entry->hash == 0? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 20:22:59 2015 From: report at bugs.python.org (Paul Hobbs) Date: Wed, 27 May 2015 18:22:59 +0000 Subject: [issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping. Message-ID: <1432750979.18.0.523128349285.issue24303@psf.upfronthosting.co.za> New submission from Paul Hobbs: Using pid namespacing it is possible to have multiple processes with the same pid. "semlock_new" creates a semaphore file with the template "/dev/shm/mp{pid}-{counter}". This can conflict if the same semaphore file already exists due to another Python process have the same pid. This bug has been fixed in Python3: https://bugs.python.org/issue8713. However, that patch is very large (40 files, ~4.4k changed lines) and only incidentally fixes this bug while introducing a large backwards-incompatible refactoring and feature addition. The following small patch to just _multiprocessing/semaphore.c fixes the problem by using the system clock and retrying to avoid conflicts: --- a/Modules/_multiprocessing/semaphore.c +++ b/Modules/_multiprocessing/semaphore.c @@ -7,6 +7,7 @@ */ #include "multiprocessing.h" +#include enum { RECURSIVE_MUTEX, SEMAPHORE }; @@ -419,7 +420,7 @@ semlock_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { char buffer[256]; SEM_HANDLE handle = SEM_FAILED; - int kind, maxvalue, value; + int kind, maxvalue, value, try; PyObject *result; static char *kwlist[] = {"kind", "value", "maxvalue", NULL}; static int counter = 0; @@ -433,10 +434,24 @@ semlock_new(PyTypeObject *type, PyObject *args, PyObject *kwds) return NULL; } - PyOS_snprintf(buffer, sizeof(buffer), "/mp%ld-%d", (long)getpid(), counter++); + /* With pid namespaces, we may have multiple processes with the same pid. + * Instead of relying on the pid to be unique, we use the microseconds time + * to attempt to a unique filename. */ + for (try = 0; try < 100; ++try) { + struct timespec tv; + long arbitrary = clock_gettime(CLOCK_REALTIME, &tv) ? 0 : tv.tv_nsec; + PyOS_snprintf(buffer, sizeof(buffer), "/mp%ld-%d-%ld", + (long)getpid(), + counter++, + arbitrary); + SEM_CLEAR_ERROR(); + handle = SEM_CREATE(buffer, value, maxvalue); + if (handle != SEM_FAILED) + break; + else if (errno != EEXIST) + goto failure; + } - SEM_CLEAR_ERROR(); - handle = SEM_CREATE(buffer, value, maxvalue); /* On Windows we should fail if GetLastError()==ERROR_ALREADY_EXISTS */ if (handle == SEM_FAILED || SEM_GET_LAST_ERROR() != 0) goto failure; ---------- messages: 244211 nosy: Paul Hobbs priority: normal severity: normal status: open title: OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping. type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 20:24:39 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 May 2015 18:24:39 +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: <1432751079.45.0.514884978282.issue24303@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +devin, sbt stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 20:25:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 May 2015 18:25:24 +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: <1432751124.14.0.787770261139.issue24299@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is not the Right Answer because on Linux the thousands-separator for the fr_FR locale is a space. Perhaps better solution would be to specify the UTF-8 encoding for fr_FR locale. ---------- assignee: -> serhiy.storchaka nosy: +lemburg, loewis, serhiy.storchaka stage: -> patch review versions: +Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39523/issue24299-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 20:26:02 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 May 2015 18:26:02 +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: <1432751162.39.0.360281682207.issue24303@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +davin -devin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 20:26:29 2015 From: report at bugs.python.org (Mike Frysinger) Date: Wed, 27 May 2015 18:26:29 +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: <1432751189.01.0.163602002572.issue24303@psf.upfronthosting.co.za> Changes by Mike Frysinger : ---------- nosy: +vapier _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 20:32:17 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 27 May 2015 18:32:17 +0000 Subject: [issue24288] Include/opcode.h is modified during building In-Reply-To: <1432626475.52.0.752359380395.issue24288@psf.upfronthosting.co.za> Message-ID: <20150527183214.5085.51378@psf.io> Roundup Robot added the comment: New changeset 055834bb3685 by Serhiy Storchaka in branch '3.5': Issue #24288: Generated opcode.h no longer contains trailing spaces and tabs. https://hg.python.org/cpython/rev/055834bb3685 New changeset 9d9438cac3db by Serhiy Storchaka in branch 'default': Issue #24288: Generated opcode.h no longer contains trailing spaces and tabs. https://hg.python.org/cpython/rev/9d9438cac3db ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 20:32:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 May 2015 18:32:47 +0000 Subject: [issue24288] Include/opcode.h is modified during building In-Reply-To: <1432626475.52.0.752359380395.issue24288@psf.upfronthosting.co.za> Message-ID: <1432751567.25.0.721924044852.issue24288@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 20:47:45 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 May 2015 18:47:45 +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: <1432752465.21.0.289382051343.issue24301@psf.upfronthosting.co.za> Ned Deily added the comment: Can you add a public copy of a file that fails this way? There are several open issues with gzip, like Issue1159051, that might cover this but it's hard to know for sure without a test case. ---------- nosy: +ned.deily type: crash -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 21:36:19 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 27 May 2015 19:36: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: <1432755379.9.0.671556897744.issue24303@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 21:43:45 2015 From: report at bugs.python.org (flying sheep) Date: Wed, 27 May 2015 19:43:45 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1432755825.9.0.0761506503114.issue23275@psf.upfronthosting.co.za> flying sheep added the comment: > isn't it logical? > > [] is a mutable data structure > while () is a immutable data structure but you don?t assign to data structures, but to names. you *modify* data structures. and in the square bracket assignment syntax you don?t modify the list created by the []. in fact the [] never even create a list. ????????????????????????????? also it?s news to me that [a, b] = range(2) works! i always did a, b = range(2), and knew that (a, b) = range(2) works. but assigning to something looking like a list literal is new and surprising to me. (and i thought i?ve mastered every corner of python?s syntax) ---------- nosy: +flying sheep _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 21:59:27 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 19:59:27 +0000 Subject: [issue24298] inspect.signature includes bound argument for wrappers around bound methods In-Reply-To: <1432740816.68.0.329507187443.issue24298@psf.upfronthosting.co.za> Message-ID: <1432756767.2.0.318321826145.issue24298@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks for reporting this, Petr! Nick, could you please take a look at the patch? ---------- assignee: -> yselivanov keywords: +patch stage: -> patch review versions: +Python 3.6 Added file: http://bugs.python.org/file39524/signature.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 22:05:34 2015 From: report at bugs.python.org (Leonardo Tada) Date: Wed, 27 May 2015 20:05:34 +0000 Subject: [issue24304] Documentation broken link to license Message-ID: <1432757134.25.0.903023321673.issue24304@psf.upfronthosting.co.za> New submission from Leonardo Tada: In this page https://docs.python.org/3.4/faq/general.html#are-there-copyright-restrictions-on-the-use-of-python the link for "the PSF license page" is broken. ---------- assignee: docs at python components: Documentation messages: 244217 nosy: Leonardo Tada, docs at python priority: normal severity: normal status: open title: Documentation broken link to license _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 23:04:06 2015 From: report at bugs.python.org (Moritz Sichert) Date: Wed, 27 May 2015 21:04:06 +0000 Subject: [issue24295] Backport of #17086 causes regression in setup.py In-Reply-To: <1432723014.0.0.831198232873.issue24295@psf.upfronthosting.co.za> Message-ID: <1432760646.76.0.298439716084.issue24295@psf.upfronthosting.co.za> Moritz Sichert added the comment: I wouldn't call it reverting since it already was like this before and only got changed by accident in another backport. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 23:23:48 2015 From: report at bugs.python.org (Brandon Milam) Date: Wed, 27 May 2015 21:23:48 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1432761828.93.0.895494589862.issue8232@psf.upfronthosting.co.za> Brandon Milam added the comment: I kept the changes to the WindowsDefault.open() method and used and extended eryksun's code to build the browser list using the registry. Also I added support for a few more browsers. Some of the browsers I could not find ways to differentiate between opening a new window or new tab using command line flags. This also removed the hardcoding I had put in the get function. ---------- Added file: http://bugs.python.org/file39525/webbrowserfix2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 23:26:07 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 27 May 2015 21:26:07 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <1432761967.19.0.875605280957.issue23359@psf.upfronthosting.co.za> Raymond Hettinger added the comment: [Reply to pitrou that I didn't seem to be able to make on Rietveld] This part of the code is the most time sensitive and warrants expansion much more than other proposals (set copying, subset tests, etc). I long aspired to split the lookup and insertion logic. The former doesn't need dummy tracking and its split relieves the callers of doing dummy checks. The latter needed to be more tightly integrated with set_insert_entry. Both sets of logic have different branch prediction statistics depending on the input data. Working going forward will be made easier for me by having the lookup and insertion logic separated. The speed-up is modest but this part of a long series of modest speed-ups collectively adding-up to a nice boost. The next in line is possibly adding likely/unlikely macros to improve the quality of code generation across different platforms. Overall the code size is just about the same it was in Python 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 27 23:52:14 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 27 May 2015 21:52:14 +0000 Subject: [issue24298] inspect.signature includes bound argument for wrappers around bound methods In-Reply-To: <1432740816.68.0.329507187443.issue24298@psf.upfronthosting.co.za> Message-ID: <1432763534.17.0.523396707897.issue24298@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file39526/signature2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 00:39:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 27 May 2015 22:39:08 +0000 Subject: [issue24304] Documentation broken link to license In-Reply-To: <1432757134.25.0.903023321673.issue24304@psf.upfronthosting.co.za> Message-ID: <20150527223905.5075.36028@psf.io> Roundup Robot added the comment: New changeset d4080f3c0894 by Ned Deily in branch '2.7': Issue 24304: Fix broken license link in FAQ. https://hg.python.org/cpython/rev/d4080f3c0894 New changeset 8631d61f6577 by Ned Deily in branch '3.4': Issue 24304: Fix broken license link in FAQ. https://hg.python.org/cpython/rev/8631d61f6577 New changeset 892a8bed619d by Ned Deily in branch '3.5': Issue 24304: Fix broken license link in FAQ. https://hg.python.org/cpython/rev/892a8bed619d New changeset e57e37c3986c by Ned Deily in branch 'default': Issue 24304: Fix broken license link in FAQ. https://hg.python.org/cpython/rev/e57e37c3986c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 00:40:31 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 27 May 2015 22:40:31 +0000 Subject: [issue24304] Documentation broken link to license In-Reply-To: <1432757134.25.0.903023321673.issue24304@psf.upfronthosting.co.za> Message-ID: <1432766431.77.0.868320225556.issue24304@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report! ---------- nosy: +ned.deily resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 00:41:12 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 May 2015 22:41:12 +0000 Subject: [issue1243678] httplib gzip support Message-ID: <1432766472.04.0.827045818051.issue1243678@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- superseder: Performance for small reads and fix seek problem -> transparent gzip compression in urllib _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 00:57:25 2015 From: report at bugs.python.org (Rony Batista) Date: Wed, 27 May 2015 22:57:25 +0000 Subject: [issue24290] c_uint32 bitfields break structures In-Reply-To: <1432666968.74.0.708060722657.issue24290@psf.upfronthosting.co.za> Message-ID: <1432767445.21.0.533907720502.issue24290@psf.upfronthosting.co.za> Rony Batista added the comment: Well, looks like the issue is with 64 bit mode then. For the first 5 cases the right answer is 69.95930480957031, and for the last 2 its -69.95930480957031. The results for the 32 bit mode are all correct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 01:18:03 2015 From: report at bugs.python.org (Mike Miller) Date: Wed, 27 May 2015 23:18:03 +0000 Subject: [issue24293] Windows installer unreadable with std/custom themes In-Reply-To: <1432684740.9.0.578796945246.issue24293@psf.upfronthosting.co.za> Message-ID: <1432768683.65.0.131342091425.issue24293@psf.upfronthosting.co.za> Mike Miller added the comment: Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 01:36:49 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Wed, 27 May 2015 23:36:49 +0000 Subject: [issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module Message-ID: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> New submission from Nathaniel Smith: (Noticed while fixing the IPython equivalent of issue 24294) The obvious way to deprecate a module is to issue a DeprecationWarning inside the main body of the module, i.e. # thirdpartymodule.py import warnings warnings.warn("{} is deprecated".format(__name__), DeprecationWarning) # mymodule.py import thirdpartymodule But this is problematic, because the resulting message will claim that the problem is in thirdpartymodule.py, not in mymodule.py. And this is especially bad if I am doing things correctly (!) and using a warnings filter that enables display of DeprecationWarnings for mymodule, but not for third-party modules. (This need for correct attribution comes up in the interactive use case cited above, but I actually have packages where the CI infrastructure requires the elimination of DeprecationWarnings triggered by my own code -- for this to work it's crucial that warnings be attributed correctly.) So the obvious fix is to instead write: # thirdpartymodule.py import warnings warnings.warn("{} is deprecated".format(__name__), DeprecationWarning, stacklevel=2) which says "the code that needs fixing is the code that called me". On Python 2.7, this works, because all the code that executes in between 'import thirdpartymodule' and the call to 'warnings.warn' is C code, so it doesn't create any intermediate stack frames. On more recent versions of Python, the import system itself is written in Python, so this doesn't work at all. On Python 3.3, the correct way to deprecate a module is: warnings.warn("this module is deprecated", DeprecationWarning, stacklevel=10) and on Python 3.4, the correct way to deprecate a module is: warnings.warn("this module is deprecated", DeprecationWarning, stacklevel=8) (See https://github.com/ipython/ipython/pull/8480#issuecomment-106107638 for test code.) Obviously this is not desireable. I'm not sure what best solution is. Maybe there should be some collaboration between the import code and the warnings module, so that when the warnings module walks the stack, it skips over stack frames that come from inside the guts of import system? ---------- messages: 244225 nosy: njs priority: normal severity: normal status: open title: The new import system makes it impossible to correctly issue a deprecation warning for a module type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 01:47:39 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Wed, 27 May 2015 23:47:39 +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: <1432770459.19.0.222516140706.issue24305@psf.upfronthosting.co.za> Changes by Thomas Kluyver : ---------- nosy: +takluyver _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 02:05:15 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 28 May 2015 00:05:15 +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: <1432771515.01.0.15920370157.issue24305@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +brett.cannon, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 02:10:56 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 28 May 2015 00:10:56 +0000 Subject: [issue24306] Backport py.exe to 3.4 Message-ID: <1432771856.97.0.606443218974.issue24306@psf.upfronthosting.co.za> New submission from Steve Dower: For 3.5 32-bit installs we register in a different key to avoid collisions with 64-bit installs, but now the 3.4 launcher can't find us. If you have installed 3.4 for all users (likely) and then install 3.5 just-for-me (also likely), then you'll continue to get the 3.4 launcher, and there's no way to avoid this because there's no option to omit it. I think we should backport the launcher to 3.4 so that the next 3.4 release will be able to also work with 3.5. Thoughts? ---------- components: Windows messages: 244226 nosy: steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Backport py.exe to 3.4 versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 02:15:18 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 May 2015 00:15:18 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1432772118.14.0.140364650741.issue23275@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 for Martin's suggestion of removing the inconsistency the other way (i.e. allowing "() = iterable" to mean the same thing as "[] = iterable", effectively asserting that an iterable is empty) I also agree with Raymond that it doesn't need to be mentioned in the What's New doc, just in the NEWS file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 02:22:43 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 May 2015 00:22:43 +0000 Subject: [issue24298] inspect.signature includes bound argument for wrappers around bound methods In-Reply-To: <1432740816.68.0.329507187443.issue24298@psf.upfronthosting.co.za> Message-ID: <1432772563.54.0.142269221248.issue24298@psf.upfronthosting.co.za> Nick Coghlan added the comment: It occurs to me we're also bypassing the check that the unwrapped obj is a callable, so it probably makes sense to just recurse unconditionally after unwrapping the object, rather than only recursing for methods. That's also a little more future-proof, in case any further checks happen to be inserted ahead of the check for __wrapped__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 02:23:33 2015 From: report at bugs.python.org (Srinivas Vamsi Parasa) Date: Thu, 28 May 2015 00:23:33 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1432772613.69.0.265118576353.issue4753@psf.upfronthosting.co.za> Srinivas Vamsi Parasa added the comment: Hi All, This is Vamsi from Server Scripting Languages Optimization team at Intel Corporation. Would like to submit a request to enable the computed goto based dispatch in Python 2.x (which happens to be enabled by default in Python 3 given its performance benefits on a wide range of workloads). We talked about this patch with Guido and he encouraged us to submit a request on Python-dev (email conversation with Guido shown at the bottom of this email). Attached is the computed goto patch (along with instructions to run) for Python 2.7.10 (based on the patch submitted by Jeffrey Yasskin at http://bugs.python.org/issue4753). We built and tested this patch for Python 2.7.10 on a Linux machine (Ubuntu 14.04 LTS server, Intel Xeon ? Haswell EP CPU with 18 cores, hyper-threading off, turbo off). Below is a summary of the performance we saw on the ?grand unified python benchmarks? suite (available at https://hg.python.org/benchmarks/). We made 3 rigorous runs of the following benchmarks. In each rigorous run, a benchmark is run 100 times with and without the computed goto patch. Below we show the average performance boost for the 3 rigorous runs. ----- Instructions to run the computed goto patch 1) Apply the patch and then generate the new configure script (autoconf configure.ac > configure) 2) Enable execute permissions for Python/makeopcodetargets.py ( sudo chmod +x Python/makeopcodetargets.py) 3) To enable computed gotos, do: ./configure --with-computed-gotos 4) Build the new python binary using make && sudo make install ------ Python 2.7.10 (original) vs Computed Goto performance Benchmark Delta (rigorous run #1) % Delta (rigorous run 2) % Delta (rigorous run #3) % Avg. Delta % iterative_count 24.48 24.36 23.78 24.2 unpack_sequence 19.06 18.47 19.48 19.0 slowspitfire 14.36 13.41 16.65 14.8 threaded_count 15.85 13.43 13.93 14.4 pystone 10.68 11.67 11.08 11.1 nbody 10.25 8.93 9.28 9.5 go 7.96 8.76 7.69 8.1 pybench 6.3 6.8 7.2 6.8 spectral_norm 5.49 9.37 4.62 6.5 float 6.09 6.2 6.96 6.4 richards 6.19 6.41 6.42 6.3 slowunpickle 6.37 8.78 3.55 6.2 json_dump_v2 1.96 12.53 3.57 6.0 call_simple 6.37 5.91 3.92 5.4 chaos 4.57 5.34 3.85 4.6 call_method_slots 2.63 3.27 7.71 4.5 telco 5.18 1.83 6.47 4.5 simple_logging 3.48 1.57 7.4 4.2 call_method 2.61 5.4 3.88 4.0 chameleon 2.03 6.26 3.2 3.8 fannkuch 3.89 3.19 4.39 3.8 silent_logging 4.33 3.07 3.39 3.6 slowpickle 5.72 -1.12 6.06 3.6 2to3 2.99 3.6 3.45 3.3 etree_iterparse 3.41 2.51 3 3.0 regex_compile 3.44 2.48 2.84 2.9 mako_v2 2.14 1.29 5.22 2.9 meteor_contest 2.01 2.2 3.88 2.7 django 6.68 -1.23 2.56 2.7 formatted_logging 1.97 5.82 -0.11 2.6 hexiom2 2.83 2.1 2.55 2.5 django_v2 1.93 2.53 2.92 2.5 etree_generate 2.38 2.13 2.51 2.3 mako -0.3 9.66 -3.11 2.1 bzr_startup 0.35 1.97 3 1.8 etree_process 1.84 1.01 1.9 1.6 spambayes 1.76 0.76 0.48 1.0 regex_v8 1.96 -0.66 1.63 1.0 html5lib 0.83 0.72 0.97 0.8 normal_startup 1.41 0.39 0.24 0.7 startup_nosite 1.2 0.41 0.42 0.7 etree_parse 0.24 0.9 0.79 0.6 json_load 1.38 0.56 -0.25 0.6 pidigits 0.45 0.33 0.28 0.4 hg_startup 0.32 2.07 -1.41 0.3 rietveld 0.05 0.91 -0.43 0.2 tornado_http 2.34 -0.92 -1.27 0.1 call_method_unknown 0.72 1.26 -1.85 0.0 raytrace -0.35 -0.75 0.94 -0.1 regex_effbot 1.97 -1.18 -2.57 -0.6 fastunpickle -1.65 0.5 -0.88 -0.7 nqueens -2.24 -1.53 -0.81 -1.5 fastpickle -0.74 1.98 -6.26 -1.7 Thanks, Vamsi ------------------------------------------------------------------------------------------------------------------------------------------------------------ From: gvanrossum at gmail.com [mailto:gvanrossum at gmail.com] On Behalf Of Guido van Rossum Sent: Tuesday, May 19, 2015 1:59 PM To: Cohn, Robert S Cc: R. David Murray (r.david.murray at murrayandwalker.com) Subject: Re: meeting at PyCon Hi Robert and David, I just skimmed that thread. There were a lot of noises about backporting it to 2.7 but the final message on the topic, by Antoine, claimed it was too late for 2.7. However, that was before we had announced the EOL extension of 2.7 till 2020, and perhaps we were also in denial about 3.x uptake vs. 2.x. So I think it's definitively worth bringing this up. I would start with a post on python-dev linking to the source code for your patch, and adding a message to the original tracker issue too (without reopening it though -- just so the people who were on the bug will be pinged about it). Because of backwards compatibility with previous 2.7.x releases, it's very important that the patch not break anything -- in particular this means you can't add opcodes or change their specification. You will also undoubtedly be asked to test this on a variety of platforms 32-bit and 64-bit that people care about. But I'm sure you're expecting all that. :-) You might also check with Benjamin Peterson, who is the 2.7 release manager. I think he just announced 2.7.10, so it's too late for that, but I assume we'll keep doing 2.7.x releases until 2020. Good luck, --Guido PS. I am assuming you are contributing this under a PSF-accepted license, e.g. Apache 2.0, otherwise it's an automatic nogo. On Tue, May 19, 2015 at 9:33 AM, Cohn, Robert S wrote: Hi Guido, When we met for lunch at pycon, I asked if performance related patches would be ok for python 2.x. My understanding is that you thought it was possible if it did not create a maintainability problem. We have an example now, a 2.7 patch for computed goto based on the implementation in python 3 http://bugs.python.org/issue4753 It increases performance by up to 10% across a wide range of workloads. As I mentioned at lunch, we hired David Murray?s company, and he is guiding intel through the development process for cpython. David and I thought it would be good to run this by you before raising the issue on python-dev. Do you have a specific concern about this patch or a more general concern about performance patches to 2.7? Thanks. Robert -------- ---------- nosy: +parasa Added file: http://bugs.python.org/file39527/cgoto_py2710_hg_final.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 02:26:40 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 May 2015 00:26:40 +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: <1432772800.88.0.542267139732.issue24301@psf.upfronthosting.co.za> Martin Panter added the comment: I suspect Eric?s file has non-zero, non-gzip garbage bytes appended to the end of it. Assuming I am right, here is way to reproduce that scenario: >>> from gzip import GzipFile >>> from io import BytesIO >>> file = BytesIO() >>> with GzipFile(fileobj=file, mode="wb") as z: ... z.write(b"data") ... 4 >>> file.write(b"garbage") 7 >>> file.seek(0) 0 >>> GzipFile(fileobj=file).read() Traceback (most recent call last): File "", line 1, in File "/home/proj/python/cpython/Lib/gzip.py", line 274, in read return self._buffer.read(size) File "/home/proj/python/cpython/Lib/gzip.py", line 461, in read if not self._read_gzip_header(): File "/home/proj/python/cpython/Lib/gzip.py", line 409, in _read_gzip_header raise OSError('Not a gzipped file (%r)' % magic) OSError: Not a gzipped file (b'ga') This is a bit different to Issue 1508475. That one is about cases where the ?gzip? trailer has been truncated, although the compressed data is probably intact. This case is the converse: extra data has been added. All of the ?gzip?, ?bzip2? and XZ Utils (for LZMA) command-line decompressors happily extract the compressed data without an error exit status, but emit warning messages: gzip: stdin: decompression OK, trailing garbage ignored bzip2: (stdin): trailing garbage after EOF ignored xz: (stdin): Unexpected end of input In Python, the ?bzip? and LZMA modules successfully extract the compressed data, and ignore the non-compressed garbage at the end without even a warning. On the other hand, the ?gzip? module has special code to ignore trailing zero bytes (Issue 2846), but treats any other trailing non-gzip data as an error. So I think a strong argument could be made for the ability to extract all the compressed data from even if there is garbage appended. The question is, how would this support be added? Perhaps the mechanism chosen could also be integrated with a fix for Issue 1508475. Some options: * Silently ignore the condition by default like the other compression modules (consistent, but could silently swallow real errors) * An optional new GzipFile(strict=False) mode * Perhaps an exception deferred until close() is called ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 02:34:28 2015 From: report at bugs.python.org (Robert Collins) Date: Thu, 28 May 2015 00:34:28 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1432773268.15.0.459927483299.issue4753@psf.upfronthosting.co.za> Robert Collins added the comment: FWIW I'm interested and willing to poke at this if more testers/reviewers are needed. ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 02:38:46 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 May 2015 00:38:46 +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: <1432773526.55.0.606860913383.issue24305@psf.upfronthosting.co.za> Nick Coghlan added the comment: Somewhat related issues are issue 16217 (traceback noise when running under python -m) and issue 23773 (traceback noise when running under custom import hooks) For 3.4 and 3.5, we may want to consider a brute force solution where the warnings module just straight up ignores _frozen_importlib frames when counting stack levels. For 3.6+, I've occasionally pondered various ideas for introducing the notion of a "frame debugging level". The most recent variant of that idea would be to have all frames live in level zero by default, but there'd be a way to flag a module at compile time to set it higher for the code objects created by that module. Displaying those frames in tracebacks would then be tied to both the current frame's debugging level and the interpreter's verbosity level (whichever was higher), while other stack related operations (like the warnings stacklevel and frame retrieval) would only consider frames at the current frame's debugging level and below. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 02:57:17 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 May 2015 00:57:17 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432774637.63.0.804712115627.issue24259@psf.upfronthosting.co.za> Martin Panter added the comment: I might be able to make a patch, but what should the patch do exactly? * Raise an exception as soon as something wrong is found * Defer exceptions until close() is called, to allow partial data recovery * Add some sort of defects API that you can optionally inspect, like the email message library has * A new tarfile.open(strict=True) mode ---------- components: +Library (Lib) nosy: +vadmium type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 03:04:03 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 May 2015 01:04:03 +0000 Subject: [issue24298] inspect.signature includes bound argument for wrappers around bound methods In-Reply-To: <1432740816.68.0.329507187443.issue24298@psf.upfronthosting.co.za> Message-ID: <1432775043.65.0.217398404892.issue24298@psf.upfronthosting.co.za> Yury Selivanov added the comment: > That's also a little more future-proof, in case any further checks happen to be inserted ahead of the check for __wrapped__. Well, we unwrap until we see a "__signature__" attribute (or we can't unwrap anymore). And right after unwrapping we try to return the __signature__; so inserting more checks before unwrapping with unconditional recursion after it won't be so safe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 03:08:19 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 May 2015 01:08:19 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432775299.28.0.0122708517032.issue24259@psf.upfronthosting.co.za> Martin Panter added the comment: Actually, looking closer at the module, perhaps you just need to set the errorlevel=1 option: >>> with tarfile.open("truncated.tar", errorlevel=1) as tar:... tar.extractall("test-dir") ... Traceback (most recent call last): File "", line 2, in File "/home/proj/python/cpython/Lib/tarfile.py", line 1996, in extractall numeric_owner=numeric_owner) File "/home/proj/python/cpython/Lib/tarfile.py", line 2038, in extract numeric_owner=numeric_owner) File "/home/proj/python/cpython/Lib/tarfile.py", line 2108, in _extract_member self.makefile(tarinfo, targetpath) File "/home/proj/python/cpython/Lib/tarfile.py", line 2154, in makefile copyfileobj(source, target, tarinfo.size) File "/home/proj/python/cpython/Lib/tarfile.py", line 242, in copyfileobj raise OSError("end of file reached") OSError: end of file reached ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 03:15:28 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 28 May 2015 01:15:28 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432775728.52.0.903334412664.issue24259@psf.upfronthosting.co.za> Ethan Furman added the comment: On the SO question [1] the OP stated that he tried errorlevel of both 1 and 2 with no effect... however, he was using Python2.6. Martin, can you run that same test with 2.6 to verify that errorlevel did not work there, but does now? [1] http://stackoverflow.com/q/30302204/208880 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 03:21:58 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 28 May 2015 01:21:58 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432776118.04.0.41705837822.issue24259@psf.upfronthosting.co.za> Ethan Furman added the comment: Actually, the OP was using 2.7.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 03:25:07 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 May 2015 01:25:07 +0000 Subject: [issue24298] inspect.signature includes bound argument for wrappers around bound methods In-Reply-To: <1432740816.68.0.329507187443.issue24298@psf.upfronthosting.co.za> Message-ID: <1432776307.11.0.150887240248.issue24298@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm OK with the patch as is, but I'm definitely concerned about the maintainability of inspect.signature in general. I'm trying to decide if a block comment covering the order of calling protocols that we check, and where we potentially recurse, would be a help (by providing a map of the function for the benefit of future maintainers) or a hindrance (by providing the opportunity for that map to get out of sync) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 03:28:19 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 28 May 2015 01:28:19 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432776499.91.0.973071797663.issue24259@psf.upfronthosting.co.za> Ethan Furman added the comment: I ran the OP's code in 2.7, 3.3, 3.4, and 3.5, as well as using ubuntu's gnu tar 1.27.1: gnu tar did not report any errors. Python (all tested versions) did not report any errors (with the errorlevel parameter missing, set to 1, and set to 2). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 03:34:55 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 May 2015 01:34:55 +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: <1432776895.28.0.117548817492.issue24294@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 for showing DeprecationWarning by default (as these features may be going away in the next X.Y release of Python) -0 for showing PendingDeprecationWarning by default (as these won't be going away until X.Y+1 at the earliest) ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 03:37:44 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 May 2015 01:37:44 +0000 Subject: [issue24298] inspect.signature includes bound argument for wrappers around bound methods In-Reply-To: <1432740816.68.0.329507187443.issue24298@psf.upfronthosting.co.za> Message-ID: <1432777064.46.0.142663877212.issue24298@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I'm OK with the patch as is, but I'm definitely concerned about the maintainability of inspect.signature in general. I agree, _signature_from_callable is getting quite complex. The good news is that we have a very good test coverage for signatures. As for a big block comment -- it might be useful. OTOH the code of _signature_from_callable is mostly if..else statements with calls to helpers and recursion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 03:58:52 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Thu, 28 May 2015 01:58:52 +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: <1432778332.71.0.311955546386.issue24294@psf.upfronthosting.co.za> Nathaniel Smith added the comment: *cough* You know, there's more to life than Python-X.Y.tar.gz :-). Not that I know how PendingDeprecationWarning is used in the wild. I've been thinking maybe we (numpy) should start using it for stuff that we want to discourage people from using (we know it was a bad idea or intrinsically broken or whatever), but don't yet have a full replacement to offer. It would help if there were some official guidance on what these things mean -- I can't find anything written down anywhere that even documents what you just said about how CPython proper uses them, so I imagine people have come up with all kinds of interpretations. Anyway, my logic would be: when I am trying something out at the REPL, usually it is because I want to check how it works, to figure out what I should be doing in the real module code that I'm writing in the next window. When doing this, I definitely appreciate knowing that it will be removed and is being replaced -- it won't necessarily stop me from putting it into my code, but at least it's information that I can take into account. I don't care a huge amount either way, though; if we decided to hide PendingDeprecationWarnings by default while showing DeprecationWarnings then numpy would just define a NumPyPendingDeprecationWarning subclass of DeprecationWarning and use that instead of PendingDeprecationWarning and all would work out fine :-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 04:00:12 2015 From: report at bugs.python.org (Mike Gilbert) Date: Thu, 28 May 2015 02:00:12 +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: <1432778412.03.0.741530215997.issue24303@psf.upfronthosting.co.za> Changes by Mike Gilbert : ---------- nosy: +floppymaster _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 04:01:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 May 2015 02:01:32 +0000 Subject: [issue24298] inspect.signature includes bound argument for wrappers around bound methods In-Reply-To: <1432740816.68.0.329507187443.issue24298@psf.upfronthosting.co.za> Message-ID: <20150528020129.10360.43695@psf.io> Roundup Robot added the comment: New changeset 42819b176d63 by Yury Selivanov in branch '3.4': Issue 24298: Fix signature() to properly unwrap wrappers around bound methods https://hg.python.org/cpython/rev/42819b176d63 New changeset d7e392c5c53a by Yury Selivanov in branch '3.5': Issue 24298: Fix signature() to properly unwrap wrappers around bound methods https://hg.python.org/cpython/rev/d7e392c5c53a New changeset ab46801ca359 by Yury Selivanov in branch 'default': Issue 24298: Fix signature() to properly unwrap wrappers around bound methods https://hg.python.org/cpython/rev/ab46801ca359 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 04:02:36 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 May 2015 02:02:36 +0000 Subject: [issue24298] inspect.signature includes bound argument for wrappers around bound methods In-Reply-To: <1432740816.68.0.329507187443.issue24298@psf.upfronthosting.co.za> Message-ID: <1432778556.85.0.337130622249.issue24298@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 Thu May 28 04:20:59 2015 From: report at bugs.python.org (tanbro-liu) Date: Thu, 28 May 2015 02:20:59 +0000 Subject: [issue24307] pip error on windows whose current user name contains non-ascii characters Message-ID: <1432779659.79.0.171307025039.issue24307@psf.upfronthosting.co.za> New submission from tanbro-liu: On windows8.1 x64, current user name contains non-ascii characters. When executing ``pip`` in the command-line, such an error happens:: C:\Users\??>pip Traceback (most recent call last): File "C:\Python27\lib\runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "C:\Python27\lib\runpy.py", line 72, in _run_code exec code in run_globals File "C:\Python27\Scripts\pip.exe\__main__.py", line 9, in File "C:\Python27\lib\site-packages\pip\__init__.py", line 210, in main cmd_name, cmd_args = parseopts(args) File "C:\Python27\lib\site-packages\pip\__init__.py", line 165, in parseopts parser.print_help() File "C:\Python27\lib\optparse.py", line 1676, in print_help file.write(self.format_help().encode(encoding, "replace")) File "C:\Python27\lib\optparse.py", line 1656, in format_help result.append(self.format_option_help(formatter)) File "C:\Python27\lib\optparse.py", line 1639, in format_option_help result.append(group.format_help(formatter)) File "C:\Python27\lib\optparse.py", line 1120, in format_help result += OptionContainer.format_help(self, formatter) File "C:\Python27\lib\optparse.py", line 1091, in format_help result.append(self.format_option_help(formatter)) File "C:\Python27\lib\optparse.py", line 1080, in format_option_help result.append(formatter.format_option(option)) File "C:\Python27\lib\optparse.py", line 322, in format_option help_text = self.expand_default(option) File "C:\Python27\lib\site-packages\pip\baseparser.py", line 110, in expand_de fault return optparse.IndentedHelpFormatter.expand_default(self, option) File "C:\Python27\lib\optparse.py", line 288, in expand_default return option.help.replace(self.default_tag, str(default_value)) UnicodeEncodeError: 'ascii' codec can't encode characters in position 9-10: ordi nal not in range(128) i think, we can modify /lib/optparse.py line 288 to avoid such an error in windows:: -- return option.help.replace(self.default_tag, str(default_value)) ++ return option.help.replace( ++ self.default_tag, ++ default_value.encode(sys.getfilesystemencoding()) ++ if isinstance(default_value, uicnode) ++ else str(default_value) ++ ) ---------- components: Library (Lib) messages: 244244 nosy: tanbro-liu priority: normal severity: normal status: open title: pip error on windows whose current user name contains non-ascii characters type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 04:27:57 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 28 May 2015 02:27:57 +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: <1432780077.22.0.26226186866.issue24307@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +Marcus.Smith, dstufft, ncoghlan, paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 04:30:41 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 May 2015 02:30:41 +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: <1432780241.16.0.511093139203.issue24294@psf.upfronthosting.co.za> Nick Coghlan added the comment: The difference between the two used to be clearer: prior to Python 2.7, PendingDeprecationWarning was hidden by default (and thus mainly only visible to folks testing with -Wall), while DeprecationWarning was visible by default. We blurred the line between the two thoroughly when DeprecationWarning also became hidden by default, giving the status quo: Test frameworks: both visible by default Interactive REPL: both hidden by default Non-interactive execution: both hidden by default Splitting them in the interactive REPL case would restore a meaningful behavioural difference that can help pragmatically guide decisions as to which is more appropriate to use: Test frameworks: both visible by default Interactive REPL: DW visible by default, PendingDW hidden by default Non-interactive execution: both hidden by default The current unanswerable "How do my users interpret the difference between DW and PendingDW?" question would be replaced by the much simpler "Do I want folks using the interactive REPL to see this warning or not?" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 04:53:03 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 28 May 2015 02:53:03 +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: <1432781583.1.0.0768989906105.issue24305@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 05:01:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 May 2015 03:01:45 +0000 Subject: [issue18032] Optimization for set/frozenset.issubset() In-Reply-To: <1369223923.83.0.620034016791.issue18032@psf.upfronthosting.co.za> Message-ID: <1432782105.64.0.0837470317673.issue18032@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Personally I don't sure that this optimization is worth to apply. Its cost is high and optimized case is not common. This is rather an experiment, how large can be maximal effect of the optimization. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 05:04:54 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 28 May 2015 03:04:54 +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: <1432782294.03.0.771397149343.issue24305@psf.upfronthosting.co.za> Berker Peksag added the comment: This looks like a duplicate of issue 23810 (there is a patch for stdlib usages, but it probably can be changed to a more general solution). ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 05:04:57 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 May 2015 03:04:57 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432782297.51.0.951914033096.issue24259@psf.upfronthosting.co.za> Martin Panter added the comment: I guess it depends on the particular tar file and where it gets truncated. Just now I tested with a tar file created from Python?s Tools directory: $ tar c Tools/ > good.tar $ ls -gG good.tar -rw-r--r-- 1 17397760 May 28 02:43 good.tar $ head -c 130000 good.tar > cut.tar $ tar -tf cut.tar Tools/ [. . .] Tools/hg/hgtouch.py tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now [Exit 2] Using Python 2.7.9, I can reproduce Thomas?s behaviour. It extracts the files with no error indication, and actually truncated the last extracted file to 2512 bytes. Adding errorlevel=1 or errorlevel=2 did not make a difference. Then I tried Python 3.3, 3.4 and 3.6 in various forms. They all seem to raise OSError, even with no errorlevel specified, and create the last file with zero bytes. So in this case I think it is a Python 2 bug (which I?m personally not so motivated to fix). Ethan: how did you create and truncate your tar file? It almost sounds like it is intact, or maybe didn?t get truncated enough to completely wipe out the EOF block. ---------- type: enhancement -> behavior versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 05:09:32 2015 From: report at bugs.python.org (koobs) Date: Thu, 28 May 2015 03:09:32 +0000 Subject: [issue24308] Test failure: test_with_pip (test.test_venv.EnsurePipTest in 3.x Message-ID: <1432782572.48.0.713630416896.issue24308@psf.upfronthosting.co.za> New submission from koobs: test_with_pip fails since revision 0d0989359bbbff9aa502158e362eb298e1a8ba7c with the following output: ====================================================================== FAIL: test_with_pip (test.test_venv.EnsurePipTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_venv.py", line 390, in test_with_pip self.assertEqual(err, "") AssertionError: "You are using pip version 6.1.1, however[102 chars]d.\n" != '' - You are using pip version 6.1.1, however version 7.0.1 is available. - You should consider upgrading via the 'pip install --upgrade pip' command. ---------- assignee: dstufft components: Distutils, Tests keywords: buildbot messages: 244249 nosy: dstufft, eric.araujo, koobs priority: normal severity: normal status: open title: Test failure: test_with_pip (test.test_venv.EnsurePipTest in 3.x versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 05:12:00 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 28 May 2015 03:12:00 +0000 Subject: [issue18032] Optimization for set/frozenset.issubset() In-Reply-To: <1369223923.83.0.620034016791.issue18032@psf.upfronthosting.co.za> Message-ID: <1432782720.1.0.118345819293.issue18032@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Personally I don't sure that this optimization is worth to apply. I concur. Closing as "not worth it" :-) ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 05:12:03 2015 From: report at bugs.python.org (koobs) Date: Thu, 28 May 2015 03:12:03 +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: <1432782723.73.0.779089177857.issue24308@psf.upfronthosting.co.za> koobs added the comment: My mistake, revision 1ca30423b0c99c9599d5d4654323eeeae4a03804 or revision 29b95625a07cc5bb22e260c983500ed9efed67bf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 05:30:02 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 28 May 2015 03:30:02 +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: <1432783802.3.0.484424800159.issue24017@psf.upfronthosting.co.za> Stefan Behnel added the comment: I added a couple of review comments to patch 6, but since no-one has responded so far, I guess they simply haven't been noticed. So I'll just repeat them here. 1) getawaitablefunc / aiternextfunc / getaiterfunc Is there a reason why these need to have their specific C type name instead of just reusing unaryfunc, or at least the existing iternextfunc / getiterfunc? They are unprefixed global names in the C namespace and I think we should be careful when adding more of those. 2) Awaitable.register(Coroutine) I think this is incorrect. A Coroutine is not Awaitable unless it also implements "__await__". How else should it be awaited? 3) I propose to use this wrapping code as a fallback for types.coroutine() in the case that a Generator (ABC) is passed instead of a generator (yield): class types_coroutine(object): def __init__(self, gen): self._gen = gen class as_coroutine(object): def __init__(self, gen): self._gen = gen self.send = gen.send self.throw = gen.throw self.close = gen.close def __await__(self): return self._gen def __call__(self, *args, **kwargs): return self.as_coroutine(self._gen(*args, **kwargs)) Note that the resulting Awaitable Coroutine type is not an Iterable. This differs from a (yield) coroutine, but it matches the Coroutine and Awaitable protocols, and the intention to separate both in order to avoid mistakes on user side. Additionally, regarding the tests: 4) def test_func_2(self): async def foo(): raise StopIteration with self.assertRaisesRegex( RuntimeError, "generator raised StopIteration"): run_async(foo()) Why is this actually necessary? I'm aware that it's also mentioned in the PEP, but is there an actual reason why a coroutine should behave the same as a generator here? Is it just an implementation detail for legacy reasons because generators and coroutines happen to share the same type implementation? (I don't think they need to, BTW.) 5) def test_func_8(self): @types.coroutine def bar(): return (yield from foo()) async def foo(): return 'spam' self.assertEqual(run_async(bar()), ([], 'spam') ) I find it surprising that this works at all. Yield-from iterates, and a coroutine is not supposed to be iterable, only awaitable (at least, that's what all error messages tell me when I try it). So why should "yield from" work on them? What if foo() was not an Iterable but a Coroutine? Should "yield from" then call "__await__" on it internally? I would find that *really* surprising, but given the above, I think it would be necessary to achieve consistency. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 05:42:32 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 28 May 2015 03:42:32 +0000 Subject: [issue24306] Backport py.exe to 3.4 In-Reply-To: <1432771856.97.0.606443218974.issue24306@psf.upfronthosting.co.za> Message-ID: <1432784552.56.0.518973942816.issue24306@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can it actually do any harm? It certainly appears to remove the potential for a lot of bug reports from a lot of frustrated users, myself included. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 05:42:37 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 28 May 2015 03:42: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: <1432784557.31.0.254474003403.issue24259@psf.upfronthosting.co.za> Ethan Furman added the comment: I took an existing tar file and chopped it in half with `head -c`. I was able to extract half the files, but I didn't check the viability of the last file as I was looking for tar or python error feedback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 05:45:09 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 28 May 2015 03:45:09 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1432784709.9.0.87793397759.issue23275@psf.upfronthosting.co.za> Changes by Stefan Behnel : ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 05:47:41 2015 From: report at bugs.python.org (koobs) Date: Thu, 28 May 2015 03:47:41 +0000 Subject: [issue24175] Sporadic test_utime() failures on FreeBSD In-Reply-To: <1431521100.95.0.772714139961.issue24175@psf.upfronthosting.co.za> Message-ID: <1432784861.07.0.777685487494.issue24175@psf.upfronthosting.co.za> koobs added the comment: See also: Issue 16287 (Solaris) Issue 15745 (Related to FreeBSD/ZFS, has patch) 3.4 and 3.x are still failing ---------- title: Test failure in test_utime on FreeBSD -> Sporadic test_utime() failures on FreeBSD _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 05:52:26 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 28 May 2015 03:52:26 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <1432785146.43.0.494800754341.issue4753@psf.upfronthosting.co.za> Ned Deily added the comment: @Vamsi, could you please open a new issue and attach your patch there so it can be properly tracked for 2.7? This issue has been closed for five years and the code has been out in the field for a long time in Python 3. Thanks! ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 05:54:41 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 May 2015 03:54:41 +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: <1432785281.63.0.593517313764.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: > 2) Awaitable.register(Coroutine) > I think this is incorrect. A Coroutine is not Awaitable unless it also implements "__await__". How else should it be awaited? It *is* correct, see PEP 492. Awaitable is either a coroutine *or* an object with an __await__ method. Generally, being an awaitable means that the object can be used in "await" expression. > 3) > I propose to use this wrapping code as a fallback for types.coroutine() in the case that a Generator (ABC) is passed instead of a generator (yield): Just implement tp_await/__await__ for coroutine-like objects coming from C-API or Cython. In general, iteration protocol is still the foundation for Future-like objects, so there is nothing wrong with this. Generator ABC isn't supposed to be used with "await" expression. > 4) > > def test_func_2(self): > async def foo(): > raise StopIteration > > with self.assertRaisesRegex( > RuntimeError, "generator raised StopIteration"): > > run_async(foo()) > Why is this actually necessary? I'm aware that it's also mentioned in the PEP, but is there an actual reason why a coroutine should behave the same as a generator here? Is it just an implementation detail for legacy reasons because generators and coroutines happen to share the same type implementation? (I don't think they need to, BTW.) Coroutines are implemented on top of generators. Until we clearly separate them (in 3.6?) I don't think we should allow coroutines to bubble up StopIteration. > 5) > def test_func_8(self): > @types.coroutine > def bar(): > return (yield from foo()) > > async def foo(): > return 'spam' > > self.assertEqual(run_async(bar()), ([], 'spam') ) > > I find it surprising that this works at all. Yield-from iterates, and a coroutine is not supposed to be iterable, only awaitable (at least, that's what all error messages tell me when I try it). So why should "yield from" work on them? What if foo() was not an Iterable but a Coroutine? Should "yield from" then call "__await__" on it internally? I would find that *really* surprising, but given the above, I think it would be necessary to achieve consistency. This is a special backwards-compatibility thing. In general, generators cannot yield-from coroutines (unless they are decorated with @types.coroutine). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 05:59:56 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 28 May 2015 03:59:56 +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: <1432785596.34.0.16818214134.issue24017@psf.upfronthosting.co.za> Stefan Behnel added the comment: Another question: is it ok if Cython implements and uses the "tp_as_async" slot in all Py3.x versions (3.2+)? It shouldn't hurt, but it would speed up async/await in Cython at least under Py3.x. Only Py2.6/7 would then have to resort to calling "__await__()" etc. at the Python level. One drawback is that Py<3.5 currently (needlessly) checks that "tp_reserved" and "tp_richcompare" are both implemented, but that can be worked around by also implementing the latter... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 06:02:49 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 May 2015 04:02:49 +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: <1432785769.29.0.195834236257.issue24305@psf.upfronthosting.co.za> Nick Coghlan added the comment: I've made this depend on issue 23810, rather than duplicating it. That way, issue 23810 can cover fixing the stdlib deprecation warnings, while this can cover making it a public API. ---------- dependencies: +Suboptimal stacklevel of deprecation warnings for formatter and imp modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 06:04:42 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 May 2015 04:04:42 +0000 Subject: [issue23810] Suboptimal stacklevel of deprecation warnings for formatter and imp modules In-Reply-To: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za> Message-ID: <1432785882.05.0.954318023225.issue23810@psf.upfronthosting.co.za> Nick Coghlan added the comment: Issue 24305 covers either making this a public API for general use, or else just making module level deprecation warnings skip the import machinery automatically. I also wonder whether Eric's _boostrap_external changes might have broken any of the frame hiding tricks for tracebacks. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 06:18:31 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 28 May 2015 04:18:31 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1432785281.63.0.593517313764.issue24017@psf.upfronthosting.co.za> Message-ID: <55669715.5050207@behnel.de> Stefan Behnel added the comment: > It *is* correct, see PEP 492. Awaitable is either a coroutine *or* an object with an __await__ method. "coroutine", yes. But "Coroutine"? Shouldn't the Coroutine ABC then require "__await__" to be implemented? Maybe even by inheriting from Awaitable? > Just implement tp_await/__await__ for coroutine-like objects coming from C-API or Cython. Sure, that's how it's done. (Specifically, Coroutine is not an Iterable/Iterator, but its __await__() returns a thin Iterator that simply calls into the Generator code. A bit annoying and slowish, but that's what it takes.) I was just wondering how Cython should compile Python code that makes use of this decorator. The Coroutine and Generator types are separated in Cython now, and I think that's actually the right thing to do. This types.coroutine() decorator and special casing in CPython's code base gets a bit in the way here. > In general, iteration protocol is still the foundation for Future-like objects That's not really reflected in the ABCs, is it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 06:25:30 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Thu, 28 May 2015 04:25:30 +0000 Subject: [issue24309] string.Template should be using str.format and/or deprecated Message-ID: <1432787130.33.0.724179416311.issue24309@psf.upfronthosting.co.za> New submission from Dmitry Kazakov: I came across this piece of code in Lib/string.py:146: # We use this idiom instead of str() because the latter will # fail if val is a Unicode containing non-ASCII characters. return '%s' % (mapping[named],) This seems vestigial. I think it'd be appropriate to "fix" the string.Template by replacing the printf-style formatting with newer str.format everywhere in the Template's source. The obvious advantage is that by tweaking some regexes we'll make possible formatting using the following syntax ${thing.attribute_or_key} by dropping to the str.format return '{named}'.format(**mapping) # <-- new version It'd also make sense to use the str.format_map to implement the Template.safe_substitute. Borrowing some ideas from issue1198569, we can then expose an additional attribute called Template.bracepattern to allow programmers use the str.format-based substitution extensively: $name ${name.thing} ${name.thing: >16} This change won't break any existing code. But I'm not exactly sure string.Template should be in Python 3 at all. It's one of the least used features and PEP 292 states it was added as an alternative to %-based substitution. I think it'd be deprecated and removed from the standard library. So what's the resolution? Should we fix it or deprecate it or both? ---------- components: Library (Lib) messages: 244262 nosy: vlth priority: normal severity: normal status: open title: string.Template should be using str.format and/or deprecated type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 06:32:27 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 28 May 2015 04:32:27 +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: <1432787547.95.0.00944330474936.issue24309@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I came across this piece of code in Lib/string.py:146: That may be artifact from the days of ASCII strings and may or may not have analog with the bytes data type. > But I'm not exactly sure string.Template should be in > Python 3 at all. It still has valid use cases (i.e. exposing safe templates to the end user). And it has features that aren't present in new-style formatting. Please learn an aversion to deprecating things (it almost never a good first reaction to seeing code in the standard library). It almost always breaks someone's code and makes migrating to Python 3 more difficult. ---------- assignee: -> barry nosy: +barry, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 06:35:16 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 May 2015 04:35:16 +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: <1432787716.5.0.179265895782.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: > > It *is* correct, see PEP 492. Awaitable is either a coroutine *or* an object with an __await__ > method. > > "coroutine", yes. But "Coroutine"? Shouldn't the Coroutine ABC then require > "__await__" to be implemented? Maybe even by inheriting from Awaitable? This is an interesting idea. Practically, when you register something as a Coroutine, you expect it to be compatible with ?await? expressions. And that?s only possible if __await__ is implemented. I?m curious what Guido and Nick think about this. I think that we can derive Coroutine from Awaitable. > > Just implement tp_await/__await__ for coroutine-like objects coming from C-API > or Cython. > > Sure, that's how it's done. (Specifically, Coroutine is not an > Iterable/Iterator, but its __await__() returns a thin Iterator that simply > calls into the Generator code. A bit annoying and slowish, but that's what > it takes.) Can't your Coroutine object return itself from its __await__, and implement __next__? Like genobject in CPython simply returns self from its __iter__. > I was just wondering how Cython should compile Python code that makes use > of this decorator. The Coroutine and Generator types are separated in > Cython now, and I think that's actually the right thing to do. This > types.coroutine() decorator and special casing in CPython's code base gets > a bit in the way here. I think we can update types.coroutine to continue using CO_ITERABLE_COROUTINE for pure python generator functions. And for something foreign we can use your proposed design. Would that be OK? > > > In general, iteration protocol is still the foundation for Future-like objects > > That's not really reflected in the ABCs, is it? Awaitable has its __await__ defined as a generator... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 06:42:03 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 28 May 2015 04:42:03 +0000 Subject: [issue24306] Backport py.exe to 3.4 In-Reply-To: <1432771856.97.0.606443218974.issue24306@psf.upfronthosting.co.za> Message-ID: <1432788123.59.0.618240901332.issue24306@psf.upfronthosting.co.za> Steve Dower added the comment: I didn't mention it initially, but the harm it can do is overriding newer versions. The 3.5 and later installers have proper versioning built in, but I don't think that's possible with the 3.4 installer as well (due to MSI limitations, not any deficiency of the previous authoring). Of course, we're already in a place where "last installed wins", so the only other option is to remove the launcher from 3.4 (or all installers...) and require a separate installation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 06:46:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 May 2015 04:46:04 +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: <1432788364.2.0.844576016959.issue24309@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm strongly -1 for deprecating string.Template. It provides simple, widely used syntax, and is used in a lot of third-party code. I don't think that it needs to be extended. However I have an idea about implementing general string composing engine than could be reused with different frontends in str.format, str.__mod__, string.Template, re.sub, and third-part template engines. Perhaps I'll try to implement it in 3.6. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 07:09:07 2015 From: report at bugs.python.org (Laura Creighton) Date: Thu, 28 May 2015 05:09:07 +0000 Subject: [issue24310] Idle documentation -- what to do if you do not see an underscore. Message-ID: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za> New submission from Laura Creighton: On some operating systems, for instance a Macbook Pro with Retina, the bottoms of hanging letters such as 'g' or 'y', as well as underscorces, cannot be seen in IDLE. The fix is to go to Options -> Configure IDLE, and change the size of the default font to 9 or 11. Can we add this line to 25.5.5.2. and 24.6.5.2. ? It is not obvious, especially to the newbie who is trying to write their first python program that the inability to type underscores is a font problem. ---------- assignee: docs at python components: Documentation messages: 244267 nosy: docs at python, lac priority: normal severity: normal status: open title: Idle documentation -- what to do if you do not see an underscore. 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 Thu May 28 07:10:10 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 May 2015 05:10:10 +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: <1432789810.81.0.506031341741.issue24017@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks for highlighting these Stefan - you guessed correctly that I'd missed them on the review. For your first question, I agree getawaitablefunc / aiternextfunc / getaiterfunc should all be dropped and replaced with the existing "unaryfunc". For your second question, I agree it makes more sense for Coroutine to inherit from Awaitable than it does to have it registered with it. For the other three, I don't have a strong opinion, except that we should make sure that whatever we do on the CPython side works by default for Cython. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 07:12:50 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 May 2015 05:12:50 +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: <1432789970.28.0.489779071662.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: > For your first question, I agree getawaitablefunc / aiternextfunc / getaiterfunc should all be dropped and replaced with the existing "unaryfunc". I have no problem with that. But why do we have iternextfunc & getiterfunc (no "a" prefix)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 07:13:47 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 28 May 2015 05:13:47 +0000 Subject: [issue24310] Idle documentation -- what to do if you do not see an underscore. In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za> Message-ID: <1432790027.96.0.870926849353.issue24310@psf.upfronthosting.co.za> Ned Deily added the comment: That may be a problem better fixed in Tk itself. I don't have a Retina display handy. Assuming you have a current ActiveTcl 8.5 (8.5.18) installed, could you try some of the Tk text widget demos in /usr/local/bin/wish8.5 and see if the problem shows up there, too? Not sure what the font sizes there are, though. Thanks! ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 07:21:41 2015 From: report at bugs.python.org (Laura Creighton) Date: Thu, 28 May 2015 05:21:41 +0000 Subject: [issue24310] Idle documentation -- what to do if you do not see an underscore. In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za> Message-ID: <1432790501.95.0.619620008061.issue24310@psf.upfronthosting.co.za> Laura Creighton added the comment: I don't have one, alas. It was a question sent to webmaster. I just happened to know that reconfiguring your font size fixes the 'no underscore' problem, so it occured to me that mentioning this in the idle documentation might save some grief. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 07:24:52 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 28 May 2015 05:24:52 +0000 Subject: [issue24310] Idle documentation -- what to do if you do not see an underscore. In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za> Message-ID: <1432790692.91.0.935278676598.issue24310@psf.upfronthosting.co.za> Ned Deily added the comment: Yes, that's probably a good thing to do in any case. I can add it to the Tcl/Tk info page for OS X as at least an interim measure: https://www.python.org/download/mac/tcltk/ ---------- assignee: docs at python -> ned.deily components: +IDLE versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 07:35:53 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 28 May 2015 05:35: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: <1432791353.73.0.128998767255.issue24017@psf.upfronthosting.co.za> Nick Coghlan added the comment: Given that tp_call is just "ternaryfunc", my guess would be "because when the iterator protocol was added, someone went with function-pointer-type-per-slot rather than function-pointer-type-per-call-signature". We *are* a little inconsistent here (e.g. "reprfunc" could also just use the "unaryfunc" signature), but Stefan's right that that isn't a good reason to *add* to the inconsistency. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 07:41:34 2015 From: report at bugs.python.org (Laura Creighton) Date: Thu, 28 May 2015 05:41:34 +0000 Subject: [issue24310] Idle documentation -- what to do if you do not see an underscore. In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za> Message-ID: <1432791694.91.0.840899031968.issue24310@psf.upfronthosting.co.za> Laura Creighton added the comment: Thank you. I don't think that this problem is unique to Retina Macbooks -- I had it on an ancient Toshiba laptop I was using about 15 years ago. It's not something that I have thought of very much recently. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 07:42:54 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Thu, 28 May 2015 05:42:54 +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: <1432791774.2.0.691459339684.issue24309@psf.upfronthosting.co.za> Dmitry Kazakov added the comment: Ugh, I guess I was too quick to propose deprecation, sorry :( But is it a strict "No" to the proposed use of str.format as well? This would be a (relatively) minor but useful change which, again, won't break anything. I can write the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 07:58:06 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Thu, 28 May 2015 05:58:06 +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: <1432792686.16.0.900876283142.issue24294@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Okay, that sounds reasonable to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 08:04:12 2015 From: report at bugs.python.org (Atzm WATANABE) Date: Thu, 28 May 2015 06:04:12 +0000 Subject: [issue24311] urllib2.urlopen() through proxy fails when HTTPS URL contains port number Message-ID: <1432793052.23.0.935714573518.issue24311@psf.upfronthosting.co.za> New submission from Atzm WATANABE: urllib2.urlopen() through proxy causes ssl.CertificateError when HTTPS URL contains port number. Sample code: $ https_proxy='http://proxy.example.com:8080/' python -c 'import urllib2; urllib2.urlopen("https://www.python.org:443/")' Traceback (most recent call last): File "", line 1, in File "/path/to/lib/python2.7/urllib2.py", line 154, in urlopen return opener.open(url, data, timeout) File "/path/to/lib/python2.7/urllib2.py", line 431, in open response = self._open(req, data) File "/path/to/lib/python2.7/urllib2.py", line 449, in _open '_open', req) File "/path/to/lib/python2.7/urllib2.py", line 409, in _call_chain result = func(*args) File "/path/to/lib/python2.7/urllib2.py", line 1240, in https_open context=self._context) File "/path/to/lib/python2.7/urllib2.py", line 1194, in do_open h.request(req.get_method(), req.get_selector(), req.data, headers) File "/path/to/lib/python2.7/httplib.py", line 1053, in request self._send_request(method, url, body, headers) File "/path/to/lib/python2.7/httplib.py", line 1093, in _send_request self.endheaders(body) File "/path/to/lib/python2.7/httplib.py", line 1049, in endheaders self._send_output(message_body) File "/path/to/lib/python2.7/httplib.py", line 893, in _send_output self.send(msg) File "/path/to/lib/python2.7/httplib.py", line 855, in send self.connect() File "/path/to/lib/python2.7/httplib.py", line 1274, in connect server_hostname=server_hostname) File "/path/to/lib/python2.7/ssl.py", line 352, in wrap_socket _context=self) File "/path/to/lib/python2.7/ssl.py", line 579, in __init__ self.do_handshake() File "/path/to/lib/python2.7/ssl.py", line 816, in do_handshake match_hostname(self.getpeercert(), self.server_hostname) File "/path/to/lib/python2.7/ssl.py", line 271, in match_hostname % (hostname, ', '.join(map(repr, dnsnames)))) ssl.CertificateError: hostname 'www.python.org:443' doesn't match either of 'www.python.org', 'python.org', 'pypi.python.org', 'docs.python.org', 'testpypi.python.org', 'bugs.python.org', 'wiki.python.org', 'hg.python.org', 'mail.python.org', 'packaging.python.org', 'pythonhosted.org', 'www.pythonhosted.org', 'test.pythonhosted.org', 'us.pycon.org', 'id.python.org' This problem seems to be caused because urllib2.AbstractHTTPHandler.do_open() calls httplib.HTTPSConnection.set_tunnel() without splitting hostname and port number. To fix this problem, I suggest applying the patch posted in issue https://bugs.python.org/issue22095 . This problem looks serious because it means we cannot access HTTPS using various port number at restricted environment (e.g. under the firewall). ---------- components: Library (Lib) messages: 244277 nosy: atzm priority: normal severity: normal status: open title: urllib2.urlopen() through proxy fails when HTTPS URL contains port number versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 08:06:40 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 28 May 2015 06:06:40 +0000 Subject: [issue24311] urllib2.urlopen() through proxy fails when HTTPS URL contains port number In-Reply-To: <1432793052.23.0.935714573518.issue24311@psf.upfronthosting.co.za> Message-ID: <1432793200.47.0.7250022224.issue24311@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 08:15:15 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 28 May 2015 06:15:15 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1432787716.5.0.179265895782.issue24017@psf.upfronthosting.co.za> Message-ID: <5566B271.2050906@behnel.de> Stefan Behnel added the comment: > Can't your Coroutine object return itself from its __await__, and implement > __next__? Like genobject in CPython simply returns self from its __iter__. That was my first try, sure, and it mostly worked. It has a drawback, though: it's an incomplete implementation of the Iterator protocol. It's still (mostly) an Iterator, but not an Iterable, so it depends on how you use it whether you notice or not, and whether it works at all with other code or not. There's a test for a failing "next(coro)" in your test suite, for example, which would then not fail in Cython. OTOH, code cannot assume that calling iter() or for-looping over on an Iterable is a sane thing to do, because it doesn't work for Python's generator type based coroutine either, so we might get away with it... All of these little details make this trick appear like a potential source of subtle inconsistencies or incompatibilities. But given that there will almost certainly remain inconsistencies for compiled Python code, I'm not sure yet which approach is better. It's not impossible that I'll end up going back to the original design. I guess I'll eventually have to include some benchmarks in the decision. On a related note, my testing made me stumble over this code in asyncio.tasks.Task(): if coro.__class__ is types.GeneratorType: self._coro = coro else: self._coro = iter(coro) # Use the iterator just in case. This seems wrong regardless of how you look at it. And it definitely fails with both designs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 08:16:10 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 28 May 2015 06:16:10 +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: <1432793770.94.0.440063211107.issue24294@psf.upfronthosting.co.za> Terry J. Reedy added the comment: For Idle, the addition could be made in current versions. Idle compiles user code in the idle process and ships it to the user process for execution. In particular, idlelib.run.Executive.runcode, line 351, is exec(code, self.locals) Am I to presume that a) the warnings that you want to display will escape the exec call and that b) they are currently being caught at the module level and c) that the filterwarnings line or lines would do what you want if added to run.main, such as at line 104? Do warnings from python code and user code get treated the same? Please post test cases to enter by hand, both at the prompt and in the editor, to get system warnings for 2.7 and 3.4 or 3.5. Also, please copy the positive and negative examples you posted to python-ideas. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 08:28:36 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 28 May 2015 06:28:36 +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: <1432794516.54.0.945521559333.issue24017@psf.upfronthosting.co.za> Stefan Behnel added the comment: BTW, given that "iter(iterator)" works and returns the iterator, should we also allow "await x.__await__()" to work? I guess that would be tricky to achieve given that __await__() is only required to return any kind of arbitrary Iterator, and Iterators cannot be awaited due to deliberate restrictions. But it might be nice to have for wrapping purposes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 08:48:01 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 28 May 2015 06:48:01 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1432785281.63.0.593517313764.issue24017@psf.upfronthosting.co.za> Message-ID: <5566BA1F.7000001@behnel.de> Stefan Behnel added the comment: >> Yield-from iterates, and a coroutine is not supposed to be iterable, only awaitable (at least, that's what all error messages tell me when I try it). So why should "yield from" work on them? What if foo() was not an Iterable but a Coroutine? Should "yield from" then call "__await__" on it internally? I would find that *really* surprising, but given the above, I think it would be necessary to achieve consistency. > > This is a special backwards-compatibility thing. That only answers the half-serious first part of my question. ;) This code only works if foo() returns an Iterable, including a (yield) coroutine: @types.coroutine def bar(): return (yield from foo()) It does not work for arbitrary Coroutines as they are not iterable, but it might trick people into writing code that fails for non-coroutine Coroutines. I'd rather like to have this either work for any Coroutine or not at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 09:21:43 2015 From: report at bugs.python.org (Dirkjan Ochtman) Date: Thu, 28 May 2015 07:21:43 +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: <1432797703.42.0.0284155729281.issue24303@psf.upfronthosting.co.za> Changes by Dirkjan Ochtman : ---------- nosy: +djc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 09:42:54 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Thu, 28 May 2015 07:42:54 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432798974.11.0.995157294499.issue24259@psf.upfronthosting.co.za> Lars Gust?bel added the comment: I have written a test for the issue, so that we have a basis for discussion. There are four different scenarios where an unexpected eof can occur: inside a metadata block, directly after a metadata block, inside a data segment or directly after a data segment (i.e. missing end of archive marker). Case #1 is taken care of (TruncatedHeaderError). Case #4 is merely a violation of standard, which is neglectable. Case #2 and #3 are essentially the same. If a data segment is empty or incomplete this means data was lost when the archive was created which should not go unnoticed when reading it. (see _FileInFile.read() for the code in question) The problem is that, even after we have fixed case #2 and #4, we have no reliable way to detect an incomplete data segment unless we read it and count the bytes. If we simply iterate over the TarFile (e.g. do a TarFile.list()) the archive will appear intact. That is because in the TarFile.next() method we seek from one metadata block to the next, but we cannot simply detect if we seek beyond the end of the archive - except if we insist on the premise that each tar that we read is standards-compliant and comes with an end of archive marker (see case #4), which we probably should not. Three possible options come to my mind: 1. Add a warning to the documentation that in order to test the integrity of an archive the user has to read through all the data segments. 2. Instead of using seek() in TarFile.next() use read() to advance the file pointer. This is a negative impact on the performance in most cases. 3. Insist on an end of archive marker. This has the disadvantage that users may get an exception although everything is fine. ---------- assignee: -> lars.gustaebel keywords: +patch Added file: http://bugs.python.org/file39528/01-issue24259-test.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 09:46:12 2015 From: report at bugs.python.org (Oz Tamir) Date: Thu, 28 May 2015 07:46:12 +0000 Subject: [issue24312] miniDOM._write_data() give a vague error message when the argument isn't of type str Message-ID: <1432799172.33.0.667430736974.issue24312@psf.upfronthosting.co.za> New submission from Oz Tamir: In Python 3.3, 3.4 and on 3.6.0a0 (default:dfe62f685538) the following snippet: >>> from xml.dom.minidom import getDOMImplementation >>> doc = getDOMImplementation().createDocument(None, 'Issues Tracker', None) >>> tracker = doc.documentElement >>> new_issue = doc.createElement('issue') >>> new_issue.setAttribute('id', 10) >>> tracker.appendChild(new_issue) >>> with open('file.xml', 'w') as f: ... doc.writexml(f, addindent='\t', newl='\n') will produce the following exception: [Traceback] AttributeError: 'int' object has no attribute 'replace' which I found to be vague and rather confusing. ---------- components: XML messages: 244283 nosy: oz.tamir priority: normal severity: normal status: open title: miniDOM._write_data() give a vague error message when the argument isn't of type str type: behavior versions: Python 3.3, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 09:49:50 2015 From: report at bugs.python.org (Oz Tamir) Date: Thu, 28 May 2015 07:49:50 +0000 Subject: [issue24312] miniDOM._write_data() give a vague error message when the argument isn't of type str In-Reply-To: <1432799172.33.0.667430736974.issue24312@psf.upfronthosting.co.za> Message-ID: <1432799390.62.0.23382789622.issue24312@psf.upfronthosting.co.za> Oz Tamir added the comment: I created a patch that will raise a TypeError when _write_data() has recvived an argument that is not a str. I found this exception and the error message it provide to be more straight forward and helpful when encountering this error. ---------- keywords: +patch Added file: http://bugs.python.org/file39529/issue24312.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 09:56:04 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 May 2015 07:56:04 +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: <1432799764.22.0.376449652917.issue24308@psf.upfronthosting.co.za> Martin Panter added the comment: Are you sure if fails since those revisions, or is _fixed_ by those revisions? See my initial report in Issue 24267. For me this test started failing a few weeks ago, and was fixed by updating to revision 29b95625a07c (?Merge 3.4 into default, upgrading pip to 7.0.1?). ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 10:14:16 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Thu, 28 May 2015 08:14:16 +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: <1432800856.85.0.232252239791.issue24294@psf.upfronthosting.co.za> Nathaniel Smith added the comment: There isn't really any magic in how warnings work. Basically someone calls warnings.warn(...), which is a regular Python function, and it gathers up some information about the specific warning message and calling context, checks a global variable ("warnings.filters") to decide how this message in this context should be handled, and then either does nothing, prints something to stderr, or raises an exception. There are lots of warnings that are printed by default, and I'm sure IDLE is handling them fine already. It's just (Pending)DeprecationWarnings in particular that have an entry stuck into warnings.filters saying "please ignore these" (unless it gets overridden by something else). So you just need to make sure that a filter is added to warnings.filters that says to treat DeprecationWarnings generated by the __main__ module using the "default" action. ("default" is the name of a specific way of handling warnings; for most types of warnings, the default handler is the one named "default", but for DeprecationWarning, the default handler is the one named "ignore". Obvious, right?) So you just need to make sure to run the following line of code somewhere in the user process: warnings.filterwarnings("default", category=DeprecationWarning, module="__main__") Adjust as necessary if (a) you want to apply similar handling to PendingDeprecationWarning, (b) your user namespace has some value of __name__ that is different from "__main__". Then to test, you can just type warnings.warn("foo", DeprecationWarning) at the prompt, and it should be printed. Note that because the warnings module tries to suppress duplicate warnings (which is good), and it has a bug where it can't tell the difference between different lines of code at the REPL (this is bad -- see https://github.com/ipython/ipython/issues/6611 , and there should probably be a python bug too but I haven't gotten around to filing it), then the *second* time you run that line of code in the same REPL, nothing will be printed. So the moral is just, when testing this, make sure you use a different warning message each time, or you'll get very confused. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 10:20:06 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 May 2015 08:20:06 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432801206.79.0.940161072863.issue24259@psf.upfronthosting.co.za> Martin Panter added the comment: If you are already seeking in the file, can?t you seek to the end to determine the length of the file, and then use that to verify if a data segment is truncated? And if you can?t seek, I guess you have to read all the bytes anyway. I guess Ethan?s test was an instance of case #4 (EOF directly after data block). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 10:32:31 2015 From: report at bugs.python.org (Thomas Arildsen) Date: Thu, 28 May 2015 08:32:31 +0000 Subject: [issue24313] json fails to serialise numpy.int64 Message-ID: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> New submission from Thomas Arildsen: When I run the attached example in Python 2.7.9, it succeeds. In Python 3.4, it fails as shown below. I use json 2.0.9 and numpy 1.9.2 with both versions of Python. Python and all packages provided by Anaconda 2.2.0. The error seems to be caused by the serialised object containing a numpy.int64 type. It might fail with other 64-bit numpy types as well (untested). --------------------------------------------------------------------------- TypeError Traceback (most recent call last) /home/tha/tmp/debug_json/debug_json.py in () 4 test = {'value': np.int64(1)} 5 ----> 6 obj=json.dumps(test) /home/tha/.conda/envs/python3/lib/python3.4/json/__init__.py in dumps(obj, skipkeys, ensure_ascii, check_circular, allow_nan, cls, indent, separators, default, sort_keys, **kw) 228 cls is None and indent is None and separators is None and 229 default is None and not sort_keys and not kw): --> 230 return _default_encoder.encode(obj) 231 if cls is None: 232 cls = JSONEncoder /home/tha/.conda/envs/python3/lib/python3.4/json/encoder.py in encode(self, o) 190 # exceptions aren't as detailed. The list call should be roughly 191 # equivalent to the PySequence_Fast that ''.join() would do. --> 192 chunks = self.iterencode(o, _one_shot=True) 193 if not isinstance(chunks, (list, tuple)): 194 chunks = list(chunks) /home/tha/.conda/envs/python3/lib/python3.4/json/encoder.py in iterencode(self, o, _one_shot) 248 self.key_separator, self.item_separator, self.sort_keys, 249 self.skipkeys, _one_shot) --> 250 return _iterencode(o, 0) 251 252 def _make_iterencode(markers, _default, _encoder, _indent, _floatstr, /home/tha/.conda/envs/python3/lib/python3.4/json/encoder.py in default(self, o) 171 172 """ --> 173 raise TypeError(repr(o) + " is not JSON serializable") 174 175 def encode(self, o): TypeError: 1 is not JSON serializable ---------- files: debug_json.py messages: 244288 nosy: thomas-arildsen priority: normal severity: normal status: open title: json fails to serialise numpy.int64 type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39530/debug_json.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 10:41:20 2015 From: report at bugs.python.org (Thomas Guettler) Date: Thu, 28 May 2015 08:41:20 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432802480.25.0.508468192098.issue24259@psf.upfronthosting.co.za> Thomas Guettler added the comment: I uploaded a broken tar for testing: tguettler at aptguettler:~/tmp ===> LANG=C tar -xf tar_which_is_cut.tar tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now tguettler at aptguettler:~/tmp ===> 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 tarfile >>> tarfile.TarFile('tar_which_is_cut.tar', errorlevel=2).extractall() >>> (Sad, no error) ---------- Added file: http://bugs.python.org/file39531/tar_which_is_cut.tar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 11:03:43 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Thu, 28 May 2015 09:03:43 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432803823.81.0.93834702794.issue24259@psf.upfronthosting.co.za> Lars Gust?bel added the comment: @Martin: Yes, that's right, but only for cases where the TarFile.fileobj attribute is an actual file object. But, most of the time it is something special, e.g. GzipFile or sys.stdin, which makes random seeking either impossible or perform very badly. But thanks for your objection, I have to withdraw the statement I made under option 2.: compressed archives are much more common than uncompressed ones. We probably wouldn't lose too much if we no longer use seek() but read() in TarFile.next(). Reading in an uncompressed file is fast anyway. I have to think about this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 11:07:54 2015 From: report at bugs.python.org (=?utf-8?q?Mat=C4=9Bj_Stuchl=C3=ADk?=) Date: Thu, 28 May 2015 09:07:54 +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: <1432804074.64.0.929790960358.issue23968@psf.upfronthosting.co.za> Changes by Mat?j Stuchl?k : ---------- nosy: +sYnfo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 11:25:04 2015 From: report at bugs.python.org (Tal Einat) Date: Thu, 28 May 2015 09:25:04 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432805104.74.0.537849463275.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: Hopefully final patch attached. This adds cmath.isclose() along with relevant tests and documentation. Note that cmath.isclose() rejects complex tolerances -- only the values may be complex. ---------- Added file: http://bugs.python.org/file39532/isclose.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 13:45:14 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 28 May 2015 11:45:14 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432813514.37.0.500486222269.issue24270@psf.upfronthosting.co.za> Stefan Krah added the comment: I think users may be surprised that any two large Decimals like "1e400000" and "1e999" are "close". In the Decimal world these aren't infinite. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 14:05:03 2015 From: report at bugs.python.org (Florian Bruhin) Date: Thu, 28 May 2015 12:05:03 +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: <1432814703.89.0.477973053317.issue24294@psf.upfronthosting.co.za> Changes by Florian Bruhin : ---------- nosy: +The Compiler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 14:05:21 2015 From: report at bugs.python.org (Tal Einat) Date: Thu, 28 May 2015 12:05:21 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432814721.42.0.430204778772.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: @Stefan: Well, this seems to already be the situation with the rest of the math module: >>> math.isinf(Decimal("1e999")) True >>> math.sqrt(Decimal("1e999")) inf Properly handling other types which are convertible to floats, such as Decimal and Fraction, is outside the scope of this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 14:07:44 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 28 May 2015 12:07:44 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432814721.42.0.430204778772.issue24270@psf.upfronthosting.co.za> Message-ID: <5567050E.5000609@behnel.de> Stefan Behnel added the comment: > Properly handling other types which are convertible to floats, such as Decimal and Fraction, is outside the scope of this issue. ... and outside of the scope of the math module in general. It's inherently floating point based. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 14:14:55 2015 From: report at bugs.python.org (Tal Einat) Date: Thu, 28 May 2015 12:14:55 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432815295.59.0.260476977695.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: Alright then, but is anyone going to review this so that it can go in? The actual code to review is very short, the documentation is clearly written and not too long, and the tests are easy to read! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 14:49:13 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 28 May 2015 12:49:13 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432817353.82.0.963079500114.issue24270@psf.upfronthosting.co.za> Paul Moore added the comment: Looks OK to me. I assume the differences between the math and cmath code and tests is because cmath uses Argument Clinic and math doesn't, and cmath uses unittest.main whereas math adds the suites manually? As far as I can see, that's what's going on. ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 14:56:37 2015 From: report at bugs.python.org (Tal Einat) Date: Thu, 28 May 2015 12:56:37 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432817797.73.0.678234036925.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: Indeed, those are major reasons for differences. I avoided using Argument Clinic for math.isclose() because there is a pending conversion patch for the entire math module and I didn't want to cause unnecessary merge conflicts. Is Paul's okay enough for me to commit this, or should we also get an okay from one of the three people listed next to the math module on the experts index? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 15:25:49 2015 From: report at bugs.python.org (Brandon Milam) Date: Thu, 28 May 2015 13:25:49 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1432819549.73.0.791850633393.issue8232@psf.upfronthosting.co.za> Brandon Milam added the comment: I went ahead and took the assert statement out and added support for vista using a union of sets for both the 32 bit and 64 bit locations. ---------- Added file: http://bugs.python.org/file39533/webbrowserfix3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 15:36:02 2015 From: report at bugs.python.org (Brandon Milam) Date: Thu, 28 May 2015 13:36:02 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1432820162.01.0.325410825586.issue8232@psf.upfronthosting.co.za> Brandon Milam added the comment: On second thought no type testing is required if sets are used because the union will take out duplicates anyways and so I removed the type testing and left in the set union code. ---------- Added file: http://bugs.python.org/file39534/webbrowserfix3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 15:39:59 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 28 May 2015 13:39:59 +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: <1432820399.4.0.897499216171.issue24305@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 16:16:16 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 28 May 2015 14:16:16 +0000 Subject: [issue24312] miniDOM._write_data() give a vague error message when the argument isn't of type str In-Reply-To: <1432799172.33.0.667430736974.issue24312@psf.upfronthosting.co.za> Message-ID: <1432822576.83.0.115963354557.issue24312@psf.upfronthosting.co.za> Eric V. Smith added the comment: As a rule, we don't put in checks like this. There are an untold number of places where such checks could be added. I suspect the new typing module will be a better way to catch these types of errors. Does the problem not occur with 3.5? ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 16:27:14 2015 From: report at bugs.python.org (July Tikhonov) Date: Thu, 28 May 2015 14:27:14 +0000 Subject: [issue24314] irrelevant cross-link in documentation of user-defined functions Message-ID: <1432823234.49.0.975414233418.issue24314@psf.upfronthosting.co.za> New submission from July Tikhonov: https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy There is a table of "special attributes" of user-defined functions. The __name__ attribute name is a link, but it leads to something quite irrelevant: the description of __name__ attribute of imported modules. In Doc/reference/datamodel.rst, there is nothing special about __name__ attribute, so it looks like some random spasm of Sphinx creating links here and there. My knowledge of rst is not sufficient to suppress it. ---------- assignee: docs at python components: Documentation messages: 244301 nosy: docs at python, july priority: normal severity: normal status: open title: irrelevant cross-link in documentation of user-defined functions type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 16:33:32 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 28 May 2015 14:33:32 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432823612.25.0.782878823799.issue24268@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 16:37:28 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 28 May 2015 14:37:28 +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: <1432823848.32.0.999682613877.issue24305@psf.upfronthosting.co.za> Brett Cannon added the comment: My personal plan was to get issue #23810 finished, make sure it worked, and then expose a public API for declaring module deprecations which used the private API under the hood. I'm hoping to get #23810 done this Friday and then we can talk about how we may want to expose a function in the warnings module for deprecating modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 16:53:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 May 2015 14:53:26 +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: <20150528145322.62595.38620@psf.io> Roundup Robot added the comment: New changeset 09327f653ec5 by Yury Selivanov in branch '3.4': asyncio: Drop some useless code from tasks.py. https://hg.python.org/cpython/rev/09327f653ec5 New changeset adf72cffceb7 by Yury Selivanov in branch '3.5': asyncio: Drop some useless code from tasks.py. https://hg.python.org/cpython/rev/adf72cffceb7 New changeset 9c0a00247021 by Yury Selivanov in branch 'default': asyncio: Drop some useless code from tasks.py. https://hg.python.org/cpython/rev/9c0a00247021 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 17:07:12 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 28 May 2015 15:07:12 +0000 Subject: [issue23810] Suboptimal stacklevel of deprecation warnings for formatter and imp modules In-Reply-To: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za> Message-ID: <1432825632.52.0.190509954594.issue23810@psf.upfronthosting.co.za> Eric Snow added the comment: I had a similar concern, Nick, but don't think I did anything that would have broken the frame hiding logic. That said, I did not take stacklevel for warnings into account. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 17:13:20 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 May 2015 15:13:20 +0000 Subject: [issue24315] collections.abc: Coroutine should be derived from Awaitable Message-ID: <1432826000.86.0.336894451346.issue24315@psf.upfronthosting.co.za> New submission from Yury Selivanov: See issue 24017 for details. ---------- assignee: yselivanov components: Library (Lib) files: abcs.patch keywords: patch messages: 244305 nosy: gvanrossum, ncoghlan, scoder, yselivanov priority: normal severity: normal stage: patch review status: open title: collections.abc: Coroutine should be derived from Awaitable versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39535/abcs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 17:13:46 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 May 2015 15:13:46 +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: <1432826026.24.0.67513272082.issue24017@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- dependencies: +collections.abc: Coroutine should be derived from Awaitable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 17:14:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 May 2015 15:14:01 +0000 Subject: [issue24312] miniDOM._write_data() give a vague error message when the argument isn't of type str In-Reply-To: <1432799172.33.0.667430736974.issue24312@psf.upfronthosting.co.za> Message-ID: <1432826041.08.0.834958983737.issue24312@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Agree with Eric. And the error message doesn't look lying. ---------- nosy: +serhiy.storchaka resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 17:22:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 May 2015 15:22:52 +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: <20150528152248.125203.89062@psf.io> Roundup Robot added the comment: New changeset dfa0288c91fd by Yury Selivanov in branch '3.5': Issue 24017: Drop getawaitablefunc and friends in favor of unaryfunc. https://hg.python.org/cpython/rev/dfa0288c91fd New changeset 99dcca3466d3 by Yury Selivanov in branch 'default': Issue 24017: Drop getawaitablefunc and friends in favor of unaryfunc. https://hg.python.org/cpython/rev/99dcca3466d3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 17:46:08 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 28 May 2015 15:46:08 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432827968.26.0.527353781578.issue24270@psf.upfronthosting.co.za> Stefan Krah added the comment: > It's inherently floating point based. Except for floor() and ceil() though. The wording in the PEP under "non-float" types made me think that something similar was intended here. Personally I'm fine with math being float-only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 17:47:36 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 28 May 2015 15:47:36 +0000 Subject: [issue23903] Generate PC/python3.def by scraping headers In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za> Message-ID: <1432828056.77.0.739379987456.issue23903@psf.upfronthosting.co.za> Steve Dower added the comment: It might be nice to have a test that tries to import all of the stable ABI at build time so that the buildbots break if someone adds a new API and doesn't think about what they've done. As an aside, it'd be nice for the script to take the version numbers as args so we can integrate it into the MSBuild steps (which already know the version) and avoid having to update this each time we update the Python version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 17:48:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 May 2015 15:48:57 +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: <1432828137.81.0.505839172609.issue24305@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be better to skip _frozen_importlib frames automatically instead of forcing end users to use special API. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 17:53:23 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 28 May 2015 15:53:23 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432828402.99.0.496002657202.issue24270@psf.upfronthosting.co.za> Stefan Krah added the comment: Also, I must say that returning inf in sqrt() bothers me much less than the assertion that two numbers with a gigantic relative error have a relerr of 1e-9. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 17:58:45 2015 From: report at bugs.python.org (Jeroen Ruigrok van der Werven) Date: Thu, 28 May 2015 15:58:45 +0000 Subject: [issue18233] SSLSocket.getpeercertchain() In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za> Message-ID: <1432828725.3.0.378001168076.issue18233@psf.upfronthosting.co.za> Jeroen Ruigrok van der Werven added the comment: Given that cryptography.io is fast becoming the solution for dealing with X.509 certificates on Python, I would like to add my vote to add my vote for this feature. Right now, getting the full chain in DER is what I am missing to complete a task at work. ---------- nosy: +asmodai _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 18:03:38 2015 From: report at bugs.python.org (Dustin Oprea) Date: Thu, 28 May 2015 16:03:38 +0000 Subject: [issue18233] SSLSocket.getpeercertchain() In-Reply-To: <1432828725.3.0.378001168076.issue18233@psf.upfronthosting.co.za> Message-ID: Dustin Oprea added the comment: Forget it. This project is dead. Dustin On May 28, 2015 11:58 AM, "Jeroen Ruigrok van der Werven" < report at bugs.python.org> wrote: > > Jeroen Ruigrok van der Werven added the comment: > > Given that cryptography.io is fast becoming the solution for dealing with > X.509 certificates on Python, I would like to add my vote to add my vote > for this feature. Right now, getting the full chain in DER is what I am > missing to complete a task at work. > > ---------- > nosy: +asmodai > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 18:07:07 2015 From: report at bugs.python.org (Dustin Oprea) Date: Thu, 28 May 2015 16:07:07 +0000 Subject: [issue18233] SSLSocket.getpeercertchain() In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za> Message-ID: <1432829227.56.0.0389094928014.issue18233@psf.upfronthosting.co.za> Dustin Oprea added the comment: Disregard. I thought this was something else. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 18:31:52 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 May 2015 16:31:52 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython Message-ID: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> New submission from Yury Selivanov: Stefan, This patch should solve the problem with types.coroutine accepting only pure python generator functions. The approach is, however, slightly different from what you've proposed. Instead of having a wrapper class (delegating .throw, .send etc to a wrapped object), we now simply check if the returned value of the wrapped function is an instance of collections.abc.Coroutine. Issue 24315 enables duck typing for coroutines, so if a cython-based coroutine implements all coroutine abstract methods, it will automatically pass types.coroutine. ---------- assignee: yselivanov components: Library (Lib) files: coroutine.patch keywords: patch messages: 244315 nosy: gvanrossum, ncoghlan, scoder, yselivanov priority: normal severity: normal stage: patch review status: open title: Fix types.coroutine to accept objects from Cython versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39536/coroutine.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 18:32:02 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 May 2015 16:32:02 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <1432830722.13.0.448980466672.issue24316@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- dependencies: +collections.abc: Coroutine should be derived from Awaitable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 18:33:16 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 28 May 2015 16:33:16 +0000 Subject: [issue24317] Change installer Customize default to match quick settings Message-ID: <1432830796.7.0.202378193583.issue24317@psf.upfronthosting.co.za> New submission from Steve Dower: (This is a reminder to myself, unless someone gets a patch in sooner than I get to it.) Currently if you click "Customize" in the installer and then Next/Install without changing any settings, you get a default per-machine installation. However, if you click the Install Now button at the start, you get a default per-user installation. The customize settings default should be changed to do a per-user install. We also need logic in the BA to enable Precompile Standard Library automatically when the all-users setting is enabled, otherwise people will miss that option. ---------- assignee: steve.dower components: Windows messages: 244316 nosy: steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Change installer Customize default to match quick settings type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 18:34:25 2015 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 28 May 2015 16:34:25 +0000 Subject: [issue24318] Make profile-opt the default Make target? Message-ID: <1432830865.51.0.995414707141.issue24318@psf.upfronthosting.co.za> New submission from Skip Montanaro: In a discussion on python-ideas about some computed goto stuff, Greg Smith brought up compilation with "profile-opt", which I'd never heard of. I asked Greg about it and he enlightened me. Looking around, I saw no mention of this make target except in the Makefile itself, and a small what's new note for Python 2.6. I was only looking on the 2.7 branch, but aside from a bug fix mention in Misc/NEWS for Python 3.4, it doesn't seem to feature more prominently there. It would seem to be stable. Should it perhaps be the default when available (presuming the proper configure tests can be written)? Alternatively, it could be featured more prominently in the build instructions. I've attached a simple patch to README for that. ---------- components: Build files: README.diff keywords: easy, patch messages: 244317 nosy: skip.montanaro priority: normal severity: normal status: open title: Make profile-opt the default Make target? versions: Python 2.7, Python 3.6 Added file: http://bugs.python.org/file39537/README.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 18:34:32 2015 From: report at bugs.python.org (Andrew Stormont) Date: Thu, 28 May 2015 16:34:32 +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: <1432830872.0.0.333825259532.issue23895@psf.upfronthosting.co.za> Andrew Stormont added the comment: The -z ignore option is actually exposing issues that could cause a problem at runtime. If the socket module were imported and libsocket/libnsl hadn't already been loaded (i.e pulled in by the loader as a dependency of another module) the loader would fail due to unresolved symbols. This problem would not effect Linux because all of the socket stuff is in libc, which is not the case on Solaris. Today it doesn't cause a problem because most other things are already pulling in libsocket and libnsl before the socket module is loaded, but there's no guarantee that will always be the case. For the sake of correctness it should be fixed, and I would suggest later making -z ignore the default on Solaris. I will see if I can find somebody else to review the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 18:42:29 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 May 2015 16:42:29 +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: <1432831349.2.0.0262735778156.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: Stefan, I've already committed fixes for: 1. getawaitablefunc / aiternextfunc / getaiterfunc -> unaryfunc 2. strange code in tasks.py doing "coro = iter(coro)" is now removed I've also opened a couple of new issues (with patches for a review): 1. abc.Coroutine derived from abc.Awaitable: issue 24315 2. types.coroutine() to support Cython objects: issue 24316 I'll reply to some of your messages below: > Another question: is it ok if Cython implements and uses the "tp_as_async" slot in all Py3.x versions (3.2+)? It shouldn't hurt, [..] I think it's totally OK, given that you can workaround the drawback you mentioned. >> Can't your Coroutine object return itself from its __await__, and implement >> __next__? Like genobject in CPython simply returns self from its __iter__. > That was my first try, sure, and it mostly worked. It has a drawback, > though: it's an incomplete implementation of the Iterator protocol. It's > still (mostly) an Iterator, but not an Iterable, so it depends on how you > use it whether you notice or not, and whether it works at all with other > code or not. There's a test for a failing "next(coro)" in your test suite, > for example, which would then not fail in Cython. [..] I think if "next(cython_coro)" does not fail is acceptable. It's not ideal, but the purpose of Cython is to make Python code as fast as possible, so I'd try to avoid having any kind of "thin wrappers" around Cyhton coroutines. ---------- dependencies: +Fix types.coroutine to accept objects from Cython _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 18:42:47 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 28 May 2015 16:42:47 +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: <1432831367.69.0.638490763828.issue24309@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, I'm sure there is a lot of code that uses string.Template, partly because I've used it in at least three different projects for three different customers ;) If you are willing to write a patch that might get superseded by Serhiy's code (if he decides to write it :), then I say go for it. I'm not sure what coverage is like on the Template code (not that coverage by itself is enough!)...you might want to add some more tests to make *sure* we aren't breaking backward compatibility. But, we should see what Barry thinks :) And yeah, that line 146 thing is probably due to the unicode coercion issues with string formatting for which there are (I believe) more than one open issue in this tracker (the most recent one was in the warnings module, I think). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 18:54:40 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 28 May 2015 16:54:40 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1432832080.52.0.379150577552.issue24313@psf.upfronthosting.co.za> R. David Murray added the comment: All python3 ints are what used to be long ints in python2, so the code that recognized short ints no longer exists. Do the numpy types implement __index__? It looks like json doesn't check for __index__, and I wonder if it should. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 18:59:00 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 28 May 2015 16:59:00 +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: <1432832340.49.0.873219734425.issue24017@psf.upfronthosting.co.za> Stefan Behnel added the comment: Thanks Yury, I'll give it a try ASAP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 19:01:02 2015 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 28 May 2015 17:01:02 +0000 Subject: [issue24319] Crash during "make coverage-report" Message-ID: <1432832461.97.0.279218434752.issue24319@psf.upfronthosting.co.za> New submission from Skip Montanaro: While trying out some of the auxiliary make targets on an openSUSE 12.2 system, I got a segfault during the test phase of the coverage-report target. Several Python processes were running as part of the test when the crash occurred. The resulting crash causes the rest of the test process(es) to hang. Ctl-C is required to get back to a shell prompt. Here's the traceback reported in the terminal window: ... File "/home/skipm/3rdParty/python/cpython/Lib/json/scanner.py", line 38 in _scan_once File "/home/skipm/3rdParty/python/cpython/Lib/json/decoder.py", line 185 in JSONObject File "/home/skipm/3rdParty/python/cpython/Lib/json/scanner.py", line 38 in _scan_once ... Traceback (most recent call last): File "/home/skipm/3rdParty/python/cpython/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/home/skipm/3rdParty/python/cpython/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/skipm/3rdParty/python/cpython/Lib/test/__main__.py", line 3, in regrtest.main_in_temp_cwd() File "/home/skipm/3rdParty/python/cpython/Lib/test/regrtest.py", line 1560, in main_in_temp_cwd main() File "/home/skipm/3rdParty/python/cpython/Lib/test/regrtest.py", line 738, in main raise Exception("Child error on {}: {}".format(test, result[1])) Exception: Child error on test_json: Exit code -11 ^CException ignored in: Traceback (most recent call last): File "/home/skipm/3rdParty/python/cpython/Lib/threading.py", line 1297, in _shutdown t.join() File "/home/skipm/3rdParty/python/cpython/Lib/threading.py", line 1063, in join self._wait_for_tstate_lock() File "/home/skipm/3rdParty/python/cpython/Lib/threading.py", line 1079, in _wait_for_tstate_lock elif lock.acquire(block, timeout): KeyboardInterrupt make: *** [coverage-report] Interrupt I noticed that while it crashes reproducibly, it's not always in the same place. Here's a traceback from a crash in test_exceptions.py: ... File "/home/skipm/3rdParty/python/cpython/Lib/test/test_exceptions.py", line 476 in f File "/home/skipm/3rdParty/python/cpython/Lib/test/test_exceptions.py", line 476 in f File "/home/skipm/3rdParty/python/cpython/Lib/test/test_exceptions.py", line 476 in f ... Traceback (most recent call last): File "/home/skipm/3rdParty/python/cpython/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/home/skipm/3rdParty/python/cpython/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/skipm/3rdParty/python/cpython/Lib/test/__main__.py", line 3, in regrtest.main_in_temp_cwd() File "/home/skipm/3rdParty/python/cpython/Lib/test/regrtest.py", line 1560, in main_in_temp_cwd main() File "/home/skipm/3rdParty/python/cpython/Lib/test/regrtest.py", line 738, in main raise Exception("Child error on {}: {}".format(test, result[1])) Exception: Child error on test_exceptions: Exit code -11 ^CException ignored in: Traceback (most recent call last): File "/home/skipm/3rdParty/python/cpython/Lib/threading.py", line 1297, in _shutdown t.join() File "/home/skipm/3rdParty/python/cpython/Lib/threading.py", line 1063, in join self._wait_for_tstate_lock() File "/home/skipm/3rdParty/python/cpython/Lib/threading.py", line 1079, in _wait_for_tstate_lock elif lock.acquire(block, timeout): KeyboardInterrupt I've attached the output of pgrep showing the Python processes which were left running. Here's the stack trace from the core file: # 0 raise () from /lib64/libc.so.6 # 1 abort () from /lib64/libc.so.6 # 2 Py_FatalError (msg=0x775528 "Py_EndInterpreter: not the last thread") at Python/pylifecycle.c:1374 # 3 Py_EndInterpreter (tstate=0x25b41c0) at Python/pylifecycle.c:826 # 4 run_in_subinterp (self=0x7f9dd8b9d9a8, args=0x7f9dd8b92e80) at /home/skipm/3rdParty/python/cpython/Modules/_testcapimodule.c:2627 # 5 PyCFunction_Call (func=0x7f9dd8babd38, args=0x7f9dd8b92e80, kwds=0x0) at Objects/methodobject.c:109 # 6 call_function (pp_stack=0x7fffc68bda98, oparg=1) at Python/ceval.c:4653 # 7 PyEval_EvalFrameEx (f=0x260ae08, throwflag=0) at Python/ceval.c:3198 # 8 _PyEval_EvalCodeWithName (_co=0x7f9dd8c5bc00, globals=0x7f9dd8c9ffc8, locals=0x7f9dd8c9ffc8, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:3964 # 9 PyEval_EvalCodeEx (_co=0x7f9dd8c5bc00, globals=0x7f9dd8c9ffc8, locals=0x7f9dd8c9ffc8, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3985 #10 PyEval_EvalCode (co=0x7f9dd8c5bc00, globals=0x7f9dd8c9ffc8, locals=0x7f9dd8c9ffc8) at Python/ceval.c:777 #11 run_mod (mod=0x264dfb8, filename=0x7f9dd8c67eb0, globals=0x7f9dd8c9ffc8, locals=0x7f9dd8c9ffc8, flags=0x7fffc68bfe80, arena=0x263e470) at Python/pythonrun.c:970 #12 PyRun_StringFlags (str=0x7f9dd8c5c050 "if 1:\n", ' ' , "import _testcapi\n\n", ' ' , "_testcapi.run_in_subinterp('if 1:\\n", ' ' , "import os\\n", ' ' , "import threading\\n", ' ' , "import time\\n\\n", ' ' , "def f():\\n", ' ' ..., start=257, globals=0x7f9dd8c9ffc8, locals=0x7f9dd8c9ffc8, flags=0x7fffc68bfe80) at Python/pythonrun.c:894 #13 PyRun_SimpleStringFlags (command=0x7f9dd8c5c050 "if 1:\n", ' ' , "import _testcapi\n\n", ' ' , "_testcapi.run_in_subinterp('if 1:\\n", ' ' , "import os\\n", ' ' , "import threading\\n", ' ' , "import time\\n\\n", ' ' , "def f():\\n", ' ' ..., flags=0x7fffc68bfe80) at Python/pythonrun.c:421 #14 run_command (command=0x259ecc0 L"if 1:\n", ' ' , "import _testcapi\n\n", ' ' , "_testcapi.run_in_subinterp('if 1:\\n", ' ' , "import os\\n", ' ' , "import threading\\n", ' ' , "import time\\n\\n", ' ' , "def f():\\n", ' ' ..., cf=0x7fffc68bfe80) at Modules/main.c:279 #15 Py_Main (argc=6, argv=0x259e010) at Modules/main.c:706 #16 main (argc=6, argv=0x7fffc68c0098) at ./Programs/python.c:69 ---------- files: running messages: 244323 nosy: skip.montanaro priority: normal severity: normal status: open title: Crash during "make coverage-report" type: crash versions: Python 3.6 Added file: http://bugs.python.org/file39538/running _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 19:11:09 2015 From: report at bugs.python.org (Alexander Pyhalov) Date: Thu, 28 May 2015 17:11:09 +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: <1432833069.22.0.16750126082.issue23895@psf.upfronthosting.co.za> Alexander Pyhalov added the comment: We have similar patch here in OpenIndiana. The patch is correct. ---------- nosy: +Alexander.Pyhalov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 19:18:48 2015 From: report at bugs.python.org (Alexander Pyhalov) Date: Thu, 28 May 2015 17:18:48 +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: <1432833528.88.0.842734848805.issue23895@psf.upfronthosting.co.za> Alexander Pyhalov added the comment: BTW, we use the following version for Python 3.4 ---------- Added file: http://bugs.python.org/file39539/socket.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 19:37:04 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 28 May 2015 17:37:04 +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: <1432834624.74.0.0722113397205.issue24309@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: So yeah, we don't want to deprecate string.Template. It has a very specific use case that's used a lot, i.e. making strings dead simple to translate. %(foo)s was very problematic. {foo} is a little better, but looks too weird for most translators. $foo is very common, well understood, and hard to get wrong. As for modernizing the code (the L146 bit was thanks to Python 2), I wouldn't be against it if it doesn't change the documented API or functionality and all the tests still pass (and there's good coverage - I don't remember anymore). I don't think it's really that important though; typically these are not used in performance critical sections. Re: ${thing.attribute} - no, that wouldn't keep them Simple and PEP 292 was deliberately targeting simplicity. Bottom line: keep $-strings simple and focused on their original use case. For more complicated use cases, use str.format(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 19:42:00 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 28 May 2015 17:42:00 +0000 Subject: [issue24318] Make profile-opt the default Make target? In-Reply-To: <1432830865.51.0.995414707141.issue24318@psf.upfronthosting.co.za> Message-ID: <1432834920.8.0.163565862278.issue24318@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The Makefile's default "make all" target is meant for developers and iterative development. make profile-opt is not. If anything, this issue should document it somewhere if we even have docs on how to make "release" builds of something. Realistically Debian already uses profile-opt for its binary builds. I _believe_ the rpm based distros do as well (but I haven't checked, someone else can confirm). Anyone else not doing so, please look at what debian does: make profile-opt PROFILE_TASK="..." where ... is regrtest.py given a test exclusion list of some of the longer running more annoying ones. Not using a profile-opt builds in production is costing you ~10-40% in CPU performance. This advice applies to all programs, not only python. :) ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 19:42:44 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 28 May 2015 17:42:44 +0000 Subject: [issue24318] Make profile-opt the default Make target? In-Reply-To: <1432830865.51.0.995414707141.issue24318@psf.upfronthosting.co.za> Message-ID: <1432834964.84.0.797821682377.issue24318@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Also FWIW, I setup a buildbot earlier this year building in profile-opt mode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 19:45:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 May 2015 17:45:39 +0000 Subject: [issue4753] Faster opcode dispatch on gcc In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za> Message-ID: <20150528174535.119128.90121@psf.io> Roundup Robot added the comment: New changeset 17d3bbde60d2 by Benjamin Peterson in branch '2.7': backport computed gotos (#4753) https://hg.python.org/cpython/rev/17d3bbde60d2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 19:45:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 May 2015 17:45:51 +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: <20150528174549.84477.59954@psf.io> Roundup Robot added the comment: New changeset 678a76610723 by Serhiy Storchaka in branch 'default': Issue #24309: Removed Python 2 idioms. https://hg.python.org/cpython/rev/678a76610723 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 19:53:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 May 2015 17:53:16 +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: <1432835596.42.0.665935021482.issue24309@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Agree with Barry. And please note, that string.Template is not invented in Python, it is used in a lot of other languages, including shell, make, Tcl, Perl. One of the advantage is that these templates are cross-language. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 20:01:38 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 28 May 2015 18:01:38 +0000 Subject: [issue24318] Better documentaiton of profile-opt (and release builds in general?) In-Reply-To: <1432830865.51.0.995414707141.issue24318@psf.upfronthosting.co.za> Message-ID: <1432836098.39.0.581829894109.issue24318@psf.upfronthosting.co.za> R. David Murray added the comment: Agreed with Greg, this should not be the default. Changing title and component to reflect that better documentation is the goal here. ---------- assignee: -> docs at python components: +Documentation -Build nosy: +docs at python, r.david.murray stage: -> needs patch title: Make profile-opt the default Make target? -> Better documentaiton of profile-opt (and release builds in general?) versions: +Python 3.4, Python 3.5 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 20:03:26 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 28 May 2015 18:03:26 +0000 Subject: [issue24306] Backport py.exe to 3.4 In-Reply-To: <1432771856.97.0.606443218974.issue24306@psf.upfronthosting.co.za> Message-ID: <1432836206.51.0.356313854604.issue24306@psf.upfronthosting.co.za> Mark Lawrence added the comment: I don't see removing the launcher as an option. So how about do the backport and make certain it's well documented in the release notes and here https://docs.python.org/3/using/windows.html ? If anyone has a better idea feel free to fire away. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 20:06:20 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 May 2015 18:06:20 +0000 Subject: [issue24297] Lib/symbol.py is out of sync with Grammar/Grammar In-Reply-To: <1432731074.7.0.288731701326.issue24297@psf.upfronthosting.co.za> Message-ID: <20150528180617.27300.11024@psf.io> Roundup Robot added the comment: New changeset a95d0dd3c2b1 by Yury Selivanov in branch 'default': Issue 24297: Add a unittest that Lib/symbol.py is in sync with Grammar https://hg.python.org/cpython/rev/a95d0dd3c2b1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 20:06:37 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 May 2015 18:06:37 +0000 Subject: [issue24297] Lib/symbol.py is out of sync with Grammar/Grammar In-Reply-To: <1432731074.7.0.288731701326.issue24297@psf.upfronthosting.co.za> Message-ID: <1432836397.27.0.242704699059.issue24297@psf.upfronthosting.co.za> Yury Selivanov added the comment: Marius, thanks for reporting the bug and review! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 20:06:48 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 May 2015 18:06:48 +0000 Subject: [issue24297] Lib/symbol.py is out of sync with Grammar/Grammar In-Reply-To: <1432731074.7.0.288731701326.issue24297@psf.upfronthosting.co.za> Message-ID: <1432836408.33.0.430716611134.issue24297@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 Thu May 28 20:37:50 2015 From: report at bugs.python.org (Steve Dougherty) Date: Thu, 28 May 2015 18:37:50 +0000 Subject: [issue11205] Evaluation order of dictionary display is different from reference manual. In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za> Message-ID: <1432838270.25.0.182806803299.issue11205@psf.upfronthosting.co.za> Steve Dougherty added the comment: Anyone care to review issue11205-v3.patch ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 20:43:42 2015 From: report at bugs.python.org (Skip Montanaro) Date: Thu, 28 May 2015 18:43:42 +0000 Subject: [issue24318] Better documentaiton of profile-opt (and release builds in general?) In-Reply-To: <1432830865.51.0.995414707141.issue24318@psf.upfronthosting.co.za> Message-ID: <1432838622.68.0.175557820584.issue24318@psf.upfronthosting.co.za> Skip Montanaro added the comment: Thanks. The doc change occurred to me while I was composing my ticket. It wasn't obvious at that time that profile-opt shouldn't be the default (though I was carrying on an email conversation with Greg at about the same time). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 20:52:09 2015 From: report at bugs.python.org (Tal Einat) Date: Thu, 28 May 2015 18:52:09 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432839129.39.0.487131155124.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: @Stefan K.: I tend to agree, but still think that's a separate issue. math.isclose() certainly shouldn't be checking the type of its arguments. While we're on the subject, though, trying to convert a very large int to float fails with an OverflowError. Perhaps Decimal should do the same? >>> float(10**999) Traceback (most recent call last): File "", line 1, in OverflowError: int too large to convert to float >>> math.isclose(10**999, 10**400000) Traceback (most recent call last): File "", line 1, in OverflowError: int too large to convert to float ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 20:55:26 2015 From: report at bugs.python.org (Remy Blank) Date: Thu, 28 May 2015 18:55:26 +0000 Subject: [issue23906] poplib maxline behaviour may be wrong In-Reply-To: <1428679593.1.0.415911204922.issue23906@psf.upfronthosting.co.za> Message-ID: <1432839326.39.0.153384366804.issue23906@psf.upfronthosting.co.za> Changes by Remy Blank : ---------- nosy: +rblank _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 20:58:40 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 28 May 2015 18:58:40 +0000 Subject: [issue11205] Evaluation order of dictionary display is different from reference manual. In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za> Message-ID: <1432839520.77.0.258146802493.issue11205@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I downloaded and tried to apply to 3.5 (then default) as it was last Saturday, before the .b1 cutoff. Only ceval.py and test_compile.py patches worked. Everything else failed. You need to update your repository (3.5 is now a branch and default is 3.6) and then the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 21:31:27 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 May 2015 19:31:27 +0000 Subject: [issue11205] Evaluation order of dictionary display is different from reference manual. In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za> Message-ID: <20150528193124.18171.6739@psf.io> Roundup Robot added the comment: New changeset 6f05f83c7010 by Benjamin Peterson in branch '3.5': in dict displays, evaluate the key before the value (closes #11205) https://hg.python.org/cpython/rev/6f05f83c7010 New changeset ba9e4df5368c by Benjamin Peterson in branch 'default': merge 3.5 (#11205) https://hg.python.org/cpython/rev/ba9e4df5368c ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 21:38:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 May 2015 19:38:00 +0000 Subject: [issue22095] Use of set_tunnel with default port results in incorrect post value in host header In-Reply-To: <1406570983.98.0.143155526303.issue22095@psf.upfronthosting.co.za> Message-ID: <20150528193754.111596.515@psf.io> Roundup Robot added the comment: New changeset 3b6e0720a69d by Serhiy Storchaka in branch '2.7': Issue #22095: Fixed HTTPConnection.set_tunnel with default port. The port https://hg.python.org/cpython/rev/3b6e0720a69d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 21:44:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 May 2015 19:44:32 +0000 Subject: [issue22095] Use of set_tunnel with default port results in incorrect post value in host header In-Reply-To: <1406570983.98.0.143155526303.issue22095@psf.upfronthosting.co.za> Message-ID: <1432842272.56.0.138438642214.issue22095@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Backported to 2.7 because this is needed to support proxy with a port in urllib/urllib2 as documented. See issue24311. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 21:45:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 May 2015 19:45:54 +0000 Subject: [issue24311] urllib2.urlopen() through proxy fails when HTTPS URL contains port number In-Reply-To: <1432793052.23.0.935714573518.issue24311@psf.upfronthosting.co.za> Message-ID: <1432842354.36.0.724060431624.issue24311@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your report Atzm. ---------- assignee: -> serhiy.storchaka resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Use of set_tunnel with default port results in incorrect post value in host header type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 22:29:03 2015 From: report at bugs.python.org (Brandon Milam) Date: Thu, 28 May 2015 20:29:03 +0000 Subject: [issue24147] Dialect class defaults are not documented. In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za> Message-ID: <1432844943.46.0.653367913656.issue24147@psf.upfronthosting.co.za> Brandon Milam added the comment: Hi all, I've been looking at this bug and am ready to start putting in some work on it but I have some questions about what is wanting to be done. From what I can tell these are the possible tasks for this issue. - Add to the docs under the dialect section the excel attributes vs. the dialect class attributes and explain how the excel dialect is the default and this is the functionality you'd be changing by creating a new dialect. - Add code to make sure that a certain number of attributes are set before the dialect can be accessed. (Though this might be C code and not really a C programmer nor do I know where _Dialect is in the repository) - Change the defaults in the dialects class because currently the documentation for "double quote" and "skip initial space" says that the default is False when in the code it is None. Also I did not find the "strict" dialect in the module at all. (maybe its part of that C code that I don't know how to find. - Add an example to the documentation on sub-classing dialect under the example on registering a new dialect If someone could clarify which of these is the desired direction for this issue it would be much appreciated. ---------- nosy: +jbmilam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 22:52:51 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 28 May 2015 20:52:51 +0000 Subject: [issue20126] sched doesn't handle events added after scheduler starts In-Reply-To: <1388890823.36.0.322424274213.issue20126@psf.upfronthosting.co.za> Message-ID: <1432846371.45.0.471680238765.issue20126@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Why would you not expect this to work in the first place? I'd think a relatively simple use case for schedulers is using a single thread to do the work of a Timer instead of spawning a thread for every Timer. In that sort of use case, the "timer worker" is constantly pulling tasks and other thread(s) are adding them; for an empty event queue, if thread A adds a task 'a' that delays for 10 minutes and thread B adds a task 'b' that delays for 1 minute, the time at which task 'b' executes changes dramatically based on which thread squeaks out a win on the race to insert into the scheduler queue. As long as task 'a' wins the race, a million other tasks could be scheduled to run before it, but all of them will be stuck behind task 'a' no matter their priority or delay. It should be possible to fix this without too much trouble (and without polling loops), but it would require scheduler to remove the option to customize delayfunc; you'd change the scheduler's RLock to a Condition, have mutations to the event queue notify the Condition, and the run method would replace sleeping outside the locked scope with a wait w/timeout inside it. The only thing blocking a fix for this is backwards compatibility. If people are okay with breaking that, I'll happily contribute a patch, but I want some indication of whether back compat can be sacrificed to make sched actually useful in threaded contexts. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 23:08:43 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 28 May 2015 21:08:43 +0000 Subject: [issue19270] Document that sched.cancel() doesn't distinguish equal events and can break order In-Reply-To: <1381913252.24.0.629122693277.issue19270@psf.upfronthosting.co.za> Message-ID: <1432847323.52.0.00979214743297.issue19270@psf.upfronthosting.co.za> Josh Rosenberg added the comment: sched has been around for a long time, but it's been useless for so many purposes that it *should* handle (completely unsafe in threaded contexts until 3.3, still can't handle useful threaded scenarios today, e.g. scheduling tasks for short delays when draining the task queue, waiting on a task with a long delay, see #20126 ) that calling it acceptable is more about lack of available uses than acceptable design. Saying "don't schedule two events for the same time and priority if expect to cancel either of them" is not a reasonable solution; the main reason to schedule two such events in that way would be to have the option to cancel one but not the other; as is, trying to cancel one will (pseudo-)randomly cancel either of them. I don't particularly care how it's fixed (though the proposed fix for #13451 seems like a good one), and the issue with changing event order isn't so important, but cancelling the wrong event is really bad. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 23:24:51 2015 From: report at bugs.python.org (Mik) Date: Thu, 28 May 2015 21:24:51 +0000 Subject: [issue24147] Dialect class defaults are not documented. In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za> Message-ID: <1432848291.57.0.805155440042.issue24147@psf.upfronthosting.co.za> Mik added the comment: Hi, I have just read the documentation once again. The problem is that it specifies that the default value for Dialect.doublequote is True : Controls how instances of quotechar appearing inside a field should be themselves be quoted. When True, the character is doubled. When False, the escapechar is used as a prefix to the quotechar. It defaults to True. So it is easy to understand that the class csv.Dialect implements this default value. Although the class Dialect default in the csv.reader calling is "Excel" and thus, implicitly, it is csv.excel the default class whose attributes are described in the above paragraph. It would be great in this case to describe the attributes of the base class Dialect or specify that all attributes must be settled when we subclass this. Optionally it would be good that the code of CSV.Dialect be changed for really Boolean values. But the clarification of documentation is more important I think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 23:41:54 2015 From: report at bugs.python.org (Brandon Milam) Date: Thu, 28 May 2015 21:41:54 +0000 Subject: [issue23659] csv.register_dialect doc string In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za> Message-ID: <1432849314.34.0.505655704332.issue23659@psf.upfronthosting.co.za> Brandon Milam added the comment: I believe this was the requested change. Let me know if more was desired. ---------- keywords: +patch nosy: +jbmilam Added file: http://bugs.python.org/file39540/register_dialect_docstring_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 28 23:53:14 2015 From: report at bugs.python.org (Brandon Milam) Date: Thu, 28 May 2015 21:53:14 +0000 Subject: [issue23659] csv.register_dialect doc string In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za> Message-ID: <1432849994.12.0.361209769494.issue23659@psf.upfronthosting.co.za> Brandon Milam added the comment: Sorry, I forgot an end parentheses in the doc string of the last patch. ---------- Added file: http://bugs.python.org/file39541/register_dialect_docstring_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 00:34:56 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 28 May 2015 22:34:56 +0000 Subject: [issue24320] Remove a now-unnecessary workaround from importlib._bootstrap. Message-ID: <1432852496.91.0.597570741784.issue24320@psf.upfronthosting.co.za> New submission from Eric Snow: In issue #23911 I worked around a bug [1] in pkg_resources (setuptools) which caused test_venv to fail when I split out importlib._bootstrap_external. That bug has now been fixed so we just(?) need to update the version of pip we're bundling and remove the hack I put in as a workaround (see msg242440). [1] https://bitbucket.org/pypa/setuptools/issue/378 ---------- assignee: eric.snow messages: 244350 nosy: brett.cannon, eric.snow, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Remove a now-unnecessary workaround from importlib._bootstrap. versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 00:36:07 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 28 May 2015 22:36:07 +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: <1432852567.5.0.27564414513.issue24320@psf.upfronthosting.co.za> Eric Snow added the comment: Would we be okay fixing this in 3.5 as well? I ask because I'm not familiar with the constraints we have on what pip is bundled. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 00:41:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 May 2015 22:41:03 +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: <1432852863.84.0.831214527351.issue24320@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 01:10:57 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 28 May 2015 23:10:57 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1432854657.44.0.0765950912915.issue24313@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > It looks like json doesn't check for __index__, and I wonder if it should. I don't know. Simply, under 2.7, int64 inherits from int: >>> np.int64.__mro__ (, , , , , , ) while it doesn't under 3.x: >>> np.int64.__mro__ (, , , , , ) ---------- nosy: +pitrou type: crash -> enhancement versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 01:47:23 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Thu, 28 May 2015 23:47:23 +0000 Subject: [issue17094] sys._current_frames() reports too many/wrong stack frames In-Reply-To: <1359668363.58.0.777154629349.issue17094@psf.upfronthosting.co.za> Message-ID: <1432856843.85.0.715879644158.issue17094@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: This bug also affects 2.7. The main problem I'm dealing with is "sys._current_frames will then return wrong stack frames for existing threads". One fix to just this would be to change how the dict is created, to keep newer threads rather than tossing them. Alternatively, we could backport the 3.4 fix. Thoughts? ---------- nosy: +Devin Jeanpierre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 01:48:59 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 28 May 2015 23:48:59 +0000 Subject: [issue10344] codecs.open() buffering doc needs fix In-Reply-To: <1289084418.05.0.231852584468.issue10344@psf.upfronthosting.co.za> Message-ID: <1432856939.76.0.525901262111.issue10344@psf.upfronthosting.co.za> Martin Panter added the comment: A couple of specific problems have been raised by Terry here. Checking each against the current Python 3 status, some have already been fixed: * The codecs.open() signature has been fixed in Issue 19548. * The StreamReader.readline(size=...) parameter documentation has been fixed to match the docstring in Issue 18336. So that leaves these three problems, as I see it: 1. The notice about opening in binary mode still needs fixing for encoding=None. 2. The buffering parameter is applied to the underlying builtins.open() call, so should be clarified in the documentation. 3. codecs.open(filename, encoding=...) will by default call builtins.open(filename, "rb", buffering=1), which makes no sense according the the documentation. ---------- nosy: +vadmium stage: -> needs patch title: codecs.StreamReader.readline doc needs fix -> codecs.open() buffering doc needs fix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 01:49:16 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 28 May 2015 23:49:16 +0000 Subject: [issue10344] codecs.open() buffering doc needs fix In-Reply-To: <1289084418.05.0.231852584468.issue10344@psf.upfronthosting.co.za> Message-ID: <1432856956.51.0.175327158186.issue10344@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 03:13:57 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 May 2015 01:13:57 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1432862037.96.0.113206592708.issue24313@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, so this is a numpy bug? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 03:55:26 2015 From: report at bugs.python.org (whitequark) Date: Fri, 29 May 2015 01:55:26 +0000 Subject: [issue24321] interaction of nonlocal and except leading to incorrect behavior Message-ID: <1432864526.16.0.510004554687.issue24321@psf.upfronthosting.co.za> New submission from whitequark: To reproduce in Python 3.4.2: def f(): x = None def g(): nonlocal x try: raise Exception() except Exception as x: pass g() # ? UnboundLocalError: local variable 'x' referenced before assignment print("x", x) f() Compare this to: def f(): x = None def g(): nonlocal x with open("/dev/null") as x: pass g() print("x", x) f() (which prints: x <_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'>) ---------- components: Interpreter Core messages: 244356 nosy: whitequark priority: normal severity: normal status: open title: interaction of nonlocal and except leading to incorrect behavior type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 03:59:44 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 01:59:44 +0000 Subject: [issue24321] interaction of nonlocal and except leading to incorrect behavior In-Reply-To: <1432864526.16.0.510004554687.issue24321@psf.upfronthosting.co.za> Message-ID: <1432864784.39.0.925321387546.issue24321@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 04:06:21 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 29 May 2015 02:06:21 +0000 Subject: [issue24321] interaction of nonlocal and except leading to incorrect behavior In-Reply-To: <1432864526.16.0.510004554687.issue24321@psf.upfronthosting.co.za> Message-ID: <1432865181.46.0.586433455899.issue24321@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 06:01:17 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 29 May 2015 04:01:17 +0000 Subject: [issue24321] interaction of nonlocal and except leading to incorrect behavior In-Reply-To: <1432864526.16.0.510004554687.issue24321@psf.upfronthosting.co.za> Message-ID: <1432872077.59.0.126314985304.issue24321@psf.upfronthosting.co.za> Martin Panter added the comment: The first example seems to behave as I would expect. The UnboundLocalError is raised by the print() call, because the ?x? variable has been deleted by the exception handler. Equivalent code without using ?nonlocal?: >>> def f(): ... x = None ... try: ... raise Exception() ... except Exception as x: ... pass ... print("x", x) # UnboundLocal due to exception handler ... >>> f() Traceback (most recent call last): File "", line 1, in File "", line 7, in f UnboundLocalError: local variable 'x' referenced before assignment In both cases, I think this is correct behaviour. See , which says ?When an exception has been assigned using ?as target?, it is cleared at the end of the except clause.? ---------- nosy: +vadmium resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 06:12:12 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 29 May 2015 04:12:12 +0000 Subject: [issue24314] irrelevant cross-link in documentation of user-defined functions In-Reply-To: <1432823234.49.0.975414233418.issue24314@psf.upfronthosting.co.za> Message-ID: <1432872732.65.0.521218277241.issue24314@psf.upfronthosting.co.za> Martin Panter added the comment: I think the proper way to suppress the link is :attr:`!__name__`. However I am posting a patch which takes a different approach. I tweaked some of the entries under that also apply to functions, etc. I invented the pseudo class name ?definition? for this; better suggestions are welcome! Then I converted the user-defined functions reference, as well as many other references, to :attr:`~definition.__name__` or similar, for these three attributes: * definition.__name__ * definition.__qualname__ * object.__dict__ I also moved the index markup so that the index entries for the table of function attributes work. ---------- keywords: +patch nosy: +vadmium stage: -> patch review Added file: http://bugs.python.org/file39542/special-attr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 06:19:24 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 29 May 2015 04:19:24 +0000 Subject: [issue23659] csv.register_dialect doc string In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za> Message-ID: <1432873164.64.0.350016127905.issue23659@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 Fri May 29 06:44:26 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 29 May 2015 04:44:26 +0000 Subject: [issue24321] interaction of nonlocal and except leading to incorrect behavior In-Reply-To: <1432864526.16.0.510004554687.issue24321@psf.upfronthosting.co.za> Message-ID: <1432874666.96.0.702291401769.issue24321@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 07:46:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 29 May 2015 05:46:35 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1432878395.7.0.670533964199.issue24313@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, it looks as a bug (or rather lack of feature) in numpy, but numpy have no chance to fix it without help from Python. The json module is not flexible enough. For now this issue can be workarounded only from user side, with special default handler. >>> import numpy, json >>> def default(o): ... if isinstance(o, numpy.integer): return int(o) ... raise TypeError ... >>> json.dumps({'value': numpy.int64(42)}, default=default) '{"value": 42}' ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 08:25:38 2015 From: report at bugs.python.org (Thomas Guettler) Date: Fri, 29 May 2015 06:25:38 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432880738.72.0.805354430613.issue24259@psf.upfronthosting.co.za> Thomas Guettler added the comment: I thought about this again. It could be solved with the help of a ByteCountingStreamReader. With ByteCountingStreamReader I mean a wrapper around a stream like codescs.StreamReader. But the ByteCountingStreamReader should not changes the content, but just count the bytes it passed. The ByteCountingStreamReader would be wrapped around ExFileObject. This class could be handy in other situations. What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 08:50:46 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Fri, 29 May 2015 06:50:46 +0000 Subject: [issue1818] Add named tuple reader to CSV module In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za> Message-ID: <1432882246.93.0.116961782954.issue1818@psf.upfronthosting.co.za> Changes by C?dric Krier : ---------- nosy: +ced _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 09:43:09 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Fri, 29 May 2015 07:43:09 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432885389.02.0.675034244851.issue24259@psf.upfronthosting.co.za> Lars Gust?bel added the comment: @Thomas: I think your proposal adds a little too much complexity. Also, ExFileObject is not used during iteration, and we would like to detect broken archives without unpacking all the data segments first. I have written patches for Python 2 and 3. ---------- stage: -> patch review versions: +Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39543/issue24259-3.x.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 09:43:18 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Fri, 29 May 2015 07:43:18 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432885398.12.0.860759463693.issue24259@psf.upfronthosting.co.za> Changes by Lars Gust?bel : Added file: http://bugs.python.org/file39544/issue24259-2.x.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 11:14:02 2015 From: report at bugs.python.org (=?utf-8?q?Mat=C4=9Bj_Stuchl=C3=ADk?=) Date: Fri, 29 May 2015 09:14:02 +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: <1432890842.42.0.221820503257.issue23968@psf.upfronthosting.co.za> Mat?j Stuchl?k added the comment: +1 from the Python team from Fedora, the patch looks good from downstream standpoint. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 11:40:57 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 May 2015 09:40:57 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1432892457.02.0.670681098421.issue24313@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I wouldn't call it a bug in Numpy (a quirk perhaps?). Numpy ints are fixed-width ints, so some of them can inherit from Python int in 2.x, but not in 3.x. But not all of them do, since the bitwidth can be different: >>> issubclass(np.int64, int) True >>> issubclass(np.int32, int) False >>> issubclass(np.int16, int) False ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 11:41:43 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 May 2015 09:41:43 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1432892503.48.0.838783153152.issue24313@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +njs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 11:43:24 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 29 May 2015 09:43:24 +0000 Subject: [issue24322] Hundreds of linker warnings on Windows Message-ID: <1432892603.92.0.682917004344.issue24322@psf.upfronthosting.co.za> New submission from Mark Lawrence: The first of them. 3>C:\cpython\PCbuild\obj\win32_Debug\python3dll\python3_d.def : warning LNK4197: export 'PyArg_Parse' specified multiple times; using first specification ---------- components: Build, Windows messages: 244364 nosy: BreamoreBoy, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Hundreds of linker warnings on Windows type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 12:44:17 2015 From: report at bugs.python.org (eimista) Date: Fri, 29 May 2015 10:44:17 +0000 Subject: [issue24323] Typo in Mutable Sequence Types documentation. Message-ID: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za> New submission from eimista: In section (https://docs.python.org/3.5/library/stdtypes.html#mutable-sequence-types) written "s.pop([i])". But this syntax doesn't work. Maybe the correct notation will be "s.pop(i)"? ---------- assignee: docs at python components: Documentation messages: 244365 nosy: docs at python, eimista priority: normal severity: normal status: open title: Typo in Mutable Sequence Types documentation. type: resource usage 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 May 29 12:54:18 2015 From: report at bugs.python.org (Cyd Haselton) Date: Fri, 29 May 2015 10:54: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: <1432896858.4.0.798722493324.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: All, Just checking in as it has been a while...is there anything I need to do on my end for this port? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 13:05:14 2015 From: report at bugs.python.org (Martin Olsen) Date: Fri, 29 May 2015 11:05:14 +0000 Subject: [issue9674] make install DESTDIR=/home/blah fails when the prefix specified is / In-Reply-To: <1282677588.85.0.771807305266.issue9674@psf.upfronthosting.co.za> Message-ID: <1432897514.55.0.364059850176.issue9674@psf.upfronthosting.co.za> Martin Olsen added the comment: I have python (2.7.9 & 3.4.3) installed with prefix=/ which causes problems when change_root() doesn't lstrip() the path separators. I have applied Ivailo's patch from 2015-02-13 and handful of packages without issues. Attached is a port of the patch to 3.4.3. Please note that the test failed (because it used the old distutils package, I suspect) and the win32 path handling is a bit messed up, but I don't have time to fix that ATM. It works as expected during runtime. ---------- nosy: +mro Added file: http://bugs.python.org/file39545/Python-3.4.3-issue9674-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 13:55:17 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 May 2015 11:55:17 +0000 Subject: [issue24321] interaction of nonlocal and except leading to incorrect behavior In-Reply-To: <1432864526.16.0.510004554687.issue24321@psf.upfronthosting.co.za> Message-ID: <1432900517.11.0.598030263461.issue24321@psf.upfronthosting.co.za> R. David Murray added the comment: Indeed, if you replace the except clause with a 'del x', you get the same UnboundLocalError. This is working as designed. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 13:56:33 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 29 May 2015 11:56:33 +0000 Subject: [issue24323] Typo in Mutable Sequence Types documentation. In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za> Message-ID: <1432900593.62.0.00634651308602.issue24323@psf.upfronthosting.co.za> Eric V. Smith added the comment: It's trying to say that "i" is optional, as stated in the footnote. I agree it would be better written as "s.pop(i)", since square brackets are otherwise used in that section as indexing operators. But the footnote should stay, explaining what happens if you omit the parameter. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 13:57:46 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 29 May 2015 11:57:46 +0000 Subject: [issue24323] Typo in Mutable Sequence Types documentation. In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za> Message-ID: <1432900666.42.0.49439633669.issue24323@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 13:59:03 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 May 2015 11:59:03 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1432900743.39.0.96517155201.issue24313@psf.upfronthosting.co.za> R. David Murray added the comment: So in python2, some were json serializable and some weren't? Yes, I'd call that a quirk :) So back to the question of whether it makes sense for json to look for __index__ to decide if something can be serialized as an int. If not, I don't think there is anything we can do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 14:01:56 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 May 2015 12:01:56 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1432900916.14.0.300809262433.issue24313@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't know about __index__, but there's the ages-old discussion of allowing some kind of __json__ hook on types. Of course, none of those solutions would allow round-tripping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 15:01:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 May 2015 13:01:57 +0000 Subject: [issue24315] collections.abc: Coroutine should be derived from Awaitable In-Reply-To: <1432826000.86.0.336894451346.issue24315@psf.upfronthosting.co.za> Message-ID: <20150529130153.24073.22726@psf.io> Roundup Robot added the comment: New changeset 968af3838553 by Yury Selivanov in branch '3.5': Issue 24315: Make collections.abc.Coroutine derived from Awaitable https://hg.python.org/cpython/rev/968af3838553 New changeset a7a9c8631d0e by Yury Selivanov in branch 'default': Issue 24315: Make collections.abc.Coroutine derived from Awaitable https://hg.python.org/cpython/rev/a7a9c8631d0e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 15:02:28 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 13:02:28 +0000 Subject: [issue24315] collections.abc: Coroutine should be derived from Awaitable In-Reply-To: <1432826000.86.0.336894451346.issue24315@psf.upfronthosting.co.za> Message-ID: <1432904548.26.0.778914333329.issue24315@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 Fri May 29 15:06:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 May 2015 13:06:37 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <20150529130634.83475.78437@psf.io> Roundup Robot added the comment: New changeset 7356f71fb0a4 by Yury Selivanov in branch '3.5': Issue 24316: Fix types.coroutine() to accept objects from Cython https://hg.python.org/cpython/rev/7356f71fb0a4 New changeset 748c55375225 by Yury Selivanov in branch 'default': Issue 24316: Fix types.coroutine() to accept objects from Cython https://hg.python.org/cpython/rev/748c55375225 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 15:07:03 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 13:07:03 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <1432904823.86.0.0673987043153.issue24316@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 Fri May 29 15:08:12 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 13:08: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: <1432904892.65.0.949480051565.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: Stefan, Because of https://mail.python.org/pipermail/python-committers/2015-May/003410.html I've decided to commit 24315 and 24316 today. Please try to check that everything works before new beta 2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 15:33:04 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 29 May 2015 13:33:04 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432906384.24.0.850861474037.issue24270@psf.upfronthosting.co.za> Stefan Krah added the comment: > While we're on the subject, though, trying to convert a very large int to float fails with an OverflowError. Perhaps Decimal should do the same? I've always viewed float() as a cast. For casting Decimal's behavior seems to be the right one to me. If we go ahead with implicit casts for isclose(), I still think the PEP's non-float section should be changed: It sounds as if native support was planned for Decimal. Does someone have the tracker id of Chris? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 15:43:03 2015 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 29 May 2015 13:43:03 +0000 Subject: [issue23659] csv.register_dialect doc string In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za> Message-ID: <1432906983.08.0.420323785404.issue23659@psf.upfronthosting.co.za> Skip Montanaro added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 15:51:17 2015 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 29 May 2015 13:51:17 +0000 Subject: [issue24324] Remove -Wunreachable-code flag Message-ID: <1432907477.51.0.798249204562.issue24324@psf.upfronthosting.co.za> New submission from Skip Montanaro: Makefile.pre defines BASECFLAGS to include -Wunreachable-code. When building in the Linux environment available to me (GCC 4.4.6), compilation spews tons of warnings about "warning: will never be executed". According to this StackOverflow thread: http://stackoverflow.com/questions/14591778/ that flag was always broken in GCC and was eventually removed in 4.5. Maybe we should dispense with it when building Python, at least unless requested by the user. ---------- components: Build messages: 244377 nosy: skip.montanaro priority: normal severity: normal stage: needs patch status: open title: Remove -Wunreachable-code flag type: compile error versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 15:57:04 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 29 May 2015 13:57:04 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432907824.3.0.742926167729.issue24268@psf.upfronthosting.co.za> Stefan Behnel added the comment: I'm seeing crashes with this assertion in Cython test modules: python: ./Python/importdl.c:75: get_encoded_name: Assertion `(((PyObject*)(encoded))->ob_refcnt) == 1' failed. The problem seems to be that the module name is only one character long ("a"), and single character byte strings are interned. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 16:06:05 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 14:06:05 +0000 Subject: [issue24323] Typo in Mutable Sequence Types documentation. In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za> Message-ID: <1432908365.35.0.867794074423.issue24323@psf.upfronthosting.co.za> Yury Selivanov added the comment: I think it should be changed to `pop(i=-1)`. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 16:27:25 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 14:27:25 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432909645.92.0.215367664874.issue16991@psf.upfronthosting.co.za> Yury Selivanov added the comment: Can we merge this patch before new beta2? https://mail.python.org/pipermail/python-committers/2015-May/003410.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 16:42:23 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 29 May 2015 14:42:23 +0000 Subject: [issue24323] Typo in Mutable Sequence Types documentation. In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za> Message-ID: <1432910543.0.0.457400123887.issue24323@psf.upfronthosting.co.za> Eric V. Smith added the comment: s.pop(i=-1) doesn't actually work, but I guess it gets the point across. For 2.7 it's even more confusing, since it includes: s.index(x[, i[, j]]) and s.sort([cmp[, key[, reverse]]]) I'd suggest not changing the 2.7 docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 16:46:57 2015 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 29 May 2015 14:46:57 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432910817.57.0.880906947203.issue24268@psf.upfronthosting.co.za> Petr Viktorin added the comment: Ah, indeed. I need to create a new bytes object here after all. Here is a fix, with a test. Thank you Stefan! ---------- Added file: http://bugs.python.org/file39546/fix-short-names.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 17:04:26 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 29 May 2015 15:04:26 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432911866.77.0.745922700782.issue24268@psf.upfronthosting.co.za> Stefan Behnel added the comment: Patch LGTM and it fixes the problem (tried it on my side). Please make sure it gets applied in time for beta 2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 17:09:41 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 29 May 2015 15:09:41 +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: <1432912181.4.0.00926541302714.issue24017@psf.upfronthosting.co.za> Stefan Behnel added the comment: Tried it, works for me. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 17:14:35 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 15:14: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: <1432912475.26.0.49687684281.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Tried it, works for me. Thanks! This is really good news! Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 17:41:41 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 29 May 2015 15:41:41 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <1432914101.1.0.793326929089.issue24316@psf.upfronthosting.co.za> Stefan Behnel added the comment: I just noticed that I hadn't used the real "types.coroutine" in my Py3.5 tests when reporting back in issue 24017. When I pass a Cython generator through it, I get """ Traceback (most recent call last): File "tests/run/test_coroutines_pep492.pyx", line 245, in test_coroutines_pep492.CoroutineTest.test_func_5 (test_coroutines_pep492.c:13445) for el in bar(): File "/opt/python3.5/lib/python3.5/types.py", line 197, in wrapped 'non-coroutine: {!r}'.format(coro)) TypeError: callable wrapped with types.coroutine() returned non-coroutine: """ This is actually obvious, given that the sole purpose of the decorator is to turn something that is a Generator and *not* a Coroutine into something that is a Coroutine, as a means for the user to say "but I know better". So checking for the return value being a Coroutine is wrong. Instead, it should check that it's a Generator and if it's not an Awaitable, wrap it as a self-returning Awaitable. That's more or less what my proposed implementation in issue 24017 did: class types_coroutine(object): def __init__(self, gen): self._gen = gen class as_coroutine(object): def __init__(self, gen): self._gen = gen self.send = gen.send self.throw = gen.throw self.close = gen.close def __await__(self): return self._gen def __call__(self, *args, **kwargs): return self.as_coroutine(self._gen(*args, **kwargs)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 17:52:23 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Fri, 29 May 2015 15:52:23 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1432896858.4.0.798722493324.issue23496@psf.upfronthosting.co.za> Message-ID: Ryan Gonzalez added the comment: I thought you were running the tests... Or was there something I had to do that I missed? On May 29, 2015 5:54:18 AM CDT, Cyd Haselton wrote: > >Cyd Haselton added the comment: > >All, >Just checking in as it has been a while...is there anything I need to >do on my end for this port? > >---------- > >_______________________________________ >Python tracker > >_______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 18:23:27 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 16:23:27 +0000 Subject: [issue24325] Speedup types.coroutine() Message-ID: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> New submission from Yury Selivanov: Attached patch provides an implementation (part of it) of types.coroutine in C. The problem with the current pure Python implementation is that it copies the code object of the generator function, which is a small overhead during import. I'm not sure if this should be merged in 3.5 at all. Please take a look at the patch. ---------- assignee: yselivanov components: Library (Lib) files: types_coroutine_speedup.patch keywords: patch messages: 244388 nosy: gvanrossum, ncoghlan, yselivanov priority: normal severity: normal stage: patch review status: open title: Speedup types.coroutine() versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39547/types_coroutine_speedup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 18:38:54 2015 From: report at bugs.python.org (Cyd Haselton) Date: Fri, 29 May 2015 16:38:54 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: Message-ID: Cyd Haselton added the comment: On May 29, 2015 10:52:23 AM CDT, Ryan Gonzalez wrote: > >Ryan Gonzalez added the comment: > >I thought you were running the tests... > Which tests? >Or was there something I had to do that I missed? >From one of the earlier messages I posted: 1) -python3.4m needs to be changed to -python3.5m...or the appropriate versioning variable. 2) colons at the end of the elif lines in setup.py (1950- ) 3) The _crypt and readline module builds in setup.py need additional libraries to work...python3.5m for both and possibly ncurses for readline, I'll test and get back to you. With #1 and #2 added, the build and install completes successfully, although you obviously can't import readline and _crypt. *snip* The messages after that one document how I got readline to work > >On May 29, 2015 5:54:18 AM CDT, Cyd Haselton >wrote: >> >>Cyd Haselton added the comment: >> >>All, >>Just checking in as it has been a while...is there anything I need to >>do on my end for this port? >> >>---------- >> >>_______________________________________ >>Python tracker >> >>_______________________________________ > >---------- > >_______________________________________ >Python tracker > >_______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 18:54:13 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 29 May 2015 16:54:13 +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: <1432918453.33.0.989749796119.issue24305@psf.upfronthosting.co.za> Brett Cannon added the comment: Skipping select frames is a shift in semantics for warnings.warn() (so can't go into 3.5b1), doing it implicitly might be costly on interpreters where getting a frame is expensive, and coming up with a new API allows for a nicer design, e.g. `warnings.deprecate_module(__name__, 'it will be removed in Python 3.6')` -> "the formatter module is deprecated; it will be removed in Python 3.6" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 19:05:40 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 17:05:40 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <1432919140.52.0.608559704971.issue24316@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I just noticed that I hadn't used the real "types.coroutine" in my Py3.5 tests when reporting back in issue 24017. Please test thoroughly the attached patch. ---------- Added file: http://bugs.python.org/file39548/types_coroutine.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 19:20:05 2015 From: report at bugs.python.org (David Moore) Date: Fri, 29 May 2015 17:20:05 +0000 Subject: [issue24326] Audioop: weightB not divided by GCD, weightA divided twice Message-ID: <1432920005.51.0.0928225945144.issue24326@psf.upfronthosting.co.za> New submission from David Moore: Hi - During a code review of Modules/audioop.c I noted that weightB is never divided by the GCD while weightA is divided twice. This is contrary to the comment and appears to be a bug: /* divide weightA and weightB by their greatest common divisor */ d = gcd(weightA, weightB); weightA /= d; weightA /= d; The patch file below (hg diff) fixes this issue. ---------- components: Extension Modules files: audioop.patch keywords: patch messages: 244392 nosy: David Moore priority: normal severity: normal status: open title: Audioop: weightB not divided by GCD, weightA divided twice type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file39549/audioop.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 19:26:16 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 29 May 2015 17:26:16 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <1432920376.88.0.280937029273.issue24316@psf.upfronthosting.co.za> Stefan Behnel added the comment: One failing test in "test_coroutines": test_func_5. The reason is that the GeneratorWrapper is not iterable (and there is no reason it shouldn't be, given that it wraps a Generator). That was my fault, I had already added an __iter__ method but didn't copy it in my previous message. Adding it as follows fixes the test for me: def __iter__(self): return self.__wrapped__ Alternatively, "__iter__ = __await__" would do the same. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 19:30:47 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 29 May 2015 17:30:47 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <1432920647.18.0.383980529718.issue24316@psf.upfronthosting.co.za> Stefan Behnel added the comment: BTW, it's not only for compiled generators but also for normal Python functions that construct Python generators internally and return them, or that delegate the generator creation in some way. With this change, it's enough to decorate the constructor function and not each of the potential generators that it returns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 19:38:45 2015 From: report at bugs.python.org (Thomas Petazzoni) Date: Fri, 29 May 2015 17:38:45 +0000 Subject: [issue23767] Library and include paths not added when cross compiling on localized sytem In-Reply-To: <1427227440.25.0.884604694697.issue23767@psf.upfronthosting.co.za> Message-ID: <1432921125.46.0.925740337686.issue23767@psf.upfronthosting.co.za> Thomas Petazzoni added the comment: I confirm seeing the same issue. This patch fixes it. ---------- nosy: +thomas-petazzoni _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 19:40:56 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 29 May 2015 17:40:56 +0000 Subject: [issue23810] Suboptimal stacklevel of deprecation warnings for formatter and imp modules In-Reply-To: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za> Message-ID: <1432921256.74.0.615576152884.issue23810@psf.upfronthosting.co.za> Brett Cannon added the comment: Latest patch should work for Serhiy's needs by taking a container of names to compare against the filename instead of a single argument. ---------- Added file: http://bugs.python.org/file39550/deprecated_module_stacklevel.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 19:41:04 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 29 May 2015 17:41:04 +0000 Subject: [issue23810] Suboptimal stacklevel of deprecation warnings for formatter and imp modules In-Reply-To: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za> Message-ID: <1432921263.99.0.330705422564.issue23810@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 20:23:02 2015 From: report at bugs.python.org (Mital Ashok) Date: Fri, 29 May 2015 18:23:02 +0000 Subject: [issue24327] yield unpacking Message-ID: <1432923782.23.0.743258740131.issue24327@psf.upfronthosting.co.za> New submission from Mital Ashok: (This is more of a feature request than a bug, but https://www.python.org/dev/peps/pep-0042/ said to post it here) My request is to have syntax like this: yield *iterable to lazily return the iterable's items, not much unlike: # ... for i in iterable: yield i # ... This is because I constantly find myself yielding all the values in, say, a list, then modifying it and yielding it in a loop. ---------- messages: 244397 nosy: Mital Ashok priority: normal severity: normal status: open title: yield unpacking type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 20:32:49 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 29 May 2015 18:32:49 +0000 Subject: [issue24327] yield unpacking In-Reply-To: <1432923782.23.0.743258740131.issue24327@psf.upfronthosting.co.za> Message-ID: <1432924369.16.0.758957293027.issue24327@psf.upfronthosting.co.za> Ethan Furman added the comment: Do you mean something like: --> def heh(): ... yield [1, 2, 3] ... --> for i in heh(): ... print(i) ... [1, 2, 3] # *grumble* --> def heh(): ... for i in [1, 2, 3]: ... yield i ... --> for i in heh(): ... print(i) ... 1 2 3 If so, use `yield from`: --> def huh(): ... yield from [1, 2, 3] ... --> for i in huh(): ... print(i) ... 1 2 3 ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 20:56:41 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 18:56:41 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <1432925801.15.0.640904212891.issue24316@psf.upfronthosting.co.za> Yury Selivanov added the comment: Please test the attached patch. > BTW, it's not only for compiled generators but also for normal Python functions that construct Python generators internally and return them You're right, that's why I used "primarily" word in that comment ;) types.coroutine() is only used by asyncio.coroutine() so far, and returning generator objects from "factory" functions isn't a very common pattern in asyncio. ---------- Added file: http://bugs.python.org/file39551/types_coroutine.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 20:54:13 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 18:54:13 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <1432925653.47.0.317190191774.issue24316@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 21:28:39 2015 From: report at bugs.python.org (Brandon Milam) Date: Fri, 29 May 2015 19:28:39 +0000 Subject: [issue24147] Dialect class defaults are not documented. In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za> Message-ID: <1432927719.61.0.46654954205.issue24147@psf.upfronthosting.co.za> Brandon Milam added the comment: Here I added on to the Dialects and Formatting Parameters paragraph explaining that the defaults listed are for the excel dialect and that all the attributes need to be specified if the user is wanting to create custom dialects through sub-classing. I will also include the html file this produces for those who do not want to look at the .rst file. Also I can go in and change the defaults of the Dialect class on the parameters that expect Boolean values if desired but I would open a separate issue for it. Let me know if there are any errors or desired changes in document change. ---------- keywords: +patch Added file: http://bugs.python.org/file39552/csv_dialect_doc_clarify.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 21:29:23 2015 From: report at bugs.python.org (Brandon Milam) Date: Fri, 29 May 2015 19:29:23 +0000 Subject: [issue24147] Dialect class defaults are not documented. In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za> Message-ID: <1432927763.91.0.31820864347.issue24147@psf.upfronthosting.co.za> Changes by Brandon Milam : Added file: http://bugs.python.org/file39553/csv.html _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 21:39:04 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 29 May 2015 19:39:04 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432928344.3.0.0175741756799.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Planning on committing today after I address some review comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 21:44:03 2015 From: report at bugs.python.org (Wes Turner) Date: Fri, 29 May 2015 19:44:03 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1432928344.3.0.0175741756799.issue16991@psf.upfronthosting.co.za> Message-ID: Wes Turner added the comment: > * Would this make it easy/faster to also have a DefaultOrderedDict (which can/could also be accomplished with .get(attr, []) and .setdefault ? On May 29, 2015 2:39 PM, "Eric Snow" wrote: > > Eric Snow added the comment: > > Planning on committing today after I address some review comments. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 21:45:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 29 May 2015 19:45:11 +0000 Subject: [issue24326] Audioop: weightB not divided by GCD, weightA divided twice In-Reply-To: <1432920005.51.0.0928225945144.issue24326@psf.upfronthosting.co.za> Message-ID: <1432928711.43.0.0701113491127.issue24326@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka stage: -> patch review versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 21:49:52 2015 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 29 May 2015 19:49:52 +0000 Subject: [issue24328] Extension modules with single-letter names can't be loaded Message-ID: <1432928992.22.0.272043188217.issue24328@psf.upfronthosting.co.za> New submission from Petr Viktorin: A regression in the PEP 489 implementation prevents loading extension modules with single-character names (because length-1 bytestrings are interned). Here is a fix. It would be great to have it in 3.5.0b2. ---------- files: fix-short-names.patch keywords: patch messages: 244403 nosy: brett.cannon, encukou, eric.snow, ncoghlan priority: normal severity: normal status: open title: Extension modules with single-letter names can't be loaded versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39554/fix-short-names.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 21:51:11 2015 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 29 May 2015 19:51:11 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432929071.83.0.933158246509.issue24268@psf.upfronthosting.co.za> Petr Viktorin added the comment: I've opened issue24328 for that regression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 21:57:23 2015 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 29 May 2015 19:57:23 +0000 Subject: [issue24268] PEP 489 -- Multi-phase extension module initialization In-Reply-To: <1432367622.95.0.57590625064.issue24268@psf.upfronthosting.co.za> Message-ID: <1432929443.07.0.944177873067.issue24268@psf.upfronthosting.co.za> Petr Viktorin added the comment: And, the remaining refleak is a known issue from 2012: PyType_FromSpec-created types with custom tp_dealloc leak references when instantiated. See issue 16690 There's more discussion is in issue 15653 Martin v. L?wis notes: > So I'd propose that it is actually the leaf subtype which decrefs > ob_type. The check whether you are the leaf type is then done by > checking whether tp_dealloc is the one you are "in" right now. Is that really the way to go? I didn't find this info in the docs, should those be updated? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 22:02:54 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 20:02:54 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <1432929774.2.0.3450699833.issue24316@psf.upfronthosting.co.za> Yury Selivanov added the comment: Updated patch. Wrapper now proxies gi_code, gi_running and gi_frame ---------- Added file: http://bugs.python.org/file39555/types_coroutine.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 22:03:06 2015 From: report at bugs.python.org (Mik) Date: Fri, 29 May 2015 20:03:06 +0000 Subject: [issue24147] Dialect class defaults are not documented. In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za> Message-ID: <1432929786.9.0.256611544319.issue24147@psf.upfronthosting.co.za> Mik added the comment: I think it's clearer that way. Thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 22:03:24 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 29 May 2015 20:03:24 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <1432929804.3.0.468116579557.issue24316@psf.upfronthosting.co.za> Stefan Behnel added the comment: Ok, now the problem with *this* patch is that __iter__ and __await__ are special methods that are being looked up on the type, not the instance. Similarly __next__, I think, as it also has its own (type) slot. But I think you're right that __next__ is also needed here. I'm attaching a patch that works for me. ---------- Added file: http://bugs.python.org/file39556/types_coroutine.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 22:07:29 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 20:07:29 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <1432930049.81.0.680602723315.issue24316@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I'm attaching a patch that works for me. Looks like we were working in parallel ;) I've incorporated your changes. Please look at the new patch (hopefully this one is final) ---------- Added file: http://bugs.python.org/file39557/types_coroutine.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 22:09:17 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 20:09:17 +0000 Subject: [issue24329] __qualname__ and __slots__ Message-ID: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> New submission from Yury Selivanov: The following code doesn't work. Would be great if we can fix it in 3.5 class Foo: __slots__ = ('__qualname__',) ---------- components: Interpreter Core messages: 244410 nosy: pitrou, yselivanov priority: normal severity: normal status: open title: __qualname__ and __slots__ versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 22:09:36 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 29 May 2015 20:09:36 +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: <1432930176.44.0.0240575168816.issue23968@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I don't know what problems I might have run into previously, but it's working now and seems fine to me. +1 ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 22:10:45 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 May 2015 20:10:45 +0000 Subject: [issue24328] Extension modules with single-letter names can't be loaded In-Reply-To: <1432928992.22.0.272043188217.issue24328@psf.upfronthosting.co.za> Message-ID: <1432930245.54.0.653013210052.issue24328@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- priority: normal -> release blocker stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 22:11:57 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 29 May 2015 20:11:57 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <1432930317.49.0.944951107813.issue24316@psf.upfronthosting.co.za> Stefan Behnel added the comment: Your latest patch works for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 22:19:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 May 2015 20:19:48 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <20150529201942.18167.63643@psf.io> Roundup Robot added the comment: New changeset 8080b53342e8 by Yury Selivanov in branch '3.5': Issue 24316: Wrap gen objects returned from callables in types.coroutine https://hg.python.org/cpython/rev/8080b53342e8 New changeset c0434ef75177 by Yury Selivanov in branch 'default': Issue 24316: Wrap gen objects returned from callables in types.coroutine https://hg.python.org/cpython/rev/c0434ef75177 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 22:21:09 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 20:21:09 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <1432930869.48.0.911760652187.issue24316@psf.upfronthosting.co.za> Yury Selivanov added the comment: Committed. Thanks, Stefan! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 22:31:04 2015 From: report at bugs.python.org (Brandon Milam) Date: Fri, 29 May 2015 20:31:04 +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: <1432931464.48.0.543936459014.issue21297@psf.upfronthosting.co.za> Brandon Milam added the comment: This code shows what Daniel Andersson was talking about. I changed the "whitespace" references in the documentation that Daniel mentioned to say spaces. Also I changed "ignore space at the start of the field" to "ignore spaces at the start of the field" due to Terry's confusion. Let me know of any errors or extra changes that are needed. ---------- nosy: +jbmilam Added file: http://bugs.python.org/file39558/csv_skipinitialspace_testing.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 22:31:58 2015 From: report at bugs.python.org (Brandon Milam) Date: Fri, 29 May 2015 20:31:58 +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: <1432931518.1.0.850739678874.issue21297@psf.upfronthosting.co.za> Changes by Brandon Milam : Added file: http://bugs.python.org/file39559/csv_skipinitialspace_testing.csv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 22:32:18 2015 From: report at bugs.python.org (Brandon Milam) Date: Fri, 29 May 2015 20:32:18 +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: <1432931538.83.0.759715031032.issue21297@psf.upfronthosting.co.za> Changes by Brandon Milam : ---------- keywords: +patch Added file: http://bugs.python.org/file39560/csv_skipinitialspace_docfix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 22:50:30 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 29 May 2015 20:50:30 +0000 Subject: [issue24329] __qualname__ and __slots__ In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> Message-ID: <1432932630.02.0.920209608682.issue24329@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 22:51:15 2015 From: report at bugs.python.org (Tal Einat) Date: Fri, 29 May 2015 20:51:15 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432932675.38.0.0841647393662.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: It's Chris.Barker. I've added him to the nosy list. ---------- nosy: +Chris.Barker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 23:01:57 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 29 May 2015 21:01:57 +0000 Subject: [issue24136] document PEP 448 In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1432933317.69.0.192662176672.issue24136@psf.upfronthosting.co.za> Neil Girdhar added the comment: Simplified functools.partial documentation. ---------- Added file: http://bugs.python.org/file39561/wn2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 23:04:11 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 29 May 2015 21:04:11 +0000 Subject: [issue24136] document PEP 448 In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1432933451.65.0.840000441379.issue24136@psf.upfronthosting.co.za> Changes by Neil Girdhar : Added file: http://bugs.python.org/file39562/wn2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 23:10:37 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 21:10:37 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1432933837.16.0.663307946056.issue24325@psf.upfronthosting.co.za> Yury Selivanov added the comment: Attached is the second iteration of the patch. Now, besides just speeding up types.coroutine() for pure python generator functions, it also provides a better wrapper around generator-like objects. ---------- nosy: +scoder Added file: http://bugs.python.org/file39563/types_coroutine_speedup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 23:11:28 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 21:11:28 +0000 Subject: [issue24316] Fix types.coroutine to accept objects from Cython In-Reply-To: <1432830712.54.0.79556846305.issue24316@psf.upfronthosting.co.za> Message-ID: <1432933888.48.0.355844762547.issue24316@psf.upfronthosting.co.za> Yury Selivanov added the comment: Stefan, please take a look at this issue #24325 too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 23:26:17 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 29 May 2015 21:26:17 +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: <1432934777.18.0.772648843887.issue16690@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 23:29:34 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 29 May 2015 21:29: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: <1432934974.31.0.646590820917.issue16690@psf.upfronthosting.co.za> Nick Coghlan added the comment: The new test cases for PEP 489 (multi-phase extension module import) appear to be encountering this leak. See issue 24268 for context. ---------- nosy: +encukou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 23:39:42 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 May 2015 21:39:42 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432935582.7.0.377210813621.issue16991@psf.upfronthosting.co.za> Yury Selivanov added the comment: > * Would this make it easy/faster to also have a DefaultOrderedDict (which can/could also be accomplished with .get(attr, []) and .setdefault ? Not in 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 23:59:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 May 2015 21:59:02 +0000 Subject: [issue24326] Audioop: weightB not divided by GCD, weightA divided twice In-Reply-To: <1432920005.51.0.0928225945144.issue24326@psf.upfronthosting.co.za> Message-ID: <20150529215859.91795.50890@psf.io> Roundup Robot added the comment: New changeset 800a55c20b56 by Serhiy Storchaka in branch '3.4': Issue #24326: Fixed audioop.ratecv() with non-default weightB argument. https://hg.python.org/cpython/rev/800a55c20b56 New changeset 418ab34fd1ce by Serhiy Storchaka in branch '2.7': Issue #24326: Fixed audioop.ratecv() with non-default weightB argument. https://hg.python.org/cpython/rev/418ab34fd1ce New changeset fc85a384b16c by Serhiy Storchaka in branch '3.5': Issue #24326: Fixed audioop.ratecv() with non-default weightB argument. https://hg.python.org/cpython/rev/fc85a384b16c New changeset 1acb6c88b901 by Serhiy Storchaka in branch 'default': Issue #24326: Fixed audioop.ratecv() with non-default weightB argument. https://hg.python.org/cpython/rev/1acb6c88b901 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 29 23:59:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 29 May 2015 21:59:52 +0000 Subject: [issue24326] Audioop: weightB not divided by GCD, weightA divided twice In-Reply-To: <1432920005.51.0.0928225945144.issue24326@psf.upfronthosting.co.za> Message-ID: <1432936792.25.0.198360719753.issue24326@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your report and patch David. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 00:11:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 May 2015 22:11:53 +0000 Subject: [issue24328] Extension modules with single-letter names can't be loaded In-Reply-To: <1432928992.22.0.272043188217.issue24328@psf.upfronthosting.co.za> Message-ID: <20150529221151.91781.57708@psf.io> Roundup Robot added the comment: New changeset 784f372d701a by Benjamin Peterson in branch '3.5': fix importing one char extension modules (closes #24328) https://hg.python.org/cpython/rev/784f372d701a New changeset d89bab1f160e by Benjamin Peterson in branch 'default': merge 3.5 (#24328) https://hg.python.org/cpython/rev/d89bab1f160e ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 00:26:25 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 29 May 2015 22:26:25 +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: <1432938385.53.0.365123665017.issue24303@psf.upfronthosting.co.za> Davin Potts added the comment: At first blush it does appear there is potential for conflict because of how the semaphore filename template was implemented -- that's a cool find. In practice, I wonder how often this has actually bitten anyone in the real world. The Linux world's use of clone() (creating pid namespaces) is relatively new/young. The BSD world's use of jails (bsd-style) take a bit of a different approach, advocate against the use of shared filesystems across jails where a similar conflict could arise, and have been around longer. @Paul: Out of curiosity, what inspired your discovery? Agreed that backporting Richard's work from issue8713 does not appeal. A few concerns: * Retrying with a modified filename makes sense but basing it on a timestamp from the system clock is not particularly robust given that the cloned processes can be executing in sufficiently close lock step that they both get the same timestamp (given the granularity/precision of the clock functions). Developers new to high performance computing often learn this the hard way when trying to use the system clock to create uniquely named files. * Instead, what about using the system's available pseudo-random number generators? Most are implemented to avoid just this problem where two or more processes/threads ask for a random/distinct value at nearly the same moment. * What about simply using a counter (not the same static int counter but another) and incrementing it when the attempt to create the semaphore file fails? This avoids a system function call and potentially simplifies things. Would this be faster in the majority of cases? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 00:32:07 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 29 May 2015 22:32:07 +0000 Subject: [issue19989] Error while sending function code over queue (multiprocessing) In-Reply-To: <1387125540.4.0.544926984003.issue19989@psf.upfronthosting.co.za> Message-ID: <1432938727.49.0.0127815283695.issue19989@psf.upfronthosting.co.za> Davin Potts added the comment: Without further information from the OP, there is not much more we can do as the problem may well originate with the user's compiled C code (which circumstantially seems quite likely). Closing as out-of-date. ---------- resolution: -> out of date status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 00:33:05 2015 From: report at bugs.python.org (Christopher Barker) Date: Fri, 29 May 2015 22:33:05 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1432938785.56.0.683465083475.issue24270@psf.upfronthosting.co.za> Christopher Barker added the comment: Sorry for the confusion: when I wrote the PEP, I was thinking in terms of a Python, duck-typed implementation. Now that it's in C, that doesn't work so well. I will update the PEP to indicate that it is float-only, or complex for the cmath implementation (thanks, Tal!). Any other type will be converted to float if possible, with the limitations that that has. As for Decimal -- the "right" thing to do would be to do a native Decimal implementation -- but that would live in the decimal module, maybe as a method on the Decimal type. (or stand alone -- not sure) Fraction doesn't have the same precision issues as floats, so not sure what the point is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 00:38:14 2015 From: report at bugs.python.org (Seungbeom Kim) Date: Fri, 29 May 2015 22:38:14 +0000 Subject: [issue7094] Add alternate float formatting styles to new-style formatting. In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za> Message-ID: <1432939094.61.0.41566955175.issue7094@psf.upfronthosting.co.za> Seungbeom Kim added the comment: It looks like this change has not been applied to Python 2.7. Do we have any chance of getting it to 2.7? > So I'm unsure if anyone is actually using alternate formatting. The "alternative form" is my favorite, and I think that "%#g" should be the default format for general floating-point values in numerical applications. That is why I miss this feature in Python 2.7 so much. ---------- nosy: +Seungbeom Kim _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 01:09:14 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Fri, 29 May 2015 23:09:14 +0000 Subject: [issue17094] sys._current_frames() reports too many/wrong stack frames In-Reply-To: <1359668363.58.0.777154629349.issue17094@psf.upfronthosting.co.za> Message-ID: <1432940954.1.0.473554985265.issue17094@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: The patch I'm providing with this comment has a ... really hokey test case, and a two line + whitespace diff for pystate.c . The objective of the patch is only to have _current_frames report the correct frame for any live thread. It continues to report dead threads' frames, up until they would conflict with a live thread. IMO it's the minimal possible fix for this aspect of the bug, and suitable for 2.7.x. Let me know what you think. ---------- Added file: http://bugs.python.org/file39564/_current_frames_27_setdefault.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 01:10:24 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 29 May 2015 23:10:24 +0000 Subject: [issue24328] Extension modules with single-letter names can't be loaded In-Reply-To: <1432928992.22.0.272043188217.issue24328@psf.upfronthosting.co.za> Message-ID: <1432941024.36.0.785848762828.issue24328@psf.upfronthosting.co.za> Martin Panter added the comment: Two minor comments on Reitveld. Looks like you alreay fixed one of them in the actual commit. ---------- nosy: +vadmium type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 01:44:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 May 2015 23:44:58 +0000 Subject: [issue24328] Extension modules with single-letter names can't be loaded In-Reply-To: <1432928992.22.0.272043188217.issue24328@psf.upfronthosting.co.za> Message-ID: <20150529234455.27650.94158@psf.io> Roundup Robot added the comment: New changeset 8428cb297d15 by Benjamin Peterson in branch '3.5': use assert method (#24328) https://hg.python.org/cpython/rev/8428cb297d15 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 02:21:04 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 30 May 2015 00:21:04 +0000 Subject: [issue7094] Add alternate float formatting styles to new-style formatting. In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za> Message-ID: <1432945264.18.0.401924176414.issue7094@psf.upfronthosting.co.za> Terry J. Reedy added the comment: New features only go in new versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 03:00:38 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 30 May 2015 01:00:38 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1432947638.87.0.566065243345.issue24259@psf.upfronthosting.co.za> Martin Panter added the comment: For the record, the difference between Python 2 and 3 is probably a side effect of revision 050f0f7be11e. Python 2 copies data from the ExFileObject returned by extractfile(), while Python 3 copies directly from the underlying file. The patches to the file reading class look good. I would be a bit hesitant about the bit that reads all the file data in the next() method. I guess if someone had an uncompressed tar file with only a couple of large files, and they just wanted to list the file names or extract a small file at the end, reading all the data would have a significant impact. Perhaps there is a way to seek almost to the end, and then just read one byte or something. Also, beware that according to the documentation, os.truncate() only supports Windows in 3.5+, so you might have to adjust the test if applying this to 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 03:34:13 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 30 May 2015 01:34:13 +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: <1432949653.98.0.62788109443.issue24079@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch with my suggestion. Let me know what you think. ---------- components: +XML keywords: +patch stage: needs patch -> patch review versions: +Python 3.6 Added file: http://bugs.python.org/file39565/etree-text.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 04:18:00 2015 From: report at bugs.python.org (Mike Frysinger) Date: Sat, 30 May 2015 02:18:00 +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: <1432952280.43.0.40865202713.issue24303@psf.upfronthosting.co.za> Mike Frysinger added the comment: we hit this problem daily in Chromium OS's build farm because we use pid namespaces heavily ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 04:48:41 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 30 May 2015 02:48:41 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432954121.86.0.837198093795.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: @Jim, I believe I've addressed all the review comments that have indicate a risk. I've also answered basically all the rest. Thanks for the great review. Unless there are any objections, I'll likely commit the patch in the next hour or two. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 04:52:53 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 30 May 2015 02:52:53 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432954373.56.0.840746820843.issue16991@psf.upfronthosting.co.za> Changes by Eric Snow : Added file: http://bugs.python.org/file39566/0813b1a88171.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 06:28:36 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 May 2015 04:28:36 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <20150530042833.18672.21395@psf.io> Roundup Robot added the comment: New changeset e7af362b78df by Eric Snow in branch 'default': Issue #16991: Add a C implementation of collections.OrderedDict. https://hg.python.org/cpython/rev/e7af362b78df ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 06:32:55 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 30 May 2015 04:32:55 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432960375.53.0.367159060398.issue16991@psf.upfronthosting.co.za> Yury Selivanov added the comment: @Eric: I think you also want to commit it to 3.5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 06:34:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 May 2015 04:34:22 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <20150530043420.111610.22357@psf.io> Roundup Robot added the comment: New changeset b85028c9d4b9 by Eric Snow in branch '3.5': Issue #16991: Add a C implementation of collections.OrderedDict. https://hg.python.org/cpython/rev/b85028c9d4b9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 06:35:03 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 30 May 2015 04:35:03 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432960503.88.0.726233721.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Yep. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 06:35:44 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 30 May 2015 04:35:44 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432960544.15.0.198036494048.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: I'll keep an eye out for trouble on the buildbots. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 07:02:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 May 2015 05:02:40 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1432960544.15.0.198036494048.issue16991@psf.upfronthosting.co.za> Message-ID: <1705079.8CgS8uXsvX@raxxla> Serhiy Storchaka added the comment: PyObject_TypeCheck() should be used instead of PyObject_IsInstance() (see issue24257). Perhaps Py_ODict_GetItemId() should be private API as relevant dict function. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 07:06:00 2015 From: report at bugs.python.org (yellow) Date: Sat, 30 May 2015 05:06:00 +0000 Subject: [issue24330] "Configure Idle" not in "Options" Message-ID: <1432962360.31.0.591497904103.issue24330@psf.upfronthosting.co.za> New submission from yellow: "Configure Idle" not in "Options" No solution found online Running OSX 10.10.3 ---------- components: Macintosh messages: 244443 nosy: Yellow, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: "Configure Idle" not in "Options" versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 07:14:20 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 May 2015 05:14:20 +0000 Subject: [issue23509] Speed up Counter operators In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za> Message-ID: <20150530051417.91789.83842@psf.io> Roundup Robot added the comment: New changeset fe4efc0032b5 by Raymond Hettinger in branch '3.5': Issue #23509: Speed up Counter operators https://hg.python.org/cpython/rev/fe4efc0032b5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 07:35:57 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 30 May 2015 05:35:57 +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: <1432964157.76.0.0632449601634.issue24079@psf.upfronthosting.co.za> Stefan Behnel added the comment: IMHO less clear and less correct than the previous suggestions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 07:40:18 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 30 May 2015 05:40:18 +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: <1432964418.53.0.390852953196.issue24079@psf.upfronthosting.co.za> Stefan Behnel added the comment: Seems like a good idea to explain "text" and "tail" in one section, though. That makes "tail" easier to find for those who are not used to this kind of split (and that's basically everyone who needs to read the docs in the first place). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 07:47:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 May 2015 05:47:00 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1432964820.36.0.859668934741.issue24325@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +larry type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 08:09:02 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 30 May 2015 06:09:02 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1432966142.09.0.835383097236.issue24325@psf.upfronthosting.co.za> Larry Hastings added the comment: This looks big and complicated. I'd prefer this skipped 3.5 and just went into 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 08:10:31 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Sat, 30 May 2015 06:10:31 +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: <1432966231.48.0.593546125117.issue24305@psf.upfronthosting.co.za> Nathaniel Smith added the comment: A nice new API is certainly a nice thing, but I feel that changing the stack walking code should be considered as fixing a regression introduced in 3.3. Indeed, searching github for code that actually uses the stacklevel= argument: https://github.com/search?p=2&q=warnings.warn+DeprecationWarning+stacklevel&ref=searchresults&type=Code&utf8=%E2%9C%93 I observe that: - there isn't a single usage on the first ten pages with stacklevel > 3, so stack walking speed is unlikely to be an issue -- esp. since it will only be slow in the cases where there are spurious import frames on the stack, i.e., you can only make it faster by making the results incorrect, and - in the first ten pages I counted 14 distinct pieces of code (GH search is chock full of duplicates, sigh), and *11* of them are specifically module deprecations that are correctly passing stacklevel=2, and thus working on 2.7 but broken on 3.3+, and - I counted zero examples where someone wrote if sys.version_info[:2] == (3, 3): stacklevel = 10 elif sys.version_info[:2] == (3, 4): stacklevel = 8 else: stacklevel = 2 warnings.warn("{} is deprecated".format(__name__), DeprecationWarning, stacklevel=stacklevel) which is the only situation where even backporting a fix for this would break code that previously worked correctly. Basically the overwhelming majority of uses of the stacklevel= argument are broken in 3.3 and 3.4 and 3.5-beta. We should fix it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 08:35:07 2015 From: report at bugs.python.org (Michiel de Hoon) Date: Sat, 30 May 2015 06:35:07 +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: <1432967707.74.0.983426610519.issue23237@psf.upfronthosting.co.za> Michiel de Hoon added the comment: Vadmium, thank you for carefully looking at this patch. Polling PyErr_CheckSignals() directly in the tkinter EventHook loop works in the #if defined(WITH_THREAD) || defined(MS_WINDOWS) block, as there Tcl_DoOneEvent(TCL_DONT_WAIT) exits immediately. However in the #else block Tcl_DoOneEvent(0) is called. Here, Tcl_DoOneEvent does not return until there is some event. So if a user presses Ctrl-C, then trip_signal in Modules/signalmodule.c does get called, but Tcl_DoOneEvent won't know about it and will continue to wait for an event. The KeyboardInterrupt will then happen only after the user presses enter or moves the mouse over the Tk window. That said, now I realize that my patch doesn't solve that problem either. So I need to go back and think of a proper way to exit Tcl_DoOneEvent in case of an interrupt. I think that that is a sufficiently complex problem to warrant its own patch. For the current patch, I suggest we consider the changes to Modules/readline.c and Parser/myreadline.c only, and leave out any changes to Modules/_tkinter.c. In response to your comments on Modules/readline.c: >Modules/readline.c:998: > if(PyOS_InputHook) has_input = PyOS_InputHook(); > This contradicts the documentation, which says > PyIO_InputHook()?s return value is ignored Yes you are correct; the documentation will have to be updated if we start using the return value of PyOS_InputHook(). My proposal to use return value == -1 and errno == EINTR to indicate interrupts is based on the convention for select(). In extension modules such as Tkinter, PyOS_InputHook points to a function that returns if input is available on stdin, so effectively it's like a simplified version of select() that only looks at stdin. In Tkinter, pygtk, and PyQT, PyOS_InputHook returns 0; in matplotlib's MacOSX backend it returns +1. So I think it is safe to start using -1 for interrupts. But yes, the documentation will have to be updated. >Modules/readline.c:1065: > old_timeout = rl_set_keyboard_input_timeout(0); > Won?t this poll PyOS_InputHook over and over, wasting CPU time? No it won't. In well-designed code (including Tkinter, pygtk, PyQT, and matplotlib's MacOSX backend) PyOS_InputHook does not return until there is some activity on stdin, and therefore PyOS_InputHook does not get called repetitively anyway. So the timeout is only relevant as the delay until readline() calls PyOS_InputHook(). Since there is no point to this delay, it's better to set it to zero. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 08:56:48 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Sat, 30 May 2015 06:56:48 +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: <1432969008.36.0.532159945274.issue24294@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Recording this here so it doesn't get lost: Marc-Andre Lemberg suggested on python-ideas that for the builtin REPL, this should be enabled iff sys.stdin.isatty(). (I guess he is worried about 'cat script.py | python'.) I'm not really sure whether this falls on the useful or confusing side of the line myself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 09:23:56 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 30 May 2015 07:23:56 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1432970636.42.0.418550392956.issue24325@psf.upfronthosting.co.za> Stefan Behnel added the comment: I would still like to see a patch in Py3.5 that only flips the bit in C when "_types" is available and otherwise falls back to the existing Python code that creates a new code object. This part is much cleaner and faster to do in C than in the current Python implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 09:57:55 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 30 May 2015 07:57:55 +0000 Subject: [issue24330] "Configure Idle" not in "Options" In-Reply-To: <1432962360.31.0.591497904103.issue24330@psf.upfronthosting.co.za> Message-ID: <1432972675.67.0.584935814955.issue24330@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report. As much as possible, IDLE and the underlying Tk GUI toolkit it is built with try go conform to the interface guidelines of the platform (e.g. Windows, OS X, Unix X11) it is running on. On OS X, application configuration options are expected to be found in a "Preferences" menu option under the application menu (the second menu item in the single menu bar at the top of the screen) and that is what happens with IDLE on OS X, rather than having "Options" -> "Configure IDLE" in the window menu bars as on other platforms. It also has the standard OS X keyboard shortcut of CMD-Comma. The IDLE documentation in the Standard Library doc set and the IDLE help file should be updated to note this and other platform differences. ---------- components: +IDLE -Macintosh nosy: -ronaldoussoren stage: -> needs patch versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 11:26:32 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 30 May 2015 09:26:32 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1432977992.53.0.617864311577.issue24004@psf.upfronthosting.co.za> Stefan Behnel added the comment: I found one more place in asyncio.coroutines, around line 190 in the coroutine() decorator: if inspect.isgeneratorfunction(func): coro = func else: @functools.wraps(func) def coro(*args, **kw): res = func(*args, **kw) if isinstance(res, futures.Future) or inspect.isgenerator(res): res = yield from res return res The wrapped isgenerator() check should be replaced by an Awaitable ABC check, e.g. this works for me: """ res = func(*args, **kw) if isinstance(res, futures.Future) or inspect.isgenerator(res): res = yield from res + else: + await_res = getattr(res, '__await__', None) + if await_res is not None: + res = yield from await_res() return res """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 11:58:57 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 30 May 2015 09:58:57 +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: <1432979937.69.0.348732792399.issue24320@psf.upfronthosting.co.za> Nick Coghlan added the comment: Donald updated 3.5 to pip 7 for the 1st beta, so the relevant fix may have already been included. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 13:00:26 2015 From: report at bugs.python.org (Thomas Guettler) Date: Sat, 30 May 2015 11:00: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: <1432983626.27.0.299298099002.issue24259@psf.upfronthosting.co.za> Thomas Guettler added the comment: With Python 3.4.0 you get an OSError if you try to extractall() the uploaded tar_which_is_cut.tar. That's nice. Seems like only 2.7 seems to be buggy. ===> python3 Python 3.4.0 (default, Apr 11 2014, 13:05:11) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import tarfile >>> tarfile.TarFile('tar_which_is_cut.tar').extractall() Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.4/tarfile.py", line 1979, in extractall self.extract(tarinfo, path, set_attrs=not tarinfo.isdir()) File "/usr/lib/python3.4/tarfile.py", line 2018, in extract set_attrs=set_attrs) File "/usr/lib/python3.4/tarfile.py", line 2087, in _extract_member self.makefile(tarinfo, targetpath) File "/usr/lib/python3.4/tarfile.py", line 2133, in makefile copyfileobj(source, target, tarinfo.size) File "/usr/lib/python3.4/tarfile.py", line 247, in copyfileobj raise OSError("end of file reached") OSError: end of file reached ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 13:34:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 May 2015 11:34:15 +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: <1432985655.16.0.468532156547.issue19543@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Nick, Benjamin, could you please look at the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 15:34:46 2015 From: report at bugs.python.org (Karl Richter) Date: Sat, 30 May 2015 13:34:46 +0000 Subject: [issue24331] *** Error in `/usr/bin/python': double free or corruption (!prev): 0x0000000000f5c760 *** when cloning hg repository into directory on cifs Message-ID: <1432992886.73.0.102368057265.issue24331@psf.upfronthosting.co.za> New submission from Karl Richter: I experience the error in the title exclusive when invoking `hg clone` (e.g. `hg clone https://bitbucket.org/Coin3D/coin` or `hg clone http://hg.netbeans.org/main-golden/ netbeans-main-golden`) when the target directory is on a cifs mount. `gdb` backtrace: #0 0x00007ffff761c267 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x00007ffff761deca in __GI_abort () at abort.c:89 #2 0x00007ffff765fc53 in __libc_message (do_abort=do_abort at entry=1, fmt=fmt at entry=0x7ffff77781a8 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x00007ffff7667c69 in malloc_printerr (ptr=, str=0x7ffff77782d8 "double free or corruption (!prev)", action=1) at malloc.c:4965 #4 _int_free (av=, p=, have_lock=0) at malloc.c:3834 #5 0x00007ffff766b89c in __GI___libc_free (mem=) at malloc.c:2950 #6 0x00007ffff130ce11 in lfree (a=a at entry=0xecde10) at mercurial/mpatch.c:67 #7 0x00007ffff130d2e7 in decode (len=196, bin=0x1037ee8 "") at mercurial/mpatch.c:228 #8 fold (bins=[], start=start at entry=0, end=end at entry=1) at mercurial/mpatch.c:296 #9 0x00007ffff130d3d3 in patches (self=, args=) at mercurial/mpatch.c:327 #10 0x00000000004ccd05 in call_function (oparg=, pp_stack=) at ../Python/ceval.c:4035 #11 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 ---Type to continue, or q to quit--- #12 0x00000000004cd4e2 in fast_function (nk=, na=, n=, pp_stack=, func=) at ../Python/ceval.c:4121 #13 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #14 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #15 0x00000000004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #16 0x00000000004ce7d3 in fast_function (nk=, na=, n=, pp_stack=, func=) at ../Python/ceval.c:4131 #17 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #18 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #19 0x00000000004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #20 0x00000000004ce7d3 in fast_function (nk=, na=, n=, pp_stack=, func=) at ../Python/ceval.c:4131 #21 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #22 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #23 0x00000000004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #24 0x00000000004ce7d3 in fast_function (nk=, na=, n=, pp_stack=, ---Type to continue, or q to quit--- func=) at ../Python/ceval.c:4131 #25 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #26 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #27 0x00000000004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #28 0x00000000004cd217 in fast_function (nk=, na=, n=, pp_stack=, func=) at ../Python/ceval.c:4131 #29 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #30 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #31 0x00000000004cd4e2 in fast_function (nk=, na=, n=, pp_stack=, func=) at ../Python/ceval.c:4121 #32 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #33 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #34 0x00000000004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #35 0x00000000004cd217 in fast_function (nk=, na=, n=, pp_stack=, func=) at ../Python/ceval.c:4131 #36 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 ---Type to continue, or q to quit--- #37 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #38 0x00000000004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #39 0x00000000004cd217 in fast_function (nk=, na=, n=, pp_stack=, func=) at ../Python/ceval.c:4131 #40 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #41 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #42 0x00000000004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #43 0x00000000004cd217 in fast_function (nk=, na=, n=, pp_stack=, func=) at ../Python/ceval.c:4131 #44 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #45 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #46 0x00000000004e7cc8 in PyEval_EvalCodeEx (closure=, defcount=, defs=, kwcount=, kws=, argcount=, args=, locals=, globals=, co=) at ../Python/ceval.c:3267 #47 function_call.lto_priv () at ../Objects/funcobject.c:526 #48 0x00000000004cf239 in PyObject_Call (kw=, arg=, func=) at ../Objects/abstract.c:2529 ---Type to continue, or q to quit--- #49 ext_do_call (nk=, na=, flags=, pp_stack=, func=) at ../Python/ceval.c:4348 #50 PyEval_EvalFrameEx () at ../Python/ceval.c:2720 #51 0x00000000004e7cc8 in PyEval_EvalCodeEx (closure=, defcount=, defs=, kwcount=, kws=, argcount=, args=, locals=, globals=, co=) at ../Python/ceval.c:3267 #52 function_call.lto_priv () at ../Objects/funcobject.c:526 #53 0x00000000004cf239 in PyObject_Call (kw=, arg=, func=) at ../Objects/abstract.c:2529 #54 ext_do_call (nk=, na=, flags=, pp_stack=, func=) at ../Python/ceval.c:4348 #55 PyEval_EvalFrameEx () at ../Python/ceval.c:2720 #56 0x00000000004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #57 0x00000000004ce7d3 in fast_function (nk=, na=, n=, pp_stack=, func=) at ../Python/ceval.c:4131 #58 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #59 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 ---Type to continue, or q to quit--- #60 0x00000000004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #61 0x00000000004ce7d3 in fast_function (nk=, na=, n=, pp_stack=, func=) at ../Python/ceval.c:4131 #62 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #63 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #64 0x00000000004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #65 0x00000000004ce7d3 in fast_function (nk=, na=, n=, pp_stack=, func=) at ../Python/ceval.c:4131 #66 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #67 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #68 0x00000000004cd4e2 in fast_function (nk=, na=, n=, pp_stack=, func=) at ../Python/ceval.c:4121 #69 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #70 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #71 0x00000000004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #72 0x00000000004ce7d3 in fast_function (nk=, na=, n=, pp_stack=, ---Type to continue, or q to quit--- func=) at ../Python/ceval.c:4131 #73 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #74 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #75 0x00000000004cd4e2 in fast_function (nk=, na=, n=, pp_stack=, func=) at ../Python/ceval.c:4121 #76 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #77 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #78 0x00000000004cd4e2 in fast_function (nk=, na=, n=, pp_stack=, func=) at ../Python/ceval.c:4121 #79 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #80 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #81 0x00000000004cd4e2 in fast_function (nk=, na=, n=, pp_stack=, func=) at ../Python/ceval.c:4121 #82 call_function (oparg=, pp_stack=) at ../Python/ceval.c:4056 #83 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #84 0x00000000004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 ---Type to continue, or q to quit--- #85 0x000000000050481f in PyEval_EvalCode ( locals={'fp': , 'demandimport': , '__builtins__': , 'mercurial': , '__file__': '/usr/bin/hg', 'libdir': '@LIBDIR@', '__package__': None, 'sys': , '__name__': '__main__', 'os': , '__doc__': None}, globals={'fp': , 'demandimport': , '__builtins__': , 'mercurial': , '__file__': '/usr/bin/hg', 'libdir': '@LIBDIR@', '__package__': None, 'sys': , '__name__': '__main__', 'os': , '__doc__': None}, co=0x7ffff7e23930) at ../Python/ceval.c:669 #86 run_mod.lto_priv () at ../Python/pythonrun.c:1371 #87 0x00000000004fc182 in PyRun_FileExFlags () at ../Python/pythonrun.c:1357 #88 0x00000000004fb247 in PyRun_SimpleFileExFlags () at ../Python/pythonrun.c:949 #89 0x000000000049aa6e in Py_Main () at ../Modules/main.c:640 #90 0x00007ffff7607a40 in __libc_start_main (main=0x49a500
, argc=4, argv=0x7fffffffd278, init=, fini=, rtld_fini=, stack_end=0x7fffffffd268) at libc-start.c:289 #91 0x000000000049a429 in _start () experienced with `mercurial` 3.4-rcm, python 2.7.9 and `cifs-utils` 2:6.0-1ubuntu2 on Ubuntu 15.04 amd64 with Linux 4.0.1 ---------- components: IO messages: 244457 nosy: krichter priority: normal severity: normal status: open title: *** Error in `/usr/bin/python': double free or corruption (!prev): 0x0000000000f5c760 *** when cloning hg repository into directory on cifs versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 15:59:13 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 30 May 2015 13:59:13 +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: <1432994353.24.0.920800943297.issue19543@psf.upfronthosting.co.za> Nick Coghlan added the comment: Serhiy's patch looks to me like it would pragmatically cover all the cases most likely to affect porting efforts: using the standard library bytes<->bytes codecs through the convenience methods. For a Python 2 backport, I'm slightly more concerned with exposing the argument in the constructor signature, but see value in being consistent with Python 3 if anyone decides to use this to check a custom codec. The main advantage this approach has over the typecheck based approach is that it can correctly warn about "data".encode("hex"), while a typecheck based approach can't distinguish that from "text".encode("ascii") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 16:16:40 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 30 May 2015 14:16:40 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1432995400.74.0.348465754961.issue24004@psf.upfronthosting.co.za> Yury Selivanov added the comment: What inspect.isgeneratorfunction(func) returns for Cython generators? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 16:49:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 May 2015 14:49:28 +0000 Subject: [issue24115] Unhandled error results of C API functions In-Reply-To: <1430585786.54.0.583087529416.issue24115@psf.upfronthosting.co.za> Message-ID: <20150530144926.18690.44089@psf.io> Roundup Robot added the comment: New changeset 82490d05f3b0 by Serhiy Storchaka in branch '2.7': Issue #24115: Update uses of PyObject_IsTrue(), PyObject_Not(), https://hg.python.org/cpython/rev/82490d05f3b0 New changeset 8167df7d4cd0 by Serhiy Storchaka in branch '3.4': Issue #24115: Update uses of PyObject_IsTrue(), PyObject_Not(), https://hg.python.org/cpython/rev/8167df7d4cd0 New changeset 7d1b81224c3b by Serhiy Storchaka in branch '3.5': Issue #24115: Update uses of PyObject_IsTrue(), PyObject_Not(), https://hg.python.org/cpython/rev/7d1b81224c3b New changeset f5d1bb0c4192 by Serhiy Storchaka in branch 'default': Issue #24115: Update uses of PyObject_IsTrue(), PyObject_Not(), https://hg.python.org/cpython/rev/f5d1bb0c4192 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 16:50:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 May 2015 14:50:12 +0000 Subject: [issue24115] Unhandled error results of C API functions In-Reply-To: <1430585786.54.0.583087529416.issue24115@psf.upfronthosting.co.za> Message-ID: <1432997412.17.0.365814082233.issue24115@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 17:02:51 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 30 May 2015 15:02:51 +0000 Subject: [issue24327] yield unpacking In-Reply-To: <1432923782.23.0.743258740131.issue24327@psf.upfronthosting.co.za> Message-ID: <1432998171.94.0.661407721817.issue24327@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Should someone be closing this with "yield from already exists"? ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 17:03:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 May 2015 15:03:57 +0000 Subject: [issue24327] yield unpacking In-Reply-To: <1432923782.23.0.743258740131.issue24327@psf.upfronthosting.co.za> Message-ID: <1432998237.5.0.990338408287.issue24327@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 Sat May 30 17:19:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 May 2015 15:19:22 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1432999162.46.0.416514961689.issue16991@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I agree with all Stephan's comments on Rietveld. See also issue24115 that fixed bugs similar to found in C implementation of OrderedDict. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 17:36:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 May 2015 15:36:07 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <20150530153604.25415.11567@psf.io> Roundup Robot added the comment: New changeset 0a7380984e37 by Eric Snow in branch '3.5': Issue #16991: Use PyObject_TypeCheck instead of PyObject_IsInstance. https://hg.python.org/cpython/rev/0a7380984e37 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 17:40:11 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 30 May 2015 15:40:11 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1705079.8CgS8uXsvX@raxxla> Message-ID: Eric Snow added the comment: > PyObject_TypeCheck() should be used instead of PyObject_IsInstance() (see > issue24257). Thanks for pointing this out. I've fixed both dictobject.h and odictobject.h. > > Perhaps Py_ODict_GetItemId() should be private API as relevant dict function. This isn't needed for 3.5, right? I'm not opposed to adding more functions to the C API for OrderedDict, but I wanted to start out as small as possible. My main motivation for the C implementation was for use in the interpreter and I hadn't given much thought to the direct use of C OrderedDict by extension modules. That can be addressed in 3.6 if it's important. I supposed you could double-check with Larry if you want to add more odict support to the C-API for 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 17:40:15 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 30 May 2015 15:40:15 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433000415.37.0.945847534747.issue16991@psf.upfronthosting.co.za> Mark Lawrence added the comment: I'm getting the following linker errors on Windows 8.1 for 32 and 64 bit debug and release builds. unresolved external symbol _PyODict_Type in C:\cpython\PCbuild\_collectionsmodule.obj, and _PyODictIter_Type, _PyODictValues_Type, _PyODictKeys_Type,_PyODictItems_Type in C:\cpython\PCbuild\object.obj ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 17:41:32 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 30 May 2015 15:41:32 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <20150530153604.25415.11567@psf.io> Message-ID: Eric Snow added the comment: > New changeset 0a7380984e37 by Eric Snow in branch '3.5': > Issue #16991: Use PyObject_TypeCheck instead of PyObject_IsInstance. > https://hg.python.org/cpython/rev/0a7380984e37 I've also merged this into default: changeset: 96384:10eabadba316b6f2034db4c076a60c63d25d8fc6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 17:50:45 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 30 May 2015 15:50:45 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1433000415.37.0.945847534747.issue16991@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: > I'm getting the following linker errors on Windows 8.1 for 32 and 64 bit debug and release builds. unresolved external symbol _PyODict_Type in C:\cpython\PCbuild\_collectionsmodule.obj, and _PyODictIter_Type, > _PyODictValues_Type, _PyODictKeys_Type,_PyODictItems_Type in C:\cpython\PCbuild\object.obj Hmm. I'm not too familiar with how things work for Windows. I'm also not clear on where the leading underscore is coming from. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 18:00:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 May 2015 16:00:50 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433001650.64.0.975823349366.issue16991@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > This isn't needed for 3.5, right? I'm not opposed to adding more > functions to the C API for OrderedDict, but I wanted to start out as > small as possible. You already added public name Py_ODict_GetItemId. It uses private _Py_Identifier API and shouldn't be public. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 18:06:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 May 2015 16:06:33 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433001993.55.0.819840743579.issue16991@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As for Windows issue, perhaps these names should be enumerated in PC/python3.def? See also issue23903. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 18:17:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 May 2015 16:17:19 +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: <1433002639.06.0.779373818578.issue22609@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 18:18:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 May 2015 16:18:52 +0000 Subject: [issue5633] fix for timeit when the statement is a string and the setup is not (and tests) In-Reply-To: <1238533299.21.0.751134071386.issue5633@psf.upfronthosting.co.za> Message-ID: <1433002732.5.0.195285703346.issue5633@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 18:46:06 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 May 2015 16:46:06 +0000 Subject: [issue5633] fix for timeit when the statement is a string and the setup is not (and tests) In-Reply-To: <1238533299.21.0.751134071386.issue5633@psf.upfronthosting.co.za> Message-ID: <20150530164603.111598.92910@psf.io> Roundup Robot added the comment: New changeset 14d1018940cb by Serhiy Storchaka in branch '2.7': Issue #5633: Fixed timeit when the statement is a string and the setup is not. https://hg.python.org/cpython/rev/14d1018940cb New changeset 89de73c0d848 by Serhiy Storchaka in branch '3.4': Issue #5633: Fixed timeit when the statement is a string and the setup is not. https://hg.python.org/cpython/rev/89de73c0d848 New changeset faea7c8bcb13 by Serhiy Storchaka in branch '3.5': Issue #5633: Fixed timeit when the statement is a string and the setup is not. https://hg.python.org/cpython/rev/faea7c8bcb13 New changeset fd01cbe4336e by Serhiy Storchaka in branch 'default': Issue #5633: Fixed timeit when the statement is a string and the setup is not. https://hg.python.org/cpython/rev/fd01cbe4336e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 18:48:24 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 30 May 2015 16:48:24 +0000 Subject: [issue24327] yield unpacking In-Reply-To: <1432923782.23.0.743258740131.issue24327@psf.upfronthosting.co.za> Message-ID: <1433004504.95.0.0465188043964.issue24327@psf.upfronthosting.co.za> Ethan Furman added the comment: I was waiting a couple days to give Mital a chance to clarify if some other behavior was intended. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 18:55:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 May 2015 16:55:14 +0000 Subject: [issue5633] fix for timeit when the statement is a string and the setup is not (and tests) In-Reply-To: <1238533299.21.0.751134071386.issue5633@psf.upfronthosting.co.za> Message-ID: <1433004914.42.0.667673887196.issue5633@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 Sat May 30 19:55:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 May 2015 17:55:02 +0000 Subject: [issue22357] inspect module documentation makes no reference to __qualname__ attribute In-Reply-To: <1410124992.98.0.0231359390306.issue22357@psf.upfronthosting.co.za> Message-ID: <20150530175459.24091.38229@psf.io> Roundup Robot added the comment: New changeset 943fa0e8b6a4 by Yury Selivanov in branch '3.4': Issue 22357: Document __qualname__ in inspect.rst https://hg.python.org/cpython/rev/943fa0e8b6a4 New changeset 1d9131bc0ea4 by Yury Selivanov in branch '3.5': Issue 22357: Merge from 3.4 https://hg.python.org/cpython/rev/1d9131bc0ea4 New changeset 5621e9a21cc3 by Yury Selivanov in branch 'default': Issue 22357: Merge from 3.5 https://hg.python.org/cpython/rev/5621e9a21cc3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 19:55:15 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 30 May 2015 17:55:15 +0000 Subject: [issue22357] inspect module documentation makes no reference to __qualname__ attribute In-Reply-To: <1410124992.98.0.0231359390306.issue22357@psf.upfronthosting.co.za> Message-ID: <1433008515.35.0.610987125775.issue22357@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 19:56:27 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 30 May 2015 17:56:27 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1433008587.05.0.66197477407.issue24004@psf.upfronthosting.co.za> Stefan Behnel added the comment: Cython functions that return a generator aren't special in any way, so it's actually correct that isgeneratorfunction() always returns False. I mean, I could set the CO_COROUTINE flag on the code object that we fake, but that wouldn't help much as Cython's functions are not Python functions, so isfunction() will also return False for them and no-one would look at the flag in the first place. And finally, a Cython generator is not a Python generator (with byte code position etc.), so isgenerator() also correctly returns False. At least iscoroutine() and iswaitable() will return True for Cython Coroutines now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 19:57:31 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 30 May 2015 17:57:31 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1433001650.64.0.975823349366.issue16991@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: > You already added public name Py_ODict_GetItemId. It uses private _Py_Identifier API and shouldn't be public. Ah. I'll remove it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 20:04:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 May 2015 18:04:25 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <20150530180422.4324.73333@psf.io> Roundup Robot added the comment: New changeset c9404fba02ba by Eric Snow in branch '3.5': Issue #16991: Properly handle return values in several places. https://hg.python.org/cpython/rev/c9404fba02ba New changeset 951a3ef82180 by Eric Snow in branch '3.5': Issue #16991: Do not return None from OrderedDict.__reversed__. https://hg.python.org/cpython/rev/951a3ef82180 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 20:05:17 2015 From: report at bugs.python.org (gdata gmail) Date: Sat, 30 May 2015 18:05:17 +0000 Subject: [issue24332] urllib.parse should not discard delimiters when associated component is empty Message-ID: <1433009117.13.0.805142378902.issue24332@psf.upfronthosting.co.za> New submission from gdata gmail: The documenatation for urllib.parse (https://docs.python.org/3.0/library/urllib.parse.html) states several times: "This may result in a slightly different, but equivalent URL, if the URL that was parsed originally had unnecessary delimiters (for example, a ? with an empty query; the RFC states that these are equivalent)." This is false -- RFC 3986 explicitly states that ? with an empty query is _not_ equivalent to a URL without it. For example, the following two URL's should be considered different: http://example.com/? http://example.com/ https://tools.ietf.org/html/rfc3986#section-6.2.3 ---------- messages: 244477 nosy: gdata gmail priority: normal severity: normal status: open title: urllib.parse should not discard delimiters when associated component is empty _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 20:08:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 May 2015 18:08:19 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <20150530180816.25409.33689@psf.io> Roundup Robot added the comment: New changeset 7117e9b0f595 by Eric Snow in branch '3.5': Issue #16991: Drop Py_ODict_GetItemId. https://hg.python.org/cpython/rev/7117e9b0f595 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 20:18:52 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 30 May 2015 18:18:52 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1433009932.81.0.311907319156.issue24004@psf.upfronthosting.co.za> Stefan Behnel added the comment: Hmm, I just noticed that this only started failing when I disabled the asyncio module patching for 3.5beta1+, assuming that it now all works. A side effect of that was that also the inspect module is no longer patched into returning True from isgenerator() for Cython generators. While there might be code that fails when it tries to inspect Cython generators as Python generators (as the first don't have byte code), I think it's still the easiest fix to simply keep the inspect patching. That would then trigger the right code path here without changes in asyncio. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 20:26:07 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 30 May 2015 18:26:07 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433010367.51.0.0431017216079.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: If it's just a matter of adding the definitions then here's a patch. Does that look correct? ---------- Added file: http://bugs.python.org/file39567/odict-windows.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 20:26:56 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 30 May 2015 18:26:56 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433010416.84.0.675118063054.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: That last message is about building on Windows. ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 20:28:37 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 30 May 2015 18:28:37 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1433010517.77.0.801053921099.issue24004@psf.upfronthosting.co.za> Stefan Behnel added the comment: ... except that the returned object may not actually be a Cython generator but a GeneratorWrapper, now that the patch from issue 24316 is in place. :) Then I guess we're back to the point where duck-typing and calling __await__() is a good idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 20:40:30 2015 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 30 May 2015 18:40:30 +0000 Subject: [issue24333] urllib2 HTTPS connection over a digest auth enabled proxy gives 407 Message-ID: <1433011230.8.0.748125435246.issue24333@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: This is originally my question at stackoverflow.com. (http://stackoverflow.com/q/30511341/3786245) I think it's a bug, so I posted it here. I'm trying to fetch HTTPS pages through a proxy with digest authentication. Here are my codes: import urllib.request class SimplePasswordManager(object): def __init__(self, username, password): self.username = username self.password = password def add_password(self, realm, uri, user, passwd): pass def find_user_password(self, realm, authuri): return self.username, self.password proxy_handler = urllib.request.ProxyHandler({ 'http': '', 'https': '', }) password_mgr = SimplePasswordManager('', '') proxy_auth_handler = urllib.request.ProxyDigestAuthHandler(passwd=password_mgr) opener = urllib.request.build_opener(proxy_auth_handler, proxy_handler) req = opener.open('http://httpbin.org/ip') print(req.read().decode('ascii')) req = opener.open('https://httpbin.org/ip') print(req.read().decode('ascii')) And the results: { "origin": "" } Traceback (most recent call last): File "/usr/lib/python3.4/urllib/request.py", line 1182, in do_open h.request(req.get_method(), req.selector, req.data, headers) File "/usr/lib/python3.4/http/client.py", line 1088, in request self._send_request(method, url, body, headers) File "/usr/lib/python3.4/http/client.py", line 1126, in _send_request self.endheaders(body) File "/usr/lib/python3.4/http/client.py", line 1084, in endheaders self._send_output(message_body) File "/usr/lib/python3.4/http/client.py", line 922, in _send_output self.send(msg) File "/usr/lib/python3.4/http/client.py", line 857, in send self.connect() File "/usr/lib/python3.4/http/client.py", line 1223, in connect super().connect() File "/usr/lib/python3.4/http/client.py", line 837, in connect self._tunnel() File "/usr/lib/python3.4/http/client.py", line 820, in _tunnel message.strip())) OSError: Tunnel connection failed: 407 Proxy Authentication Required During handling of the above exception, another exception occurred: Traceback (most recent call last): File "proxy_test.py", line 25, in req = opener.open('https://httpbin.org/ip') File "/usr/lib/python3.4/urllib/request.py", line 463, in open response = self._open(req, data) File "/usr/lib/python3.4/urllib/request.py", line 481, in _open '_open', req) File "/usr/lib/python3.4/urllib/request.py", line 441, in _call_chain result = func(*args) File "/usr/lib/python3.4/urllib/request.py", line 1225, in https_open context=self._context, check_hostname=self._check_hostname) File "/usr/lib/python3.4/urllib/request.py", line 1184, in do_open raise URLError(err) urllib.error.URLError: Seems HTTP connection works while HTTPS not. I think it's a bug in urllib. For HTTPS connections, HTTPConnection.connect() calls HTTPConnection._tunnel(), and the latter function throws an OSError for 407 when sending a CONNECT request. There's no chance for OpenerDirector.open() to call HTTPErrorProcessor.http_response(). As a result, 407 errors are not handled correctly in ProxyDigestAuthHandler.http_error_407(). Finally, is there a workaround before this is fixed? ---------- components: Library (Lib) messages: 244483 nosy: Chi Hsuan Yen priority: normal severity: normal status: open title: urllib2 HTTPS connection over a digest auth enabled proxy gives 407 type: behavior versions: Python 2.7, Python 3.2, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 20:55:47 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 May 2015 18:55:47 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <20150530185544.91783.39194@psf.io> Roundup Robot added the comment: New changeset 030205f1e716 by Eric Snow in branch '3.5': Issue #16991: Fix a few leaks and other memory-related concerns in OrderedDict. https://hg.python.org/cpython/rev/030205f1e716 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 20:56:12 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Sat, 30 May 2015 18:56:12 +0000 Subject: [issue15138] base64.urlsafe_b64**code are too slow In-Reply-To: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za> Message-ID: <1433012172.03.0.250122692283.issue15138@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: Here's a backport of the patch to 2.7. It's pretty rad, and basically identical to how YouTube monkeypatches base64. Not sure what will happen to this patch. According to recent discussion on the list (e.g. https://mail.python.org/pipermail/python-dev/2015-May/140380.html ), performance improvements are open for inclusion in 2.7 if anyone wants to bother with merging this in and taking on the review / maintenance burden. I'm OK with just publishing it for others to merge in with their own private versions of Python. It is only relevant if you use base64 a lot. :) ---------- nosy: +Devin Jeanpierre Added file: http://bugs.python.org/file39568/base64_27.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 21:25:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 May 2015 19:25:22 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <20150530192520.25411.14201@psf.io> Roundup Robot added the comment: New changeset fbe74badb0c6 by Eric Snow in branch 'default': Issue #16991: Ensure that the proper OrderedDict is used in tests. https://hg.python.org/cpython/rev/fbe74badb0c6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 21:44:32 2015 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 30 May 2015 19:44:32 +0000 Subject: [issue24333] urllib2 HTTPS connection over a digest auth enabled proxy gives 407 In-Reply-To: <1433011230.8.0.748125435246.issue24333@psf.upfronthosting.co.za> Message-ID: <1433015072.22.0.806646220947.issue24333@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: For those who are working on this problem, my squid.conf may be helpful: --- squid.conf.default 2015-05-31 03:33:34.006361795 +0800 +++ squid.conf 2015-05-31 03:36:28.533034294 +0800 @@ -49,9 +49,15 @@ # Example rule allowing access from your local networks. # Adapt localnet in the ACL section to list your (internal) IP networks # from where browsing should be allowed -http_access allow localnet -http_access allow localhost +# http_access allow localnet +# http_access allow localhost +auth_param digest realm Proxy digest auth test +auth_param digest program /usr/lib/squid/digest_file_auth -c /etc/squid/squid-passwd +auth_param digest children 2 + +acl squid-passwd proxy_auth REQUIRED +http_access allow squid-passwd # And finally deny all other access to this proxy http_access deny all And the content of /etc/squid/squid-passwd: test_username:Proxy digest auth test:ab1e6b5de6ea6c8b072c5e513eea9c61 I'm testing for squid 3.5.5 on Arch Linux. I can test its correctness with curl: $ curl -v --proxy-user test_username:test_password --proxy localhost:3128 --proxy-digest https://httpbin.org/ip ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 22:01:44 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 30 May 2015 20:01:44 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1433016104.27.0.10982396874.issue24004@psf.upfronthosting.co.za> Yury Selivanov added the comment: Stefan, > Then I guess we're back to the point where duck-typing and calling __await__() is a good idea. Please test the attached patch. I agree this is a good idea. ---------- keywords: +patch Added file: http://bugs.python.org/file39569/coroutine.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 22:02:03 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 30 May 2015 20:02:03 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1433016123.7.0.310824304622.issue24004@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: fixed -> status: closed -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 22:19:28 2015 From: report at bugs.python.org (Marc Jofre) Date: Sat, 30 May 2015 20:19:28 +0000 Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za> Message-ID: <1433017168.98.0.0486207328987.issue24291@psf.upfronthosting.co.za> Marc Jofre added the comment: When executing, wsgiref produces the following error dump: D:\SixSensoCytometerWebBased\include\bin>D:\SixSensoCytometerWebBased\include\bi n\manage.exe runserver 8765 Validating models... 0 errors found May 26, 2015 - 16:20:56 Django version 1.5.8, using settings 'settings' Development server is running at http://127.0.0.1:8765/ Quit the server with CTRL-BREAK. [26/May/2015 16:20:56] "GET / HTTP/1.1" 200 29661 100 [26/May/2015 16:20:59] "POST /login HTTP/1.1" 200 25980 [26/May/2015 16:20:59] "GET /static/js/ready.js HTTP/1.1" 500 79563 Traceback (most recent call last): File "D:\WinPython-64bit-2.7.6.3\python-2.7.6.amd64\Lib\wsgiref\handlers.py", line 86, in run self.finish_response() File "D:\WinPython-64bit-2.7.6.3\python-2.7.6.amd64\Lib\wsgiref\handlers.py", line 128, in finish_response self.write(data) File "D:\WinPython-64bit-2.7.6.3\python-2.7.6.amd64\Lib\wsgiref\handlers.py", line 217, in write self._write(data) File "D:\WinPython-64bit-2.7.6.3\python-2.7.6.amd64\lib\socket.py", line 324, in write [26/May/2015 16:20:59] "GET /static/js/ClasePrincipalAutobahn.js HTTP/1.1" 500 7 9818 [26/May/2015 16:20:59] "GET /static/img/initialGUIimage.png HTTP/1.1" 500 79777 self.flush() File "D:\WinPython-64bit-2.7.6.3\python-2.7.6.amd64\lib\socket.py", line 303, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) error: [Errno 10053] An established connection was aborted by the software in yo ur host machine ---------- nosy: +marcjofre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 22:22:26 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 30 May 2015 20:22:26 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1433017346.39.0.349591009262.issue24325@psf.upfronthosting.co.za> Yury Selivanov added the comment: Larry, can you accept the first version of the patch (only function that patches code object's co_flags) after beta2? I'm OK if you think it should only be committed in 3.6, but I also agree with Stefan, that using C is better in this particular case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 22:27:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 May 2015 20:27:10 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <20150530202707.111604.65171@psf.io> Roundup Robot added the comment: New changeset 1d851112922f by Eric Snow in branch '3.5': Issue #16991: Add PyODict* to Windows builds. https://hg.python.org/cpython/rev/1d851112922f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 22:29:44 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 30 May 2015 20:29:44 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433017784.85.0.222437541351.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: I'm checking a fix for Windows against a buildbot (http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 22:35:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 May 2015 20:35:26 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <20150530203523.27656.61906@psf.io> Roundup Robot added the comment: New changeset 3ba1fa925f17 by Eric Snow in branch 'default': Issue #16991: Use the correct version for master. https://hg.python.org/cpython/rev/3ba1fa925f17 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 22:37:28 2015 From: report at bugs.python.org (Christian Heimes) Date: Sat, 30 May 2015 20:37:28 +0000 Subject: [issue24334] SSLSocket extra level of indirection Message-ID: <1433018248.44.0.756605302302.issue24334@psf.upfronthosting.co.za> New submission from Christian Heimes: I just noticed that #21965 has added an extra level of indirection to the SSLSocket object. In Python 3.4 and earlier the ssl.SSLSocket object has one level of indirection: >>> import ssl >>> ctx = ssl.create_default_context() >>> sock = ssl.create_connection(('www.python.org', 443)) >>> ssock = ctx.wrap_socket(sock, server_hostname='www.python.org') >>> ssock >>> ssock._sslobj <_ssl._SSLSocket object at 0x7efcb9fd8c00> In 3.5 an additional level comes into play: >>> import ssl >>> ctx = ssl.create_default_context() >>> sock = ssl.create_connection(('www.python.org', 443)) >>> ssock = ctx.wrap_socket(sock, server_hostname='www.python.org') >>> ssock >>> ssock._sslobj >>> ssock._sslobj._sslobj <_ssl._SSLSocket object at 0x7fa5506918a0> Method calls like SSLSocket.read() now call SSLObject.read(), which call _SSLSocket.read(). That seems a bit excessive. Isn't there a better way with less indirections? I have created a proof-of-concept patch that removes the extra layer with some code duplication. Maybe the common code can be moved into a commmon base class for SSLObject and SSLSocket? After all both classes provide a similar interface. ---------- components: Library (Lib) files: no_sslobject.patch keywords: patch messages: 244494 nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou priority: normal severity: normal stage: needs patch status: open title: SSLSocket extra level of indirection type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39570/no_sslobject.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 22:38:32 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 May 2015 20:38:32 +0000 Subject: [issue24334] SSLSocket extra level of indirection In-Reply-To: <1433018248.44.0.756605302302.issue24334@psf.upfronthosting.co.za> Message-ID: <1433018312.2.0.229671784537.issue24334@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm nosying Geert, who is the original author of the SSLObject code. ---------- nosy: +geertj _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 22:56:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 May 2015 20:56:38 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <20150530205635.27656.39934@psf.io> Roundup Robot added the comment: New changeset aea27164d207 by Eric Snow in branch '3.5': Issue #16991: Add odictobject.h on Windows. https://hg.python.org/cpython/rev/aea27164d207 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 23:00:37 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 30 May 2015 21:00:37 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1433019637.25.0.57656695672.issue24004@psf.upfronthosting.co.za> Stefan Behnel added the comment: Works for me. Why is the AwaitableABC type check needed, in addition to looking up the relevant method? IIUC, the type check will just do a lookup of the same method if the type hasn't been registered as Awaitable explicitly. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 23:01:56 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 30 May 2015 21:01:56 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1433019716.91.0.964187001066.issue24004@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Why is the AwaitableABC type check needed, in addition to looking up the relevant method? IIUC, the type check will just do a lookup of the same method if the type hasn't been registered as Awaitable explicitly. Because __await__ should be defined on the class, not on the method (as for all other magic methods in Python). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 23:08:22 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 30 May 2015 21:08:22 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433020102.73.0.583587969157.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Well, that last one has everything compiling again. I expect it should be okay now. I'll watch the results. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 23:08:29 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 30 May 2015 21:08:29 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433020109.93.0.225820742677.issue16991@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 23:09:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 May 2015 21:09:33 +0000 Subject: [issue23934] inspect.signature reporting "()" for all builtin & extension types In-Reply-To: <1428943093.46.0.94678170323.issue23934@psf.upfronthosting.co.za> Message-ID: <20150530210930.18177.39255@psf.io> Roundup Robot added the comment: New changeset e59966bb6de5 by Yury Selivanov in branch '3.5': Issue #23934: Fix inspect.signature to fail correctly for builtin types. https://hg.python.org/cpython/rev/e59966bb6de5 New changeset 19e0ffdd1daa by Yury Selivanov in branch 'default': Issue #23934: Fix inspect.signature to fail correctly for builtin types. https://hg.python.org/cpython/rev/19e0ffdd1daa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 23:10:04 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 30 May 2015 21:10:04 +0000 Subject: [issue23934] inspect.signature reporting "()" for all builtin & extension types In-Reply-To: <1428943093.46.0.94678170323.issue23934@psf.upfronthosting.co.za> Message-ID: <1433020204.95.0.336779092852.issue23934@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 30 23:11:34 2015 From: report at bugs.python.org (Elazar Gershuni) Date: Sat, 30 May 2015 21:11:34 +0000 Subject: [issue19235] Add a dedicated subclass for recursion errors In-Reply-To: <1381596107.9.0.320701037292.issue19235@psf.upfronthosting.co.za> Message-ID: <1433020294.05.0.628305721698.issue19235@psf.upfronthosting.co.za> Elazar Gershuni added the comment: Ok ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 00:41:12 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 May 2015 22:41:12 +0000 Subject: [issue24331] *** Error in `/usr/bin/python': double free or corruption (!prev): 0x0000000000f5c760 *** when cloning hg repository into directory on cifs In-Reply-To: <1432992886.73.0.102368057265.issue24331@psf.upfronthosting.co.za> Message-ID: <1433025672.01.0.711653411514.issue24331@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the report. I would say it looks very much like a Mercurial issue. You can find the Mercurial bug tracker at http://bz.selenic.com/ ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 01:03:38 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 30 May 2015 23:03:38 +0000 Subject: [issue24332] urllib.parse should not discard delimiters when associated component is empty In-Reply-To: <1433009117.13.0.805142378902.issue24332@psf.upfronthosting.co.za> Message-ID: <1433027018.43.0.375592271344.issue24332@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 02:20:34 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 00:20: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: <1433031634.59.0.632884379475.issue22609@psf.upfronthosting.co.za> Martin Panter added the comment: Left a couple pedantic comments. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 02:35:32 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 31 May 2015 00:35:32 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1433017346.39.0.349591009262.issue24325@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Since it's a speedup it could also go into 3.5.1. On May 30, 2015 1:22 PM, "Yury Selivanov" wrote: > > Yury Selivanov added the comment: > > Larry, can you accept the first version of the patch (only function that > patches code object's co_flags) after beta2? > > I'm OK if you think it should only be committed in 3.6, but I also agree > with Stefan, that using C is better in this particular case. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 02:40:10 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 00:40:10 +0000 Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za> Message-ID: <1433032810.04.0.449640966558.issue24291@psf.upfronthosting.co.za> Martin Panter added the comment: Marc, if you think your connection aborted error is related, can you say what kind of object the ?stdout? parameter is in the handler class? In other words, what class?s method is being called in the write() function at line 217? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 02:48:21 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 00:48:21 +0000 Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za> Message-ID: <1433033301.73.0.174741696349.issue24291@psf.upfronthosting.co.za> Martin Panter added the comment: Actually, looking closer at Marc?s traceback, it appears to be the ordinary socket._fileobject class. So I suspect it is unrelated to this bug because the Python 2 socket code appears to call sendall() in a loop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 03:03:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 01:03:00 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <20150531010256.111614.31967@psf.io> Roundup Robot added the comment: New changeset b7b73029c825 by Yury Selivanov in branch '3.4': Issue 24004: Support Awaitables (pep 492) in @asyncio.coroutine decorator https://hg.python.org/cpython/rev/b7b73029c825 New changeset d1959cafc68c by Yury Selivanov in branch '3.5': Issue 24004: Support Awaitables (pep 492) in @asyncio.coroutine decorator https://hg.python.org/cpython/rev/d1959cafc68c New changeset 6c53591d589b by Yury Selivanov in branch 'default': Issue 24004: Support Awaitables (pep 492) in @asyncio.coroutine decorator https://hg.python.org/cpython/rev/6c53591d589b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 03:05:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 01:05:11 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <20150531010509.27642.21885@psf.io> Roundup Robot added the comment: New changeset 5f1e24f083c7 by Yury Selivanov in branch '3.5': Issue 24004: Add a unittest for @asyncio.coroutine supporting Awaitables https://hg.python.org/cpython/rev/5f1e24f083c7 New changeset 9d261141eb0c by Yury Selivanov in branch 'default': Issue 24004: Add a unittest for @asyncio.coroutine supporting Awaitables https://hg.python.org/cpython/rev/9d261141eb0c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 03:06:23 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 31 May 2015 01:06:23 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1433034383.86.0.203546472201.issue24004@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 03:12:17 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 01:12:17 +0000 Subject: [issue23377] HTTPResponse may drop buffer holding next response In-Reply-To: <1422881776.12.0.998068930599.issue23377@psf.upfronthosting.co.za> Message-ID: <1433034737.54.0.548548652322.issue23377@psf.upfronthosting.co.za> Martin Panter added the comment: Just realized that the makefile() call in _tunnel() still lets this bug occur when a HTTPSConnection is being used with a proxy using the CONNECT method. So while my patch shouldn?t make things any worse than they already are, it needs more work to fix this instance. Maybe we would have to use the new SSL memory BIO support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 04:56:03 2015 From: report at bugs.python.org (Zachary Ware) Date: Sun, 31 May 2015 02:56:03 +0000 Subject: [issue5497] openssl compileerror with original source In-Reply-To: <1237272241.76.0.44185655243.issue5497@psf.upfronthosting.co.za> Message-ID: <1433040963.66.0.698692910732.issue5497@psf.upfronthosting.co.za> Zachary Ware added the comment: If this wasn't outdated two and a half years ago, it is now :) ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 05:00:01 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 31 May 2015 03:00:01 +0000 Subject: [issue22203] inspect.getargspec() returns wrong spec for builtins In-Reply-To: <1408080032.86.0.165011450626.issue22203@psf.upfronthosting.co.za> Message-ID: <1433041201.89.0.595725177754.issue22203@psf.upfronthosting.co.za> Yury Selivanov added the comment: This was fixed in issue #23934 ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> sphinx - building muppy docs fails on Linux _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 05:02:10 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 31 May 2015 03:02:10 +0000 Subject: [issue21853] Fix inspect in unicodeless build In-Reply-To: <1403595669.37.0.0818329424469.issue21853@psf.upfronthosting.co.za> Message-ID: <1433041330.02.0.307487696832.issue21853@psf.upfronthosting.co.za> Yury Selivanov added the comment: Serhiy, could you please commit it in 2.7? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 05:32:17 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 03:32:17 +0000 Subject: [issue15928] Open url with proxy causes TypeError In-Reply-To: <1347428702.03.0.0537807562119.issue15928@psf.upfronthosting.co.za> Message-ID: <1433043137.2.0.759147282316.issue15928@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: not a bug -> duplicate superseder: -> Missing size argument in readline() method for httplib's class LineAndFileWrapper _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 05:57:45 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 03:57:45 +0000 Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za> Message-ID: <1433044665.24.0.646802932899.issue7291@psf.upfronthosting.co.za> Martin Panter added the comment: I believe this also affects Python 3; see Issue 24333. I think making the CONNECT response object available to the caller is the right general approach. But I really dislike raising an exception that holds a socket connection to be closed. (I know this is already done with urllib.error.HTTPError; let?s not repeat this in the ?http.client? module!) Ideally, at the ?http.client? level I would prefer to avoid all the special set_tunnel() calls, and use the usual request() and getresponse() API to make the CONNECT request. This way the response status and header fields would be available just like any other response. For this approach to work, we would probably need to add a new HTTPConnection.detach() method that released the original socket reader and writer, and add a way to create a new HTTPConnection instance using these socket objects. This enhancement probably wouldn?t be appropriate for Python 2 or a bug fix release. But it seems the cleanest approach to me, and may also allow using HTTPConnection with the Upgrade header (e.g. for opportunistic encryption, HTTP 2, Web etc), and proxying non-HTTP connections, as bonuses. A less revolutionary approach might be to add a HTTPSConnection.tunnel() method, that always returns the proxy?s response, but only does the SSL wrapping for a successful response. ---------- nosy: +vadmium versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 06:00:10 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 04:00:10 +0000 Subject: [issue24333] urllib2 HTTPS connection over a digest auth enabled proxy gives 407 In-Reply-To: <1433011230.8.0.748125435246.issue24333@psf.upfronthosting.co.za> Message-ID: <1433044810.84.0.507780334242.issue24333@psf.upfronthosting.co.za> Martin Panter added the comment: There is already work done on this at Issue 7291. There is a patch there, but IMO it needs more work or a different approach. ---------- nosy: +vadmium resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> urllib2 cannot handle https with proxy requiring auth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 06:25:46 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 04:25:46 +0000 Subject: [issue5843] Normalization error in urlunparse In-Reply-To: <1240686759.57.0.0410680082249.issue5843@psf.upfronthosting.co.za> Message-ID: <1433046346.32.0.55242394815.issue5843@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> urllib.parse wrongly strips empty #fragment _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 06:28:09 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 04:28:09 +0000 Subject: [issue15009] urlsplit can't round-trip relative-host urls. In-Reply-To: <1338935307.83.0.455725477737.issue15009@psf.upfronthosting.co.za> Message-ID: <1433046489.91.0.300698360067.issue15009@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> urllib.parse wrongly strips empty #fragment _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 06:34:30 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 04:34:30 +0000 Subject: [issue24332] urllib.parse should not discard delimiters when associated component is empty In-Reply-To: <1433009117.13.0.805142378902.issue24332@psf.upfronthosting.co.za> Message-ID: <1433046870.59.0.535548413426.issue24332@psf.upfronthosting.co.za> Martin Panter added the comment: This is essentially the same as Issue 22852. The title just refers to stripping an empty #fragment, but the netloc and query components are also affected. I have a patch there which needs reviewing, if you are interested. Or if you have any alternative ideas on how to solve this they would be welcome too. ---------- nosy: +vadmium resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> urllib.parse wrongly strips empty #fragment _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 06:39:12 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 04:39:12 +0000 Subject: [issue22852] urllib.parse wrongly strips empty #fragment, ?query, //netloc In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za> Message-ID: <1433047152.66.0.0368493522136.issue22852@psf.upfronthosting.co.za> Martin Panter added the comment: Anyone want to review my new patch? This is a perennial issue; see all the duplicates I just linked. ---------- keywords: +needs review title: urllib.parse wrongly strips empty #fragment -> urllib.parse wrongly strips empty #fragment, ?query, //netloc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 06:59:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 31 May 2015 04:59:52 +0000 Subject: [issue21853] Fix inspect in unicodeless build In-Reply-To: <1403595669.37.0.0818329424469.issue21853@psf.upfronthosting.co.za> Message-ID: <1433048392.27.0.348441955691.issue21853@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 07:02:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 05:02:18 +0000 Subject: [issue21853] Fix inspect in unicodeless build In-Reply-To: <1403595669.37.0.0818329424469.issue21853@psf.upfronthosting.co.za> Message-ID: <20150531050215.18668.44716@psf.io> Roundup Robot added the comment: New changeset 44590c1b264e by Serhiy Storchaka in branch '2.7': Issue #21853: Fixed the inspect module in unicode disabled build. https://hg.python.org/cpython/rev/44590c1b264e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 07:04:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 31 May 2015 05:04:17 +0000 Subject: [issue21853] Fix inspect in unicodeless build In-Reply-To: <1403595669.37.0.0818329424469.issue21853@psf.upfronthosting.co.za> Message-ID: <1433048657.7.0.473401908593.issue21853@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: -Fix unicodeless build of Python resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 07:29:05 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 05:29:05 +0000 Subject: [issue24334] SSLSocket extra level of indirection In-Reply-To: <1433018248.44.0.756605302302.issue24334@psf.upfronthosting.co.za> Message-ID: <1433050145.1.0.764793603485.issue24334@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 08:06:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 06:06:18 +0000 Subject: [issue24264] imageop Unsafe Arithmetic In-Reply-To: <1432278063.26.0.673606816428.issue24264@psf.upfronthosting.co.za> Message-ID: <20150531060615.27650.76255@psf.io> Roundup Robot added the comment: New changeset de0ccaaf2e64 by Serhiy Storchaka in branch '2.7': Issue #24264: Fixed buffer overflow in the imageop module. https://hg.python.org/cpython/rev/de0ccaaf2e64 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 08:07:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 31 May 2015 06:07:16 +0000 Subject: [issue24264] imageop Unsafe Arithmetic In-Reply-To: <1432278063.26.0.673606816428.issue24264@psf.upfronthosting.co.za> Message-ID: <1433052436.47.0.521418149474.issue24264@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your report John. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 08:09:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 31 May 2015 06:09:05 +0000 Subject: [issue24284] Inconsistency in startswith/endswith In-Reply-To: <1432554087.61.0.0896292215981.issue24284@psf.upfronthosting.co.za> Message-ID: <1433052545.58.0.407953938604.issue24284@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Martin. ---------- assignee: -> serhiy.storchaka versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 08:17:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 06:17:05 +0000 Subject: [issue24284] Inconsistency in startswith/endswith In-Reply-To: <1432554087.61.0.0896292215981.issue24284@psf.upfronthosting.co.za> Message-ID: <20150531061702.83495.59611@psf.io> Roundup Robot added the comment: New changeset a82498f424fe by Serhiy Storchaka in branch '3.5': Issue #24284: The startswith and endswith methods of the str class no longer https://hg.python.org/cpython/rev/a82498f424fe New changeset 04162e06323f by Serhiy Storchaka in branch 'default': Issue #24284: The startswith and endswith methods of the str class no longer https://hg.python.org/cpython/rev/04162e06323f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 08:17:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 31 May 2015 06:17:31 +0000 Subject: [issue24284] Inconsistency in startswith/endswith In-Reply-To: <1432554087.61.0.0896292215981.issue24284@psf.upfronthosting.co.za> Message-ID: <1433053051.59.0.708735716184.issue24284@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 May 31 08:53:15 2015 From: report at bugs.python.org (Rohith PR) Date: Sun, 31 May 2015 06:53:15 +0000 Subject: [issue24335] Provide __list__(self) along the lines of __str__(self) Message-ID: <1433055195.26.0.479174159358.issue24335@psf.upfronthosting.co.za> New submission from Rohith PR: It would be cleaner to do list(obj) than obj.to_list() (Eg: in numpy). PS: this is the first time that I'm contributing to python. If this feature request is accepted can I work on it myself? ---------- messages: 244522 nosy: Rohith.PR priority: normal severity: normal status: open title: Provide __list__(self) along the lines of __str__(self) type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 09:49:28 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 31 May 2015 07:49:28 +0000 Subject: [issue22852] urllib.parse wrongly strips empty #fragment, ?query, //netloc In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za> Message-ID: <1433058568.31.0.951631716303.issue22852@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 09:55:38 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 07:55:38 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions Message-ID: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> New submission from Martin Panter: This patch allows many context managers to accept keyword arguments called ?func? and ?self?. Current behaviour: >>> with TestCase().subTest(func="blaua"): pass ... Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.4/contextlib.py", line 126, in helper return _GeneratorContextManager(func, *args, **kwds) TypeError: __init__() got multiple values for argument 'func' ---------- files: context-kw.patch keywords: patch messages: 244523 nosy: vadmium priority: normal severity: normal stage: patch review status: open title: Allow arbitrary keywords to @contextmanager functions type: behavior versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39571/context-kw.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 10:00:02 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 08:00:02 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1433059202.49.0.553422403076.issue24004@psf.upfronthosting.co.za> Martin Panter added the comment: Yury, your last change causes DeprecationWarning: [ 38/398] test_asyncio /media/disk/home/proj/python/cpython/Lib/test/test_asyncio/test_pep492.py:119: DeprecationWarning: Please use assertEqual instead. self.assertEquals(coro.send(None), 'spam') ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 10:03:53 2015 From: report at bugs.python.org (Ethan Furman) Date: Sun, 31 May 2015 08:03:53 +0000 Subject: [issue24335] Provide __list__(self) along the lines of __str__(self) In-Reply-To: <1433055195.26.0.479174159358.issue24335@psf.upfronthosting.co.za> Message-ID: <1433059433.83.0.11797908978.issue24335@psf.upfronthosting.co.za> Ethan Furman added the comment: If somebody wants their class to support being turned into a list, the obvious answer is to have that class support iteration, and there are already three ways to do that: - supply an __iter__ that returns a separate iterator - supply an __iter__/__next__ that makes instances of the class be their own iterators - supply a __getitem__ that works with ints (0, 1, 2, ...) to return the values. If numpy objects do not already support any of those three methods it probably means there isn't just one way to want to iterate through them, but you'll have to take that up with the numpy folks. In the future you should discuss enhancement ideas on the Python Ideas list first. Your contributions are welcome, but you'll need to sign the Contributors License Agreement first (found at https://www.python.org/psf/contrib/contrib-form/). If I have misunderstood what you intended, please provide more context and an example. ---------- nosy: +ethan.furman resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 10:05:22 2015 From: report at bugs.python.org (Ethan Furman) Date: Sun, 31 May 2015 08:05:22 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <1433059522.95.0.797869853946.issue24336@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 10:23:11 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 08:23:11 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <1433060591.25.0.70318686213.issue24336@psf.upfronthosting.co.za> Martin Panter added the comment: Sorry here?s a better version that adapts some monkey-patching in the test suite (test_with). ---------- Added file: http://bugs.python.org/file39572/context-kw.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 10:30:15 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 31 May 2015 08:30:15 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <1433061015.44.0.239580096211.issue24336@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> ncoghlan nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 10:39:20 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 31 May 2015 08:39:20 +0000 Subject: [issue24326] Audioop: weightB not divided by GCD, weightA divided twice In-Reply-To: <1432920005.51.0.0928225945144.issue24326@psf.upfronthosting.co.za> Message-ID: <1433061560.65.0.190159630379.issue24326@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: The changed test passes on 3.4 branch, but fails on 2.7 branch: $ python2.7 -m test.test_audioop test_add (__main__.TestAudioop) ... ok test_adpcm2lin (__main__.TestAudioop) ... ok test_alaw2lin (__main__.TestAudioop) ... ok test_avg (__main__.TestAudioop) ... ok test_avgpp (__main__.TestAudioop) ... ok test_bias (__main__.TestAudioop) ... ok test_cross (__main__.TestAudioop) ... ok test_findfactor (__main__.TestAudioop) ... ok test_findfit (__main__.TestAudioop) ... ok test_findmax (__main__.TestAudioop) ... ok test_getsample (__main__.TestAudioop) ... ok test_issue7673 (__main__.TestAudioop) ... ok test_lin2adpcm (__main__.TestAudioop) ... ok test_lin2alaw (__main__.TestAudioop) ... ok test_lin2lin (__main__.TestAudioop) ... ok test_lin2ulaw (__main__.TestAudioop) ... ok test_max (__main__.TestAudioop) ... ok test_maxpp (__main__.TestAudioop) ... ok test_minmax (__main__.TestAudioop) ... ok test_mul (__main__.TestAudioop) ... ok test_negativelen (__main__.TestAudioop) ... ok test_ratecv (__main__.TestAudioop) ... ERROR test_reverse (__main__.TestAudioop) ... ok test_rms (__main__.TestAudioop) ... ok test_tomono (__main__.TestAudioop) ... ok test_tostereo (__main__.TestAudioop) ... ok test_ulaw2lin (__main__.TestAudioop) ... ok test_wrongsize (__main__.TestAudioop) ... ok ====================================================================== ERROR: test_ratecv (__main__.TestAudioop) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib64/python2.7/test/test_audioop.py", line 304, in test_ratecv 3: packs[3](0, 0x0da740, 0x377776, -0x262fca, KeyError: 3 ---------------------------------------------------------------------- Ran 28 tests in 0.009s FAILED (errors=1) Traceback (most recent call last): File "/usr/lib64/python2.7/runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/lib64/python2.7/runpy.py", line 72, in _run_code exec code in run_globals File "/usr/lib64/python2.7/test/test_audioop.py", line 410, in test_main() File "/usr/lib64/python2.7/test/test_audioop.py", line 407, in test_main run_unittest(TestAudioop) File "/usr/lib64/python2.7/test/test_support.py", line 1400, in run_unittest _run_suite(suite) File "/usr/lib64/python2.7/test/test_support.py", line 1383, in _run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/usr/lib64/python2.7/test/test_audioop.py", line 304, in test_ratecv 3: packs[3](0, 0x0da740, 0x377776, -0x262fca, KeyError: 3 ---------- nosy: +Arfrever resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 10:57:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 08:57:31 +0000 Subject: [issue20014] Makes array.array constructor accepts ascii-unicode typecode In-Reply-To: <1387360195.98.0.786950742842.issue20014@psf.upfronthosting.co.za> Message-ID: <20150531085728.27664.55599@psf.io> Roundup Robot added the comment: New changeset 6ee122fac1e8 by Serhiy Storchaka in branch '2.7': Fixed the array module in unicode disabled build (regression of issue20014). https://hg.python.org/cpython/rev/6ee122fac1e8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 11:06:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 09:06:07 +0000 Subject: [issue24326] Audioop: weightB not divided by GCD, weightA divided twice In-Reply-To: <1432920005.51.0.0928225945144.issue24326@psf.upfronthosting.co.za> Message-ID: <20150531090604.4352.19009@psf.io> Roundup Robot added the comment: New changeset 7d6a6028b104 by Serhiy Storchaka in branch '2.7': Fixed test_audioop for issue #24326. https://hg.python.org/cpython/rev/7d6a6028b104 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 11:06:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 31 May 2015 09:06:49 +0000 Subject: [issue24326] Audioop: weightB not divided by GCD, weightA divided twice In-Reply-To: <1432920005.51.0.0928225945144.issue24326@psf.upfronthosting.co.za> Message-ID: <1433063209.6.0.685679541436.issue24326@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Arfrever. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 11:12:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 31 May 2015 09:12:52 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <1433063572.92.0.339009844374.issue24336@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Library (Lib) nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 12:38:14 2015 From: report at bugs.python.org (Ram Rachum) Date: Sun, 31 May 2015 10:38:14 +0000 Subject: [issue24337] Implement `http.client.HTTPMessage.__repr__` to make debugging easier Message-ID: <1433068694.84.0.410376118699.issue24337@psf.upfronthosting.co.za> Changes by Ram Rachum : ---------- components: Library (Lib) nosy: cool-RR priority: normal severity: normal status: open title: Implement `http.client.HTTPMessage.__repr__` to make debugging easier type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 12:45:47 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 10:45:47 +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: <1433069147.16.0.0822514900635.issue23684@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch changing the table entries to ?*scheme* argument?. Hopefully this is fairly obvious and doesn?t sound like it defaults to itself. I also made the descriptions of ?scheme? and ?allow_fragments? more specific, and added some unit tests, because there didn?t seem to be any exercising them. ---------- components: +Tests keywords: +patch stage: -> patch review type: -> behavior versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39573/urlparse-scheme.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 12:55:52 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 10:55:52 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <1433069752.7.0.460218504499.issue24336@psf.upfronthosting.co.za> Martin Panter added the comment: New version with simpler test; thanks Serhiy. Looking closer at the history, this actually seems to be a regression caused by revision e4ba097123f6 (Issue 11647). Python 2 is not affected. ---------- Added file: http://bugs.python.org/file39574/context-kw.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 13:00:01 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 11:00:01 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <1433070001.22.0.746256451653.issue24336@psf.upfronthosting.co.za> Martin Panter added the comment: But maybe it wouldn?t hurt adding the test case in test_contextlib to Python 2. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 13:01:36 2015 From: report at bugs.python.org (py.user) Date: Sun, 31 May 2015 11:01:36 +0000 Subject: [issue24338] In argparse adding wrong arguments makes malformed namespace Message-ID: <1433070096.48.0.744562806973.issue24338@psf.upfronthosting.co.za> New submission from py.user: >>> import argparse >>> >>> parser = argparse.ArgumentParser() >>> _ = parser.add_argument('foo bar') >>> _ = parser.add_argument('--x --y') >>> args = parser.parse_args(['abc']) >>> >>> args Namespace(foo bar='abc', x __y=None) >>> >>> 'foo bar' in dir(args) True >>> 'x __y' in dir(args) True >>> Passing wrong arguments silently makes a namespace which attributes are not accessible. ISTM, add_argument() should raise a ValueError exception. ---------- components: Library (Lib) messages: 244534 nosy: py.user priority: normal severity: normal status: open title: In argparse adding wrong arguments makes malformed namespace type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 13:09:56 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 31 May 2015 11:09:56 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1433070596.67.0.13224154515.issue16991@psf.upfronthosting.co.za> Stefan Krah added the comment: Opening again. I have too many questions. :) ---------- nosy: +skrah status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 13:10:59 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 11:10:59 +0000 Subject: [issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly parsed In-Reply-To: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za> Message-ID: <1433070659.69.0.229394846064.issue5054@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 13:13:17 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 11:13:17 +0000 Subject: [issue5053] http.client.HTTPMessage.getallmatchingheaders() always returns [] In-Reply-To: <1232897073.53.0.7443757693.issue5053@psf.upfronthosting.co.za> Message-ID: <1433070797.59.0.797759508102.issue5053@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- dependencies: +CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly parsed stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 13:23:29 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 31 May 2015 11:23:29 +0000 Subject: [issue24337] Implement `http.client.HTTPMessage.__repr__` to make debugging easier Message-ID: <1433071409.14.0.465304271938.issue24337@psf.upfronthosting.co.za> New submission from Martin Panter: HTTPMessage essentially has exactly the same functionality as email.message.Message. It has been suggested to replace it with an alias to the Message class; see Issue 5053. So perhaps it would be best to add __repr__() to the underlying Message class instead? What information do you think should be included? The whole tostring() value? Specific header fields, such as Content-Type? ---------- components: +email nosy: +barry, r.david.murray, vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 13:25:19 2015 From: report at bugs.python.org (Ram Rachum) Date: Sun, 31 May 2015 11:25:19 +0000 Subject: [issue24337] Implement `http.client.HTTPMessage.__repr__` to make debugging easier In-Reply-To: <1433071409.14.0.465304271938.issue24337@psf.upfronthosting.co.za> Message-ID: <1433071519.33.0.877158441631.issue24337@psf.upfronthosting.co.za> Ram Rachum added the comment: Regarding a unified `__repr__`: Sounds good. What I needed is to know whether there are any headers in there or not. So the number of headers, or the first 2-3, would have solved my problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 15:20:03 2015 From: report at bugs.python.org (John Helour) Date: Sun, 31 May 2015 13:20:03 +0000 Subject: [issue24339] iso6937 encoding missing Message-ID: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> New submission from John Helour: Please add encoding for the iso6937 charset. Many settopboxes (DVB-T/S) and relevant devices uses it for displaying EPG, videotext, etc. I've wrote (please look at the attached file) the encoding/decoding conversion codec some years ago. ---------- components: Library (Lib) files: iso6937.py messages: 244538 nosy: John Helour priority: normal severity: normal status: open title: iso6937 encoding missing type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file39575/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 16:26:53 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 31 May 2015 14:26:53 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <1433082413.8.0.968227894639.issue24336@psf.upfronthosting.co.za> Nick Coghlan added the comment: The v3 patch looks good to me, and indeed it's a regression I introduced back in 3.2. I don't see much value in adding the test to the 2.7 test suite (with contextlib2 just a pip install away, it's very unlikely the standard library version will see any significant updates) ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 16:31:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 31 May 2015 14:31:35 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1433082695.36.0.789363082836.issue24339@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New encoding can be added only in new Python release (3.6). ---------- nosy: +lemburg, loewis, serhiy.storchaka versions: +Python 3.6 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 16:38:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 31 May 2015 14:38:59 +0000 Subject: [issue24336] Allow arbitrary keywords to @contextmanager functions In-Reply-To: <1433058938.29.0.435645583396.issue24336@psf.upfronthosting.co.za> Message-ID: <1433083139.61.0.75417928741.issue24336@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. The patch isn't applied cleanly to 2.7. If you Martin will provide the patch with tests for 2.7, I don't see why not apply it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 16:51:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 31 May 2015 14:51:32 +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: <1433083892.69.0.662210765444.issue24338@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: They are accessible. >>> getattr(args, 'foo bar') 'abc' The limitation that argument names should be Python identifiers is too strong and adding it will break existing code (for example the use of such popular options as -0 or -@). ---------- nosy: +serhiy.storchaka resolution: -> rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 17:29:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 15:29:05 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <20150531152902.18159.65346@psf.io> Roundup Robot added the comment: New changeset 8296f0119f20 by Yury Selivanov in branch '3.5': Issue 24004: Fix DeprecationWarning in a unittest https://hg.python.org/cpython/rev/8296f0119f20 New changeset 60f5091cbfbf by Yury Selivanov in branch 'default': Issue 24004: Fix DeprecationWarning in a unittest https://hg.python.org/cpython/rev/60f5091cbfbf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 17:29:12 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 31 May 2015 15:29:12 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1433086152.93.0.795905916952.issue24004@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks, Martin! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 17:49:46 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 31 May 2015 15:49:46 +0000 Subject: [issue24323] Typo in Mutable Sequence Types documentation. In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za> Message-ID: <1433087386.16.0.801977016234.issue24323@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 18:49:53 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 31 May 2015 16:49:53 +0000 Subject: [issue24323] Typo in Mutable Sequence Types documentation. In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za> Message-ID: <1433090993.3.0.243753836951.issue24323@psf.upfronthosting.co.za> Raymond Hettinger added the comment: There isn't much defense against an overly literal reading of the docs. Both ``s.pop([i])`` and ``s.pop(i=-1)`` fail (the latter because pop doesn't take key word arguments and the docstring calls it "index". Also, you would have to define *s* and *i*. FWIW, there is already a note to the effect, "The optional argument i defaults to -1, so that by default the last item is removed and returned." The [optional_arg] notation is used in a number of places in the docs and docstrings. It is also common with other languages as well and it is used in third-party Python references as well. Eric's initial suggestion of ``s.pop(i)`` is simply wrong and would make the docs worse. As a starting point, realize that the docs have worked well for a lot of people for a long time so there should be a reluctance to change them on a single misreading. The tutorial also includes the same notation, (see https://docs.python.org/3/tutorial/datastructures.html#more-on-lists ) and as far as I can tell, this has never been an issue. One other thought, the most common way to call pop() is without an argument (usually, if you use an argument, it is a performance bug). We want to make sure the docs don't suggest otherwise. Unless there is some strong objection, I recommend leaving the docs as-is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 19:04:33 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 31 May 2015 17:04:33 +0000 Subject: [issue24323] Typo in Mutable Sequence Types documentation. In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za> Message-ID: <1433091873.82.0.384025600568.issue24323@psf.upfronthosting.co.za> Eric V. Smith added the comment: I don't feel particularly strongly about it. It's mildly more confusing in the 3.x docs than 2.7 because it's the only use in that section of an optional argument. I disagree that s.pop(i) is wrong, since it agrees with the "Results" column. But I agree it's not an improvement and we shouldn't encourage it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 19:21:40 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 17:21:40 +0000 Subject: [issue19619] Blacklist base64, hex, ... codecs from bytes.decode() and str.encode() In-Reply-To: <1384562829.72.0.617857672471.issue19619@psf.upfronthosting.co.za> Message-ID: <20150531172137.111612.87384@psf.io> Roundup Robot added the comment: New changeset cf6e782a7f94 by Serhiy Storchaka in branch '2.7': Issue #19543: Emit deprecation warning for known non-text encodings. https://hg.python.org/cpython/rev/cf6e782a7f94 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 19:21:40 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 17:21:40 +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: <20150531172137.111612.12868@psf.io> Roundup Robot added the comment: New changeset cf6e782a7f94 by Serhiy Storchaka in branch '2.7': Issue #19543: Emit deprecation warning for known non-text encodings. https://hg.python.org/cpython/rev/cf6e782a7f94 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 19:21:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 17:21:42 +0000 Subject: [issue20404] Delayed exception using non-text encodings with TextIOWrapper In-Reply-To: <1390798876.83.0.936873438895.issue20404@psf.upfronthosting.co.za> Message-ID: <20150531172137.111612.28625@psf.io> Roundup Robot added the comment: New changeset cf6e782a7f94 by Serhiy Storchaka in branch '2.7': Issue #19543: Emit deprecation warning for known non-text encodings. https://hg.python.org/cpython/rev/cf6e782a7f94 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 19:23:55 2015 From: report at bugs.python.org (Marc Jofre) Date: Sun, 31 May 2015 17:23:55 +0000 Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za> Message-ID: <1433093035.83.0.165977414779.issue24291@psf.upfronthosting.co.za> Marc Jofre added the comment: Hi all, I did more tests, identifying that the main issue I have resides in another script (multiprocessing), when using nuitka compiler. I will get back to you with more info when I solve the multiprocessing issue. The command prompt dump is: data: HTTP/1.0 200 OK self.stdout: data: HTTP/1.0 200 OK self.stdout: data: HTTP/1.0 200 OK self.stdout: data: HTTP/1.0 200 OK self.stdout: data: HTTP/1.0 200 OK self.stdout: data: HTTP/1.0 200 OK self.stdout: data: HTTP/1.0 200 OK self.stdout: data: HTTP/1.0 200 OK self.stdout: data: HTTP/1.0 200 OK self.stdout: data: HTTP/1.0 200 OK self.stdout: data: HTTP/1.0 200 OK self.stdout: data: HTTP/1.0 200 OK self.stdout: data: HTTP/1.0 500 INTERNAL SERVER ERROR self.stdout: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 19:59:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 31 May 2015 17:59:54 +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: <1433095194.7.0.432498580352.issue19543@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed patch covers a large part of this issue, but not all. Following patch emits py3k warning for unicode.decode(). For now unicode(u'a', 'ascii') is forbidden, but u'a'.decode('ascii') is allowed in 2.7. The risk of false positive in this patch is lower than in emitting warning on str.encode(), but is larger than in just committed patch. ---------- Added file: http://bugs.python.org/file39576/issue19543_unicode_decode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 20:29:54 2015 From: report at bugs.python.org (Armin Rigo) Date: Sun, 31 May 2015 18:29:54 +0000 Subject: [issue24340] co_stacksize estimate can be highly off Message-ID: <1433096994.94.0.20833461119.issue24340@psf.upfronthosting.co.za> New submission from Armin Rigo: The computation of `co_stacksize' by the compiler is known to give only an upper bound estimate. http://bugs.python.org/issue1754094 is an example of fixing a "leak" where every repetition of a statement makes `co_stacksize' bigger by 1. However, in the whole 3.x series (from at least 3.2), the following simple code, which at runtime requires about 4 or 5 stack slots, leaks 14(!) slots for every `try:' block. Maybe this should be improved to reduce the extreme size of the leak. def g(): try: pass except ImportError as e: pass try: pass except ImportError as e: pass try: pass except ImportError as e: pass ... i.e. any function that is big enough to contain 6 try: blocks in sequence will have its stack size overestimated by about 70. ---------- components: Interpreter Core messages: 244552 nosy: arigo priority: normal severity: normal status: open title: co_stacksize estimate can be highly off _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 20:51:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 31 May 2015 18:51:30 +0000 Subject: [issue24341] Test suite emits many DeprecationWarnings about sys.exc_clear() when -3 is enabled Message-ID: <1433098290.5.0.721765999777.issue24341@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -3 -We -bb -m test.regrtest -uall -W test___all__ test_threading [1/2] test___all__ [2/2] test_threading Unhandled exception in thread started by > Traceback (most recent call last): File "/home/serhiy/py/cpython2.7/Lib/threading.py", line 783, in __bootstrap self.__bootstrap_inner() File "/home/serhiy/py/cpython2.7/Lib/threading.py", line 855, in __bootstrap_inner Unhandled exception in thread started by > Traceback (most recent call last): self.__exc_clear() DeprecationWarning: sys.exc_clear() not supported in 3.x; use except clauses File "/home/serhiy/py/cpython2.7/Lib/threading.py", line 783, in __bootstrap Unhandled exception in thread started by > Traceback (most recent call last): File "/home/serhiy/py/cpython2.7/Lib/threading.py", line 783, in __bootstrap self.__bootstrap_inner() File "/home/serhiy/py/cpython2.7/Lib/threading.py", line 855, in __bootstrap_inner self.__bootstrap_inner() self.__exc_clear() DeprecationWarning: sys.exc_clear() not supported in 3.x; use except clauses File "/home/serhiy/py/cpython2.7/Lib/threading.py", line 855, in __bootstrap_inner Unhandled exception in thread started by > ---------- components: Tests messages: 244553 nosy: amaury.forgeotdarc, jyasskin, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Test suite emits many DeprecationWarnings about sys.exc_clear() when -3 is enabled type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 21:05:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 19:05:33 +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: <20150531190530.24069.11650@psf.io> Roundup Robot added the comment: New changeset 0347f6e14ad6 by Tal Einat in branch '3.5': Issue #19543: Implementation of isclose as per PEP 485 https://hg.python.org/cpython/rev/0347f6e14ad6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 21:16:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 19:16:37 +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: <20150531191634.111614.35305@psf.io> Roundup Robot added the comment: New changeset 5c8c123943cf by Tal Einat in branch 'default': Issue #19543: Implementation of isclose as per PEP 485 https://hg.python.org/cpython/rev/5c8c123943cf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 21:23:18 2015 From: report at bugs.python.org (Tal Einat) Date: Sun, 31 May 2015 19:23:18 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1433100198.69.0.46314812475.issue24270@psf.upfronthosting.co.za> Tal Einat added the comment: I've just committed this into 3.5 and 3.6. (I accidentally included the wrong issue number in the commit message, so the bot hasn't posted here about it. Sorry!) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 21:55:54 2015 From: report at bugs.python.org (Christopher Barker) Date: Sun, 31 May 2015 19:55:54 +0000 Subject: [issue24270] PEP 485 (math.isclose) implementation In-Reply-To: <1432387083.17.0.326791152965.issue24270@psf.upfronthosting.co.za> Message-ID: <1433102154.11.0.442276409705.issue24270@psf.upfronthosting.co.za> Christopher Barker added the comment: I wrote: """I will update the PEP to indicate that it is float-only, or complex for the cmath implementation (thanks, Tal!).""" Done: https://github.com/PythonCHB/close_pep/blob/master/pep-0485.txt Hopefully pushed to the official PEP repo soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 22:31:37 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 31 May 2015 20:31:37 +0000 Subject: [issue24293] Windows installer unreadable with std/custom themes In-Reply-To: <1432684740.9.0.578796945246.issue24293@psf.upfronthosting.co.za> Message-ID: <1433104297.42.0.00988610114897.issue24293@psf.upfronthosting.co.za> Steve Dower added the comment: Reopening this because the lack of a background colour means that the progress text accumulates while installed. I'll get to this sooner or later, but b2 is probably going to have this issue. ---------- resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 22:51:18 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 31 May 2015 20:51:18 +0000 Subject: [issue24340] co_stacksize estimate can be highly off In-Reply-To: <1433096994.94.0.20833461119.issue24340@psf.upfronthosting.co.za> Message-ID: <1433105478.55.0.224833776465.issue24340@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 23:13:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 21:13:42 +0000 Subject: [issue24180] PEP 492: Documentation In-Reply-To: <1432188222.61.0.941907273276.issue24180@psf.upfronthosting.co.za> Message-ID: <20150531211339.18173.23220@psf.io> Roundup Robot added the comment: New changeset 3eb817e19090 by Yury Selivanov in branch '3.5': Issue 24180: Document sys.(set|get)_coroutine_wrapper https://hg.python.org/cpython/rev/3eb817e19090 New changeset ca489c50fbd1 by Yury Selivanov in branch 'default': Issue 24180: Document sys.(set|get)_coroutine_wrapper https://hg.python.org/cpython/rev/ca489c50fbd1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 31 23:21:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 31 May 2015 21:21:56 +0000 Subject: [issue24180] PEP 492: Documentation In-Reply-To: <1432188222.61.0.941907273276.issue24180@psf.upfronthosting.co.za> Message-ID: <20150531212153.91791.36108@psf.io> Roundup Robot added the comment: New changeset 8a185bb62a25 by Yury Selivanov in branch '3.5': Issue 24180: Mention sys.(get|set)_coroutine_wrapper in whatsnew https://hg.python.org/cpython/rev/8a185bb62a25 New changeset 10f92b4d55ed by Yury Selivanov in branch 'default': Issue 24180: Mention sys.(get|set)_coroutine_wrapper in whatsnew https://hg.python.org/cpython/rev/10f92b4d55ed ---------- _______________________________________ Python tracker _______________________________________