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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24088>
_______________________________________

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: [New-bugs-announce] [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 <module>
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24089>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24090>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24091>
_______________________________________

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: [New-bugs-announce] [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 <PyList_Type>}, 
#     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 <report at bugs.python.org>
<http://bugs.python.org/issue24092>
_______________________________________

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: [New-bugs-announce] [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=<unknown at remote 0x405743ec>) at Objects/object.c:203
# #5  0x4063dfa6 in element_remove (self=0x40583c34, args=(<xml.etree.ElementTree.Element at remote 0x40583bb4>,))
#     at /home/p/Python-3.4.1/Modules/_elementtree.c:1436
# (gdb) frame 5
# #5  0x4063dfa6 in element_remove (self=0x40583c34, args=(<xml.etree.ElementTree.Element at remote 0x40583bb4>,))
#     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 <report at bugs.python.org>
<http://bugs.python.org/issue24093>
_______________________________________

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: [New-bugs-announce] [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=<D at remote 0x405c8b34>, 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 <PyList_Type>}
# (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 <PyLong_Type>) at Objects/typeobject.c:1292
# 1292        mro = a->tp_mro;
# (gdb) bt
# #0  0x08108825 in PyType_IsSubtype (a=0xdbdbdbdb, b=0x830f1a0 <PyLong_Type>) at Objects/typeobject.c:1292
# #1  0x080f22d6 in do_richcompare (v=1337, w=<unknown at remote 0x4059006c>, op=2) at Objects/object.c:643
# #2  0x080f263d in PyObject_RichCompare (v=1337, w=<unknown at remote 0x4059006c>, op=2) at Objects/object.c:701
# #3  0x080f26ce in PyObject_RichCompareBool (v=1337, w=<unknown at remote 0x4059006c>, op=2) at Objects/object.c:723
# #4  0x080df7b5 in lookdict (mp=0x405c8b34, key=<unknown at remote 0x4059006c>, hash=1337, value_addr=0xbfc40200)
#     at Objects/dictobject.c:485
# #5  0x080e145d in PyDict_GetItem (op=<D at remote 0x405c8b34>, key=<unknown at remote 0x4059006c>) at Objects/dictobject.c:1095
# #6  0x405bf6f9 in encoder_listencode_dict (s=0x405b23fc, acc=0xbfc4038c, dct=<D at remote 0x405c8b34>, 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 <report at bugs.python.org>
<http://bugs.python.org/issue24094>
_______________________________________

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: [New-bugs-announce] [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=<D at remote 0x405c8af4>, 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 <PyLong_Type>}
# (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 <report at bugs.python.org>
<http://bugs.python.org/issue24095>
_______________________________________

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: [New-bugs-announce] [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=<D at remote 0x405b2fb4>, 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 <PyList_Type>}, 
#     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 <report at bugs.python.org>
<http://bugs.python.org/issue24096>
_______________________________________

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: [New-bugs-announce] [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=<unknown at remote 0x405720e4>) at Objects/object.c:746
# 746         if (tp->tp_hash != NULL)
# (gdb) bt
# #0  0x080f27b2 in PyObject_Hash (v=<unknown at remote 0x405720e4>) at Objects/object.c:746
# #1  0x080e1717 in PyDict_SetItem (op={}, key=<unknown at remote 0x405720e4>, value=None) at Objects/dictobject.c:1201
# #2  0x0810e8a0 in _PyObject_GetState (obj=<Y at remote 0x405731bc>) at Objects/typeobject.c:3657
# #3  0x081100e9 in reduce_2 (obj=<Y at remote 0x405731bc>) at Objects/typeobject.c:3949
# #4  0x08110551 in _common_reduce (self=<Y at remote 0x405731bc>, proto=2) at Objects/typeobject.c:4012
# #5  0x08110641 in object_reduce (self=<Y at remote 0x405731bc>, args=(2,)) at Objects/typeobject.c:4032
# 
# (gdb) frame 2
# #2  0x0810e8a0 in _PyObject_GetState (obj=<Y at remote 0x405731bc>) 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 <report at bugs.python.org>
<http://bugs.python.org/issue24097>
_______________________________________

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: [New-bugs-announce] [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 <PyList_Type>}, 
#     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 <PyList_Type>}, 
#     ob_size = 1}, ob_item = 0x8491ae0, allocated = 4}
# (gdb) c
# Continuing.
# 
# Program received signal SIGSEGV, Segmentation fault.
# 0x080f2c17 in PyObject_GetAttr (v=<unknown at remote 0x405733b4>, 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 <report at bugs.python.org>
<http://bugs.python.org/issue24098>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24099>
_______________________________________

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: [New-bugs-announce] [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 <PyList_Type>}, 
#       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 <report at bugs.python.org>
<http://bugs.python.org/issue24100>
_______________________________________

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: [New-bugs-announce] [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 <refchain>, 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 <PyList_Type>}, 
#       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 <report at bugs.python.org>
<http://bugs.python.org/issue24101>
_______________________________________

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: [New-bugs-announce] [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=<X at remote 0x405730e4>, end=0xbf9e8f7c) at Objects/exceptions.c:1643
# 1643        PyObject *obj = get_unicode(((PyUnicodeErrorObject *)exc)->object,
# (gdb) s
# get_unicode (attr=<unknown at remote 0x8c6a120>, 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=<unknown at remote 0x8cbe250>, 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 <report at bugs.python.org>
<http://bugs.python.org/issue24102>
_______________________________________

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: [New-bugs-announce] [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 <PyList_Type>}, 
#     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 <report at bugs.python.org>
<http://bugs.python.org/issue24103>
_______________________________________

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: [New-bugs-announce] [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=([], [<S2 at remote 0x4064b0e4>]))
#     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 <report at bugs.python.org>
<http://bugs.python.org/issue24104>
_______________________________________

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: [New-bugs-announce] [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=<D at remote 0x405b2fb4>, 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 <PyList_Type>}, 
#     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 <report at bugs.python.org>
<http://bugs.python.org/issue24105>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24106>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24107>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24108>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24109>
_______________________________________

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: [New-bugs-announce] [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 "<stdin>", line 1, in <module>
  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 <report at bugs.python.org>
<http://bugs.python.org/issue24110>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24111>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24112>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24113>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24114>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24115>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24116>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24117>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24118>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24119>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24120>
_______________________________________

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: [New-bugs-announce] [issue24121] collections page doesn't
Message-ID: <1430679494.03.0.839245374833.issue24121@psf.upfronthosting.co.za>


Changes by lf <thereallucasfink at gmail.com>:


----------
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 <report at bugs.python.org>
<http://bugs.python.org/issue24121>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24122>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24123>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24124>
_______________________________________

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: [New-bugs-announce] [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: <http://mitya57.me/builds/python-docutils_0.12+dfsg-1_amd64.build>.

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 <report at bugs.python.org>
<http://bugs.python.org/issue24125>
_______________________________________

From report at bugs.python.org  Tue May  5 11:21:48 2015
From: report at bugs.python.org (Davide Mancusi)
Date: Tue, 05 May 2015 09:21:48 +0000
Subject: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24126>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24127>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24128>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24129>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24130>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24131>
_______________________________________

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: [New-bugs-announce] [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 <module>
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24132>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24133>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24134>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24135>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24136>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24137>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24138>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24139>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24140>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24141>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24142>
_______________________________________

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: [New-bugs-announce] [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 <krichter722 at aol.de>:


----------
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 <report at bugs.python.org>
<http://bugs.python.org/issue24143>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24144>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24145>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24146>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24147>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24148>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24149>
_______________________________________

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: [New-bugs-announce] [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 <module>
  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 <module>
    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: <module 'threading' from '/Users/rainierharvey/Documents/cs/openSource/cpython/Lib/threading.py'>
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 <report at bugs.python.org>
<http://bugs.python.org/issue24150>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24151>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24152>
_______________________________________

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: [New-bugs-announce] [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: {<Process(Process-236, started daemon)>}
Dangling threads: {<Thread(QueueFeederThread, started daemon 139869752682240)>}
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 <module>
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24153>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24154>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24155>
_______________________________________

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: [New-bugs-announce] [issue24156] unit test
Message-ID: <1431255846.39.0.865425621117.issue24156@psf.upfronthosting.co.za>


Changes by Roman Rader <antigluk at gmail.com>:


----------
nosy: Roman.Rader
priority: normal
severity: normal
status: open
title: unit test

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24156>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24157>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24158>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24159>
_______________________________________

From report at bugs.python.org  Sun May 10 18:30:16 2015
From: report at bugs.python.org (ppperry)
Date: Sun, 10 May 2015 16:30:16 +0000
Subject: [New-bugs-announce] [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)")
> <string>(1)<module>()
(Pdb) s
--Call--
> c:\documents and settings\perry\desktop\coding_projects\python\test3.py(1)<module>()
-> 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)<module>()
-> bar = 7788
(Pdb) c
>>> pdb.run("reload(test3)")
> <string>(1)<module>()
(Pdb) s
--Call--
> c:\documents and settings\perry\desktop\coding_projects\python\test3.py(1)<module>()
-> 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 "<pyshell#592>", line 1, in <module>
    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 "<string>", line 1, in <module>
  File "test3.py", line 1, in <module>
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24160>
_______________________________________

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: [New-bugs-announce] [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)
    <type 'instance'>
    >>> 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 <report at bugs.python.org>
<http://bugs.python.org/issue24161>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24162>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24163>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24166>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24167>
_______________________________________

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: [New-bugs-announce] [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 <module>
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24168>
_______________________________________

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: [New-bugs-announce] [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) )
<socket.socket object, fd=408, family=2, type=1, proto=0>

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 <report at bugs.python.org>
<http://bugs.python.org/issue24169>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24170>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24171>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24172>
_______________________________________

From report at bugs.python.org  Wed May 13 10:42:09 2015
From: report at bugs.python.org (White_Rabbit)
Date: Wed, 13 May 2015 08:42:09 +0000
Subject: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24173>
_______________________________________

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: [New-bugs-announce] [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 <main_arena>, p=<optimized out>, 
    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 <main_arena>, 
    p=<optimized out>, 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=<optimized out>) at ../Objects/dictobject.c:1282
#6  0x000000000045c102 in PyDict_Clear (op=<optimized out>)
    at ../Objects/dictobject.c:1260
#7  0x000000000047b8d8 in type_clear (type=0xb46f28) at ../Objects/typeobject.c:3228
#8  0x000000000052bb3a in delete_garbage (old=<optimized out>, 
    collectable=<optimized out>) 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=<optimized out>) at ../Python/pythonrun.c:1822
#18 0x00000000005123cf in PyErr_Print () at ../Python/pythonrun.c:1718
#19 PyRun_SimpleFileExFlags (fp=0x7ffff6e65620 <main_arena>, 
    filename=0xffffffff <error: Cannot access memory at address 0xffffffff>, 
    closeit=1, flags=0xffff800008d504d0) at ../Python/pythonrun.c:1611
#20 0x0000000000422cbc in run_file (p_cf=<optimized out>, filename=<optimized out>, 
    fp=<optimized out>) at ../Modules/main.c:319
#21 Py_Main (argc=-157933448, argv=0x7ffff6a24180) at ../Modules/main.c:751
#22 0x000000000041f06c in main (argc=2, argv=<optimized out>)
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24174>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24175>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24176>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24177>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24178>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24179>
_______________________________________

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: [New-bugs-announce] [issue24180] PEP 492: Documentation
Message-ID: <1431546447.0.0.742432302216.issue24180@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
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 <report at bugs.python.org>
<http://bugs.python.org/issue24180>
_______________________________________

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: [New-bugs-announce] [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 <module>
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24181>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24182>
_______________________________________

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: [New-bugs-announce] [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 <module>
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24183>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24184>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24185>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24186>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24187>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24188>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24189>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24190>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24191>
_______________________________________

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: [New-bugs-announce] [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 <module>
    import package.mod
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load
  File "<frozen importlib._bootstrap>", line 947, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 657, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 575, in module_from_spec
  File "<frozen importlib._bootstrap>", 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 <report at bugs.python.org>
<http://bugs.python.org/issue24192>
_______________________________________

From report at bugs.python.org  Thu May 14 14:03:49 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 14 May 2015 12:03:49 +0000
Subject: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24193>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24194>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24195>
_______________________________________

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: [New-bugs-announce] [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 "<pyshell#80>", line 1, in <module>
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24196>
_______________________________________

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: [New-bugs-announce] [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 = """<html>
  <body>
    <!-- <img src="/images/obraz--super.jpg"/> -->
  </body>
</html>"""


minidom.parseString(html)


Result:
Traceback (most recent call last):
  File "minidom.py", line 10, in <module>
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24197>
_______________________________________

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: [New-bugs-announce] [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 <base cpu>-<os>-<abi>.  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 <base cpu>-<os>
 - 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 <os>.

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 <report at bugs.python.org>
<http://bugs.python.org/issue24198>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24199>
_______________________________________

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: [New-bugs-announce] [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)
<Signature at 0xb6e2768c "(a, *, b=10)">

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 <report at bugs.python.org>
<http://bugs.python.org/issue24200>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24201>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24202>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24203>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24204>
_______________________________________

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: [New-bugs-announce] [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 "<stdin>", line 1, in <module>
    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 "<stdin>", line 1, in <module>
      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 "<stdin>", line 1, in <module>
    TypeError: foo() missing 1 required positional argument: 'anarg'

While bind gives:

    >>> sig.bind(1, 2)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      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 <report at bugs.python.org>
<http://bugs.python.org/issue24205>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24206>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24207>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24208>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24209>
_______________________________________

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: [New-bugs-announce] [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 <module>
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24210>
_______________________________________

From report at bugs.python.org  Sat May 16 23:19:09 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 May 2015 21:19:09 +0000
Subject: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24211>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24212>
_______________________________________

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: [New-bugs-announce] [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 <module>
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24213>
_______________________________________

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: [New-bugs-announce] [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 "<stdin>", line 2, in <module>
  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 <report at bugs.python.org>
<http://bugs.python.org/issue24214>
_______________________________________

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: [New-bugs-announce] [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 "<string>", line 1, in <module>
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 "<string>", line 1, in <module>
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 <report at bugs.python.org>
<http://bugs.python.org/issue24215>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24216>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24217>
_______________________________________

From report at bugs.python.org  Sun May 17 18:21:59 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 17 May 2015 16:21:59 +0000
Subject: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24218>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24219>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24220>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24221>
_______________________________________

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: [New-bugs-announce] [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 "<pyshell#0>", 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 <report at bugs.python.org>
<http://bugs.python.org/issue24222>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24223>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24224>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24226>
_______________________________________

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: [New-bugs-announce] [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 "<string>", line 1, in <module>
  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 <report at bugs.python.org>
<http://bugs.python.org/issue24227>
_______________________________________

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: [New-bugs-announce] [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:
<https://support.codesourcery.com/GNUToolchain/>.
..
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=<value optimized out>, 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 <report at bugs.python.org>
<http://bugs.python.org/issue24228>
_______________________________________

From report at bugs.python.org  Mon May 18 18:35:13 2015
From: report at bugs.python.org (Josh Holland)
Date: Mon, 18 May 2015 16:35:13 +0000
Subject: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24229>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24230>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24231>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24232>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24233>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24234>
_______________________________________

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: [New-bugs-announce] [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 "<stdin>", line 1, in <module>
TypeError: Can't instantiate abstract class B with abstract methods foo
>>> class C(A, type): pass
... 
>>> class c(metaclass=C): pass
... 
>>> C('', (), {})
<class '__main__.'>
>>>

----------
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 <report at bugs.python.org>
<http://bugs.python.org/issue24235>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24236>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24237>
_______________________________________

From report at bugs.python.org  Tue May 19 13:17:59 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 May 2015 11:17:59 +0000
Subject: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24238>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24239>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24240>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24241>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24242>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24243>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24244>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24245>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24246>
_______________________________________

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: [New-bugs-announce] [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 <module>
    import pdb
  File "/usr/lib/python2.7/pdb.py", line 59, in <module>
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24247>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24248>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24249>
_______________________________________

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: [New-bugs-announce] [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(<string>, ""), I found three instances which could be re-written as *<string> = '\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 <report at bugs.python.org>
<http://bugs.python.org/issue24250>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24251>
_______________________________________

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: [New-bugs-announce] [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 "<pyshell#14>", line 1, in <module>
    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 "<string>", line 1, in <module>
  File "test3.py", line 1, in <module>
    [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 "<pyshell#592>", line 1, in <module>
    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 "<string>", line 1, in <module>
  File "test3.py", line 1, in <module>
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24252>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24253>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24254>
_______________________________________

From report at bugs.python.org  Thu May 21 08:25:54 2015
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 21 May 2015 06:25:54 +0000
Subject: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24255>
_______________________________________

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: [New-bugs-announce] [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
<function Timer at 0x7f99cae23848>

----------
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 <report at bugs.python.org>
<http://bugs.python.org/issue24256>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24257>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24258>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24259>
_______________________________________

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: [New-bugs-announce] [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":

<tab><8 spaces>
<8 spaces><tab>

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 <report at bugs.python.org>
<http://bugs.python.org/issue24260>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24261>
_______________________________________

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: [New-bugs-announce] [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 <stdin>, line 3
Traceback (most recent call last):
  File "<stdin>", line 6, in <module>
  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 <report at bugs.python.org>
<http://bugs.python.org/issue24262>
_______________________________________

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: [New-bugs-announce] [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 <ihcaoe at gmail.com>:


----------
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 <report at bugs.python.org>
<http://bugs.python.org/issue24263>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24264>
_______________________________________

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: [New-bugs-announce] [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 <module>
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24265>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24266>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24267>
_______________________________________

From report at bugs.python.org  Sat May 23 09:53:42 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Sat, 23 May 2015 07:53:42 +0000
Subject: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24268>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24269>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24270>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24271>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24272>
_______________________________________

From report at bugs.python.org  Sun May 24 04:36:12 2015
From: report at bugs.python.org (Jacob)
Date: Sun, 24 May 2015 02:36:12 +0000
Subject: [New-bugs-announce] [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) <F3E86789-301E-3857-AD2B-06D0EC027377> /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) <C3BECD10-1B84-3136-8BDD-3741ECA45B67> /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) <EE481CDA-4762-3245-89D3-F5EBC8C5818E> /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) <DDA3275D-3F76-3DE5-A300-01D27FAA6676> /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) <E3A72D4D-CC10-33BD-8540-6207BDCAC4F1> /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
       0x1009ee000 -        0x100b5e47f +libcrypto.1.0.0.dylib (0) <E670BEBD-393C-3E43-8D3D-2244A2799727> /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) <BD658403-190F-36A7-82FF-F28405B0D144> /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) <E2FE7A2A-9870-36A6-9B30-163414B662EE> /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) <B3E54060-EDAC-3842-B65A-987168573EBC> /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) <ED99FBAA-E336-3BB6-810E-60206797ECBE> /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) <EDB26E4B-DF8D-3E43-A0AD-90C066E82896> /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) <FC68D05B-9326-31E0-903D-C952478C9B08> /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) <BCF5C2EA-E058-33B5-811A-5816733EF3D2> /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) <ABED5651-61C7-30E5-BBFB-303AEA98DAD3> /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) <D6939B55-F83C-30B8-9F16-27B46F693E8E> /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) <AE62A92E-EDA7-37AD-8AF0-7912E9381A1F> /System/Library/PrivateFrameworks/AppleVPA.framework/Versions/A/AppleVPA
    0x7fff80caa000 -     0x7fff80f79ff3  com.apple.CoreImage (10.3.4) <C1AE8252-A95D-3BF4-83B8-BE85E979F2CB> /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) <F0FF3A5D-C5B7-34A1-9319-DE1EF928E58E> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
    0x7fff82087000 -     0x7fff8209dff7  libsystem_asl.dylib (267) <F153AC5B-0542-356E-88C8-20A62CA704E2> /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) <E83DFE3B-6541-3736-96BB-26DC5D0100F1> /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) <A67CE7D7-AAE4-3AC0-86B7-EAF403853D09> /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) <C69DA8A7-B536-34BF-A93F-1C170E2C6D58> /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) <E805398D-9A92-31F8-8005-8DC188BD8B6E> /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) <AED1143F-B848-3E73-81ED-71356F25F084> /usr/lib/libxslt.1.dylib
    0x7fff83acb000 -     0x7fff83acffff  com.apple.CommonPanels (1.2.6 - 96) <F9ECC8AF-D9CA-3350-AFB4-5113A9B789A5> /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) <A260789B-D4D8-316A-9490-254767B8A5F1> /usr/lib/libauto.dylib
    0x7fff83b20000 -     0x7fff83b25ff7  libunwind.dylib (35.3) <BE7E51A0-B6EA-3A54-9CCA-9D88F683A6D6> /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) <B214D528-7D1C-39B2-BE36-821D417A0297> /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) <A7B6447A-6680-3625-83C3-993B58D5C43F> /usr/lib/libheimdal-asn1.dylib
    0x7fff8500e000 -     0x7fff85036fff  libxpc.dylib (559.20.9) <D35D0DB2-D7BD-3BE4-8378-062BFE545E1D> /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) <CCEC13A5-D0D9-31C5-B0B0-1C564B4A20A6> /usr/lib/libSystem.B.dylib
    0x7fff85265000 -     0x7fff85aa1fe3  com.apple.CoreGraphics (1.600.0 - 779.11) <DC15AADD-387C-348E-84F0-1C8BAAB1B567> /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) <BF8FC133-EE10-3DA6-9B90-92039E28678F> /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) <EAC0EA1E-3C62-3B28-A941-5D8B1E085FF8> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
    0x7fff863cf000 -     0x7fff863ecfff  libsystem_kernel.dylib (2782.20.48) <EAFD7BD0-0C30-3E7D-9528-F9916BA0167C> /usr/lib/system/libsystem_kernel.dylib
    0x7fff863ed000 -     0x7fff86463fe7  libcorecrypto.dylib (233.1.2) <E1789801-3985-3949-B736-6B3378873301> /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) <ACA61D8F-9535-3141-8FDD-AC3EF6BF0806> /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) <E5335492-7EFE-31EA-BE72-4A9CEE68D58E> /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) <F9201AE7-B031-36DB-BCF8-971E994EF7C1> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
    0x7fff87646000 -     0x7fff87647fff  liblangid.dylib (117) <B54A4AA0-2E53-3671-90F5-AFF711C0EB9E> /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) <C9A62691-B0D9-34B7-B71C-A48B5F4DC553> /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) <D45790B0-E1A3-3C7D-8BA2-AB71D2CFA7FB> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
    0x7fff898af000 -     0x7fff898c6ff7  libLinearAlgebra.dylib (1128) <E78CCBAA-A999-3B65-8EC9-06DB15E67C37> /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) <A37BAF76-C262-3292-B82D-F004CAC5F333> /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) <C3B823AA-C261-37D3-B4AC-C59CE91C8241> /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) <DF56A657-CC6E-3BE2-86A0-71F07127724C> /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) <ACA93FE0-A0E3-333E-AE3C-8EB7DE5F362F> /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling
    0x7fff8adf0000 -     0x7fff8adfbfff  libGL.dylib (11.1.2) <BF99CC65-215A-3C7D-87D7-3F7EE6E9B3DD> /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) <E0605012-0DDB-3150-8FD0-699376FA3CD0> /usr/lib/libOpenScriptingUtil.dylib
    0x7fff8b939000 -     0x7fff8b985ff7  libcups.2.dylib (408.2) <E8AD18F9-61E4-3791-B840-504468C25556> /usr/lib/libcups.2.dylib
    0x7fff8ba72000 -     0x7fff8ba72ff7  liblaunch.dylib (559.20.9) <FA89A113-696E-3271-8FE1-A0D7324E8481> /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) <F5652650-87ED-3D53-9E59-A897DFA41DD0> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
    0x7fff8be5a000 -     0x7fff8be65fff  libcommonCrypto.dylib (60061) <D381EBC6-69D8-31D3-8084-5A80A32CB748> /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) <D64571B1-4483-3FE2-BD67-A91360F79727> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
    0x7fff8c074000 -     0x7fff8c09cfff  libsystem_info.dylib (459.20.1) <AEB3FE62-4763-3050-8352-D6F9AF961AE6> /usr/lib/system/libsystem_info.dylib
    0x7fff8c0d9000 -     0x7fff8c1e8ff3  com.apple.desktopservices (1.9.3 - 1.9.3) <FEE11342-5BC4-37A7-8169-DA48BE17B9C9> /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) <A1120885-F31B-3C13-9B0D-2589F391CC7A> /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) <DAAD7013-A19D-3858-BFF7-DE1DAF664401> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport
    0x7fff8c357000 -     0x7fff8c37bff7  com.apple.Sharing (328.16 - 328.16) <F96C7040-5FAF-3BC6-AE1E-5BF9CBE786C4> /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) <DE992474-0841-38A1-B4F6-46D653E454D5> /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) <FBC3F80F-A0FB-3BD6-9A7E-800DE45F092E> /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) <CE41D8C2-BEED-345C-BC4F-3775CC06C672> /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) <D87A64FA-64B1-3B23-BB43-ADE173C108C6> /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) <D3862426-2586-3DF7-BA75-9A184FCD74C4> /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Apple80211
    0x7fff8daa7000 -     0x7fff8dbcfff7  com.apple.coreui (2.1 - 308.6) <DEA5D3E1-D333-302B-A6CF-7643BFDFAED0> /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) <CA4541F4-CEF5-355C-8F1F-EA65DC1B400F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
    0x7fff8dfdb000 -     0x7fff8e0cbfef  libJP2.dylib (1237) <A24C99BF-2360-343F-BCA1-F044E78EA0DE> /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) <AE11CFBC-4D46-30F3-BEEC-4C8131079391> /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) <BA9F5A09-D200-3D18-9F4A-20C789291A30> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
    0x7fff8e7c3000 -     0x7fff8e7d2fff  com.apple.LangAnalysis (1.7.0 - 1.7.0) <D1E527E4-C561-352F-9457-E8C50232793C> /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) <B834E7C8-EC3E-3382-BC5A-DA38DC4D720C> /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) <E6B42781-A556-355A-8A49-82A8D2B347FF> /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) <F03DFAC6-6285-3176-9C6D-7CC50F8CD52A> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
    0x7fff8f06a000 -     0x7fff8f085ff7  libCRFSuite.dylib (34) <D64842BE-7BD4-3D0C-9842-1D202F7C2A51> /usr/lib/libCRFSuite.dylib
    0x7fff8f216000 -     0x7fff8f260ff7  com.apple.HIServices (1.22 - 522.1) <E8BD41E4-7747-3CAF-807A-5CA9AD16B525> /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) <A5640275-E2A6-3856-95EF-5F0DC440B10C> /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) <BB2D573F-0A01-379F-A2BA-3C454EDCB111> /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) <A3A2E56C-2B65-37C7-B43A-A1F926E1A0BB> /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) <CCA42EE2-3400-3444-9486-BC454E60D944> /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) <C4D2AD03-B839-350A-AAF0-B4A08F8BED77> /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 <report at bugs.python.org>
<http://bugs.python.org/issue24273>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24274>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24275>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24276>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24277>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24278>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24279>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24280>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24281>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24282>
_______________________________________

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: [New-bugs-announce] [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 <module>
    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='<stdout>'>

----------
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 <report at bugs.python.org>
<http://bugs.python.org/issue24283>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24284>
_______________________________________

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: [New-bugs-announce] [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 "<stdin>", line 1, in <module>
  File "/Users/ronald/Projects/pyobjc-hg/pyobjc/pyobjc-core/Lib/objc/__init__.py", line 18, in <module>
    _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 <report at bugs.python.org>
<http://bugs.python.org/issue24285>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24286>
_______________________________________

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: [New-bugs-announce] [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:

    <?xml version='1.0' encoding='utf-8'?>
    <?xml-stylesheet href="latest_ob.xsl" type="text/xsl"?>
    <!--Published at: http://w1.weather.gov/xml/current_obs/KSJC.xml-->
    <current_observation version="1.0">
    Nothing to see here.  Move along.
    </current_observation>

----------
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 <report at bugs.python.org>
<http://bugs.python.org/issue24287>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24288>
_______________________________________

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: [New-bugs-announce] [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 <module>
    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 <module>
    import re
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/re.py", line 336, in <module>
    import copyreg
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/copyreg.py", line 3, in <module>
    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 <report at bugs.python.org>
<http://bugs.python.org/issue24289>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24290>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24291>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24292>
_______________________________________

From report at bugs.python.org  Wed May 27 01:59:00 2015
From: report at bugs.python.org (Mike Miller)
Date: Tue, 26 May 2015 23:59:00 +0000
Subject: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24293>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24295>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24296>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24297>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24298>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24299>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24300>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24301>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24302>
_______________________________________

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: [New-bugs-announce] [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 <time.h>
 
 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 <report at bugs.python.org>
<http://bugs.python.org/issue24303>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24304>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24306>
_______________________________________

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: [New-bugs-announce] [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 <module>
	  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 <report at bugs.python.org>
<http://bugs.python.org/issue24307>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24308>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24309>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24310>
_______________________________________

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: [New-bugs-announce] [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 "<string>", line 1, in <module>
  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 <report at bugs.python.org>
<http://bugs.python.org/issue24311>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24312>
_______________________________________

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: [New-bugs-announce] [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 <module>()
      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 <report at bugs.python.org>
<http://bugs.python.org/issue24313>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24314>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24315>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24316>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24317>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24318>
_______________________________________

From report at bugs.python.org  Thu May 28 19:01:01 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 28 May 2015 17:01:01 +0000
Subject: [New-bugs-announce] [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 <module>
    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: <module 'threading' from '/home/skipm/3rdParty/python/cpython/Lib/threading.py'>
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 <module>
    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: <module 'threading' from '/home/skipm/3rdParty/python/cpython/Lib/threading.py'>
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", ' ' <repeats 12 times>, "import _testcapi\n\n", ' ' <repeats 12 times>, "_testcapi.run_in_subinterp('if 1:\\n", ' ' <repeats 12 times>, "import os\\n", ' ' <repeats 12 times>, "import threading\\n", ' ' <repeats 12 times>, "import time\\n\\n", ' ' <repeats 12 times>, "def f():\\n", ' ' <repeats 15 times>..., start=257, globals=0x7f9dd8c9ffc8, locals=0x7f9dd8c9ffc8, flags=0x7fffc68bfe80) at Python/pythonrun.c:894
#13
PyRun_SimpleStringFlags (command=0x7f9dd8c5c050 "if 1:\n", ' ' <repeats 12 times>, "import _testcapi\n\n", ' ' <repeats 12 times>, "_testcapi.run_in_subinterp('if 1:\\n", ' ' <repeats 12 times>, "import os\\n", ' ' <repeats 12 times>, "import threading\\n", ' ' <repeats 12 times>, "import time\\n\\n", ' ' <repeats 12 times>, "def f():\\n", ' ' <repeats 15 times>..., flags=0x7fffc68bfe80) at Python/pythonrun.c:421
#14
run_command (command=0x259ecc0 L"if 1:\n", ' ' <repeats 12 times>, "import _testcapi\n\n", ' ' <repeats 12 times>, "_testcapi.run_in_subinterp('if 1:\\n", ' ' <repeats 12 times>, "import os\\n", ' ' <repeats 12 times>, "import threading\\n", ' ' <repeats 12 times>, "import time\\n\\n", ' ' <repeats 12 times>, "def f():\\n", ' ' <repeats 15 times>..., 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 <report at bugs.python.org>
<http://bugs.python.org/issue24319>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24320>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24321>
_______________________________________

From report at bugs.python.org  Fri May 29 11:43:23 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 29 May 2015 09:43:23 +0000
Subject: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24322>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24323>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24324>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24325>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24326>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24327>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24328>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24329>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24330>
_______________________________________

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: [New-bugs-announce] [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=<optimized out>, 
        str=0x7ffff77782d8 "double free or corruption (!prev)", action=1)
        at malloc.c:4965
    #4  _int_free (av=<optimized out>, p=<optimized out>, have_lock=0)
        at malloc.c:3834
    #5  0x00007ffff766b89c in __GI___libc_free (mem=<optimized out>)
        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=[<buffer at remote 0x7ffff10d40b0>], start=start at entry=0, 
        end=end at entry=1) at mercurial/mpatch.c:296
    #9  0x00007ffff130d3d3 in patches (self=<optimized out>, args=<optimized out>)
        at mercurial/mpatch.c:327
    #10 0x00000000004ccd05 in call_function (oparg=<optimized out>, 
        pp_stack=<optimized out>) at ../Python/ceval.c:4035
    #11 PyEval_EvalFrameEx () at ../Python/ceval.c:2681
    ---Type <return> to continue, or q <return> to quit---
    #12 0x00000000004cd4e2 in fast_function (nk=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
        func=<optimized out>) at ../Python/ceval.c:4121
    #13 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        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=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
        func=<optimized out>) at ../Python/ceval.c:4131
    #17 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        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=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
        func=<optimized out>) at ../Python/ceval.c:4131
    #21 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        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=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
    ---Type <return> to continue, or q <return> to quit---
        func=<optimized out>) at ../Python/ceval.c:4131
    #25 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        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=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
        func=<optimized out>) at ../Python/ceval.c:4131
    #29 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        at ../Python/ceval.c:4056
    #30 PyEval_EvalFrameEx () at ../Python/ceval.c:2681
    #31 0x00000000004cd4e2 in fast_function (nk=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
        func=<optimized out>) at ../Python/ceval.c:4121
    #32 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        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=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
        func=<optimized out>) at ../Python/ceval.c:4131
    #36 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        at ../Python/ceval.c:4056
    ---Type <return> to continue, or q <return> 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=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
        func=<optimized out>) at ../Python/ceval.c:4131
    #40 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        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=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
        func=<optimized out>) at ../Python/ceval.c:4131
    #44 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        at ../Python/ceval.c:4056
    #45 PyEval_EvalFrameEx () at ../Python/ceval.c:2681
    #46 0x00000000004e7cc8 in PyEval_EvalCodeEx (closure=<optimized out>, 
        defcount=<optimized out>, defs=<optimized out>, kwcount=<optimized out>, 
        kws=<optimized out>, argcount=<optimized out>, args=<optimized out>, 
        locals=<optimized out>, globals=<optimized out>, co=<optimized out>)
        at ../Python/ceval.c:3267
    #47 function_call.lto_priv () at ../Objects/funcobject.c:526
    #48 0x00000000004cf239 in PyObject_Call (kw=<optimized out>, 
        arg=<optimized out>, func=<optimized out>) at ../Objects/abstract.c:2529
    ---Type <return> to continue, or q <return> to quit---
    #49 ext_do_call (nk=<optimized out>, na=<optimized out>, 
        flags=<optimized out>, pp_stack=<optimized out>, func=<optimized out>)
        at ../Python/ceval.c:4348
    #50 PyEval_EvalFrameEx () at ../Python/ceval.c:2720
    #51 0x00000000004e7cc8 in PyEval_EvalCodeEx (closure=<optimized out>, 
        defcount=<optimized out>, defs=<optimized out>, kwcount=<optimized out>, 
        kws=<optimized out>, argcount=<optimized out>, args=<optimized out>, 
        locals=<optimized out>, globals=<optimized out>, co=<optimized out>)
        at ../Python/ceval.c:3267
    #52 function_call.lto_priv () at ../Objects/funcobject.c:526
    #53 0x00000000004cf239 in PyObject_Call (kw=<optimized out>, 
        arg=<optimized out>, func=<optimized out>) at ../Objects/abstract.c:2529
    #54 ext_do_call (nk=<optimized out>, na=<optimized out>, 
        flags=<optimized out>, pp_stack=<optimized out>, func=<optimized out>)
        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=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
        func=<optimized out>) at ../Python/ceval.c:4131
    #58 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        at ../Python/ceval.c:4056
    #59 PyEval_EvalFrameEx () at ../Python/ceval.c:2681
    ---Type <return> to continue, or q <return> to quit---
    #60 0x00000000004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267
    #61 0x00000000004ce7d3 in fast_function (nk=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
        func=<optimized out>) at ../Python/ceval.c:4131
    #62 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        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=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
        func=<optimized out>) at ../Python/ceval.c:4131
    #66 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        at ../Python/ceval.c:4056
    #67 PyEval_EvalFrameEx () at ../Python/ceval.c:2681
    #68 0x00000000004cd4e2 in fast_function (nk=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
        func=<optimized out>) at ../Python/ceval.c:4121
    #69 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        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=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
    ---Type <return> to continue, or q <return> to quit---
        func=<optimized out>) at ../Python/ceval.c:4131
    #73 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        at ../Python/ceval.c:4056
    #74 PyEval_EvalFrameEx () at ../Python/ceval.c:2681
    #75 0x00000000004cd4e2 in fast_function (nk=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
        func=<optimized out>) at ../Python/ceval.c:4121
    #76 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        at ../Python/ceval.c:4056
    #77 PyEval_EvalFrameEx () at ../Python/ceval.c:2681
    #78 0x00000000004cd4e2 in fast_function (nk=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
        func=<optimized out>) at ../Python/ceval.c:4121
    #79 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        at ../Python/ceval.c:4056
    #80 PyEval_EvalFrameEx () at ../Python/ceval.c:2681
    #81 0x00000000004cd4e2 in fast_function (nk=<optimized out>, 
        na=<optimized out>, n=<optimized out>, pp_stack=<optimized out>, 
        func=<optimized out>) at ../Python/ceval.c:4121
    #82 call_function (oparg=<optimized out>, pp_stack=<optimized out>)
        at ../Python/ceval.c:4056
    #83 PyEval_EvalFrameEx () at ../Python/ceval.c:2681
    #84 0x00000000004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267
    ---Type <return> to continue, or q <return> to quit---
    #85 0x000000000050481f in PyEval_EvalCode (
        locals={'fp': <file at remote 0x7ffff7fd81e0>, 'demandimport': <module at remote 0x7ffff32e44b0>, '__builtins__': <module at remote 0x7ffff7fb6b08>, 'mercurial': <module at remote 0x7ffff7e37fd8>, '__file__': '/usr/bin/hg', 'libdir': '@LIBDIR@', '__package__': None, 'sys': <module at remote 0x7ffff7fb6bb0>, '__name__': '__main__', 'os': <module at remote 0x7ffff7f5ad00>, '__doc__': None}, 
        globals={'fp': <file at remote 0x7ffff7fd81e0>, 'demandimport': <module at remote 0x7ffff32e44b0>, '__builtins__': <module at remote 0x7ffff7fb6b08>, 'mercurial': <module at remote 0x7ffff7e37fd8>, '__file__': '/usr/bin/hg', 'libdir': '@LIBDIR@', '__package__': None, 'sys': <module at remote 0x7ffff7fb6bb0>, '__name__': '__main__', 'os': <module at remote 0x7ffff7f5ad00>, '__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 <main>, argc=4, 
        argv=0x7fffffffd278, init=<optimized out>, fini=<optimized out>, 
        rtld_fini=<optimized out>, 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 <report at bugs.python.org>
<http://bugs.python.org/issue24331>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24332>
_______________________________________

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: [New-bugs-announce] [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': '<proxy server ip>',
    'https': '<proxy server ip>',
})
password_mgr = SimplePasswordManager('<username>', '<password>')
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": "<proxy server ip>"
}

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 <module>
    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: <urlopen error Tunnel connection failed: 407 Proxy Authentication Required>

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 <report at bugs.python.org>
<http://bugs.python.org/issue24333>
_______________________________________

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: [New-bugs-announce] [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
<ssl.SSLSocket fd=3, family=AddressFamily.AF_INET, type=SocketType.SOCK_STREAM, proto=6, laddr=('192.168.7.122', 39657), raddr=('185.31.17.223', 443)>
>>> 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
<ssl.SSLSocket fd=3, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=6, laddr=('192.168.7.122', 39664), raddr=('185.31.17.223', 443)>
>>> ssock._sslobj
<ssl.SSLObject object at 0x7fa55a96bb00>
>>> 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 <report at bugs.python.org>
<http://bugs.python.org/issue24334>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24335>
_______________________________________

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: [New-bugs-announce] [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 "<stdin>", line 1, in <module>
  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 <report at bugs.python.org>
<http://bugs.python.org/issue24336>
_______________________________________

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: [New-bugs-announce] [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 <ram at rachum.com>:


----------
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 <report at bugs.python.org>
<http://bugs.python.org/issue24337>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24338>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24339>
_______________________________________

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: [New-bugs-announce] [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 <report at bugs.python.org>
<http://bugs.python.org/issue24340>
_______________________________________

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: [New-bugs-announce] [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 <bound method Thread.__bootstrap of <Thread(Thread-1, stopped -1326462144)>>
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 <bound method Thread.__bootstrap of <Thread(Thread-2, stopped -1376818368)>>    
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 <bound method Thread.__bootstrap of <Thread(Thread-3, stopped -1309676736)>>
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 <bound method Thread.__bootstrap of <Thread(Thread-4, stopped -1326462144)>>

----------
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 <report at bugs.python.org>
<http://bugs.python.org/issue24341>
_______________________________________