From report at bugs.python.org  Sat Dec  1 01:23:52 2012
From: report at bugs.python.org (Markus Kettunen)
Date: Sat, 01 Dec 2012 00:23:52 +0000
Subject: [New-bugs-announce] [issue16587] Py_Initialize breaks wprintf on
	Windows
Message-ID: <1354321432.5.0.798652538273.issue16587@psf.upfronthosting.co.za>


New submission from Markus Kettunen:

In a C application on Windows, at least on MSVC 2010 and Windows 7, do this:

wprintf(L"Test\n");
Py_Initialize();
wprintf(L"Test\n");

Output is:
Test
 T e s t

I was able to track the issue to fileio.c to the following code block by searching where wprintf breaks:

    if (dircheck(self, nameobj) < 0)
        goto error;

#if defined(MS_WINDOWS) || defined(__CYGWIN__)
    /* don't translate newlines (\r\n <=> \n) */
    _setmode(self->fd, O_BINARY); <----- breaks it
#endif

    if (PyObject_SetAttrString((PyObject *)self, "name", nameobj) < 0)
        goto error;

This can be easily confirmed by adding wprintfs on both sides of _setmode.

This issue was also raised at http://mail.python.org/pipermail/python-list/2012-February/620528.html but no solution was provided back then.

----------
components: IO, Unicode, Windows
messages: 176732
nosy: ezio.melotti, makegho
priority: normal
severity: normal
status: open
title: Py_Initialize breaks wprintf on Windows
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Dec  1 03:41:38 2012
From: report at bugs.python.org (Bruno Dupuis)
Date: Sat, 01 Dec 2012 02:41:38 +0000
Subject: [New-bugs-announce] [issue16588] gcc 4.7 ilegitimate unused-but-set
	warnings on	Python/thread_pthread.h
Message-ID: <1354329698.56.0.368664055406.issue16588@psf.upfronthosting.co.za>


New submission from Bruno Dupuis:

Looks like #10951, but for another version of gcc.

I get these warnings:

 In file included from Python/thread.c:86:0:
 Python/thread_pthread.h: In function ?PyThread_free_lock?:
 Python/thread_pthread.h:304:17: attention : variable ?error? set but not used [-Wunused-but-set-variable]
 Python/thread_pthread.h: In function ?PyThread_acquire_lock_timed?:
 Python/thread_pthread.h:335:17: attention : variable ?error? set but not used [-Wunused-but-set-variable]
 Python/thread_pthread.h: In function ?PyThread_release_lock?:
 Python/thread_pthread.h:386:17: attention : variable ?error? set but not used [-Wunused-but-set-variable]

I tried to remove the variables, but the build crash as they are used in

 #define CHECK_STATUS(name)  if (status != 0) { perror(name); error = 1; }

looks like a gcc 4.7.2 bug.

----------
components: Build
messages: 176737
nosy: bruno.dupuis
priority: normal
severity: normal
status: open
title: gcc 4.7 ilegitimate unused-but-set warnings on Python/thread_pthread.h
versions: Python 3.3

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

From report at bugs.python.org  Sat Dec  1 18:26:05 2012
From: report at bugs.python.org (mindrones)
Date: Sat, 01 Dec 2012 17:26:05 +0000
Subject: [New-bugs-announce] [issue16589] PrettyPrinter docs is incomplete
Message-ID: <1354382765.36.0.618684854763.issue16589@psf.upfronthosting.co.za>


New submission from mindrones:

Hi,

at http://docs.python.org/2.7/library/pprint.html#pprint.PrettyPrinter we see:
"class pprint.PrettyPrinter(...)"

while at http://docs.python.org/3.3/library/pprint.html#pprint.PrettyPrinter we see:
"class pprint.PrettyPrinter(indent=1, width=80, depth=None, stream=None)"

I think the first case is a bug.

Regards,
Luca

----------
assignee: docs at python
components: Documentation
messages: 176745
nosy: docs at python, mindrones
priority: normal
severity: normal
status: open
title: PrettyPrinter docs is incomplete
versions: Python 2.7

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

From report at bugs.python.org  Sat Dec  1 18:55:07 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Dec 2012 17:55:07 +0000
Subject: [New-bugs-announce] [issue16590] Drop <2.6 support from _json.c
Message-ID: <1354384507.61.0.431771846234.issue16590@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Modules/_json.c contains workarounds for Python versions <2.6. Now this code is not needed and can be safely dropped.

This patch moved from issue16586.

----------
components: Extension Modules
files: json_size_t_cleanup.patch
keywords: patch
messages: 176748
nosy: ezio.melotti, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Drop <2.6 support from _json.c
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28179/json_size_t_cleanup.patch

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

From report at bugs.python.org  Sat Dec  1 20:43:13 2012
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 01 Dec 2012 19:43:13 +0000
Subject: [New-bugs-announce] [issue16591] RUNSHARED wrong for OSX no
	framework
Message-ID: <1354390993.26.0.328076404417.issue16591@psf.upfronthosting.co.za>


New submission from Fabian Groffen:

Python fails to run python.exe on OSX when a non-framework build is requested, due to wrong quoting in configure.ac.

Like all other RUNSHARED, it shouldn't be quoted because then `pwd` won't be expanded, resulting in a wrong DYLD_LIBRARY_PATH when regen is ran (from a different directory than where libpython3.3.dylib resides).

Attached patch solves the issue.  The issue seems to be in current 3.3 and default heads.

----------
components: Build
files: 11_all_darwin-dyld-library-path.patch
hgrepos: 162
keywords: patch
messages: 176754
nosy: grobian
priority: normal
severity: normal
status: open
title: RUNSHARED wrong for OSX no framework
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file28180/11_all_darwin-dyld-library-path.patch

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

From report at bugs.python.org  Sun Dec  2 02:27:30 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Dec 2012 01:27:30 +0000
Subject: [New-bugs-announce] [issue16592] stringlib_bytes_join doesn't raise
	MemoryError on	allocation failure
Message-ID: <1354411650.12.0.480511904473.issue16592@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

>>> l = [b''] * (100*1024*1024)
[104918914 refs]
>>> d = b''.join(l)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: error return without exception set

(you'll have to adjust the list size based on your system memory size)

----------
components: Interpreter Core
keywords: easy
messages: 176767
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: stringlib_bytes_join doesn't raise MemoryError on allocation failure
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec  2 07:11:18 2012
From: report at bugs.python.org (Daniel Shahaf)
Date: Sun, 02 Dec 2012 06:11:18 +0000
Subject: [New-bugs-announce] [issue16593] Have BSD 'make -s' DTRT
Message-ID: <1354428678.52.0.554916840287.issue16593@psf.upfronthosting.co.za>


New submission from Daniel Shahaf:

FreeBSD make sets $$MAKEFLAGS differently than GNU make does.  Attached patch updates Makefile.pre.in to recognise that syntax too.

Preliminary versions discussed with Crys on #python-dev.

----------
components: Build
messages: 176768
nosy: danielsh
priority: normal
severity: normal
status: open
title: Have BSD 'make -s' DTRT
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec  2 10:07:29 2012
From: report at bugs.python.org (Andy Zeldis)
Date: Sun, 02 Dec 2012 09:07:29 +0000
Subject: [New-bugs-announce] [issue16594] SocketServer should set
	SO_REUSEPORT along with	SO_REUSEADDR when present
Message-ID: <1354439249.45.0.0324812571604.issue16594@psf.upfronthosting.co.za>


New submission from Andy Zeldis:

On BSD (including Mac OS X) SO_REUSEPORT should be specified along with SO_REUSEADDR to match behavior on Linux (and possible Windows). This is needed to have multiple listeners to a UDP broadcast.

I discovered this when using PyOSC. Attached is an example modified to subclass SocketServer with a workaround. It should be possible to start multiple instances of this program, all of which will receive messages to a broadcast address (eg 255.255.255.255:7110).

This test uses Python 2.7 on OS X (despite the "python3" shebang line from the example)

----------
components: Library (Lib)
files: osc-broadcast-rcv.py
messages: 176777
nosy: Andy.Zeldis
priority: normal
severity: normal
status: open
title: SocketServer should set SO_REUSEPORT along with SO_REUSEADDR when present
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file28183/osc-broadcast-rcv.py

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

From report at bugs.python.org  Sun Dec  2 12:14:41 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 02 Dec 2012 11:14:41 +0000
Subject: [New-bugs-announce] [issue16595] Add resource.prlimit
Message-ID: <1354446881.9.0.288115855459.issue16595@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Linux has an additional function to setrlimit and getrlimit which supports to query and/or modify resource limits of another process.

http://www.kernel.org/doc/man-pages/online/pages/man2/getrlimit.2.html

The patch implements resource.prlimit(pid, resource[, limits]) on all platforms that have a prlimit() function. I haven't included the regenerated configure script. You have to run autoreconf in order to test the new function.

----------
assignee: christian.heimes
components: Extension Modules
files: prlimit.patch
keywords: patch
messages: 176783
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: Add resource.prlimit
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28184/prlimit.patch

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

From report at bugs.python.org  Mon Dec  3 00:23:04 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 02 Dec 2012 23:23:04 +0000
Subject: [New-bugs-announce] [issue16596] Skip stack unwinding when "next",
	"until" and "return" pdb commands executed
Message-ID: <1354490584.78.0.706210856716.issue16596@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

GvR in http://mail.python.org/pipermail/python-ideas/2012-November/017991.html has requested for improving pdb to jump over yield instead of following it.

----------
components: Library (Lib)
messages: 176815
nosy: asvetlov, gvanrossum
priority: normal
severity: normal
status: open
title: Skip stack unwinding when "next",  "until" and "return" pdb commands executed
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec  3 00:24:53 2012
From: report at bugs.python.org (John-John Tedro)
Date: Sun, 02 Dec 2012 23:24:53 +0000
Subject: [New-bugs-announce] [issue16597] close not being called with
	context manager on IOError	when device is full.
Message-ID: <1354490693.79.0.337514443024.issue16597@psf.upfronthosting.co.za>


New submission from John-John Tedro:

In 3.2.2 and 3.2.3 on linux64, when running the following code. 

    try:
        print("Writing to /dev/full")

        with open("/dev/full", "w") as f:
             f.write("Write to full device")
    except:
        print("Catch, file closed?")

Using

    strace -e close ~/usr/python3.2.3/bin/python3 test.py
    ...
    Writing to /dev/full
    Catch, file closed?
    close(3)                                = 0

The file descriptor being used (3) to attempt writing to /dev/full is not closed until the process exits.

I expected this to be closed when leaving the context manager.

----------
components: IO
messages: 176816
nosy: udoprog
priority: normal
severity: normal
status: open
title: close not being called with context manager on IOError when device is full.
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Dec  3 04:41:42 2012
From: report at bugs.python.org (Steven Kryskalla)
Date: Mon, 03 Dec 2012 03:41:42 +0000
Subject: [New-bugs-announce] [issue16598] Docs: double newlines printed in
	some file iteration	examples
Message-ID: <1354506102.98.0.373990465676.issue16598@psf.upfronthosting.co.za>


New submission from Steven Kryskalla:

I heard someone complain about this code appearing in the official documentation in a few places:

for line in open("file.txt"):
    print(line)

This code will print two newlines.

I went through the current "default" and "2.7" branches and changed the places where this occurred to use print(line, end="") for 3.x or "print line," for 2.x.

r80699.patch is for the "default" branch (3.x)
r80694.py27.patch is for the "2.7" branch

----------
assignee: docs at python
components: Documentation
files: r80699.patch
hgrepos: 164
keywords: patch
messages: 176824
nosy: docs at python, lost-theory
priority: normal
severity: normal
status: open
title: Docs: double newlines printed in some file iteration examples
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file28191/r80699.patch

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

From report at bugs.python.org  Mon Dec  3 10:42:03 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 03 Dec 2012 09:42:03 +0000
Subject: [New-bugs-announce] [issue16599] unittest: Access test result from
	tearDown
Message-ID: <1354527723.36.0.769611290906.issue16599@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

A common usage pattern is to prevent clean up in tearDown() if the test failed. However, it requires a hack: http://stackoverflow.com/questions/4414234/getting-pythons-unittest-results-in-a-teardown-method. Would be nice to have an officially documented feature.

----------
components: Library (Lib), Tests
messages: 176832
nosy: techtonik
priority: normal
severity: normal
status: open
title: unittest: Access test result from tearDown
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Dec  3 10:55:29 2012
From: report at bugs.python.org (Robert McGibbon)
Date: Mon, 03 Dec 2012 09:55:29 +0000
Subject: [New-bugs-announce] [issue16600] rlcompleter
Message-ID: <1354528529.28.0.687527154306.issue16600@psf.upfronthosting.co.za>


New submission from Robert McGibbon:

I'm not really sure how what the format for filing bugs with python is, so I'm sorry in advance if I've done something wrong.

There is a very small py3k bug in the readline completer (rlcompleter.py).

Specifically, if you look at line 105 (http://hg.python.org/cpython/file/03ce83e43e1b/Lib/rlcompleter.py#l105), you can see that the rlcompleter module is trying to remove '__builtins__' from the list of possible completions that it gives. This made sense in python2.x, but sense the name '__bultins__' was changed to 'builtins', perhaps the line should be changed?

The same issue applies on line 131-134 of the same file I think.

Thanks!

----------
messages: 176833
nosy: rmcgibbo
priority: normal
severity: normal
status: open
title: rlcompleter
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Dec  3 21:01:12 2012
From: report at bugs.python.org (Michael Birtwell)
Date: Mon, 03 Dec 2012 20:01:12 +0000
Subject: [New-bugs-announce] [issue16601] Restarting iteration over tarfile
	continues from where	it left off.
Message-ID: <1354564872.87.0.0661195327337.issue16601@psf.upfronthosting.co.za>


New submission from Michael Birtwell:

If you partially iterate over a tarfile then try and restart iteration of that tarfile it will continue from where it left off rather than restarting from the beginning.

I've only tried this with the tarfile implementation in python 2.7 but the 3.x code looks the same in this respect.

I've included a patch with my approach to fixing this.

----------
components: Library (Lib)
files: fix-tarfile-restart-iteration.patch
keywords: patch
messages: 176863
nosy: mbirtwell
priority: normal
severity: normal
status: open
title: Restarting iteration over tarfile continues from where it left off.
versions: Python 2.7
Added file: http://bugs.python.org/file28200/fix-tarfile-restart-iteration.patch

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

From report at bugs.python.org  Tue Dec  4 07:50:28 2012
From: report at bugs.python.org (Eugene Toder)
Date: Tue, 04 Dec 2012 06:50:28 +0000
Subject: [New-bugs-announce] [issue16602] weakref can return an object with
	0 refcount
Message-ID: <1354603828.49.0.407579608192.issue16602@psf.upfronthosting.co.za>


New submission from Eugene Toder:

An interaction between weakrefs and trashcan can cause weakref to return the object it's pointing to after object's refcount is already 0. Given that the object is usually increfed and decrefed, this leads to double dealloc and crashing or hanging.
Tested 2.6.6, 2.7.2 and 3.3.0 on win7.

In more details. The documentation for Py_TRASHCAN_SAFE_BEGIN tells to put it right after PyObject_GC_UnTrack. This means that PyObject_ClearWeakRefs goes after it, and, for example, in subtype_dealloc of Objects/typeobject.c this is indeed the case. This means that if we get into a long chain of deallocations and the trashcan kicks in, we get an object with 0 refcount and without cleared weakrefs lying in trash_delete_later until we go PyTrash_UNWIND_LEVEL levels up. During that time we can execute arbitrary python code, so all we need is some code with an access to the weakref to dereference it.
The current recommendation of clearing weakrefs before clearing attributes makes this less likely to happen, but it's still easy enough:

import weakref

class C:
    def __init__(self, parent):
        if not parent:
            return
        wself = weakref.ref(self)
        def cb(wparent):
            o = wself()
        self.wparent = weakref.ref(parent, cb)

d = weakref.WeakKeyDictionary()
root = c = C(None)
for n in range(100):
    d[c] = c = C(c)

print('deleting')
del root
print('done')

In this case weakref callback in WeakKeyDictionary deletes the reference to the next object, causing the next level of destruction, until trashcan kicks in. Trashcan delays clearing of weakrefs, allowing the second weakref's (wparent) callback to see the dead object via wself that it captured.

Attached is a similar example with less weakrefs using __del__.

----------
components: Interpreter Core
files: wr2.py
messages: 176874
nosy: eltoder, pitrou
priority: normal
severity: normal
status: open
title: weakref can return an object with 0 refcount
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file28204/wr2.py

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

From report at bugs.python.org  Tue Dec  4 09:35:54 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Dec 2012 08:35:54 +0000
Subject: [New-bugs-announce] [issue16603] Sporadic test_socket failures:
	testFDPassCMSG_SPACE on	Mac OS X
Message-ID: <1354610154.86.0.887949323401.issue16603@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20Mountain%20Lion%20%5BSB%5D%203.x/builds/523/steps/test/logs/stdio

======================================================================
ERROR: testFDPassCMSG_SPACE (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Volumes/bay2/buildslave/cpython/3.x.snakebite-mountainlion-amd64/build/Lib/test/test_socket.py", line 2502, in testFDPassCMSG_SPACE
    socket.CMSG_SPACE(4 * SIZEOF_INT)))
  File "/Volumes/bay2/buildslave/cpython/3.x.snakebite-mountainlion-amd64/build/Lib/test/test_socket.py", line 1786, in doRecvmsg
    result = sock.recvmsg_into([buf], *args)
socket.timeout: timed out

======================================================================
ERROR: testFDPassCMSG_SPACE (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Volumes/bay2/buildslave/cpython/3.x.snakebite-mountainlion-amd64/build/Lib/test/test_socket.py", line 232, in _tearDown
    raise exc
  File "/Volumes/bay2/buildslave/cpython/3.x.snakebite-mountainlion-amd64/build/Lib/test/test_socket.py", line 244, in clientRun
    test_func()
  File "/Volumes/bay2/buildslave/cpython/3.x.snakebite-mountainlion-amd64/build/Lib/test/test_socket.py", line 2506, in _testFDPassCMSG_SPACE
    self.createAndSendFDs(4)
  File "/Volumes/bay2/buildslave/cpython/3.x.snakebite-mountainlion-amd64/build/Lib/test/test_socket.py", line 2445, in createAndSendFDs
    array.array("i", self.newFDs(n)))]),
  File "/Volumes/bay2/buildslave/cpython/3.x.snakebite-mountainlion-amd64/build/Lib/test/test_socket.py", line 1687, in sendmsgToServer
    *(args + self.sendmsg_to_server_defaults[len(args):]))
BrokenPipeError: [Errno 32] Broken pipe

--

See also issue #13876. I copied the nosy list of this issue.

----------
components: Tests
messages: 176879
nosy: giampaolo.rodola, haypo, nadeem.vawda, neologix, pitrou, rosslagerwall
priority: normal
severity: normal
status: open
title: Sporadic test_socket failures: testFDPassCMSG_SPACE on Mac OS X
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec  4 09:37:14 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Dec 2012 08:37:14 +0000
Subject: [New-bugs-announce] [issue16604] Sporadic .test_threaded_import
	failure:	test_parallel_meta_path on Windows 7
Message-ID: <1354610234.83.0.00487836911931.issue16604@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/5975/steps/test/logs/stdio

======================================================================
FAIL: test_parallel_meta_path (test.test_threaded_import.ThreadedImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_threaded_import.py", line 133, in test_parallel_meta_path
    self.assertEqual(finder.x, finder.numcalls)
AssertionError: 93 != 94

----------
components: Tests
messages: 176880
nosy: brett.cannon, haypo, pitrou
priority: normal
severity: normal
status: open
title: Sporadic .test_threaded_import failure: test_parallel_meta_path on Windows 7
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec  4 09:49:17 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Dec 2012 08:49:17 +0000
Subject: [New-bugs-announce] [issue16605] test_posix.test_fs_holes() fails
	on FreeBSD 9.0
Message-ID: <1354610957.0.0.869745259261.issue16605@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.x/builds/761/steps/test/logs/stdio



======================================================================
FAIL: test_fs_holes (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd/build/Lib/test/test_posix.py", line 1003, in test_fs_holes
    self.assertLessEqual(size, os.lseek(fno, i, os.SEEK_HOLE))
AssertionError: 5 not less than or equal to 0


--

See also the issue #10142 which added this feature. I copied the nosy list of this issue.

----------
components: Tests
messages: 176882
nosy: aklauer, amaury.forgeotdarc, benjamin.peterson, georg.brandl, haypo, jcea, loewis, pitrou, python-dev, rhettinger, skrah, terry.reedy
priority: normal
severity: normal
status: open
title: test_posix.test_fs_holes() fails on FreeBSD 9.0
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec  4 13:43:32 2012
From: report at bugs.python.org (Thorsten Simons)
Date: Tue, 04 Dec 2012 12:43:32 +0000
Subject: [New-bugs-announce] [issue16606] hashlib memory leak
Message-ID: <1354625012.22.0.133818584828.issue16606@psf.upfronthosting.co.za>


New submission from Thorsten Simons:

hashlib seems to leak memory when used on a Linux box (whereas the same works fine when run under Windows 7) (tested w/ Python 3.2.1 and 3.2.3)

<snip file "mem.py">
import hashlib

#file = 'B:\\video\\TEST\\01_file_10G'
file = '/video/TEST/01_file_10G'

myhash = hashlib.sha256()

with open(file, "rb") as f:
    for buffer in f:
        myhash.update(buffer)

print('hash =', myhash.hexdigest())
<snip>

On Windows, 'python3 mem.py' occupies roundabout 7 MB memory,
on Linux (OpenSuse 12.2), it quickly acquires all available memory, then all swap, than get's killed.

----------
components: Library (Lib)
messages: 176907
nosy: Thorsten.Simons
priority: normal
severity: normal
status: open
title: hashlib memory leak
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Tue Dec  4 19:48:27 2012
From: report at bugs.python.org (myreallycoolname)
Date: Tue, 04 Dec 2012 18:48:27 +0000
Subject: [New-bugs-announce] [issue16607] Bad examples in documentation
Message-ID: <1354646907.48.0.243839497772.issue16607@psf.upfronthosting.co.za>


New submission from myreallycoolname:

The doumentation examples imn the tutorial in python3.2 are at lest in part invalid. I was having trouble understanding the documentation so I pulled out my pthony interperator and pluged in one of tyhe examples.
Just as I thought self was not defined.
You can't learn python if the docs are bad.
Please review the examples under classes to make sure they are all correct.

----------
assignee: docs at python
components: Documentation
messages: 176927
nosy: docs at python, myreallycoolname
priority: normal
severity: normal
status: open
title: Bad examples in documentation
versions: Python 3.2

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

From report at bugs.python.org  Tue Dec  4 19:54:03 2012
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 04 Dec 2012 18:54:03 +0000
Subject: [New-bugs-announce] [issue16608] subclass str fails
Message-ID: <1354647243.72.0.494328426401.issue16608@psf.upfronthosting.co.za>


New submission from David W. Lambert:

http://forums.devshed.com/newreply.php?do=newreply&noquote=1&p=2838814

>>> class c(tuple):
...  def __init__(s,a,b):
...   tuple.__init__(s,a)
...   self.b = b
...
>>> c(tuple(),666)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: tuple() takes at most 1 argument (2 given)
>>>

----------
components: Interpreter Core
messages: 176928
nosy: LambertDW
priority: normal
severity: normal
status: open
title: subclass str fails
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Dec  4 20:03:07 2012
From: report at bugs.python.org (Cal Leeming)
Date: Tue, 04 Dec 2012 19:03:07 +0000
Subject: [New-bugs-announce] [issue16609] random.random() / float() loses
	precision when passed to	str()
Message-ID: <1354647787.87.0.344652748044.issue16609@psf.upfronthosting.co.za>


New submission from Cal Leeming:

Hello,

Today I came up against a strange problem where collisions were being encountered after less than 1mil iterations when attempting to use random.random().

After much digging, the problem was because I was casting my float to a string, and this was automatically rounding it.

Some explanation is given [1], but it still leaves me with questions.

>>> import random
>>> random.random()
0.33885573194811902
>>> x = random.random()
>>> x
0.88022393777095409
>>> print x
0.880223937771
>>> str(x)
'0.880223937771'
>>> print str(x)
0.880223937771
>>> repr(x)
'0.88022393777095409'
>>> str(repr(x))
'0.88022393777095409'

After painstakingly searching through documentation (including the lengthy one about floating points arithmetic), I was unable to find any explanation behind why the float is automatically rounded if str() is called on it.

Although I doubt this behavior would ever be changed, it would be nice to update the documentation to reflect this. I'm thinking a note underneath random.random() explaining that you have to use repr() and not str() in order to maintain floating point precision.

Thoughts?

Cal

[1] http://stackoverflow.com/questions/3481289/converting-a-python-float-to-a-string-without-losing-precision

----------
components: Interpreter Core
messages: 176930
nosy: sleepycal
priority: normal
severity: normal
status: open
title: random.random() / float() loses precision when passed to str()
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec  4 20:46:00 2012
From: report at bugs.python.org (Stepan Wagner)
Date: Tue, 04 Dec 2012 19:46:00 +0000
Subject: [New-bugs-announce] [issue16610] Silent StopIteration exc when
	raised from generator	inside of another generator
Message-ID: <1354650360.2.0.9530636235.issue16610@psf.upfronthosting.co.za>


New submission from Stepan Wagner:

def emptygen():
    # Or other more meaningful generator
    raise StopIteration
    yield

def wrap(gen):
    next(gen)
    print("This should be printed or StopIteration raised.")
    while True:
        try:
            yield next(gen)
        except StopIteration as exc:
            return

items = wrap(emptygen())
for item in items:
    print(item)

print("End.")

----------
components: Interpreter Core
messages: 176939
nosy: Stepan.Wagner
priority: normal
severity: normal
status: open
title: Silent StopIteration exc when raised from generator inside of another generator
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Tue Dec  4 21:50:24 2012
From: report at bugs.python.org (John Dennis)
Date: Tue, 04 Dec 2012 20:50:24 +0000
Subject: [New-bugs-announce] [issue16611] multiple problems with Cookie.py
Message-ID: <1354654224.49.0.677339520856.issue16611@psf.upfronthosting.co.za>


New submission from John Dennis:

There are multiple problems with Cookie.py. Some of the issues are covered in http://bugs.python.org/issue3073 which is still open (after 4.5 years).

In all honesty the API and the implementation are not great perhaps the best thing would be to remove it from the core libraries, however you can't remove a core library. There is cookielib.py is which is pretty good however cookielib.py is tightly coupled to urllib2 and if you're not using urllib2 you can't use cookielib.py so you're stuck using Cookie.py which means the best thing is to get the bugs in Cookie.py fixed.

Of the problems illustrated in the attached unittest (test_cookie.py) the absolute must fix issues are the inability to parse an Expires attribute and the impossibility of testing the HttpOnly & Secure flags for a truth value after parsing. Those are critical because it makes using Cookie.py impossible. The other errors would be nice to get fixed, but not as critical. Next in importance would be respecting the truth value when setting the HttpOnly & Secure flags. Failing to detect an improperly formatted cookie when parsing is the least important because hopefully you won't have improperly formatted cookies (unfortunately a weak assumption)

Note: the HttpOnly and Secure issues are symmetrical, they both suffer the same problems because they're both boolean flags whose True value is asserted by the flag's presence and it's False value by it's absence.
 
Cookie parsing problems:

* Cannot read a properly formatted Expires attribute (see also issue 3073)

* Impossible to determine state of HttpOnly boolean flag after parsing

* Impossible to determine state of Secure boolean flag after parsing

* Fails to raise any errors when parsing invalid cookie strings

Cookie creation/initialization problems:

* Setting HttpOnly flag to a value which evaluates to False results in the flag being set to True (there is no check whatsoever on the value).

* Setting Secure flag to a value which evaluates to False results in the flag being set to True (there is no check whatsoever on the value).

Attached is a unittest illustrating the problems (more details are in the unittest).

python test_cookie.py
FF.FFFFFF...F
----------------------------------------------------------------------
Ran 13 tests in 0.003s

FAILED (failures=9)

----------
components: Library (Lib)
files: test_cookie.py
messages: 176957
nosy: jdennis
priority: normal
severity: normal
status: open
title: multiple problems with Cookie.py
versions: Python 2.7
Added file: http://bugs.python.org/file28208/test_cookie.py

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

From report at bugs.python.org  Tue Dec  4 23:18:57 2012
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 04 Dec 2012 22:18:57 +0000
Subject: [New-bugs-announce] [issue16612] Integrate "Argument Clinic"
	specialized preprocessor	into CPython trunk
Message-ID: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This bug tracker entry is to track adding "Argument Clinic" to CPython trunk.

Please see http://mail.python.org/pipermail/python-dev/2012-December/122920.html for more information.

----------
assignee: larry
components: Interpreter Core
messages: 176965
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Integrate "Argument Clinic" specialized preprocessor into CPython trunk
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Dec  5 10:13:11 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 05 Dec 2012 09:13:11 +0000
Subject: [New-bugs-announce] [issue16613] ChainMap.new_child could use
	improvement
Message-ID: <1354698791.22.0.0978748363163.issue16613@psf.upfronthosting.co.za>


New submission from Vinay Sajip:

ChainMap.new_child could IMO be improved through allowing an optional dict to be passed, which is used to create the child. The use case is that you sometimes need to temporarily push a new non-empty mapping in front of an existing chain. This could be achieved by changing new_child to the following, which is backwards-compatible:

    def new_child(self, d=None):
        'New ChainMap with a new dict followed by all previous maps.'
        return self.__class__(d or {}, *self.maps)

----------
components: Library (Lib)
messages: 176974
nosy: rhettinger, vinay.sajip
priority: normal
severity: normal
status: open
title: ChainMap.new_child could use improvement
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Dec  5 14:28:07 2012
From: report at bugs.python.org (Michael Edwards)
Date: Wed, 05 Dec 2012 13:28:07 +0000
Subject: [New-bugs-announce] [issue16614] argparse accepts partial parameters
Message-ID: <1354714087.56.0.314171831729.issue16614@psf.upfronthosting.co.za>


New submission from Michael Edwards:

When running parse_args, ArgumentParser is liberal in accepting parameters. Partial matches will be accepted as arguments

(in the included example, --test bob, --tester bob, --testers bob all set the testers argument)

Perhaps this is documented, but it was super unexpected for me.

----------
components: Library (Lib)
files: test.py
messages: 176981
nosy: Michael.Edwards
priority: normal
severity: normal
status: open
title: argparse accepts partial parameters
versions: Python 2.7
Added file: http://bugs.python.org/file28209/test.py

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

From report at bugs.python.org  Wed Dec  5 14:45:09 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 05 Dec 2012 13:45:09 +0000
Subject: [New-bugs-announce] [issue16615] gcc 4.7 unused-but-set warnings
Message-ID: <1354715109.8.0.920033612812.issue16615@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

GCC 4.7 is showing some compilation warning about setting variables never read.

----------
assignee: jcea
messages: 176984
nosy: jcea
priority: normal
severity: normal
status: open
title: gcc 4.7 unused-but-set warnings
type: compile error
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Dec  5 17:25:28 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 05 Dec 2012 16:25:28 +0000
Subject: [New-bugs-announce] [issue16616]
	test_poll.PollTests.poll_unit_tests() is dead code
Message-ID: <1354724728.62.0.359623055954.issue16616@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

PollTests.poll_unit_tests() is not run because its method name does not begin with "test".  It looks it was accidentally disabled when test_poll() was converted to unittest in f56b25168142.

Renaming it test_poll_unit_tests() makes it run successfully (at least under Linux).

Is it sufficient to reenable it only for the 3.4 branch?

----------
components: Tests
messages: 176989
nosy: georg.brandl, sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: test_poll.PollTests.poll_unit_tests() is dead code
versions: Python 3.4

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

From report at bugs.python.org  Wed Dec  5 18:05:26 2012
From: report at bugs.python.org (Vladimir Kotulskiy)
Date: Wed, 05 Dec 2012 17:05:26 +0000
Subject: [New-bugs-announce] [issue16617] mimetypes.py UnicodeDecodeError:
	'ascii' codec can't	decode byte 0xe0 in position 0: ordinal
	not in range(128)
Message-ID: <1354727126.64.0.779112456141.issue16617@psf.upfronthosting.co.za>


New submission from Vladimir Kotulskiy:

File "C:\DevTools\Python27\lib\mimetypes.py", line 355, in init
    db.read_windows_registry()
  File "C:\DevTools\Python27\lib\mimetypes.py", line 259, in read_windows_registry
    for ctype in enum_types(mimedb):
  File "C:\DevTools\Python27\lib\mimetypes.py", line 249, in enum_types
    ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal not in range(128)

----------
components: Unicode, Windows
files: mimetypes.patch
keywords: patch
messages: 176990
nosy: Vladimir.Kotulskiy, ezio.melotti
priority: normal
severity: normal
status: open
title: mimetypes.py UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal not in range(128)
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file28210/mimetypes.patch

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

From report at bugs.python.org  Wed Dec  5 18:09:02 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Dec 2012 17:09:02 +0000
Subject: [New-bugs-announce] [issue16618] Different glob() results for
	strings and bytes
Message-ID: <1354727342.49.0.756705140261.issue16618@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

glob ignores names which starts with dot if pattern is not starts with dot. But this is wrong for bytes pattern in Python 3.

>>> import glob
>>> glob.glob('*hg')
[]
>>> glob.glob(b'*hg')
[b'.hg']

The proposed patch fixes this inconsistency. Also it contains new tests for this and some other possible cases.

----------
components: Library (Lib)
files: glob_dotfiles.patch
keywords: patch
messages: 176991
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Different glob() results for strings and bytes
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28211/glob_dotfiles.patch

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

From report at bugs.python.org  Wed Dec  5 20:28:31 2012
From: report at bugs.python.org (Bruno Dupuis)
Date: Wed, 05 Dec 2012 19:28:31 +0000
Subject: [New-bugs-announce] [issue16619] LOAD_GLOBAL used to load `None`
	under certain	circumstances
Message-ID: <1354735711.68.0.957152871087.issue16619@psf.upfronthosting.co.za>


New submission from Bruno Dupuis:

We found some strange behaviour of the compiler in this discussion on python-list: http://mail.python.org/pipermail/python-list/2012-December/636104.html

The fact is, `return` and `return None` result in inconsistent bytecode depending on the context.

Consider :

>>> import dis
>>> def f(x):
...     return None
... 
>>> dis.dis(f)
  2           0 LOAD_CONST               0 (None) 
              3 RETURN_VALUE         
>>> def g(x):
...     return None
...     print(x)
... 
>>> dis.dis(g)
  2           0 LOAD_GLOBAL              0 (None) 
              3 RETURN_VALUE         

  3           4 LOAD_GLOBAL              1 (print) 
              7 LOAD_FAST                0 (x) 
             10 CALL_FUNCTION            1 (1 positional, 0 keyword pair) 
             13 POP_TOP              

`return None` statement results in LOAD_GLOBAL 0 if there is some unreachable code after it. I first saw that as an optimization issue, but Ian Kelly's message http://mail.python.org/pipermail/python-list/2012-December/636117.html gives an extensive analysis and some examples:

"""
  I think this should even be considered a bug, not just a missing
  optimization.  Consider:

  >>> globals()['None'] = 42
  >>> def f(x):
  ...     return None
  ...     print(x)
  ...
  >>> f('test')
  42

  The use of the LOAD_GLOBAL allows None to effectively be reassigned.

"""

Ian also points out in this message that `return` and `return None` don't result in the same bytecode when followed by trash code.

----------
components: Interpreter Core
messages: 176999
nosy: Horpner, bruno.dupuis, ikelly, python-dev, stevenjd
priority: normal
severity: normal
status: open
title: LOAD_GLOBAL used to load `None` under certain circumstances
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Dec  5 20:34:09 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Dec 2012 19:34:09 +0000
Subject: [New-bugs-announce] [issue16620] Avoid using private function
	glob.glob1() in msi module	and tools
Message-ID: <1354736049.23.0.98660459286.issue16620@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Private function glob.glob1() used in Lib/msilib and Tools/msi to prevent unexpected globbing in parent directory name. ``glob.glob1(dirname, pattern)`` should be replaced by ``glob.glob(os.path.join(fnmatch.escape(dirname), pattern)`` in external code.

----------
components: Demos and Tools, Library (Lib)
messages: 177001
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Avoid using private function glob.glob1() in msi module and tools
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Dec  5 20:36:59 2012
From: report at bugs.python.org (Carlos Ferreira)
Date: Wed, 05 Dec 2012 19:36:59 +0000
Subject: [New-bugs-announce] [issue16621] sched module enhancement request
Message-ID: <1354736219.44.0.000463218427314.issue16621@psf.upfronthosting.co.za>


New submission from Carlos Ferreira:

The sched module available in the Python core lacks a simple but very useful which is waiting for new events scheduling.

Current version only process events that are present in the queue before the schedule.run() is issued or for events that are schedule while the scheduler is still active and processing events from the queue.

I propose a simple enhancement, by using an Event object from the threading module, so that the thread that is running the scheduler, waits for new events scheduling, after finishing processing all queued events.

The sched2.py is a modified version of the original sched.py (modified by means of a large hammer), which adds an "alwaysRunning" argument in the object constructor, a self.wakeUpEvent attribute which is the Event Object, a modified eterabs method to call the Event.set() and finally, a modified run() to wait for new events.

This modification is just a quick patch in order to pass the idea of what is being requested here. If there is a better way to do this, then it should be taken.

----------
components: Library (Lib)
files: sched2.py
messages: 177002
nosy: carlosmf.pt
priority: normal
severity: normal
status: open
title: sched module enhancement request
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file28214/sched2.py

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

From report at bugs.python.org  Wed Dec  5 22:13:23 2012
From: report at bugs.python.org (Steve OBrien)
Date: Wed, 05 Dec 2012 21:13:23 +0000
Subject: [New-bugs-announce] [issue16622] IDLE crashes on parentheses
Message-ID: <1354742003.92.0.600931221581.issue16622@psf.upfronthosting.co.za>


New submission from Steve OBrien:

Working in IDLE on Mac OSX 10.8 when I type a parentheses IDLE crashes.
Here is the output of the crash report:

Process:         Python [60507]
Path:            /Applications/Python 3.3/IDLE.app/Contents/MacOS/Python
Identifier:      org.python.IDLE
Version:         3.3.0 (3.3.0)
Code Type:       X86-64 (Native)
Parent Process:  launchd [324]
User ID:         493825946

Date/Time:       2012-12-05 13:04:49.616 -0800
OS Version:      Mac OS X 10.8.2 (12C60)
Report Version:  10

Interval Since Last Report:          112281 sec
Crashes Since Last Report:           4
Per-App Interval Since Last Report:  27530 sec
Per-App Crashes Since Last Report:   3
Anonymous UUID:                      337BE211-7572-210E-6815-99D0FE44035F

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1000) creating window shape'
terminate called throwing an exception
abort() called

Application Specific Backtrace 1:
0   CoreFoundation                      0x00007fff8e7050a6 __exceptionPreprocess + 198
1   libobjc.A.dylib                     0x00007fff91e733f0 objc_exception_throw + 43
2   CoreFoundation                      0x00007fff8e704e7c +[NSException raise:format:] + 204
3   AppKit                              0x00007fff8d7d0eb3 _NXCreateWindowWithStyleMask + 276
4   AppKit                              0x00007fff8d86591f _NSCreateWindow + 64
5   AppKit                              0x00007fff8d6e14bd -[NSWindow _commonAwake] + 2159
6   AppKit                              0x00007fff8d79185b -[NSWindow _makeKeyRegardlessOfVisibility] + 88
7   AppKit                              0x00007fff8d7917c5 -[NSWindow makeKeyAndOrderFront:] + 25
8   Tk                                  0x0000000101410c99 XMapWindow + 156
9   Tk                                  0x000000010137d3dc Tk_MapWindow + 89
10  Tk                                  0x00000001013862ea MapFrame + 62
11  Tcl                                 0x00000001012d8197 TclServiceIdle + 76
12  Tcl                                 0x00000001012bc5b6 Tcl_DoOneEvent + 329
13  Tk                                  0x000000010135c8c7 Tk_UpdateObjCmd + 162
14  Tcl                                 0x0000000101256c76 TclEvalObjvInternal + 782
15  Tcl                                 0x0000000101257e68 Tcl_EvalObjv + 66
16  _tkinter.so                         0x00000001007d75be Tkapp_Call + 190
17  Python                              0x00000001000de02e PyEval_EvalFrameEx + 29774
18  Python                              0x00000001000dd7cf PyEval_EvalFrameEx + 27631
19  Python                              0x00000001000dd7cf PyEval_EvalFrameEx + 27631
20  Python                              0x00000001000dd7cf PyEval_EvalFrameEx + 27631
21  Python                              0x00000001000df1b8 PyEval_EvalCodeEx + 2296
22  Python                              0x000000010003d67a function_call + 186
23  Python                              0x000000010000d418 PyObject_Call + 104
24  Python                              0x00000001000d9003 PyEval_EvalFrameEx + 9251
25  Python                              0x00000001000df1b8 PyEval_EvalCodeEx + 2296
26  Python                              0x000000010003d67a function_call + 186
27  Python                              0x000000010000d418 PyObject_Call + 104
28  Python                              0x00000001000d9003 PyEval_EvalFrameEx + 9251
29  Python                              0x00000001000df1b8 PyEval_EvalCodeEx + 2296
30  Python                              0x000000010003d67a function_call + 186
31  Python                              0x000000010000d418 PyObject_Call + 104
32  Python                              0x0000000100027b0a method_call + 138
33  Python                              0x000000010000d418 PyObject_Call + 104
34  Python                              0x00000001000d5197 PyEval_CallObjectWithKeywords + 87
35  _tkinter.so                         0x00000001007d58a8 PythonCmd + 456
36  Tcl                                 0x000000010125392f TclInvokeStringCommand + 105
37  Tcl                                 0x0000000101256c76 TclEvalObjvInternal + 782
38  Tcl                                 0x0000000101290138 TclExecuteByteCode + 4379
39  Tcl                                 0x0000000101296d8f TclCompEvalObj + 460
40  Tcl                                 0x000000010125823d TclEvalObjEx + 817
41  Tcl                                 0x00000001012d8494 AfterProc + 86
42  Tcl                                 0x00000001012d8391 TimerHandlerEventProc + 104
43  Tcl                                 0x00000001012bc2b3 Tcl_ServiceEvent + 147
44  Tcl                                 0x00000001012bc5a7 Tcl_DoOneEvent + 314
45  _tkinter.so                         0x00000001007d4e51 Tkapp_MainLoop + 177
46  Python                              0x00000001000de02e PyEval_EvalFrameEx + 29774
47  Python                              0x00000001000df1b8 PyEval_EvalCodeEx + 2296
48  Python                              0x00000001000dd647 PyEval_EvalFrameEx + 27239
49  Python                              0x00000001000dd7cf PyEval_EvalFrameEx + 27631
50  Python                              0x00000001000df1b8 PyEval_EvalCodeEx + 2296
51  Python                              0x00000001000df27f PyEval_EvalCode + 63
52  Python                              0x000000010010639b PyRun_FileExFlags + 187
53  Python                              0x00000001001066b6 PyRun_SimpleFileExFlags + 598
54  Python                              0x000000010011d783 Py_Main + 3203
55  Python                              0x0000000100000e0e Python + 3598
56  Python                              0x0000000100000c54 Python + 3156

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff9822b212 __pthread_kill + 10
1   libsystem_c.dylib             	0x00007fff8ea53af4 pthread_kill + 90
2   libsystem_c.dylib             	0x00007fff8ea97dce abort + 143
3   libc++abi.dylib               	0x00007fff9124fa17 abort_message + 257
4   libc++abi.dylib               	0x00007fff9124d3c6 default_terminate() + 28
5   libobjc.A.dylib               	0x00007fff91e73873 _objc_terminate() + 91
6   libc++abi.dylib               	0x00007fff9124d3f5 safe_handler_caller(void (*)()) + 8
7   libc++abi.dylib               	0x00007fff9124d450 std::terminate() + 16
8   libc++abi.dylib               	0x00007fff9124e5b7 __cxa_throw + 111
9   libobjc.A.dylib               	0x00007fff91e7350c objc_exception_throw + 327
10  com.apple.CoreFoundation      	0x00007fff8e704e7c +[NSException raise:format:] + 204
11  com.apple.AppKit              	0x00007fff8d7d0eb3 _NXCreateWindowWithStyleMask + 276
12  com.apple.AppKit              	0x00007fff8d86591f _NSCreateWindow + 64
13  com.apple.AppKit              	0x00007fff8d6e14bd -[NSWindow _commonAwake] + 2159
14  com.apple.AppKit              	0x00007fff8d79185b -[NSWindow _makeKeyRegardlessOfVisibility] + 88
15  com.apple.AppKit              	0x00007fff8d7917c5 -[NSWindow makeKeyAndOrderFront:] + 25
16  Tk                            	0x0000000101410c99 XMapWindow + 156
17  Tk                            	0x000000010137d3dc Tk_MapWindow + 89
18  Tk                            	0x00000001013862ea MapFrame + 62
19  Tcl                           	0x00000001012d8197 TclServiceIdle + 76
20  Tcl                           	0x00000001012bc5b6 Tcl_DoOneEvent + 329
21  Tk                            	0x000000010135c8c7 Tk_UpdateObjCmd + 162
22  Tcl                           	0x0000000101256c76 TclEvalObjvInternal + 782
23  Tcl                           	0x0000000101257e68 Tcl_EvalObjv + 66
24  _tkinter.so                   	0x00000001007d75be Tkapp_Call + 190
25  org.python.python             	0x00000001000de02e PyEval_EvalFrameEx + 29774
26  org.python.python             	0x00000001000dd7cf PyEval_EvalFrameEx + 27631
27  org.python.python             	0x00000001000dd7cf PyEval_EvalFrameEx + 27631
28  org.python.python             	0x00000001000dd7cf PyEval_EvalFrameEx + 27631
29  org.python.python             	0x00000001000df1b8 PyEval_EvalCodeEx + 2296
30  org.python.python             	0x000000010003d67a function_call + 186
31  org.python.python             	0x000000010000d418 PyObject_Call + 104
32  org.python.python             	0x00000001000d9003 PyEval_EvalFrameEx + 9251
33  org.python.python             	0x00000001000df1b8 PyEval_EvalCodeEx + 2296
34  org.python.python             	0x000000010003d67a function_call + 186
35  org.python.python             	0x000000010000d418 PyObject_Call + 104
36  org.python.python             	0x00000001000d9003 PyEval_EvalFrameEx + 9251
37  org.python.python             	0x00000001000df1b8 PyEval_EvalCodeEx + 2296
38  org.python.python             	0x000000010003d67a function_call + 186
39  org.python.python             	0x000000010000d418 PyObject_Call + 104
40  org.python.python             	0x0000000100027b0a method_call + 138
41  org.python.python             	0x000000010000d418 PyObject_Call + 104
42  org.python.python             	0x00000001000d5197 PyEval_CallObjectWithKeywords + 87
43  _tkinter.so                   	0x00000001007d58a8 PythonCmd + 456
44  Tcl                           	0x000000010125392f TclInvokeStringCommand + 105
45  Tcl                           	0x0000000101256c76 TclEvalObjvInternal + 782
46  Tcl                           	0x0000000101290138 TclExecuteByteCode + 4379
47  Tcl                           	0x0000000101296d8f TclCompEvalObj + 460
48  Tcl                           	0x000000010125823d TclEvalObjEx + 817
49  Tcl                           	0x00000001012d8494 AfterProc + 86
50  Tcl                           	0x00000001012d8391 TimerHandlerEventProc + 104
51  Tcl                           	0x00000001012bc2b3 Tcl_ServiceEvent + 147
52  Tcl                           	0x00000001012bc5a7 Tcl_DoOneEvent + 314
53  _tkinter.so                   	0x00000001007d4e51 Tkapp_MainLoop + 177
54  org.python.python             	0x00000001000de02e PyEval_EvalFrameEx + 29774
55  org.python.python             	0x00000001000df1b8 PyEval_EvalCodeEx + 2296
56  org.python.python             	0x00000001000dd647 PyEval_EvalFrameEx + 27239
57  org.python.python             	0x00000001000dd7cf PyEval_EvalFrameEx + 27631
58  org.python.python             	0x00000001000df1b8 PyEval_EvalCodeEx + 2296
59  org.python.python             	0x00000001000df27f PyEval_EvalCode + 63
60  org.python.python             	0x000000010010639b PyRun_FileExFlags + 187
61  org.python.python             	0x00000001001066b6 PyRun_SimpleFileExFlags + 598
62  org.python.python             	0x000000010011d783 Py_Main + 3203
63  Python                        	0x0000000100000e0e 0x100000000 + 3598
64  Python                        	0x0000000100000c54 0x100000000 + 3156

Thread 1:
0   libsystem_kernel.dylib        	0x00007fff9822b6d6 __workq_kernreturn + 10
1   libsystem_c.dylib             	0x00007fff8ea54eec _pthread_workq_return + 25
2   libsystem_c.dylib             	0x00007fff8ea54cb3 _pthread_wqthread + 412
3   libsystem_c.dylib             	0x00007fff8ea3f171 start_wqthread + 13

Thread 2:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib        	0x00007fff9822bd16 kevent + 10
1   libdispatch.dylib             	0x00007fff92af8dea _dispatch_mgr_invoke + 883
2   libdispatch.dylib             	0x00007fff92af89ee _dispatch_mgr_thread + 54

Thread 3:
0   libsystem_kernel.dylib        	0x00007fff9822b6d6 __workq_kernreturn + 10
1   libsystem_c.dylib             	0x00007fff8ea54eec _pthread_workq_return + 25
2   libsystem_c.dylib             	0x00007fff8ea54cb3 _pthread_wqthread + 412
3   libsystem_c.dylib             	0x00007fff8ea3f171 start_wqthread + 13

Thread 4:
0   libsystem_kernel.dylib        	0x00007fff9822b322 __select + 10
1   Tcl                           	0x00000001012efde3 NotifierThreadProc + 558
2   libsystem_c.dylib             	0x00007fff8ea52742 _pthread_start + 327
3   libsystem_c.dylib             	0x00007fff8ea3f181 thread_start + 13

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000000000006  rcx: 0x00007fff5fbfb528  rdx: 0x0000000000000000
  rdi: 0x0000000000001007  rsi: 0x0000000000000006  rbp: 0x00007fff5fbfb550  rsp: 0x00007fff5fbfb528
   r8: 0x00007fff7c768278   r9: 0x0000000000000015  r10: 0x0000000020000000  r11: 0x0000000000000206
  r12: 0x00007fff5fbfb6b0  r13: 0x0000000101827610  r14: 0x00007fff7c769180  r15: 0x00007fff5fbfb590
  rip: 0x00007fff9822b212  rfl: 0x0000000000000206  cr2: 0x00007fff7c761fe8
Logical CPU: 0

Binary Images:
       0x100000000 -        0x100000ff7 +Python (???) <B6BD9095-E447-FC67-101E-FACD12B76288> /Applications/Python 3.3/IDLE.app/Contents/MacOS/Python
       0x100003000 -        0x1001cafff +org.python.python (3.3.0, [c] 2004-2012 Python Software Foundation. - 3.3.0) <7322AE55-7D5B-D794-C34A-008F718FDD9E> /Library/Frameworks/Python.framework/Versions/3.3/Python
       0x1003ef000 -        0x1003effff +_bisect.so (???) <9B7DA040-0268-66BA-44D0-8B99D4DD5F5C> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/_bisect.so
       0x1003f4000 -        0x1003f5ff7 +_heapq.so (???) <5C90A077-D3A3-B15F-D979-DA502BACBCED> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/_heapq.so
       0x1003fa000 -        0x1003fbff7 +_posixsubprocess.so (???) <B3639CED-A4C9-1B9D-F400-1066704150CF> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/_posixsubprocess.so
       0x10073f000 -        0x100743ff7 +_struct.so (???) <DEC54C4D-6E5F-1714-1E2A-9402348E05AF> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/_struct.so
       0x10074a000 -        0x100754ff7 +_socket.so (???) <5A8950A5-94B3-F9CA-99AC-07A78A7F5064> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/_socket.so
       0x100760000 -        0x100762fff +time.so (???) <D43D60CC-8291-2FF2-B2A5-12FABF8D5F67> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/time.so
       0x1007c9000 -        0x1007ccfff +select.so (???) <D56DBA57-C9C7-D2B8-BB1C-4004AD996FE4> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/select.so
       0x1007d2000 -        0x1007d9ff7 +_tkinter.so (???) <7BAA763A-7C3E-3690-A57C-41E5E92958A8> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/_tkinter.so
       0x1007fc000 -        0x1007fdff7 +_random.so (???) <BD7DBCEC-79CA-7958-868A-41E8CE2D54ED> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/_random.so
       0x101246000 -        0x101323fef +Tcl (8.5.11 - 8.5.11) <985B2C1E-F571-8BE9-20CB-C9252A009C75> /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
       0x10134f000 -        0x10145dfff +Tk (8.5.11 - 8.5.11) <71FC9167-700A-4984-D34A-5E71E101C01F> /Library/Frameworks/Tk.framework/Versions/8.5/Tk
       0x1014df000 -        0x1014e4ff7 +math.so (???) <174FC328-DDD1-B9BA-7F5C-635AB356C246> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/math.so
       0x1014eb000 -        0x1014edff7 +_hashlib.so (???) <8D219436-DEC8-887D-6F07-08CEB0DD057D> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/_hashlib.so
       0x1014f1000 -        0x1014f2ff7 +fcntl.so (???) <B93A0365-6300-CD12-A10D-18FA9E98CF6F> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/fcntl.so
       0x1016c3000 -        0x1016d3ff7 +_pickle.so (???) <EBBBD928-66E1-A4CD-05D4-5AED4A48A9BB> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/_pickle.so
       0x1020d5000 -        0x1020dcfef +array.so (???) <36C1D84F-51B0-2128-CE0D-977FE11F512B> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/array.so
       0x108a48000 -        0x108aebfe7 +unicodedata.so (???) <8758869B-96C8-781F-8B5A-0FE9628A4430> /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/unicodedata.so
       0x109300000 -        0x109584ff7  com.apple.RawCamera.bundle (4.02 - 672) <03BC689F-CE3F-351D-AAD4-3D6C5E81F34C> /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera
    0x7fff60eb1000 -     0x7fff60ee593f  dyld (210.2.3) <A40597AA-5529-3337-8C09-D8A014EB1578> /usr/lib/dyld
    0x7fff8c22a000 -     0x7fff8c27fff7  libTIFF.dylib (845) <ADCB4683-69EB-318B-8BE7-5FDF38BCADAF> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
    0x7fff8c2bc000 -     0x7fff8c2e7fff  libxslt.1.dylib (11.3) <441776B8-9130-3893-956F-39C85FFA644F> /usr/lib/libxslt.1.dylib
    0x7fff8caa6000 -     0x7fff8caf5ff7  libcorecrypto.dylib (106.2) <CE0C29A3-C420-339B-ADAA-52F4683233CC> /usr/lib/system/libcorecrypto.dylib
    0x7fff8caf6000 -     0x7fff8cafdfff  libcopyfile.dylib (89) <876573D0-E907-3566-A108-577EAD1B6182> /usr/lib/system/libcopyfile.dylib
    0x7fff8cb09000 -     0x7fff8cb0bff7  libunc.dylib (25) <92805328-CD36-34FF-9436-571AB0485072> /usr/lib/system/libunc.dylib
    0x7fff8cb0c000 -     0x7fff8cb8cff7  com.apple.ApplicationServices.ATS (332 - 341.1) <BD83B039-AB25-3E3E-9975-A67DAE66988B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
    0x7fff8cb8d000 -     0x7fff8cb91fff  libpam.2.dylib (20) <C8F45864-5B58-3237-87E1-2C258A1D73B8> /usr/lib/libpam.2.dylib
    0x7fff8cb92000 -     0x7fff8cb94fff  com.apple.securityhi (4.0 - 55002) <34E45C60-DC7E-3FCC-A1ED-EBF48B77C559> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
    0x7fff8cba2000 -     0x7fff8cda2fff  libicucore.A.dylib (491.11.1) <CC318A27-878A-38CE-9292-1B98353FA9C7> /usr/lib/libicucore.A.dylib
    0x7fff8cda3000 -     0x7fff8cda3fff  com.apple.CoreServices (57 - 57) <9DD44CB0-C644-35C3-8F57-0B41B3EC147D> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
    0x7fff8cda4000 -     0x7fff8cea1ff7  libxml2.2.dylib (22.3) <47B09CB2-C636-3024-8B55-6040F7829B4C> /usr/lib/libxml2.2.dylib
    0x7fff8d13d000 -     0x7fff8d181fff  libcups.2.dylib (327) <9B3F3321-D2BC-3195-BF20-4008FC52A390> /usr/lib/libcups.2.dylib
    0x7fff8d29c000 -     0x7fff8d2d9fe7  libGLImage.dylib (8.6.1) <7F31DD61-3110-3541-A9BB-035CD1262E50> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
    0x7fff8d522000 -     0x7fff8d528fff  com.apple.DiskArbitration (2.5.1 - 2.5.1) <F7DAF7CC-5893-3F06-9168-3B0192B66D15> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
    0x7fff8d584000 -     0x7fff8e1b1ff7  com.apple.AppKit (6.8 - 1187.34) <1FF64844-EB62-3F96-AED7-6525B7CCEC23> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
    0x7fff8e1b4000 -     0x7fff8e1e5ff7  com.apple.DictionaryServices (1.2 - 184.4) <054F2D6F-9CFF-3EF1-9778-25C551B616C1> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
    0x7fff8e1e6000 -     0x7fff8e1f4fff  libcommonCrypto.dylib (60026) <2D6537F5-1B5E-305C-A1CF-D1FA80CA3939> /usr/lib/system/libcommonCrypto.dylib
    0x7fff8e1f5000 -     0x7fff8e1fbfff  libGFXShared.dylib (8.6.1) <CF55E720-1B9E-3E24-A1DA-7FA8B261CD8E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
    0x7fff8e2ed000 -     0x7fff8e2f1fff  libGIF.dylib (845) <2690CE83-E934-3EF8-A30A-996EDADCE3E4> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
    0x7fff8e2f2000 -     0x7fff8e2fdfff  com.apple.CommonAuth (3.0 - 2.0) <74A86DDD-57D0-3178-AB74-E1F31DBFFC39> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
    0x7fff8e2fe000 -     0x7fff8e325ff7  com.apple.PerformanceAnalysis (1.16 - 16) <E4888388-F41B-313E-9CBB-5807D077BDA9> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
    0x7fff8e326000 -     0x7fff8e446fff  com.apple.desktopservices (1.7.2 - 1.7.2) <CDE8C2C2-C505-31B0-8C61-E40E4EA364A5> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
    0x7fff8e4a4000 -     0x7fff8e4affff  libsystem_notify.dylib (98.5) <C49275CC-835A-3207-AFBA-8C01374927B6> /usr/lib/system/libsystem_notify.dylib
    0x7fff8e4bc000 -     0x7fff8e506ff7  libGLU.dylib (8.6.1) <DF45C1E3-3884-3991-B84F-F39B482E8BF8> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
    0x7fff8e507000 -     0x7fff8e5a5ff7  com.apple.ink.framework (10.8.2 - 150) <84B9825C-3822-375F-BE58-A753444FBDE2> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
    0x7fff8e651000 -     0x7fff8e671fff  libPng.dylib (845) <C3CDD2B4-3CB0-3F6D-8411-DAAF267E952B> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
    0x7fff8e672000 -     0x7fff8e85bfff  com.apple.CoreFoundation (6.8 - 744.12) <EF002794-DAEF-31C6-866C-E3E3AC387A9F> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff8e85c000 -     0x7fff8e85cfff  com.apple.Accelerate (1.8 - Accelerate 1.8) <6AD48543-0864-3D40-80CE-01F184F24B45> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
    0x7fff8e909000 -     0x7fff8ea22ff7  com.apple.ImageIO.framework (3.2.0 - 845) <553B9828-A7D9-3AE4-A214-1C33417545FD> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
    0x7fff8ea3e000 -     0x7fff8eb0afe7  libsystem_c.dylib (825.25) <8CBCF9B9-EBB7-365E-A3FF-2F3850763C6B> /usr/lib/system/libsystem_c.dylib
    0x7fff8eb2e000 -     0x7fff8eb4fff7  libCRFSuite.dylib (33) <736ABE58-8DED-3289-A042-C25AF7AE5B23> /usr/lib/libCRFSuite.dylib
    0x7fff8ebd3000 -     0x7fff8ebd7fff  com.apple.IOSurface (86.0.3 - 86.0.3) <C121DE83-ED12-3DC1-BDB3-4FCB29AB0571> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
    0x7fff8ebe7000 -     0x7fff8ecacff7  com.apple.coreui (2.0 - 181.1) <83D2C92D-6842-3C9D-9289-39D5B4554C3A> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
    0x7fff8ed04000 -     0x7fff8ee55fff  com.apple.audio.toolbox.AudioToolbox (1.8 - 1.8) <833DA682-A3C1-39E7-AEC3-9EDC734DE2A9> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
    0x7fff8ee56000 -     0x7fff8ee64ff7  libsystem_network.dylib (77.10) <0D99F24E-56FE-380F-B81B-4A4C630EE587> /usr/lib/system/libsystem_network.dylib
    0x7fff8ee79000 -     0x7fff8f1d5fff  com.apple.Foundation (6.8 - 945.11) <A5D41956-A354-3ACC-9355-BE200072223B> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
    0x7fff8f1d6000 -     0x7fff8f2cbfff  libiconv.2.dylib (34) <FEE8B996-EB44-37FA-B96E-D379664DEFE1> /usr/lib/libiconv.2.dylib
    0x7fff8f2cc000 -     0x7fff8f31bff7  libFontRegistry.dylib (100) <2E03D7DA-9B8F-31BB-8FB5-3D3B6272127F> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
    0x7fff8f31c000 -     0x7fff8f379fff  com.apple.audio.CoreAudio (4.1.0 - 4.1.0) <B3198BD6-EA1D-3E5E-ADD4-37D8E6B72678> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
    0x7fff8f45e000 -     0x7fff8f461fff  com.apple.help (1.3.2 - 42) <343904FE-3022-3573-97D6-5FE17F8643BA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
    0x7fff8f533000 -     0x7fff8f589fff  com.apple.HIServices (1.20 - 417) <A1129272-FEC8-350B-BA26-5A97F23C413D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
    0x7fff8f5ce000 -     0x7fff8f5f0ff7  libxpc.dylib (140.41) <FAC04D8B-680E-325F-8F0C-DD69859D0E01> /usr/lib/system/libxpc.dylib
    0x7fff8f609000 -     0x7fff8f61cff7  com.apple.LangAnalysis (1.7.0 - 1.7.0) <2F2694E9-A7BC-33C7-B4CF-8EC907DF0FEB> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
    0x7fff8f61d000 -     0x7fff8f7cbfff  com.apple.QuartzCore (1.8 - 304.0) <BDC66714-F60C-386D-A773-F897D1E87AB6> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
    0x7fff8f981000 -     0x7fff8f98cff7  com.apple.bsd.ServiceManagement (2.0 - 2.0) <C12962D5-85FB-349E-AA56-64F4F487F219> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
    0x7fff8f99b000 -     0x7fff8f99bfff  com.apple.ApplicationServices (45 - 45) <A3ABF20B-ED3A-32B5-830E-B37831A45A80> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
    0x7fff90251000 -     0x7fff90252fff  libsystem_blocks.dylib (59) <D92DCBC3-541C-37BD-AADE-ACC75A0C59C8> /usr/lib/system/libsystem_blocks.dylib
    0x7fff90253000 -     0x7fff902afff7  com.apple.Symbolication (1.3 - 93) <F2C7E0B6-B241-3020-B30A-0636D0FA3378> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
    0x7fff902b6000 -     0x7fff90367fff  com.apple.LaunchServices (539.7 - 539.7) <DA7C602E-5E01-31B8-925D-B45360CA089F> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
    0x7fff90368000 -     0x7fff903d0fff  libvDSP.dylib (380.6) <CD4C5EEB-9E63-30C4-8103-7A5EAEA0BE60> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
    0x7fff903d1000 -     0x7fff907c8fff  libLAPACK.dylib (1073.4) <D632EC8B-2BA0-3853-800A-20DA00A1091C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
    0x7fff907c9000 -     0x7fff907cbfff  libCVMSPluginSupport.dylib (8.6.1) <7EFDA31E-E463-3897-A8DC-7FD266EB713E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
    0x7fff907cc000 -     0x7fff90803ff7  libssl.0.9.8.dylib (47) <923945E6-C489-3406-903B-A362410753F8> /usr/lib/libssl.0.9.8.dylib
    0x7fff90848000 -     0x7fff9085ffff  com.apple.CFOpenDirectory (10.8 - 151.10) <FFBBA538-00B5-334E-BA5B-C8AD6CDCDA14> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
    0x7fff90860000 -     0x7fff9087dfff  com.apple.openscripting (1.3.6 - 148.2) <33B87CFB-CACC-3EBC-893D-38AECB94FB8A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
    0x7fff9087e000 -     0x7fff90893fff  com.apple.ImageCapture (8.0 - 8.0) <17A45CE6-7DA3-36A5-B7EF-72BC136981AE> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
    0x7fff90894000 -     0x7fff90921ff7  com.apple.SearchKit (1.4.0 - 1.4.0) <C7F43889-F8BF-3CB9-AD66-11AEFCBCEDE7> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
    0x7fff90922000 -     0x7fff90961ff7  com.apple.QD (3.42 - 285) <8DF36FCA-C06B-30F4-A631-7BE2FF7E56D1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
    0x7fff90e58000 -     0x7fff910fcfff  com.apple.CoreImage (8.2.2 - 1.0.1) <930B0B23-DD84-3B0C-B5A9-C09B7068A6F0> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage
    0x7fff911a5000 -     0x7fff9124bff7  com.apple.CoreServices.OSServices (557.4 - 557.4) <841878A8-6F3E-300D-8F01-444B3CC1F41D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
    0x7fff9124c000 -     0x7fff91271ff7  libc++abi.dylib (24.4) <E7BD9363-1D25-3551-A68A-2E2FF6ABECD7> /usr/lib/libc++abi.dylib
    0x7fff91272000 -     0x7fff912beff7  libauto.dylib (185.1) <73CDC482-16E3-3FC7-9BB4-FBA2DA44DBC2> /usr/lib/libauto.dylib
    0x7fff912bf000 -     0x7fff91341fff  com.apple.Heimdal (3.0 - 2.0) <660A6C64-4912-32C8-A332-B64164032A2D> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
    0x7fff91342000 -     0x7fff91577ff7  com.apple.CoreData (106.1 - 407.7) <24E0A6B4-9ECA-3D12-B26A-72B9DCF09768> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
    0x7fff91578000 -     0x7fff91635ff7  com.apple.ColorSync (4.8.0 - 4.8.0) <6CE333AE-EDDB-3768-9598-9DB38041DC55> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
    0x7fff91735000 -     0x7fff91a65ff7  com.apple.HIToolbox (2.0 - 625) <317F75F7-4B0F-35F5-89A7-F20BA60AC944> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
    0x7fff91a92000 -     0x7fff91ad5ff7  com.apple.bom (12.0 - 192) <0BF1F2D2-3648-36B7-BE4B-551A0173209B> /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom
    0x7fff91d6c000 -     0x7fff91dc3ff7  com.apple.ScalableUserInterface (1.0 - 1) <F1D43DFB-1796-361B-AD4B-39F1EED3BE19> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface
    0x7fff91e52000 -     0x7fff91e61ff7  libxar.1.dylib (105) <370ED355-E516-311E-BAFD-D80633A84BE1> /usr/lib/libxar.1.dylib
    0x7fff91e62000 -     0x7fff91f7a92f  libobjc.A.dylib (532.2) <90D31928-F48D-3E37-874F-220A51FD9E37> /usr/lib/libobjc.A.dylib
    0x7fff91f7b000 -     0x7fff91f7cfff  libDiagnosticMessagesClient.dylib (8) <8548E0DC-0D2F-30B6-B045-FE8A038E76D8> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff91f96000 -     0x7fff91f97ff7  libsystem_sandbox.dylib (220) <3C3B03CF-C525-3CB3-8557-62E91B93AC95> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff9204c000 -     0x7fff9204fff7  libdyld.dylib (210.2.3) <F59367C9-C110-382B-A695-9035A6DD387E> /usr/lib/system/libdyld.dylib
    0x7fff92050000 -     0x7fff92059fff  com.apple.CommerceCore (1.0 - 26) <997CD214-BC78-3C61-A1B8-813EA1CB9997> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore
    0x7fff9205a000 -     0x7fff9215cfff  libcrypto.0.9.8.dylib (47) <74F165AD-4572-3B26-B0E2-A97477FE59D0> /usr/lib/libcrypto.0.9.8.dylib
    0x7fff9224f000 -     0x7fff92261ff7  libz.1.dylib (43) <2A1551E8-A272-3DE5-B692-955974FE1416> /usr/lib/libz.1.dylib
    0x7fff92262000 -     0x7fff92364fff  libJP2.dylib (845) <405CAF25-0AA5-3C6B-A4A6-94471A1EDD2F> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
    0x7fff92365000 -     0x7fff92366ff7  libSystem.B.dylib (169.3) <365477AB-D641-389D-B8F4-A1FAE9657EEE> /usr/lib/libSystem.B.dylib
    0x7fff9236b000 -     0x7fff92378fff  libbz2.1.0.dylib (29) <CE9785E8-B535-3504-B392-82F0064D9AF2> /usr/lib/libbz2.1.0.dylib
    0x7fff92379000 -     0x7fff923a7fff  com.apple.CoreServicesInternal (154.2 - 154.2) <3E6196E6-F3B4-316F-9E1F-13B6B9694C7E> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal
    0x7fff923a8000 -     0x7fff923aafff  com.apple.TrustEvaluationAgent (2.0 - 23) <A97D348B-32BF-3E52-8DF2-59BFAD21E1A3> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
    0x7fff923ab000 -     0x7fff923b0fff  com.apple.OpenDirectory (10.8 - 151.10) <CF44120B-9B01-32DD-852E-C9C0E1243FC0> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
    0x7fff92590000 -     0x7fff925b2ff7  com.apple.Kerberos (2.0 - 1) <C49B8820-34ED-39D7-A407-A3E854153556> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
    0x7fff925b3000 -     0x7fff925b3fff  com.apple.Accelerate.vecLib (3.8 - vecLib 3.8) <B5A18EE8-DF81-38DD-ACAF-7076B2A26225> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fff92638000 -     0x7fff92646fff  com.apple.Librarian (1.1 - 1) <1635162F-239A-341E-83C7-710C55E254AF> /System/Library/PrivateFrameworks/Librarian.framework/Versions/A/Librarian
    0x7fff92647000 -     0x7fff926afff7  libc++.1.dylib (65.1) <20E31B90-19B9-3C2A-A9EB-474E08F9FE05> /usr/lib/libc++.1.dylib
    0x7fff92717000 -     0x7fff929e7fff  com.apple.security (7.0 - 55179.1) <639641EF-8156-3190-890C-1053658E044A> /System/Library/Frameworks/Security.framework/Versions/A/Security
    0x7fff929e8000 -     0x7fff92af3fff  libFontParser.dylib (84.5) <617A7D30-C7BC-39FC-A1FE-59367B4A5719> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
    0x7fff92af4000 -     0x7fff92b09ff7  libdispatch.dylib (228.23) <D26996BF-FC57-39EB-8829-F63585561E09> /usr/lib/system/libdispatch.dylib
    0x7fff92e96000 -     0x7fff92ebdfff  com.apple.framework.familycontrols (4.1 - 410) <AE49B2AB-7D2B-3D52-8E21-60EBEA1A38E6> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
    0x7fff92f3a000 -     0x7fff92f44fff  com.apple.speech.recognition.framework (4.1.5 - 4.1.5) <D803919C-3102-3515-A178-61E9C86C46A1> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
    0x7fff92f45000 -     0x7fff92f9ffff  com.apple.print.framework.PrintCore (8.1 - 387.1) <1FA17B75-33E6-35BD-9198-35F92E37B248> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
    0x7fff930c8000 -     0x7fff930f4ff7  libRIP.A.dylib (324.6) <5A7EB5C2-BA60-36D7-BF41-9853F37837AA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
    0x7fff9335f000 -     0x7fff93363fff  libCGXType.A.dylib (324.6) <2FC25246-A69F-3F81-9AC6-0A1753E1C6A8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib
    0x7fff93493000 -     0x7fff934a7fff  com.apple.speech.synthesis.framework (4.1.12 - 4.1.12) <94EDF2AB-809C-3D15-BED5-7AD45B2A7C16> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
    0x7fff93533000 -     0x7fff93534ff7  libremovefile.dylib (23.1) <DBBFAF35-AC78-3856-92F6-6E4FD9DF14A2> /usr/lib/system/libremovefile.dylib
    0x7fff93586000 -     0x7fff935b4ff7  libsystem_m.dylib (3022.6) <B434BE5C-25AB-3EBD-BAA7-5304B34E3441> /usr/lib/system/libsystem_m.dylib
    0x7fff935f0000 -     0x7fff93625ff7  libTrueTypeScaler.dylib (84.5) <DF2335F3-07BE-30BA-B73C-3204E95B42C3> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib
    0x7fff93626000 -     0x7fff93632fff  com.apple.CrashReporterSupport (10.8.2 - 415) <55783BF9-125E-3F9C-A412-6A095ECD9353> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport
    0x7fff936ca000 -     0x7fff936cafff  com.apple.Cocoa (6.7 - 19) <1F77945C-F37A-3171-B22E-F7AB0FCBB4D4> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
    0x7fff93712000 -     0x7fff93729fff  com.apple.GenerationalStorage (1.1 - 132.2) <3F5C87BD-D866-3732-8CB9-D23ED9784D6E> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage
    0x7fff943b3000 -     0x7fff9444dfff  libvMisc.dylib (380.6) <714336EA-1C0E-3735-B31C-19DFDAAF6221> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
    0x7fff9444e000 -     0x7fff9446dff7  com.apple.ChunkingLibrary (2.0 - 133.2) <D2A746DE-002A-3C6C-961E-BE94E71DB835> /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary
    0x7fff948ab000 -     0x7fff948abfff  libkeymgr.dylib (25) <CC9E3394-BE16-397F-926B-E579B60EE429> /usr/lib/system/libkeymgr.dylib
    0x7fff948ac000 -     0x7fff948b1fff  libcache.dylib (57) <65187C6E-3FBF-3EB8-A1AA-389445E2984D> /usr/lib/system/libcache.dylib
    0x7fff948b2000 -     0x7fff94933fff  com.apple.Metadata (10.7.0 - 707.3) <A45D75C1-B311-39F0-AF4A-63FCCC098C1D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
    0x7fff94934000 -     0x7fff94934ffd  com.apple.audio.units.AudioUnit (1.8 - 1.8) <29E2C990-3617-3FA2-BDD7-DB7DF493E443> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
    0x7fff94935000 -     0x7fff94942ff7  com.apple.NetAuth (4.0 - 4.0) <F5BC7D7D-AF28-3C83-A674-DADA48FF7810> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
    0x7fff94985000 -     0x7fff949f2fff  com.apple.datadetectorscore (4.0 - 269.1) <C94C372B-3821-3A46-A8C2-091AB1CFF7F4> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
    0x7fff94d4d000 -     0x7fff94d6cff7  libresolv.9.dylib (51) <0882DC2D-A892-31FF-AD8C-0BB518C48B23> /usr/lib/libresolv.9.dylib
    0x7fff94d6e000 -     0x7fff94d7afff  libCSync.A.dylib (324.6) <2033247A-CABC-3E20-8498-7367A8F44A08> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
    0x7fff94ec7000 -     0x7fff94ec7fff  com.apple.vecLib (3.8 - vecLib 3.8) <794317C7-4E38-338A-A874-5E18001C8503> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fff94ec8000 -     0x7fff94ed0ff7  libsystem_dnssd.dylib (379.32.1) <62AA0B84-188A-348B-8F9E-3E2DB08DB93C> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff94ed1000 -     0x7fff94ed2fff  liblangid.dylib (116) <864C409D-D56B-383E-9B44-A435A47F2346> /usr/lib/liblangid.dylib
    0x7fff94f11000 -     0x7fff958a1c67  com.apple.CoreGraphics (1.600.0 - 324.6) <DCC70C6E-AB6D-3457-A823-7569CB29B107> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
    0x7fff958a2000 -     0x7fff9590fff7  com.apple.framework.IOKit (2.0 - 755.18.10) <142E19DD-1C8D-3D61-ABC8-83994A73279F> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
    0x7fff95910000 -     0x7fff959eaff7  com.apple.backup.framework (1.4.1 - 1.4.1) <A3CFCA9E-717C-302D-821B-16FD35E6673F> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup
    0x7fff959eb000 -     0x7fff959f0fff  libcompiler_rt.dylib (30) <08F8731D-5961-39F1-AD00-4590321D24A9> /usr/lib/system/libcompiler_rt.dylib
    0x7fff95a45000 -     0x7fff95a59fff  libGL.dylib (8.6.1) <2E00615F-97F5-34EB-BE07-75A24F3C18D7> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
    0x7fff95ba7000 -     0x7fff95d2dfff  libBLAS.dylib (1073.4) <C102C0F6-8CB6-3B49-BA6B-2EB61F0B2784> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
    0x7fff95d40000 -     0x7fff95d6aff7  com.apple.CoreVideo (1.8 - 99.3) <C424838A-889C-39E5-8108-FD05C93D26A0> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
    0x7fff95d6b000 -     0x7fff95d71fff  libmacho.dylib (829) <BF332AD9-E89F-387E-92A4-6E1AB74BD4D9> /usr/lib/system/libmacho.dylib
    0x7fff95d72000 -     0x7fff95ee6fff  com.apple.CFNetwork (596.2.3 - 596.2.3) <6A16C2BD-1035-30F9-AE96-D9E3BB54A976> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
    0x7fff96ea9000 -     0x7fff96eb7ff7  libkxld.dylib (2050.18.24) <7027CE49-007D-3553-8FFA-3E3B428B2316> /usr/lib/system/libkxld.dylib
    0x7fff96eb8000 -     0x7fff96efbfff  com.apple.RemoteViewServices (2.0 - 80.5) <F3A897C9-A277-3B56-8FB3-2BC2C10C33BF> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices
    0x7fff971c0000 -     0x7fff971cdfff  com.apple.AppleFSCompression (49 - 1.0) <5508344A-2A7E-3122-9562-6F363910A80E> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
    0x7fff971ce000 -     0x7fff975ebfff  FaceCoreLight (2.4.1) <A34C9575-C4C1-31B1-809B-7751070B4E8B> /System/Library/PrivateFrameworks/FaceCoreLight.framework/Versions/A/FaceCoreLight
    0x7fff975ec000 -     0x7fff976e9fff  libsqlite3.dylib (138.1) <ADE9CB98-D77D-300C-A32A-556B7440769F> /usr/lib/libsqlite3.dylib
    0x7fff976ed000 -     0x7fff97700ff7  libbsm.0.dylib (32) <F497D3CE-40D9-3551-84B4-3D5E39600737> /usr/lib/libbsm.0.dylib
    0x7fff97afb000 -     0x7fff97b23fff  libJPEG.dylib (845) <A32618D7-FB91-3EE2-A105-5407B2F3F8D8> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
    0x7fff97b24000 -     0x7fff97b7aff7  com.apple.opencl (2.1.20 - 2.1.20) <AF142CA4-EA1D-31B0-A48F-AA2B75D4309E> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
    0x7fff97bed000 -     0x7fff97bf3ff7  libunwind.dylib (35.1) <21703D36-2DAB-3D8B-8442-EAAB23C060D3> /usr/lib/system/libunwind.dylib
    0x7fff97bf4000 -     0x7fff97bfbfff  com.apple.NetFS (5.0 - 4.0) <82E24B9A-7742-3DA3-9E99-ED267D98C05E> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
    0x7fff97ca5000 -     0x7fff97ca7ff7  com.apple.print.framework.Print (8.0 - 258) <34666CC2-B86D-3313-B3B6-A9977AD593DA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
    0x7fff97ca8000 -     0x7fff97fbfff7  com.apple.CoreServices.CarbonCore (1037.3 - 1037.3) <DF7CABCA-F2CB-345B-8EFF-F0F4E937B7FF> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
    0x7fff97fc0000 -     0x7fff97fd6fff  com.apple.MultitouchSupport.framework (235.28 - 235.28) <BD78B16E-9B5A-3E07-93B4-13AD1A538CAC> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
    0x7fff98040000 -     0x7fff98043fff  libRadiance.dylib (845) <E8956A35-494E-3014-8B86-362D32576116> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
    0x7fff98044000 -     0x7fff980adfff  libstdc++.6.dylib (56) <EAA2B53E-EADE-39CF-A0EF-FB9D4940672A> /usr/lib/libstdc++.6.dylib
    0x7fff98137000 -     0x7fff98194ff7  com.apple.AE (645.3 - 645.3) <FF867ACA-8628-3E5A-8FA0-AF429B42C5D7> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
    0x7fff98214000 -     0x7fff98218fff  libCoreVMClient.dylib (24.4) <55F71158-ADEE-3863-92E9-4772DCEA8E31> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
    0x7fff98219000 -     0x7fff98234ff7  libsystem_kernel.dylib (2050.18.24) <C0535565-35D1-31A7-A744-63D9F10F12A4> /usr/lib/system/libsystem_kernel.dylib
    0x7fff98251000 -     0x7fff982cfff7  com.apple.securityfoundation (6.0 - 55115.4) <C5461971-E455-31A6-99B8-AF80C4BC26DD> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
    0x7fff98370000 -     0x7fff9837fff7  com.apple.opengl (1.8.6 - 1.8.6) <720CC06C-0D01-37AE-BB3D-D7F0242B262A> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
    0x7fff983b9000 -     0x7fff983b9fff  libOpenScriptingUtil.dylib (148.2) <B8061D13-C1B2-38D5-A723-9A98D64E67AC> /usr/lib/libOpenScriptingUtil.dylib
    0x7fff983ba000 -     0x7fff983bbff7  libdnsinfo.dylib (453.18) <E7595861-ECF9-336E-9901-BED2620FAA80> /usr/lib/system/libdnsinfo.dylib
    0x7fff983bc000 -     0x7fff983f2fff  libsystem_info.dylib (406.17) <4FFCA242-7F04-365F-87A6-D4EFB89503C1> /usr/lib/system/libsystem_info.dylib
    0x7fff983f3000 -     0x7fff98414fff  com.apple.Ubiquity (1.2 - 243.10) <F97D3A33-2C8B-3CFF-AF75-A74866D42853> /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity
    0x7fff986dc000 -     0x7fff98712fff  com.apple.DebugSymbols (98 - 98) <14E788B1-4EB2-3FD7-934B-849534DFC198> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
    0x7fff9872e000 -     0x7fff98732ff7  com.apple.TCC (1.0 - 1) <F2F3B753-FC73-3543-8BBE-859FDBB4D6A6> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
    0x7fff98766000 -     0x7fff98901fef  com.apple.vImage (6.0 - 6.0) <FAE13169-295A-33A5-8E6B-7C2CC1407FA7> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
    0x7fff98e0d000 -     0x7fff98ea7fff  com.apple.CoreSymbolication (3.0 - 87) <75F2C0DD-549A-36F6-BD9E-FB40A924344F> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
    0x7fff98ea8000 -     0x7fff98ea8fff  com.apple.Carbon (154 - 155) <372716D2-6FA1-3611-8501-3DD1D4A6E8C8> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
    0x7fff98ea9000 -     0x7fff98eabfff  libquarantine.dylib (52) <4BE2E642-A14F-340A-B482-5BD2AEFD9C24> /usr/lib/system/libquarantine.dylib
    0x7fff98f6c000 -     0x7fff9903eff7  com.apple.CoreText (260.0 - 275.16) <5BFC1D67-6A6F-38BC-9D90-9C712684EDAC> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
    0x7fff9906b000 -     0x7fff99073fff  liblaunch.dylib (442.26.2) <2F71CAF8-6524-329E-AC56-C506658B4C0C> /usr/lib/system/liblaunch.dylib
    0x7fff99074000 -     0x7fff990aefff  com.apple.GSS (3.0 - 2.0) <0BDF8090-5EF4-3759-94DE-8521D74188AA> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
    0x7fff99155000 -     0x7fff991a6ff7  com.apple.SystemConfiguration (1.12.2 - 1.12.2) <E095637C-457F-3D8F-AE32-A032F9D5A46C> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
    0x7fff991a7000 -     0x7fff991abff7  com.apple.CommonPanels (1.2.5 - 94) <AAC003DE-2D6E-38B7-B66B-1F3DA91E7245> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 2
    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: 84208
    thread_create: 5
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=153.5M resident=92.7M(60%) swapped_out_or_unallocated=60.8M(40%)
Writable regions: Total=124.0M written=12.6M(10%) resident=32.5M(26%) swapped_out=1332K(1%) unallocated=91.4M(74%)
 
REGION TYPE                      VIRTUAL
===========                      =======
CG backing stores                  3244K
CG image                              4K
CG shared images                    224K
CoreServices                       2672K
MALLOC                             91.1M
MALLOC guard page                    48K
MALLOC_LARGE (reserved)             512K        reserved VM address space (unallocated)
Memory tag=240                        4K
Memory tag=242                       12K
Memory tag=251                        8K
STACK GUARD                        56.0M
Stack                              9820K
VM_ALLOCATE                        16.1M
__DATA                             11.6M
__IMAGE                             528K
__LINKEDIT                         54.4M
__TEXT                             99.2M
__UNICODE                           544K
mapped file                        41.5M
shared memory                       308K
===========                      =======
TOTAL                             387.3M
TOTAL, minus reserved VM space    386.8M

Model: MacBookPro8,2, BootROM MBP81.0047.B27, 4 processors, Intel Core i7, 2.2 GHz, 8 GB, SMC 1.69f3
Graphics: Intel HD Graphics 3000, Intel HD Graphics 3000, Built-In, 512 MB
Graphics: AMD Radeon HD 6750M, AMD Radeon HD 6750M, PCIe, 1024 MB
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80CE, 0x4D34373142353237334448302D4348392020
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80CE, 0x4D34373142353237334448302D4348392020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xD6), Broadcom BCM43xx 1.0 (5.106.98.81.22)
Bluetooth: Version 4.0.9f33 10885, 2 service, 18 devices, 1 incoming serial ports
Network Service: Ethernet, Ethernet, en0
Network Service: AirPort, AirPort, en1
Serial ATA Device: TOSHIBA MK7559GSXF, 750.16 GB
Serial ATA Device: MATSHITADVD-R   UJ-898
USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8509, 0xfa200000 / 3
USB Device: hub_device, 0x0424  (SMSC), 0x2513, 0xfa100000 / 2
USB Device: BRCM2070 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0xfa110000 / 5
USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x821a, 0xfa113000 / 7
USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0245, 0xfa120000 / 4
USB Device: hub_device, 0x0424  (SMSC), 0x2513, 0xfd100000 / 2
USB Device: USB2.0 Hub, 0x05e3  (Genesys Logic, Inc.), 0x0608, 0xfd120000 / 4
USB Device: USB Receiver, 0x046d  (Logitech Inc.), 0xc508, 0xfd122000 / 7
USB Device: DualHead2Go-DP, 0x18ea, 0x0009, 0xfd121000 / 6
USB Device: USB2.0 Hub, 0x05e3  (Genesys Logic, Inc.), 0x0608, 0xfd123000 / 5
USB Device: Backup+ Desk, 0x0bc2  (Seagate LLC), 0xa0a1, 0xfd123200 / 9
USB Device: IR Receiver, apple_vendor_id, 0x8242, 0xfd110000 / 3

----------
components: IDLE
messages: 177010
nosy: Steve.OBrien
priority: normal
severity: normal
status: open
title: IDLE crashes on parentheses
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Wed Dec  5 23:03:21 2012
From: report at bugs.python.org (Roy Smith)
Date: Wed, 05 Dec 2012 22:03:21 +0000
Subject: [New-bugs-announce] [issue16623] argparse help formatter does not
	honor non-breaking space
Message-ID: <1354745001.59.0.580615965604.issue16623@psf.upfronthosting.co.za>


New submission from Roy Smith:

Running this code:

---------------------------------------
import argparse

p = argparse.ArgumentParser()
p.add_argument('--foo',
               help=u'This is a very long help string.  ex: "--s3\u00A0s3://my.bucket/dir1/dir2"')
p.parse_args()
---------------------------------------

produces:

---------------------------------------
$ ./arg.py  --help
usage: arg.py [-h] [--foo FOO]

optional arguments:
  -h, --help  show this help message and exit
  --foo FOO   This is a very long help string. ex: "--s3
              s3://my.bucket/dir1/dir2"
---------------------------------------

It should not be breaking the line at a non-breaking space.  I'm running:

Python 2.7.3 (default, Aug  1 2012, 05:14:39) 
[GCC 4.6.3] on linux2

----------
components: Library (Lib)
messages: 177012
nosy: roysmith
priority: normal
severity: normal
status: open
title: argparse help formatter does not honor non-breaking space
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec  5 23:54:17 2012
From: report at bugs.python.org (Zack Weinberg)
Date: Wed, 05 Dec 2012 22:54:17 +0000
Subject: [New-bugs-announce] [issue16624] subprocess.check_output should
	allow specifying stdin as	a string
Message-ID: <1354748057.02.0.623269532787.issue16624@psf.upfronthosting.co.za>


New submission from Zack Weinberg:

subprocess.check_output calls Popen.communicate but does not allow you to specify its argument (i.e. data to send to the child process's stdin).  It would be nice if it were enhanced to allow this.  Proposed patch attached (to the 2.7 subprocess.py; should apply with trivial changes in 3.x).

----------
components: Library (Lib)
files: subprocess-check-output-allow-input.diff
keywords: patch
messages: 177014
nosy: zwol
priority: normal
severity: normal
status: open
title: subprocess.check_output should allow specifying stdin as a string
type: enhancement
Added file: http://bugs.python.org/file28218/subprocess-check-output-allow-input.diff

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

From report at bugs.python.org  Thu Dec  6 07:43:23 2012
From: report at bugs.python.org (Sworddragon)
Date: Thu, 06 Dec 2012 06:43:23 +0000
Subject: [New-bugs-announce] [issue16625] Exception on mode 'br'
Message-ID: <1354776203.28.0.947074059507.issue16625@psf.upfronthosting.co.za>


New submission from Sworddragon:

The mode 'br' on open() can cause an exception with the following message: "ValueError: mode string must begin with one of 'r', 'w', 'a' or 'U', not 'br'". Curriously most times the mode 'br' is working fine and I'm not able to create a simple test case where it fails. Only in one of my scripts it fails with an exception (in the attachments is an example).

----------
components: Interpreter Core
files: error.log
messages: 177028
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Exception on mode 'br'
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file28220/error.log

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

From report at bugs.python.org  Thu Dec  6 12:17:19 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Dec 2012 11:17:19 +0000
Subject: [New-bugs-announce] [issue16626] Infinite recursion in
	glob.glob('*:') on Windows
Message-ID: <1354792639.08.0.445639143612.issue16626@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

glob.glob() can fall in infinite recursion (causing stack overflow) on Windows with patterns which contains metacharacters in drive or UNC path ('*:foo', r'\\?\c:\bar'). This is my assumption, someone should confirm it on Windows.

Here is a patch, which fix an infinite recursion.

----------
components: Library (Lib), Windows
files: glob_magic_in_drive.patch
keywords: patch
messages: 177038
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Infinite recursion in glob.glob('*:') on Windows
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28221/glob_magic_in_drive.patch

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

From report at bugs.python.org  Thu Dec  6 12:29:27 2012
From: report at bugs.python.org (Singer Song)
Date: Thu, 06 Dec 2012 11:29:27 +0000
Subject: [New-bugs-announce] [issue16627] comparison problem of two 'dict'
	objects
Message-ID: <1354793367.35.0.329772791063.issue16627@psf.upfronthosting.co.za>


New submission from Singer Song:

#python code:
a={600072:1, 80000880:2, 600243:3, 600495:4, 80002529:5}
b={600072:1, 80000880:2, 600243:3, 80002529:5, 600495:4}
print(a)
print(b)
print(a==b)
print(str(a)==str(b))
print(a.keys()==b.keys())

#output in python2.7.3:
{600072: 1, 80000880: 2, 600243: 3, 80002529: 5, 600495: 4}
{600072: 1, 80000880: 2, 600243: 3, 600495: 4, 80002529: 5}
True
False
False

#output in python3.2.3:
{600072: 1, 80000880: 2, 600243: 3, 80002529: 5, 600495: 4}
{600072: 1, 80000880: 2, 600243: 3, 600495: 4, 80002529: 5}
True
False
True

#two questions:
1)str(a) and str(b) are different, why?
2)keys method returns different result between python2.7.3 and python3.2.3

----------
components: Interpreter Core
messages: 177039
nosy: singer
priority: normal
severity: normal
status: open
title: comparison problem of two 'dict' objects
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Dec  6 20:58:48 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Dec 2012 19:58:48 +0000
Subject: [New-bugs-announce] [issue16628] leak in ctypes.resize()
Message-ID: <1354823928.79.0.806934333118.issue16628@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

ctypes.resize() (and/or the deallocator) can leak because of a logic error. Attached patch seems to fix it.

----------
components: Library (Lib)
files: ctypesresizeleak.patch
keywords: patch
messages: 177052
nosy: amaury.forgeotdarc, belopolsky, meador.inge, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: leak in ctypes.resize()
type: resource usage
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28226/ctypesresizeleak.patch

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

From report at bugs.python.org  Fri Dec  7 02:29:31 2012
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 07 Dec 2012 01:29:31 +0000
Subject: [New-bugs-announce] [issue16629] IDLE: Calltips test fails due to
	int docstring change
Message-ID: <1354843771.05.0.636250293313.issue16629@psf.upfronthosting.co.za>


New submission from Roger Serwy:

Revision e4598364ea29 changed the docstring for "int", causing the CallTips test to fail in IDLE.

The attached patch fixes the problem.

----------
components: IDLE
files: calltips_test_update.patch
keywords: easy, patch
messages: 177063
nosy: serwy, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: IDLE: Calltips test fails due to int docstring change
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28230/calltips_test_update.patch

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

From report at bugs.python.org  Fri Dec  7 02:46:15 2012
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 07 Dec 2012 01:46:15 +0000
Subject: [New-bugs-announce] [issue16630] IDLE: Calltip fails if __getattr__
	raises exception
Message-ID: <1354844775.58.0.855877358898.issue16630@psf.upfronthosting.co.za>


New submission from Roger Serwy:

The calltip fails if __getattr__ raises an exception. Take as an example:


Python 3.4.0a0 (default:0238cc842805+, Dec  6 2012, 19:17:04) 
[GCC 4.7.2] on linux
Type "copyright", "credits" or "license()" for more information.
>>> class Test:
	def __getattr__(self, name):
		raise Exception()

	
>>> a = Test()
>>> a(

This traceback is sent to stderr:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/serwy/Code/python/cpython/Lib/tkinter/__init__.py", line 1442, in __call__
    return self.func(*args)
  File "/home/serwy/Code/python/cpython/Lib/idlelib/MultiCall.py", line 166, in handler
    r = l[i](event)
  File "/home/serwy/Code/python/cpython/Lib/idlelib/CallTips.py", line 56, in try_open_calltip_event
    self.open_calltip(False)
  File "/home/serwy/Code/python/cpython/Lib/idlelib/CallTips.py", line 75, in open_calltip
    argspec = self.fetch_tip(expression)
  File "/home/serwy/Code/python/cpython/Lib/idlelib/CallTips.py", line 101, in fetch_tip
    (expression,), {})
  File "/home/serwy/Code/python/cpython/Lib/idlelib/rpc.py", line 216, in remotecall
    return self.asyncreturn(seq)
  File "/home/serwy/Code/python/cpython/Lib/idlelib/rpc.py", line 247, in asyncreturn
    return self.decoderesponse(response)
  File "/home/serwy/Code/python/cpython/Lib/idlelib/rpc.py", line 267, in decoderesponse
    raise what
Exception


The attached patch fixes the issue.

----------
components: IDLE
files: calltips_getattr_error.patch
keywords: easy, needs review, patch
messages: 177064
nosy: serwy, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: IDLE: Calltip fails if __getattr__ raises exception
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28231/calltips_getattr_error.patch

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

From report at bugs.python.org  Fri Dec  7 05:41:16 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 07 Dec 2012 04:41:16 +0000
Subject: [New-bugs-announce] [issue16631] tarfile.extractall() doesn't
	extract everything if	.next() was used
Message-ID: <1354855276.1.0.878015275431.issue16631@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

If tarfile.next() is used before .extractall(), the latter fails to extract files that were accessed.

----------
components: Library (Lib)
messages: 177065
nosy: techtonik
priority: normal
severity: normal
status: open
title: tarfile.extractall() doesn't extract everything if .next() was used
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec  7 11:23:01 2012
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 07 Dec 2012 10:23:01 +0000
Subject: [New-bugs-announce] [issue16632] Enable DEP and ASLR
Message-ID: <1354875781.46.0.686705865065.issue16632@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Python 3.3 doesn't use address space layout randomization [1] and data execution prevention [2] on Windows. ASLR and DEP make certain kinds of attacks harder. An attacker can't predict the address of functions or globals anymore and DEP helps against NOP sled attacks.

Python's test suite runs fine with DEP and ASLR on AMD64. I see a crash in test_capi and a couple of crashes in test_faulthandler but these don't seem to be related.

[1] http://en.wikipedia.org/wiki/ASLR
[2] http://en.wikipedia.org/wiki/Data_Execution_Prevention

----------
components: Windows
files: depaslr.patch
keywords: patch
messages: 177077
nosy: christian.heimes
priority: normal
severity: normal
stage: test needed
status: open
title: Enable DEP and ASLR
type: security
versions: Python 3.4
Added file: http://bugs.python.org/file28236/depaslr.patch

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

From report at bugs.python.org  Fri Dec  7 13:01:43 2012
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiDFoG1pbGF1ZXI=?=)
Date: Fri, 07 Dec 2012 12:01:43 +0000
Subject: [New-bugs-announce] [issue16633] os.environ updates only one copy
	of env vars under	Windows (GetEnvironmentVariable vs. getenv)
Message-ID: <1354881703.99.0.276690917603.issue16633@psf.upfronthosting.co.za>


New submission from V?clav ?milauer:

On windows, environment variables exist in two copies: one is manipulated using win32 API (GetEnvironmentVariable, SetEnvironmentVariable), and another one is maintained by the C runtime (getenv, _putenv). This is explained in more depth in [1].

os.environ manipulates win32 environment variables, but *not* those seen by the CRT. This means that if I set an environment variable using os.environ and later read it, in the same process, using getenv in an extension module, it will not give the expected result. Child processes *do* see those vars in CRT, since it is copied over from the win32 version at process startup.

Setting env vars has legitimate uses, since it is one of the few ways to influence initialization of extension modules: for instance, setting OMP_NUM_THREADS sets number of threads for OpenMP runtime (which cannot be changed once the module using it is loaded).

It would be ideal to keep both CRT and win32 env vars in sync transparently. If that is not realistically achievable, this gotcha should be documented as a warning in the os.environ documentation.

A workaround to this problem to set variables in both win32 and CRT using something like

    import ctypes, ctypes.util, os.environ
    ctypes.cdll[ctypes.util.find_msvcrt()]._putenv("%s=%s"%(name,value))
    os.environ[name]=value



[1] http://msmvps.com/blogs/senthil/archive/2009/10/13/when-what-you-set-is-not-what-you-get-setenvironmentvariable-and-getenv.aspx

----------
assignee: docs at python
components: Documentation
messages: 177081
nosy: docs at python, eudoxos
priority: normal
severity: normal
status: open
title: os.environ updates only one copy of env vars under Windows (GetEnvironmentVariable vs. getenv)
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Dec  7 13:50:56 2012
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 07 Dec 2012 12:50:56 +0000
Subject: [New-bugs-announce] [issue16634] urllib.error.HTTPError.reason is
	not documented
Message-ID: <1354884656.5.0.110910747898.issue16634@psf.upfronthosting.co.za>


New submission from Berker Peksag:

The "reason" attribute has been added to urllib.error.HTTPError in issue 13211.

Related changeset: http://hg.python.org/cpython/rev/deb60efd32eb

----------
assignee: docs at python
components: Documentation
files: httperror-reason.diff
keywords: patch
messages: 177083
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: urllib.error.HTTPError.reason is not documented
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28241/httperror-reason.diff

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

From report at bugs.python.org  Fri Dec  7 14:33:50 2012
From: report at bugs.python.org (Filip Zyzniewski)
Date: Fri, 07 Dec 2012 13:33:50 +0000
Subject: [New-bugs-announce] [issue16635] Interpreter not closing
	stdout/stderr on exit
Message-ID: <1354887230.33.0.111304282824.issue16635@psf.upfronthosting.co.za>


New submission from Filip Zyzniewski:

When using a Python script as a unix pipe filter with its stdout redirected to a file:

python script.py > /nfs/foo

user is not notified of some writing problems on NFS, because these are sometimes reported on close(), and the interpreter never does neither close(1) nor close(2):

$ strace -eclose python -c '' 2>&1 | grep  'close([12])'
$

----------
components: IO
messages: 177090
nosy: filip.zyzniewski
priority: normal
severity: normal
status: open
title: Interpreter not closing stdout/stderr on exit
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Dec  7 18:01:38 2012
From: report at bugs.python.org (Laurynas Speicys)
Date: Fri, 07 Dec 2012 17:01:38 +0000
Subject: [New-bugs-announce] [issue16636] codecs: readline() followed by
	readlines() returns	trunkated results
Message-ID: <1354899698.79.0.269419302823.issue16636@psf.upfronthosting.co.za>


New submission from Laurynas Speicys:

codecs.readlines() does not read to the end of the file if called after codecs.readline().  

Skimmed through tasks containing codecs in title and could not find a candidate that sounded identical.

Repro follows:

$ cat sample_text.txt
Subject: Incorrect email address
 
RATER EMAIL rejected an invitation from SUBJECT NAME <SUBJECT EMAIL> in
the PROJECT TITLE project.  Notification was sent to <RECIPIENT EMAIL>,
but the email address was no longer valid.


$ python
Python 2.7.3 (default, Sep 26 2012, 21:53:58) 
[GCC 4.7.2] on linux2
>>>
>>> import codecs
>>>
>>> # No problem if readlines() are run at the beginning:
>>>
>>> f_in = codecs.open('sample_text.txt', 'rb', 'utf-8')
>>> f_in.readlines()
[u'Subject: Incorrect email address\n', u'\n', u'RATER EMAIL rejected an invitation from SUBJECT NAME <SUBJECT EMAIL> in\n', u'the PROJECT TITLE project.  Notification was sent to <RECIPIENT EMAIL>,\n', u'but the email address was no longer valid.']
>>> f_in.close()
>>>
>>> # Let us try to read the first line separately,
>>> # and then read the remainder of the file:
>>>
>>> f_in = codecs.open('sample_text.txt', 'rb', 'utf-8')
>>> f_in.readline()
u'Subject: Incorrect email address\n'
>>> f_in.readlines()
[u'\n', u'RATER EMAIL rejected an invitation fro']

The first readlines() does not read to the end. Subsequent readlines() returns what's left to read.

sample_text.txt attached.

----------
files: sample_text.txt
messages: 177098
nosy: laurynas
priority: normal
severity: normal
status: open
title: codecs: readline() followed by readlines() returns trunkated results
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file28242/sample_text.txt

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

From report at bugs.python.org  Fri Dec  7 19:04:52 2012
From: report at bugs.python.org (Mark Shroyer)
Date: Fri, 07 Dec 2012 18:04:52 +0000
Subject: [New-bugs-announce] [issue16637] py-bt, py-locals,
	etc. GDB commands fail with output-radix 16
Message-ID: <1354903492.9.0.822155625877.issue16637@psf.upfronthosting.co.za>


New submission from Mark Shroyer:

When debugging a Python process in GDB with output-radix 16, the py-bt, py-locals, py-value, etc. commands from python-gdb.py fail with messages like "(unable to read python frame information)".

The problem comes down to the int_from_int function attempting to convert its string argument from a base-10 integer representation, even if that string is something like "0xf".  The attached patch fixes this.

----------
components: Demos and Tools
files: python_gdb_fix.patch
keywords: patch
messages: 177105
nosy: mshroyer
priority: normal
severity: normal
status: open
title: py-bt, py-locals, etc. GDB commands fail with output-radix 16
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file28244/python_gdb_fix.patch

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

From report at bugs.python.org  Fri Dec  7 20:49:36 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 07 Dec 2012 19:49:36 +0000
Subject: [New-bugs-announce] [issue16638] support multi-line docstring
	signatures in IDLE calltips
Message-ID: <1354909776.12.0.96265352257.issue16638@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to add support for rendering multi-line docstring signatures in IDLE calltips (e.g. iter(), min(), int(), etc).  This was suggested by Serhiy in the comments to issue 16629.

----------
components: IDLE
messages: 177118
nosy: chris.jerdonek, serhiy.storchaka, serwy, terry.reedy
priority: normal
severity: normal
status: open
title: support multi-line docstring signatures in IDLE calltips
type: enhancement

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

From report at bugs.python.org  Fri Dec  7 23:26:47 2012
From: report at bugs.python.org (Nurhusien Hasen)
Date: Fri, 07 Dec 2012 22:26:47 +0000
Subject: [New-bugs-announce] [issue16639] not your all issuse send
Message-ID: <CA+3n20JbVe=n8j00oeEKrhRFoUopYYYcfMBRrbe0TLDRe_oT_Q@mail.gmail.com>


New submission from Nurhusien Hasen:

Not find  python all issuse pleas pleas find one issuse

----------
messages: 177135
nosy: Nurhusien2
priority: normal
severity: normal
status: open
title: not your all issuse send

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

From report at bugs.python.org  Sat Dec  8 10:33:59 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Dec 2012 09:33:59 +0000
Subject: [New-bugs-announce] [issue16640] Less code under lock in
	sched.scheduler
Message-ID: <1354959239.11.0.372090079452.issue16640@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In additional to issue16165 I think that sched.scheduler runs more code under a lock than needed. The proposed patch moves this code outside a lock. This unlikely a bug, may be only small enhancement and cleanup.

----------
components: Library (Lib)
files: sched_less_lock.patch
keywords: patch
messages: 177147
nosy: giampaolo.rodola, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Less code under lock in sched.scheduler
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28255/sched_less_lock.patch

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

From report at bugs.python.org  Sat Dec  8 11:14:21 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Dec 2012 10:14:21 +0000
Subject: [New-bugs-announce] [issue16641] sched.scheduler.enter arguments
	should be modifiable
Message-ID: <1354961661.69.0.670095014649.issue16641@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Example:

>>> import sched
>>> s=sched.scheduler()
>>> s.enter(10, 1, print)
Event(time=7452.676787873, priority=1, action=<built-in function print>, argument=[], kwargs={})
>>> next(s.queue).argument.append("spam")
>>> s.enter(5, 1, print)
Event(time=7473.326011725, priority=1, action=<built-in function print>, argument=['spam'], kwargs={})
>>> s.run()
spam
spam

Now every s.enter() call (even for other schedulers) without explicit "argument" use ['spam'] as "argument".

Usually functions should not have modifiable arguments (unless it is intentional). We should use non-modifiable value or a sentinel for default. For example an empty tuple as default for "argument" and None as default for "kwargs".

----------
components: Library (Lib)
files: sched_nonmodifiable_args.patch
keywords: patch
messages: 177151
nosy: giampaolo.rodola, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: sched.scheduler.enter arguments should be modifiable
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28256/sched_nonmodifiable_args.patch

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

From report at bugs.python.org  Sat Dec  8 11:52:50 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Dec 2012 10:52:50 +0000
Subject: [New-bugs-announce] [issue16642] Mention new "kwargs" named tuple
	parameter in sched	module
Message-ID: <1354963970.59.0.876106484214.issue16642@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which adds missed mentions of "kwargs" named tuple parameter.

----------
assignee: docs at python
components: Documentation
files: sched_docs_kwargs.patch
keywords: patch
messages: 177154
nosy: docs at python, giampaolo.rodola, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Mention new "kwargs" named tuple parameter in sched module
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28258/sched_docs_kwargs.patch

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

From report at bugs.python.org  Sat Dec  8 11:59:41 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Dec 2012 10:59:41 +0000
Subject: [New-bugs-announce] [issue16643] Wrong documented default value for
	timefunc parameter in	sched.scheduler()
Message-ID: <1354964381.71.0.639628706124.issue16643@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

sched.scheduler() prefers to use time.monotonic as a default value for timefunc parameter, and time.time used only as a fallback. But time.time documented as a default value.

----------
assignee: docs at python
components: Documentation
messages: 177155
nosy: docs at python, giampaolo.rodola, haypo, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Wrong documented default value for timefunc parameter in sched.scheduler()
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Dec  8 18:03:55 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Dec 2012 17:03:55 +0000
Subject: [New-bugs-announce] [issue16644] Wrong code in
	ContextManagerTests.test_invalid_args() in	test_subprocess.py
Message-ID: <1354986235.92.0.873586035968.issue16644@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Test ContextManagerTests.test_invalid_args() in file Lib/test/test_subprocess.py contains code which has no sense. When Popen() fail then this code will not reachable. When Popen() success then c.exception will not assigned.

Here is a patch with right test.

----------
components: Tests
files: test_subprocess_test_invalid_args.patch
keywords: patch
messages: 177164
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Wrong code in ContextManagerTests.test_invalid_args() in test_subprocess.py
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28259/test_subprocess_test_invalid_args.patch

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

From report at bugs.python.org  Sat Dec  8 19:02:08 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Dec 2012 18:02:08 +0000
Subject: [New-bugs-announce] [issue16645] Wrong test_extract_hardlink() in
	test_tarfile.py
Message-ID: <1354989728.58.0.0717635689948.issue16645@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Test test_extract_hardlink() in Lib/test/test_tarfile.py ran 4 times. First time (uncompressed tarfile) it extract symbolic and hard links successfully, but in other 3 times (gzipped, bzipped and lzma'ed tarfile) extracting fails becouse this links already exists (left from first test). The test just ignore this error and other possible errors (error EEXIST raised, but ignored all except ENOENT).

Here is a patch, which adds a right cleanup of extracted links.

----------
components: Tests
files: test_tarfile_test_extract_hardlink.patch
keywords: patch
messages: 177166
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Wrong test_extract_hardlink() in test_tarfile.py
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28260/test_tarfile_test_extract_hardlink.patch

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

From report at bugs.python.org  Sat Dec  8 19:51:28 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Dec 2012 18:51:28 +0000
Subject: [New-bugs-announce] [issue16646] FTP.makeport() loses socket error
	details
Message-ID: <1354992688.45.0.00340883588323.issue16646@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In FTP.makeport() a socket error catched and saved but then raised a new error with saved error as argument.

Here is a patch which reraises an original error.

----------
components: Library (Lib)
files: ftplib_makeport_raise_err.patch
keywords: patch
messages: 177171
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: FTP.makeport() loses socket error details
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28262/ftplib_makeport_raise_err.patch

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

From report at bugs.python.org  Sat Dec  8 20:09:43 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Dec 2012 19:09:43 +0000
Subject: [New-bugs-announce] [issue16647] LMTP.connect() loses socket error
	details
Message-ID: <1354993783.87.0.258604768595.issue16647@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In LMTP.connect() a socket error catched and saved but then raised a new error with saved error as argument.

Here is a patch which reraises an original error.

----------
components: Library (Lib)
files: smtplib_LMTP_connect_raise_err.patch
keywords: patch
messages: 177172
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: LMTP.connect() loses socket error details
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28264/smtplib_LMTP_connect_raise_err.patch

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

From report at bugs.python.org  Sat Dec  8 20:35:47 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 08 Dec 2012 19:35:47 +0000
Subject: [New-bugs-announce] [issue16648] stdib should use new exception
	types from PEP 3151
Message-ID: <1354995347.5.0.732021100427.issue16648@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

http://www.python.org/dev/peps/pep-3151 define exception classes like ConnectionError and BrokenPipeError

We need to refactor stdlib to use that shiny new exceptions instead of checking errno values if possible.

Also maybe we need to add some absent exceptions.
I guess NotConnectedError for ENOTCONN, which should be ConnectionError subclass.

----------
components: Library (Lib)
messages: 177174
nosy: asvetlov
priority: normal
severity: normal
stage: needs patch
status: open
title: stdib should use new exception types from PEP 3151
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec  9 07:34:28 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 09 Dec 2012 06:34:28 +0000
Subject: [New-bugs-announce] [issue16649] Add a
	PyCF_PRINT_EXPRESSION_RESULTS flag
Message-ID: <1355034868.91.0.795623819186.issue16649@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

code.InteractiveConsole.push attempts to support multi-line input when using an input method that doesn't reliably split on newlines.

This support fails as soon as the multi-line input contains multiple statements (including when the last statement is incomplete).

However, switching to 'exec' instead of 'single' causes other problems - specifically, it turns off the expression printing.

While expression printing could be implied by the PyCF_DONT_IMPLY_DEDENT flag in addition to the "single" evaluation mode, it seems cleaner to break out the expression printing behaviour into its own flag and setting it appropriately in the code and/or codeop modules.

----------
components: Interpreter Core
messages: 177199
nosy: aliles, kristjan.jonsson, ncoghlan
priority: low
severity: normal
status: open
title: Add a PyCF_PRINT_EXPRESSION_RESULTS flag
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec  9 08:03:20 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Dec 2012 07:03:20 +0000
Subject: [New-bugs-announce] [issue16650] Popen._internal_poll() references
	errno.ECHILD outside	of the local scope
Message-ID: <1355036600.83.0.376355184043.issue16650@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

As noted in Popen._internal_poll() docstring this method cannot reference anything outside of the local scope. However it references errno.ECHILD. The proposed patch fixes this.

Is it good that Popen._handle_exitstatus() references building SubprocessError?

----------
components: Library (Lib)
files: subprocess_reference_nonlocal.patch
keywords: patch
messages: 177201
nosy: asvetlov, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Popen._internal_poll() references errno.ECHILD outside of the local scope
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28266/subprocess_reference_nonlocal.patch

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

From report at bugs.python.org  Sun Dec  9 19:39:53 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 09 Dec 2012 18:39:53 +0000
Subject: [New-bugs-announce] [issue16651] Find out what stdlib modules lack
	a pure Python	implementation
Message-ID: <1355078393.91.0.564166411172.issue16651@psf.upfronthosting.co.za>


New submission from Brett Cannon:

I'm wondering which modules in the stdlib lack pure Python implementations (and could legitimately have one, e.g. sqlite can't really have a pure Python implementation). Once we know how big/small the list is a decision could be made as to whether to take on the effort to bring over some pure Python version from another VM or something for any of these modules.

To start the list:

csv
itertools

----------
components: Library (Lib)
keywords: easy
messages: 177230
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Find out what stdlib modules lack a pure Python implementation
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec  9 22:44:41 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 09 Dec 2012 21:44:41 +0000
Subject: [New-bugs-announce] [issue16652] socket.getfqdn docs are not
	explicit enough about the	algorithm.
Message-ID: <1355089481.55.0.645096435972.issue16652@psf.upfronthosting.co.za>


New submission from R. David Murray:

>From the docs it isn't quite clear if getfqnd() does the equivalent of:

  gethostbyaddr('127.0.0.1')

or

  gethostbyaddr(gethostbyname(gethostname()))

It matters which it is, when debugging a host's name configuration and DNS server problems.

----------
assignee: docs at python
components: Documentation
messages: 177236
nosy: docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: socket.getfqdn docs are not explicit enough about the algorithm.
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Dec  9 23:01:58 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 09 Dec 2012 22:01:58 +0000
Subject: [New-bugs-announce] [issue16653] reference kept in f_locals
	prevents the	tracing/profiling of a destructor
Message-ID: <1355090518.29.0.154365424175.issue16653@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The following debugging session, run with python on the default branch, shows
that pdb does not stop in __del__ when it is invoked.

The reason is:

  - The destructor is not called when processing the 'c = 1' statement because
    foo frame.f_locals owns a reference to the C instance.
  - When the interpreter is about to invoke the trace function with the ensuing
    debug event, the call to PyFrame_LocalsToFast in call_trampoline causes the
    destructor to be invoked (as shown by gdb), and the destructor is not traced
    because at that time tstate->use_tracing is false.

This is confirmed by the fact that when 'c = 1' is replaced with
'c = 1; locals()' (on one single line so as not to trigger the trace function
before the call to locals()), then pdb stops in __del__.

===   foo.py   ================
class C:
    def __del__(self):
        print("Calling C destructor.")

def foo():
    c = C()
    import pdb; pdb.set_trace()
    c = 1

foo()
===============================
$ ./python /tmp/foo.py
> /tmp/foo.py(8)foo()
-> c = 1
(Pdb) step
Calling C destructor.
--Return--
> /tmp/foo.py(8)foo()->None
-> c = 1
(Pdb)
===============================

----------
components: Interpreter Core
messages: 177240
nosy: xdegaye
priority: normal
severity: normal
status: open
title: reference kept in f_locals prevents the tracing/profiling of a destructor
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec 10 01:39:36 2012
From: report at bugs.python.org (stephenhohs)
Date: Mon, 10 Dec 2012 00:39:36 +0000
Subject: [New-bugs-announce] [issue16654] IDLE problems with Mac OS 10.6.8
	("print syntax")
Message-ID: <1355099976.92.0.551820682272.issue16654@psf.upfronthosting.co.za>


New submission from stephenhohs:

Numerous attempts were made to install (and deinstall) IDLE along with getting the recommended version of ActiveTCL.  IDLE will always give a print syntax error with one liners print "hello, world".  This is occurring for Mac OS 10.6.8

----------
components: IDLE
messages: 177246
nosy: stephenhohs
priority: normal
severity: normal
status: open
title: IDLE problems with Mac OS 10.6.8 ("print syntax")
versions: Python 3.3

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

From report at bugs.python.org  Mon Dec 10 03:31:20 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 10 Dec 2012 02:31:20 +0000
Subject: [New-bugs-announce] [issue16655] IDLE list.append calltips test
	failures
Message-ID: <1355106680.63.0.980843765647.issue16655@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

There are three IDLE test failures in the 3.2 branch:

$ ./python.exe Lib/idlelib/CallTips.py
list.append - expected
'L.append(object) -> None -- append object to end'
 - but got
'L.append(object) -- append object to end'
[].append - expected
'L.append(object) -> None -- append object to end'
 - but got
'L.append(object) -- append object to end'
List.append - expected
'L.append(object) -> None -- append object to end'
 - but got
'L.append(object) -- append object to end'
3 of 41 tests failed

----------
components: IDLE
messages: 177253
nosy: chris.jerdonek, kbk
priority: normal
severity: normal
status: open
title: IDLE list.append calltips test failures
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Dec 10 12:41:44 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 10 Dec 2012 11:41:44 +0000
Subject: [New-bugs-announce] [issue16656] os.walk ignores international dirs
	on Windows
Message-ID: <1355139704.15.0.993406857034.issue16656@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

This critical bug is one of the reasons that non-English speaking communities doesn't adopt Python as broadly as it happens in English world compared to other technologies (PHP etc.). 


# -*- coding: utf-8 -*-

import os

os.mkdir(u'??????? ???')
os.mkdir(u'English name')

for r, dirs, files in os.walk('.'):
  print dirs


This gives:
['English name']
[]


Windows Vista.
>dir /b
English name
test.py
??????? ???

----------
components: Library (Lib)
messages: 177276
nosy: techtonik
priority: normal
severity: normal
status: open
title: os.walk ignores international dirs on Windows
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec 10 14:33:20 2012
From: report at bugs.python.org (Marius Gedminas)
Date: Mon, 10 Dec 2012 13:33:20 +0000
Subject: [New-bugs-announce] [issue16657] traceback.format_tb incorrect
	docsting
Message-ID: <1355146400.65.0.00525928914729.issue16657@psf.upfronthosting.co.za>


New submission from Marius Gedminas:

The docstring for traceback.format_tb says

  """A shorthand for 'format_list(extract_stack(f, limit))."""

which is incorrect -- it's actually a shorthand for format_list(extract_tb(tb, limit)).

Patch attached.

----------
components: Library (Lib)
files: fix-format_tb-docstring.patch
keywords: patch
messages: 177288
nosy: mgedmin
priority: normal
severity: normal
status: open
title: traceback.format_tb incorrect docsting
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file28276/fix-format_tb-docstring.patch

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

From report at bugs.python.org  Mon Dec 10 21:14:32 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 10 Dec 2012 20:14:32 +0000
Subject: [New-bugs-announce] [issue16658] Missing "return" in
	HTTPConnection.send()
Message-ID: <1355170472.23.0.747956680603.issue16658@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

HTTPConnection.send() accepts a bytes string, a file, and any iterable.

When a file is passed, data is read in blocks until read() returns an empty string.
But because a "return" statement is missing, execution continues with an attempt to iterate the file again...
This exits quickly most of the time, but this can lead to surprising behavior if more data is available, or for custom implementations of the file object.

----------
keywords: easy
messages: 177312
nosy: amaury.forgeotdarc
priority: normal
severity: normal
status: open
title: Missing "return" in HTTPConnection.send()
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Dec 10 23:21:06 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 10 Dec 2012 22:21:06 +0000
Subject: [New-bugs-announce] [issue16659] Pure Python implementation of
	random
Message-ID: <1355178066.71.0.0702719631559.issue16659@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

C implemented part of random module does not depend on any specific C level abilities. Here is a patch which implements this part on pure Python. May be this is not a best implementation. And I don't know how write tests for both implementations.

----------
components: Library (Lib)
files: random_pure_python.patch
keywords: patch
messages: 177315
nosy: brett.cannon, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Pure Python implementation of random
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28278/random_pure_python.patch

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

From report at bugs.python.org  Tue Dec 11 00:52:48 2012
From: report at bugs.python.org (ashwani)
Date: Mon, 10 Dec 2012 23:52:48 +0000
Subject: [New-bugs-announce] [issue16660] Segmentation fault when importing
	hashlib
Message-ID: <1355183568.14.0.00662853136149.issue16660@psf.upfronthosting.co.za>


New submission from ashwani:

Hello,

I did a local installation of python 3.3.0 on my organization's CentOS machine.
We also have Python 2.6.6 installed for every users on this machine.
Python 3.3.0 crashes when I import the hash lib.
Following is snapshot of the crash.


ir[63] [~/]$ python3  -X faulthandler
Python 3.3.0 (default, Dec  9 2012, 20:13:58) 
[GCC 4.4.6 20110731 (Red Hat 4.4.6-3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
Fatal Python error: Segmentation fault

Current thread 0x00007f0362784700:
  File "/usa/arao/Python-3.3.0/lib/python3.3/hashlib.py", line 99 in __get_openssl_constructor
  File "/usa/arao/Python-3.3.0/lib/python3.3/hashlib.py", line 141 in <module>
  File "<frozen importlib._bootstrap>", line 313 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 869 in _load_module
  File "<frozen importlib._bootstrap>", line 562 in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 1004 in load_module
  File "<frozen importlib._bootstrap>", line 1023 in load_module
  File "<frozen importlib._bootstrap>", line 586 in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1525 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1558 in _find_and_load
  File "<stdin>", line 1 in <module>
Segmentation fault


Can someone help me on this?

Thanks,
Ashwin

----------
components: Library (Lib)
messages: 177317
nosy: nixdash
priority: normal
severity: normal
status: open
title: Segmentation fault when importing hashlib
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Tue Dec 11 04:46:15 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Dec 2012 03:46:15 +0000
Subject: [New-bugs-announce] [issue16661] test_posix.test_getgrouplist fails
	on some systems -	incorrectly comparing getgroups and
	getgrouplist results
Message-ID: <1355197575.99.0.863883653591.issue16661@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

test_posix.test_getgrouplist is failing for me on my Linux (ubuntu precise) based desktop at work.

It looks like posix.getgrouplist() is returning all of the larger GIDs.  The lowest one it is reporting for my user is 499 but the more distro specific groups that I am are not included in its 18 element long list it returns so the test fails:

test test_posix failed -- Traceback (most recent call last):
  File "cpython/default/Lib/test/test_posix.py", line 660, in test_getgrouplist
    pwd.getpwuid(os.getuid())[3])))
AssertionError: Items in the first set but not the second:
128
4
104
44
46
20
24
25

strace reveals that the 'id -G' command this test is trying to compare against calls getgroups() while posix.getgrouplist() appears to do something else that does not make that syscall.

posix.getgroups() does the same thing as 'id -G', this test for posix.getgrouplist(username, uid) is making an incorrect assertion.

----------
components: Library (Lib)
messages: 177320
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: test_posix.test_getgrouplist fails on some systems - incorrectly comparing getgroups and getgrouplist results
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec 11 10:14:51 2012
From: report at bugs.python.org (Robert Collins)
Date: Tue, 11 Dec 2012 09:14:51 +0000
Subject: [New-bugs-announce] [issue16662] load_tests not invoked in
	package/__init__.py
Message-ID: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za>


New submission from Robert Collins:

In loader.py:
                if fnmatch(path, pattern):
                    # only check load_tests if the package directory itself matches the filter
                    name = self._get_name_from_path(full_path)
                    package = self._get_module_from_name(name)
                    load_tests = getattr(package, 'load_tests', None)
                    tests = self.loadTestsFromModule(package, use_load_tests=False)


But pattern is test*.py by default, and packages will never match that.

Its not at all clear why this is special cased at all, but if it is, we'll need a separate pattern. (Its not special cased in the bzrlib implementation that acted as the initial implementation).

----------
messages: 177327
nosy: rbcollins
priority: normal
severity: normal
status: open
title: load_tests not invoked in package/__init__.py

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

From report at bugs.python.org  Tue Dec 11 17:16:31 2012
From: report at bugs.python.org (r3m0t)
Date: Tue, 11 Dec 2012 16:16:31 +0000
Subject: [New-bugs-announce] [issue16663] Poor documentation for
	METH_KEYWORDS
Message-ID: <1355242591.45.0.999993608815.issue16663@psf.upfronthosting.co.za>


New submission from r3m0t:

http://docs.python.org/3.3/c-api/structures.html#METH_KEYWORDS

"Methods with these flags must be of type PyCFunctionWithKeywords. The function expects three parameters: self, args, and a dictionary of all the keyword arguments. The flag is typically combined with METH_VARARGS, and the parameters are typically processed using PyArg_ParseTupleAndKeywords()."

The documentation doesn't mention the args/dictionary arguments will be NULL when there are no positional/keyword arguments. It might also be worth mentioning the arguments are in effect "borrowed" references.

----------
assignee: docs at python
components: Documentation
messages: 177341
nosy: docs at python, r3m0t
priority: normal
severity: normal
status: open
title: Poor documentation for METH_KEYWORDS
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Dec 11 19:25:32 2012
From: report at bugs.python.org (Sebastian Kreft)
Date: Tue, 11 Dec 2012 18:25:32 +0000
Subject: [New-bugs-announce] [issue16664] [PATCH] Test Glob: files starting
	with .
Message-ID: <1355250332.3.0.793167258455.issue16664@psf.upfronthosting.co.za>


New submission from Sebastian Kreft:

Please find attached a patch to improve the test cases for the glob module. It adds test cases for files starting with '.'.

----------
components: Tests
files: python.patch
keywords: patch
messages: 177345
nosy: Sebastian.Kreft
priority: normal
severity: normal
status: open
title: [PATCH] Test Glob: files starting with .
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file28281/python.patch

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

From report at bugs.python.org  Tue Dec 11 21:33:17 2012
From: report at bugs.python.org (rurpy the second)
Date: Tue, 11 Dec 2012 20:33:17 +0000
Subject: [New-bugs-announce] [issue16665] doc for builtin hex() is poor
Message-ID: <1355257997.08.0.0348964643873.issue16665@psf.upfronthosting.co.za>


New submission from rurpy the second:

The documentation of the hex() builtin function is poor.  Specifically it does not say (directly) that:

1. The resulting string is prefixed with "0x".

2. Any a-f characters used are lower case.

3. Negative integers are converted by prefixing a minus sign to hex() of the absolute value of the argument.

4. It should have a cross reference to the %x format of the "%" operator with a note that it is more veratile than the hex() builtin. 

5. It should have a cross reference to the way of performing the inverse operation: hex->int

I am not a good writer but here is an attempt at improving it:

--------
Convert an integer number to a hexadecimal string.  The resulting string is prefixed with "0x" and any alpha characters a-f are lowercase ascii.  Negative integers are converted to hex(abs(x)) prefixed with "-".  In all cases the result is a valid Python expression.

If x is not a Python int object, it has to define an __index__() method that returns an integer.

Note: For another more flexible way of converting an integer to hexadecimal see the "x" and "X" conversion types in link:[4.7.2 -  printf-style String Formatting] and link:[6.1.3.1 - Format Specification Mini-Language]

Note: To convert a hexadecimal string to an integer, use link:[int()] with a radix argument of 16. 

Note: To obtain a hexadecimal string representation for a float, use the link:[float.hex()] method.
--------

----------
assignee: docs at python
components: Documentation
messages: 177352
nosy: docs at python, rurpy2
priority: normal
severity: normal
status: open
title: doc for builtin hex() is poor
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Dec 12 00:00:09 2012
From: report at bugs.python.org (Mikel Ward)
Date: Tue, 11 Dec 2012 23:00:09 +0000
Subject: [New-bugs-announce] [issue16666] docs wrongly imply
	socket.getaddrinfo takes keyword	arguments in 2.x
Message-ID: <1355266809.79.0.222027583908.issue16666@psf.upfronthosting.co.za>


New submission from Mikel Ward:

The docs for 2.6 and 2.7 say socket.getaddrinfo takes keyword arguments.

http://docs.python.org/release/2.6.6/library/socket.html?highlight=socket#socket.getaddrinfo

> socket.getaddrinfo(host, port, family=0, socktype=0, proto=0, flags=0)

But that doesn't actually work in Python 2.7.

$ ./python 
Python 2.7.3+ (2.7:ec4ea40be2f6, Dec 11 2012, 14:43:35) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> import socket
>>> s = socket.getaddrinfo('localhost', 999, family=socket.AF_INET)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: getaddrinfo() takes no keyword arguments

Looks like it was introduced in 61999:c963478b9092.

----------
assignee: docs at python
components: Documentation
messages: 177356
nosy: Mikel.Ward, docs at python
priority: normal
severity: normal
status: open
title: docs wrongly imply socket.getaddrinfo takes keyword arguments in 2.x
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Dec 12 01:30:02 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 12 Dec 2012 00:30:02 +0000
Subject: [New-bugs-announce] [issue16667] timezone docs need "versionadded:
	3.2"
Message-ID: <1355272202.83.0.0809647453086.issue16667@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The docs for the fixed offset timezone objects added in 3.2 need a versionadded tag.

Also, the "see also" link for pytz in the preceding section still incorrectly states that the stdlib only provides UTC as a timezone, rather than handling arbitrary fixed offsets from UTC.

----------
messages: 177358
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: timezone docs need "versionadded: 3.2"
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Dec 12 12:43:10 2012
From: report at bugs.python.org (Trent Nelson)
Date: Wed, 12 Dec 2012 11:43:10 +0000
Subject: [New-bugs-announce] [issue16668] Remove python3dll.vcxproj from
	pcbuild.sln
Message-ID: <1355312590.66.0.754548661845.issue16668@psf.upfronthosting.co.za>


New submission from Trent Nelson:

As far as I can tell, the python3dll.vcxproj is bitrot and should be removed from pcbuild.sln.  It's a makefile target project that invokes ..\PC\python3.mak, which builds a target named python3.dll; however, pythoncore.vxcproj builds python34[_d].dll as a proper VS project.

(Additionally, the python3dll.vxcproj has no Debug configuration, which is what brought it to my attention in the first place.)

Christian/Martin: is this python3dll.vcxproj and resulting python3.dll still used or can it be safely removed from pcbuild.sln?

----------
assignee: trent
components: Build
messages: 177372
nosy: christian.heimes, loewis, trent
priority: normal
severity: normal
status: open
title: Remove python3dll.vcxproj from pcbuild.sln
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Dec 12 18:31:35 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Dec 2012 17:31:35 +0000
Subject: [New-bugs-announce] [issue16669] Docstrings for namedtuple
Message-ID: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here are two patches which implementation two different interface for same feature.

In first patch you can use *doc* and *field_docs* arguments to specify namedtuple class docstring and field docstrings. For example:

    Point = namedtuple('Point', 'x y',
                       doc='Point: 2-dimensional coordinate',
                       field_docs=['abscissa', 'ordinate'])

In second patch you can use *doc* argument to specify namedtuple class docstring and *field_names* argument can be a sequence of pairs: field name and field docstring. For example:

    Point = namedtuple('Point', [('x', 'absciss'), ('y', 'ordinate')],
                       doc='Point: 2-dimensional coordinate')

What approach is better?

Feel free to correct a documentation. I know that it need a correction.

----------
components: Library (Lib)
files: namedtuple_docstrings_field_docs.patch
keywords: patch
messages: 177381
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Docstrings for namedtuple
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28294/namedtuple_docstrings_field_docs.patch

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

From report at bugs.python.org  Wed Dec 12 18:39:54 2012
From: report at bugs.python.org (julien tayon)
Date: Wed, 12 Dec 2012 17:39:54 +0000
Subject: [New-bugs-announce] [issue16670] [docs] class Point in
	collections.namedtuples may be not	that good example
Message-ID: <1355333994.73.0.927546875612.issue16670@psf.upfronthosting.co.za>


New submission from julien tayon:

Priority: low
Keywords: documentation

After watching 
http://www.youtube.com/watch?v=o9pEzgHorH0 (Stop writing classes by diedrich)
I think the class Point example for the named tuples may be a wrong practice: 
http://docs.python.org/2/library/collections.html#collections.namedtuple

Since complex basic types

1*  does the same, (if x is real and y is imag)
2*  does more (rotation, norms,  symbolic notation with i)

At my opnion pointing some code to http://bugs.python.org/issue1818 (if it is accepted) may be the case of use of the named tuple.

----------
assignee: docs at python
components: Documentation
messages: 177382
nosy: docs at python, julien.tayon
priority: normal
severity: normal
status: open
title: [docs] class Point in collections.namedtuples may be not that good example
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Dec 12 19:28:09 2012
From: report at bugs.python.org (Andras Szalai)
Date: Wed, 12 Dec 2012 18:28:09 +0000
Subject: [New-bugs-announce] [issue16671] logging.handlers.QueueListener
	sentinel should not be	None
Message-ID: <1355336889.66.0.674591387362.issue16671@psf.upfronthosting.co.za>


New submission from Andras Szalai:

In the class `logging.handlers.QueueListener` the `_sentinel` is `None`.

But
>>> a = None
>>> b = None
>>> a is b
True

Because of this, the QueueListener stops if it receives a `None`.
Were the sentinel a proper instance, like:
_sentinel = {}

This would not happen.

----------
messages: 177385
nosy: Andras.Szalai
priority: normal
severity: normal
status: open
title: logging.handlers.QueueListener sentinel should not be None
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Dec 12 22:37:38 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 12 Dec 2012 21:37:38 +0000
Subject: [New-bugs-announce] [issue16672] improve tracing performances when
	f_trace is NULL
Message-ID: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

When f_trace is NULL, only PyTrace_CALL tracing events trigger the invocation of
the trace function (see trace_trampoline).
maybe_call_line_trace() does quite some work though _PyCode_CheckLineNumber to
find out if the instruction should be traced, and all this work is useless when f_trace
is NULL. The patch checks for f_trace on all tracing events that are not
PyTrace_CALL.

The performance gain with the following test is about 30%. The first test is
with python on the default branch, the second one with the patch applied.
Note: a breakpoint is set at line 1 to ensure that tracing is enabled, without
any breakpoint, pdb sets the trace function to None after a continue.

$ ./python -m pdb /tmp/foo.py
> /tmp/foo.py(1)<module>()
-> import timeit
(Pdb) break 1
Breakpoint 1 at /tmp/foo.py:1
(Pdb) continue
9.226385930000106
The program finished and will be restarted
> /tmp/foo.py(1)<module>()
-> import timeit
(Pdb) q
[62276 refs]


$ ./python -m pdb /tmp/foo.py 
> /tmp/foo.py(1)<module>()
-> import timeit
(Pdb) break 1
Breakpoint 1 at /tmp/foo.py:1
(Pdb) continue
7.199809867001022
The program finished and will be restarted
> /tmp/foo.py(1)<module>()
-> import timeit
(Pdb)

----------
components: Interpreter Core
files: f_trace_perfs.diff
keywords: patch
messages: 177390
nosy: xdegaye
priority: normal
severity: normal
status: open
title: improve tracing performances when f_trace is NULL
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28297/f_trace_perfs.diff

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

From report at bugs.python.org  Thu Dec 13 11:22:48 2012
From: report at bugs.python.org (Raninho Fernandes)
Date: Thu, 13 Dec 2012 10:22:48 +0000
Subject: [New-bugs-announce] [issue16673] Corrections in the library OS
	(PEP8)
Message-ID: <1355394168.38.0.46112052435.issue16673@psf.upfronthosting.co.za>


New submission from Raninho Fernandes:

Community, I realized that there are libraries that do not follow the standard PEP8, in order to start to contribute, I am providing the OS patch.

I do not know if has community interest in the corrections (PEP8).

thank you

----------
files: os_pep8.patch
keywords: patch
messages: 177402
nosy: raninho
priority: normal
severity: normal
status: open
title: Corrections in the library OS (PEP8)
Added file: http://bugs.python.org/file28300/os_pep8.patch

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

From report at bugs.python.org  Thu Dec 13 21:54:36 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Dec 2012 20:54:36 +0000
Subject: [New-bugs-announce] [issue16674] Faster getrandbits() for small
	integers
Message-ID: <1355432076.17.0.54183868892.issue16674@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds a fast patch for generating small integers (the most common use case).

Microbenchmark:
$ ./python -m timeit -s "import random; r=random.getrandbits; n=30"  "r(n);r(n);r(n);r(n);r(n);r(n);r(n);r(n);r(n);r(n)"

Non patched: 4.27 usec per loop
Patched: 2.97 usec per loop

----------
components: Extension Modules
files: random_getrandbits_fastpath.patch
keywords: patch
messages: 177436
nosy: mark.dickinson, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Faster getrandbits() for small integers
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file28304/random_getrandbits_fastpath.patch

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

From report at bugs.python.org  Thu Dec 13 22:53:14 2012
From: report at bugs.python.org (Matt Hickford)
Date: Thu, 13 Dec 2012 21:53:14 +0000
Subject: [New-bugs-announce] [issue16675] Ship Python with a package manager
Message-ID: <1355435594.3.0.516927010626.issue16675@psf.upfronthosting.co.za>


New submission from Matt Hickford:

Python should ship with a full-featured package manager. Why?

1. Most programmers would rather use a reliable maintained library for a common task than roll their own code. Then the programmer can get on with solving their unique problems. This assumes the library is convenient to install (and licensed appropriately). 

2. Other languages ship with package managers - Ruby with Gem, Nodejs with Npm. As a result, these languages have extremely successful open-source communities encouraging sharing. https://github.com/languages  Yes, Python has a strong open-source community, but there's a real hurdle to publishing packages. Nodejs is still in short trousers, but https://npmjs.org/ will shortly outnumber Python's package index. 

If you believe sharing is worthwhile, then you should want to make it easy.

Python has a decent package manager (distribute + pip) but it's ironically complicated to install. On Windows 64 bit (a very popular platform), this requires installing a package from source. You, dear Reader, surely find that easy, but it's still a big an ask for anyone new to programming. You perhaps recommend Python to friends wishing to learn programming. Could you explain over the phone how to install a package such as 'requests'? The Django homepage actually forsakes Python package management and encourages new users to build from source.

You only have to write 'python install package' into Google or read http://stackoverflow.com/questions/4750806/how-to-install-pip-on-windows to see just how much *pain* new users have with package management.

I humbly suggest pip (+ distribute), which happens to be the community's de facto standard.

----------
messages: 177437
nosy: Matt.Hickford
priority: normal
severity: normal
status: open
title: Ship Python with a package manager
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Dec 14 03:31:02 2012
From: report at bugs.python.org (Tres Seaver)
Date: Fri, 14 Dec 2012 02:31:02 +0000
Subject: [New-bugs-announce] [issue16676] Segfault under Python 3.3 after
	PyType_GenericNew
Message-ID: <1355452262.45.0.54382908485.issue16676@psf.upfronthosting.co.za>


New submission from Tres Seaver:

A test of the 'persistent' package C extension segfaults under 3.3,
but completes successfully under 3.2.  The C function being tested
is a wrapper around PyType_GenericNew:



static PyObject *
simple_new(PyObject *self, PyObject *type_object)
{
    if (!PyType_Check(type_object))
    {
        PyErr_SetString(PyExc_TypeError,
                        "simple_new argument must be a type object.");
        return NULL;
    }
    return PyType_GenericNew((PyTypeObject *)type_object, NULL, NULL);
}


The unit test which segfaults just iterates over basic types:


        def test_w_type(self):
            for typ in (type, list, dict, tuple, object):
                self.assertTrue(isinstance(self._callFUT(typ), typ))

Some digging shows that the segfault comes while deallocating the
newly-made 'dict' object.



#0  dict_dealloc (mp=0x7ffff3f9d248) at Objects/dictobject.c:1392
#1  0x00000000004261cb in tupledealloc (op=0x7ffff3d90ab8)
    at Objects/tupleobject.c:238
#2  0x000000000048065d in call_function (oparg=<optimized out>, 
    pp_stack=0x7fffffffa6e0) at Python/ceval.c:4064
#3  PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>)
    at Python/ceval.c:2679
#4  0x0000000000480b23 in fast_function (nk=<optimized out>, na=1, 
    n=<optimized out>, pp_stack=0x7fffffffa850, func=0x7ffff42284d0)
    at Python/ceval.c:4150
#5  call_function (oparg=<optimized out>, pp_stack=0x7fffffffa850)
    at Python/ceval.c:4083

----------
components: Extension Modules, Interpreter Core
messages: 177441
nosy: tseaver
priority: normal
severity: normal
status: open
title: Segfault under Python 3.3 after PyType_GenericNew
versions: Python 3.3

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

From report at bugs.python.org  Fri Dec 14 07:09:55 2012
From: report at bugs.python.org (rurpy)
Date: Fri, 14 Dec 2012 06:09:55 +0000
Subject: [New-bugs-announce] [issue16677] Hard to find operator precedence
	in Lang Ref.
Message-ID: <1355465395.03.0.430403844231.issue16677@psf.upfronthosting.co.za>


New submission from rurpy:

Python Language Reference, chapter 6 "Expressions".

The last section (6.15) of this is titled, "Summary".  That title is misleading -- it is not really a summary of the "Expressions" chapter but rather, as the first sentence makes clear, a table of operator precedences.  It is not really even a "summary" of operator precedences since some of the preceeding operator sections don't mention their precedence.  And adding to the confusion, none of preceding sections even use the word precedence, referring instead to "binding" or "priority".

Operator precedences are something many users frequently look for frequently in a language reference and the lack of an Operator Precedence entry in the ToC makes this section hard to find.

There are no index entries for "operators/precedence" or "expressions/order of evaluation".  There is an index entry for "evaluation order" but that points to a different section.

At a minimum, this section should have its title changed from "Summary" to "Operator Precedence" and get one or more index entries.

In other languages operator precedence is often described and indexed under "order of evaluation", often as a subindex of "expressions".  In the Python reference, there is a very short section called, 6.14, "Evaluation Order" that immediately preceeds the Operator Precedence section.  That section and the Operator Precedence section could be effectively combined into a single section.

----------
assignee: docs at python
components: Documentation
messages: 177444
nosy: docs at python, rurpy2
priority: normal
severity: normal
status: open
title: Hard to find operator precedence in Lang Ref.
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec 14 09:27:36 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 14 Dec 2012 08:27:36 +0000
Subject: [New-bugs-announce] [issue16678] optparse: parse only known options
Message-ID: <1355473656.34.0.647093207019.issue16678@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

This following recipe from Optik examples should be added to documentation. It is extremely helpful when porting to optparse from getopt or other option parsing schemes.

----------
assignee: docs at python
components: Documentation
messages: 177447
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: optparse: parse only known options
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Dec 14 09:28:30 2012
From: report at bugs.python.org (Claude Paroz)
Date: Fri, 14 Dec 2012 08:28:30 +0000
Subject: [New-bugs-announce] [issue16679] Wrong URL path decoding
Message-ID: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za>


New submission from Claude Paroz:

In wsgiref/simple_server.py (WSGIRequestHandler.get_environ), Python 3 is currently populating the env['PATH_INFO'] variable by decoding the URL path, assuming it was encoded with 'iso-8859-1', which appears to be wrong, according to RFC 3986/3987.
For example, if you request the path /???? in any modern browser, PATH_INFO will contain "/???????".
'iso-8859-1' should be replaced by 'utf-8' for decoding.

Note that this was introduced as part of the fix for http://bugs.python.org/issue10155

----------
components: Library (Lib)
messages: 177449
nosy: claudep
priority: normal
severity: normal
status: open
title: Wrong URL path decoding
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Dec 14 10:10:28 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 14 Dec 2012 09:10:28 +0000
Subject: [New-bugs-announce] [issue16680] Line buffering in
	socket._fileobject is borken
Message-ID: <1355476228.38.0.0287776037478.issue16680@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson:

socket._fileobject supports line buffering for output with the bufsize=1 option.  Unfortunately, it is broken and behaves like no buffering.  This patch remedies the situation.

----------
components: Library (Lib)
files: _fileobject.diff
keywords: patch
messages: 177452
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: Line buffering in socket._fileobject is borken
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file28309/_fileobject.diff

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

From report at bugs.python.org  Fri Dec 14 18:25:34 2012
From: report at bugs.python.org (Pander)
Date: Fri, 14 Dec 2012 17:25:34 +0000
Subject: [New-bugs-announce] [issue16681] Documentation 'bidirectional
	category' should be	'bidirectional class' in unicodedata package
Message-ID: <1355505934.2.0.688425095085.issue16681@psf.upfronthosting.co.za>


New submission from Pander:

Documentation in
  docs.python.org/3/library/unicodedata.html
on 'bidirectional category' should be 'bidirectional class' in unicodedata package. Please see
  www.unicode.org/Public/UNIDATA/PropertyValueAliases.txt
where only bidirectional class is being referred to.

----------
components: Unicode
messages: 177473
nosy: PanderMusubi, ezio.melotti
priority: normal
severity: normal
status: open
title: Documentation 'bidirectional category' should be 'bidirectional class' in unicodedata package
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Dec 14 18:27:44 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Dec 2012 17:27:44 +0000
Subject: [New-bugs-announce] [issue16682] Document that audioop works with
	bytes, not strings
Message-ID: <1355506064.79.0.581209145854.issue16682@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The audioop module documentation says that functions works with Python strings. This was right in 2.x, but in 3.x here should be bytes objects (actually the functions accept strings too, but this is an implementation detail, meaningless in general).

----------
assignee: docs at python
components: Documentation
messages: 177474
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Document that audioop works with bytes, not strings
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec 14 18:31:31 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Dec 2012 17:31:31 +0000
Subject: [New-bugs-announce] [issue16683] Resort audioop documentation
Message-ID: <1355506291.98.0.0406500704965.issue16683@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Functions in the audioop module documentation enumerated in alphabetic order. Only one function out of order. Here is a patch that fixes this.

----------
assignee: docs at python
components: Documentation
files: audioop_docs_resort.patch
keywords: patch
messages: 177475
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Resort audioop documentation
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28313/audioop_docs_resort.patch

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

From report at bugs.python.org  Fri Dec 14 18:33:12 2012
From: report at bugs.python.org (Pander)
Date: Fri, 14 Dec 2012 17:33:12 +0000
Subject: [New-bugs-announce] [issue16684] Unicode property value abbreviated
	names and long names
Message-ID: <1355506392.97.0.314398568458.issue16684@psf.upfronthosting.co.za>


New submission from Pander:

The package unicodedata
  http://docs.python.org/3/library/unicodedata.html
offers looking up of property values in terms of general category, bidirectional class and east asian width for Unicode characters
  unicodedata.category(unichr)
  unicodedata.bidirectional(unichr)
  unicodedata.east_asian_width(chr)

The abbreviated name of the specific category is returned. However, for certain applications it is important to be able to get the from abbreviated name to the long name and vice versa.

The data needed to do this can be found at
  http://www.unicode.org/Public/UNIDATA/PropertyValueAliases.txt
under sections
  # General_Category (gc)
  # Bidi_Class (bc)
  # East_Asian_Width (ea)
Use only the second (abbreviated name) and third (long name) fields and ignoring other fields and possible comments.

For general category, also support translation back and forth of the one-letter abbreviations which are groups representing two-letter general categories abbreviations with the same initial letter.

Please extend this package with a way of translating back and forth between abbreviated name and long name for property values defined in Unicode for general category, bidirectional class and East Asian width. This functionality should be independent of retrieving the abbreviated names for Unicode character as is available now and should be accessible via separate methods or dictionaries in which developers can perform lookups themselves.

Implementing the functionality requested in this issue allows Python developers to get from an abbreviated property value to a meaningful property value name and vice versa without having to retrieve this information from the Unicode Consortium and/or shipping this information with their code with the risk of using outdated information.

----------
components: Unicode
messages: 177476
nosy: PanderMusubi, ezio.melotti
priority: normal
severity: normal
status: open
title: Unicode property value abbreviated names and long names
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Dec 14 18:37:35 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Dec 2012 17:37:35 +0000
Subject: [New-bugs-announce] [issue16685] Deprecate accepting strings as
	arguments in audioop	functions
Message-ID: <1355506655.59.0.00344503753899.issue16685@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Inadvertently strings accepted as arguments of audioop functions. This is a meaningless behavior and remnant of Python 2. We should drop string support.

----------
components: Extension Modules
messages: 177477
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Deprecate accepting strings as arguments in audioop functions
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Dec 14 19:15:07 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Dec 2012 18:15:07 +0000
Subject: [New-bugs-announce] [issue16686] audioop overflow issues
Message-ID: <1355508907.39.0.527029919241.issue16686@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The audioop module has some issues with an overflow.

1. It uses post-checks for an integer overflow. This means using an undefined behavior.

2. When the result truncated in case of overflow, -maxval used as minimal value. But real minimum value is less (-maxval - 1). This means not using full possible range and causes an odd result of some operations (for example add(b'\x80', '\x00', 1) returns b'\x81').

3. Some operations (for example bias()) does not truncating and just overflow.

4. lin2lin() conversion from 4 to 4 (should do nothing) loses 16 lowest bits.

----------
components: Extension Modules
messages: 177482
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: audioop overflow issues
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec 14 21:55:54 2012
From: report at bugs.python.org (Jeff Knupp)
Date: Fri, 14 Dec 2012 20:55:54 +0000
Subject: [New-bugs-announce] [issue16687] Fix small gramatical error and add
	reference link in	hashlib documentation
Message-ID: <1355518554.59.0.0791078366076.issue16687@psf.upfronthosting.co.za>


New submission from Jeff Knupp:

Original text is: 

> Feeding string objects is to update is not supported

Should be "... objects in to update" instead of "is to"

Also, mark "GIL" as a :term: to provide a link to its definition, as it's used without much context in the following note:

> .. note::
>
>   For better multithreading performance, the Python :term:`GIL` is 
>   released for strings of more than 2047 bytes at object creation or
>   on update.

----------
assignee: docs at python
components: Documentation
files: patch.txt
messages: 177507
nosy: Jeff.Knupp, docs at python
priority: normal
severity: normal
status: open
title: Fix small gramatical error and add reference link in hashlib documentation
versions: Python 3.5
Added file: http://bugs.python.org/file28318/patch.txt

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

From report at bugs.python.org  Fri Dec 14 23:19:34 2012
From: report at bugs.python.org (pyos)
Date: Fri, 14 Dec 2012 22:19:34 +0000
Subject: [New-bugs-announce] [issue16688] Backreferences make
	case-insensitive regex fail on	non-ASCII strings.
Message-ID: <1355523574.0.0.662120788659.issue16688@psf.upfronthosting.co.za>


New submission from pyos:

The title says it all: if a regular expression that makes use of backreferences is compiled with `re.I` flag, it will always fail when matched against a string that contains characters outside of U+0000-U+00FF range. I've been unable to further narrow the bug down.

A simple example:

    >>> import re
    >>> r = re.compile(r'(a)\1', re.I)  # should match "aa", "aA", "Aa", or "AA"
    >>> r.findall('aa')  # works as expected
    ['a']
    >>> r.findall('aa bcd')  # still works
    ['a']
    >>> r.findall('aa ?')  # ord('?') == 0x0100
    []

The same code works as expected in Python 3.2:

    >>> r.findall('aa ?')
    ['a']

----------
components: Regular Expressions
messages: 177518
nosy: ezio.melotti, mrabarnett, pitrou, pyos
priority: normal
severity: normal
status: open
title: Backreferences make case-insensitive regex fail on non-ASCII strings.
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Dec 15 01:56:53 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 15 Dec 2012 00:56:53 +0000
Subject: [New-bugs-announce] [issue16689] stdout stderr redirection mess
Message-ID: <1355533013.89.0.974705743737.issue16689@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Tested on Windows. When Python output is redirected with:

> py test_unicode_fname.py > test.log 2>&1

In Python 2.7 the traceback is at the end of file, in Python 3.3 it is at the beginning. In should be in the middle, and it appears on the screen correctly.

>From issue16656.

----------
files: test_unicode_fname.py
messages: 177525
nosy: techtonik
priority: normal
severity: normal
status: open
title: stdout stderr redirection mess
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28320/test_unicode_fname.py

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

From report at bugs.python.org  Sat Dec 15 02:39:25 2012
From: report at bugs.python.org (Bradley Froehle)
Date: Sat, 15 Dec 2012 01:39:25 +0000
Subject: [New-bugs-announce] [issue16690] Reference leak with custom
	tp_dealloc in PyType_FromSpec
Message-ID: <1355535565.73.0.312355807055.issue16690@psf.upfronthosting.co.za>


New submission from Bradley Froehle:

There is a reference leak when using PyType_FromSpec with custom tp_dealloc.  This was first noted in issue #15142, where a fix was given which only applies to types which do not override tp_dealloc.

For example, the xxlimited.Xxo type suffers from this:

Python 3.3.0 (default, Oct 26 2012, 11:06:17) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import xxlimited
>>> import sys
>>> Xxo = type(xxlimited.new())
>>> e = Xxo()
>>> sys.getrefcount(Xxo)
7
>>> e = Xxo()
>>> sys.getrefcount(Xxo)
8
>>> e = Xxo()
>>> sys.getrefcount(Xxo)
9

----------
components: Interpreter Core
messages: 177527
nosy: bfroehle
priority: normal
severity: normal
status: open
title: Reference leak with custom tp_dealloc in PyType_FromSpec
type: resource usage
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Dec 15 06:05:05 2012
From: report at bugs.python.org (David Wolf)
Date: Sat, 15 Dec 2012 05:05:05 +0000
Subject: [New-bugs-announce] [issue16691] How to use
	ctypes.windll.user32.MessageBoxW
Message-ID: <1355547905.83.0.364744647491.issue16691@psf.upfronthosting.co.za>


New submission from David Wolf:

import ctypes
ctypes.windll.user32.MessageBoxW(0,"Time's up!","Message",0)


My quention is that I want to set my message box topmost.
It's said I just need to change the first parameter, but I don't know how I should change it.

Help me please! I've been working on this for an hour.

----------
components: ctypes
messages: 177529
nosy: David.Wolf
priority: normal
severity: normal
status: open
title: How to use ctypes.windll.user32.MessageBoxW
type: resource usage
versions: Python 3.3

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

From report at bugs.python.org  Sat Dec 15 18:31:05 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Dec 2012 17:31:05 +0000
Subject: [New-bugs-announce] [issue16692] Support TLS 1.1 and TLS 1.2
Message-ID: <1355592665.89.0.539973629387.issue16692@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Recent OpenSSL versions (e.g. 1.0.1c) have explicit support for TLS 1.1 and (presumably, although undocumented-ly) TLS 1.2 through TLSv1_1_method() and TLSv1_2_method(). It should be easy to add such support to the ssl module (although figuring out how exactly protocol version compatibility is handled - for the docs - might be a challenge).

----------
components: Library (Lib)
keywords: easy
messages: 177541
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Support TLS 1.1 and TLS 1.2
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Dec 15 18:40:43 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 15 Dec 2012 17:40:43 +0000
Subject: [New-bugs-announce] [issue16693] Assertion error in ceval if
	Chainmap(object()) used as	locals in eval
Message-ID: <1355593243.44.0.295822676062.issue16693@psf.upfronthosting.co.za>


New submission from R. David Murray:

>>> import collections
[61531 refs, 20955 blocks]
>>> eval('foo', {}, collections.ChainMap(object()))
python: Python/ceval.c:2996: PyEval_EvalFrameEx: Assertion `0' failed.
zsh: abort      ./python

----------
messages: 177542
nosy: r.david.murray, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Assertion error in ceval if Chainmap(object()) used as locals in eval
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec 16 08:24:41 2012
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 16 Dec 2012 07:24:41 +0000
Subject: [New-bugs-announce] [issue16694] Add pure Python operator module
Message-ID: <1355642681.84.0.519392654153.issue16694@psf.upfronthosting.co.za>


New submission from Zachary Ware:

(Brett, I've made you nosy due to the relation to Issue16651.)

Here is a pure Python implementation of the operator module, or at least a first draft thereof :).  I'm attaching the module itself, as well as a patch to integrate it.

Any and all review is quite welcome. I'm confident in the fact that the module as it stands passes all current tests, but how it gets there is entirely up for debate (namely, the attrgetter, itemgetter, and methodcaller classes, as well as length_hint(), countOf(), and indexOf()).

Note that there's also a change to hmac.py; _compare_digest() in operator.c doesn't seem to have any relation to the rest of the module (see issue15061 discussion) and is private anyway, so operator.py doesn't go near it.  hmac.py has to import directly from _operator.

Thanks,

Zach Ware

----------
components: Extension Modules, Library (Lib)
files: operator.py
messages: 177579
nosy: brett.cannon, zach.ware
priority: normal
severity: normal
status: open
title: Add pure Python operator module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28327/operator.py

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

From report at bugs.python.org  Sun Dec 16 11:32:16 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 16 Dec 2012 10:32:16 +0000
Subject: [New-bugs-announce] [issue16695] Clarify fnmatch & glob docs about
	the handling of	leading "."s
Message-ID: <1355653936.06.0.839482874064.issue16695@psf.upfronthosting.co.za>


New submission from Hynek Schlawack:

See issue16664.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 177584
nosy: Sebastian.Kreft, docs at python, hynek, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Clarify fnmatch & glob docs about the handling of leading "."s
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Dec 16 14:20:31 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Dec 2012 13:20:31 +0000
Subject: [New-bugs-announce] [issue16696] BytesWarning in glob.glob
Message-ID: <1355664031.2.0.313803756669.issue16696@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This failure appeared on one of the Windows buildbots:

======================================================================
ERROR: test_glob_magic_in_drive (test.test_glob.GlobTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.2.kloth-win64\build\lib\test\test_glob.py", line 118, in test_glob_magic_in_drive
    eq(glob.glob(b'*:'), [])
  File "C:\buildbot.python.org\3.2.kloth-win64\build\lib\glob.py", line 15, in glob
    return list(iglob(pathname))
  File "C:\buildbot.python.org\3.2.kloth-win64\build\lib\glob.py", line 44, in iglob
    for name in glob_in_dir(dirname, basename):
  File "C:\buildbot.python.org\3.2.kloth-win64\build\lib\glob.py", line 66, in glob0
    if basename == '':
BytesWarning: Comparison between bytes and string

----------
components: Library (Lib), Windows
messages: 177596
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: BytesWarning in glob.glob
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Dec 16 14:53:55 2012
From: report at bugs.python.org (wim glenn)
Date: Sun, 16 Dec 2012 13:53:55 +0000
Subject: [New-bugs-announce] [issue16697] argparse kwarg 'choices'
	documentation
Message-ID: <1355666035.13.0.877787561314.issue16697@psf.upfronthosting.co.za>


New submission from wim glenn:

Any object that supports the in operator can be passed as the choices value, so dict objects, set objects, custom containers, etc. are all supported.  (from  http://docs.python.org/dev/library/argparse.html#choices )

Actual behaviour is contradicted by the docs - it seems the container must additionally be iterable.  When using a custom container, argparse b0rks on trying to iterate through choices.  Using a metavar prevents this, but it still breaks on cases where the element is not in the container.  

More details here:  
http://stackoverflow.com/questions/13833566/python-argparse-choices-from-an-infinite-set

----------
assignee: docs at python
components: Documentation
messages: 177599
nosy: docs at python, wim.glenn
priority: normal
severity: normal
status: open
title: argparse kwarg 'choices' documentation
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sun Dec 16 15:05:09 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 16 Dec 2012 14:05:09 +0000
Subject: [New-bugs-announce] [issue16698] test_posix.test_getgroups fails on
	some systems
Message-ID: <1355666709.31.0.161385459804.issue16698@psf.upfronthosting.co.za>


New submission from Ross Lagerwall:

test_posix.test_getgroups() fails on some systems:

http://buildbot.python.org/all/builders/AMD64%20Mountain%20Lion%20%5BSB%5D%203.2

This could be related to #16661.

----------
components: Tests
messages: 177601
nosy: rosslagerwall
priority: normal
severity: normal
stage: needs patch
status: open
title: test_posix.test_getgroups fails on some systems
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Dec 16 17:26:25 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Dec 2012 16:26:25 +0000
Subject: [New-bugs-announce] [issue16699] Mountain Lion buildbot lacks disk
	space
Message-ID: <1355675185.68.0.917040495846.issue16699@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: pitrou
priority: normal
severity: normal
status: open
title: Mountain Lion buildbot lacks disk space

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

From report at bugs.python.org  Sun Dec 16 17:58:37 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Dec 2012 16:58:37 +0000
Subject: [New-bugs-announce] [issue16700] Document that bytes OS API can
	returns unusable results	on Windows
Message-ID: <1355677117.39.0.191453655217.issue16700@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Some OS functions which returns bytes (os.environb, os.getenvb(), os.getcwdb(), os.listdir(), os.readlink(), os.walk(), os.path.abspath(), os.path.expanduser(), os.path.expandvars(), os.path.realpath() and may be other) can return unusable result on Windows (see for example issue13247 and issue16656). The documentation should contains strong warnings about this.

----------
assignee: docs at python
components: Documentation, Windows
messages: 177613
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Document that bytes OS API can returns unusable results on Windows
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Dec 16 21:41:14 2012
From: report at bugs.python.org (Ashwini Chaudhary)
Date: Sun, 16 Dec 2012 20:41:14 +0000
Subject: [New-bugs-announce] [issue16701] Docs missing the behavior of +=
	(in-place add) for lists.
Message-ID: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>


New submission from Ashwini Chaudhary:

I think the python docs are missing the behavior of += for lists. It actually calls list.extend() but can't find that anywhere in docs expect in source code, http://hg.python.org/cpython/file/2d2d4807a3ed/Objects/listobject.c#l892.

----------
assignee: docs at python
components: Documentation
messages: 177627
nosy: docs at python, montysinngh
priority: normal
severity: normal
status: open
title: Docs missing the behavior of += (in-place add) for lists.
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Dec 17 18:40:12 2012
From: report at bugs.python.org (Jeff Knupp)
Date: Mon, 17 Dec 2012 17:40:12 +0000
Subject: [New-bugs-announce] [issue16702] Force urllib2_localnet test not to
	use http proxies
Message-ID: <1355766012.42.0.0371520737596.issue16702@psf.upfronthosting.co.za>


New submission from Jeff Knupp:

test_urllib2_localnet is concerned with testing connections only using 'localhost' or '127.0.0.1' hosts. If a user has the "http_proxy" environment variable set, these test will likely fail as the proxy won't have any idea where to send a request for 'localhost'.

Patch makes urllib.request.urlopen ignore proxies set in the environment. Note that this only works for http proxies. https proxies are trickier and require more work.

----------
components: Tests
files: test_proxy.patch
keywords: patch
messages: 177654
nosy: Jeff.Knupp
priority: normal
severity: normal
status: open
title: Force urllib2_localnet test not to use http proxies
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file28343/test_proxy.patch

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

From report at bugs.python.org  Mon Dec 17 20:38:45 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Dec 2012 19:38:45 +0000
Subject: [New-bugs-announce] [issue16703] except statement turns defined
	variable into undefined
Message-ID: <1355773125.79.0.0457031741632.issue16703@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Example:

>>> err = None
>>> try: raise ValueError
... except ValueError as err: pass
... 
>>> err
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'err' is not defined

It is expected that either the variable will have the catched value, or save the old value, or the compiler will raise an error. But it didn't even warns.

----------
components: Interpreter Core
messages: 177657
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: except statement turns defined variable into undefined
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec 17 21:09:32 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 17 Dec 2012 20:09:32 +0000
Subject: [New-bugs-announce] [issue16704] Get rid of select.error in stdlib.
	Use OSError instead
Message-ID: <1355774972.19.0.330000367797.issue16704@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
assignee: asvetlov
components: Library (Lib)
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Get rid of select.error in stdlib. Use OSError instead
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec 17 21:31:39 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 17 Dec 2012 20:31:39 +0000
Subject: [New-bugs-announce] [issue16705] Use concrete classes inherited
	from OSError instead of	errno check
Message-ID: <1355776299.81.0.3555135726.issue16705@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

Probably it is long enough work and should be done in several iteration after converting all exceptions like IOError, EnvironmentError, WindowsError, mmap.error, socket.error and select.error to OSError.

----------
assignee: asvetlov
components: Library (Lib)
messages: 177668
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Use concrete classes inherited from OSError instead of errno check
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec 17 21:51:37 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 17 Dec 2012 20:51:37 +0000
Subject: [New-bugs-announce] [issue16706] Get rid of os.error. Use OSError
	instead
Message-ID: <1355777497.03.0.498840147649.issue16706@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
assignee: asvetlov
components: Library (Lib)
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Get rid of os.error. Use OSError instead
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec 17 22:51:03 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Dec 2012 21:51:03 +0000
Subject: [New-bugs-announce] [issue16707] --with-pydebug and
	--without-pymalloc are incompatible
Message-ID: <1355781063.36.0.527295218216.issue16707@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Here is what happens when combining --with-pydebug and --without-pymalloc:

gcc -pthread -g -O0 -Wall -Wstrict-prototypes   Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/dynamic_annotations.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/parsetok_pgen.o Parser/pgenmain.o -lpthread -ldl  -lutil -o Parser/pgen
Parser/tokenizer_pgen.o: In function `tok_new':
/home/antoine/cpython/default/Parser/tokenizer.c:115: undefined reference to `_PyMem_DebugMalloc'
Parser/tokenizer_pgen.o: In function `new_string':
/home/antoine/cpython/default/Parser/tokenizer.c:152: undefined reference to `_PyMem_DebugMalloc'
Parser/tokenizer_pgen.o: In function `PyTokenizer_FromUTF8':
/home/antoine/cpython/default/Parser/tokenizer.c:799: undefined reference to `_PyMem_DebugMalloc'
Parser/tokenizer_pgen.o: In function `PyTokenizer_FromFile':
/home/antoine/cpython/default/Parser/tokenizer.c:819: undefined reference to `_PyMem_DebugMalloc'
/home/antoine/cpython/default/Parser/tokenizer.c:831: undefined reference to `_PyMem_DebugMalloc'
Parser/tokenizer_pgen.o: In function `PyTokenizer_Free':
/home/antoine/cpython/default/Parser/tokenizer.c:849: undefined reference to `_PyMem_DebugFree'
/home/antoine/cpython/default/Parser/tokenizer.c:856: undefined reference to `_PyMem_DebugFree'
/home/antoine/cpython/default/Parser/tokenizer.c:858: undefined reference to `_PyMem_DebugFree'
/home/antoine/cpython/default/Parser/tokenizer.c:859: undefined reference to `_PyMem_DebugFree'
Parser/tokenizer_pgen.o: In function `tok_nextc':
/home/antoine/cpython/default/Parser/tokenizer.c:928: undefined reference to `_PyMem_DebugFree'
/home/antoine/cpython/default/Parser/tokenizer.c:936: undefined reference to `_PyMem_DebugRealloc'
/home/antoine/cpython/default/Parser/tokenizer.c:939: undefined reference to `_PyMem_DebugFree'
/home/antoine/cpython/default/Parser/tokenizer.c:941: undefined reference to `_PyMem_DebugFree'
/home/antoine/cpython/default/Parser/tokenizer.c:949: undefined reference to `_PyMem_DebugFree'
/home/antoine/cpython/default/Parser/tokenizer.c:957: undefined reference to `_PyMem_DebugFree'
/home/antoine/cpython/default/Parser/tokenizer.c:973: undefined reference to `_PyMem_DebugMalloc'
/home/antoine/cpython/default/Parser/tokenizer.c:1008: undefined reference to `_PyMem_DebugRealloc'
Parser/tokenizer_pgen.o: In function `PyTokenizer_FindEncodingFilename':
/home/antoine/cpython/default/Parser/tokenizer.c:1753: undefined reference to `_PyMem_DebugMalloc'
Parser/parsetok_pgen.o: In function `parsetok':
/home/antoine/cpython/default/Parser/parsetok.c:179: undefined reference to `_PyObject_DebugMalloc'
/home/antoine/cpython/default/Parser/parsetok.c:193: undefined reference to `_PyObject_DebugFree'
/home/antoine/cpython/default/Parser/parsetok.c:199: undefined reference to `_PyObject_DebugFree'
/home/antoine/cpython/default/Parser/parsetok.c:217: undefined reference to `_PyObject_DebugFree'
/home/antoine/cpython/default/Parser/parsetok.c:275: undefined reference to `_PyObject_DebugMalloc'
/home/antoine/cpython/default/Parser/parsetok.c:288: undefined reference to `_PyObject_DebugMalloc'
/home/antoine/cpython/default/Parser/parsetok.c:292: undefined reference to `_PyObject_DebugFree'
/home/antoine/cpython/default/Parser/parsetok.c:297: undefined reference to `_PyMem_DebugFree'
Parser/pgenmain.o: In function `getgrammar':
/home/antoine/cpython/default/Parser/pgenmain.c:111: undefined reference to `_PyObject_DebugFree'
Parser/pgenmain.o: In function `PyOS_Readline':
/home/antoine/cpython/default/Parser/pgenmain.c:143: undefined reference to `_PyMem_DebugMalloc'
/home/antoine/cpython/default/Parser/pgenmain.c:156: undefined reference to `_PyMem_DebugRealloc'
collect2: ld a retourn? 1 code d'?tat d'ex?cution
make[1]: *** [Parser/pgen] Erreur 1
make[1] : on quitte le r?pertoire ? /home/antoine/cpython/default ?
make: *** [Include/graminit.h] Erreur 2

----------
components: Interpreter Core
messages: 177671
nosy: pitrou, skrah
priority: low
severity: normal
status: open
title: --with-pydebug and --without-pymalloc are incompatible
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec 18 02:54:02 2012
From: report at bugs.python.org (luke wood)
Date: Tue, 18 Dec 2012 01:54:02 +0000
Subject: [New-bugs-announce] [issue16708] Module: shutil will not import
	when writen in the text	editor but will in the python shell
Message-ID: <1355795642.02.0.671749780764.issue16708@psf.upfronthosting.co.za>


Changes by luke wood <dj_law at live.com>:


----------
components: Library (Lib)
files: dropbox dropper.py
nosy: dj_law
priority: normal
severity: normal
status: open
title: Module: shutil will not import when writen in the text editor but will in the python shell
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file28346/dropbox dropper.py

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

From report at bugs.python.org  Tue Dec 18 03:28:57 2012
From: report at bugs.python.org (Robert Collins)
Date: Tue, 18 Dec 2012 02:28:57 +0000
Subject: [New-bugs-announce] [issue16709] unittest discover order is
	filesystem specific - hard to	reproduce
Message-ID: <1355797737.36.0.999533489695.issue16709@psf.upfronthosting.co.za>


New submission from Robert Collins:

Openstack recently switched from nose to using discover. discover walks the filesystem using os.listdir(), and that is just a thin layer over readdir. On ext3/ext4 filesystems, readdir is in an arbitrary order dependent on file insertion into the directory if dir_index is enabled (which is the default).

This means that files are loaded in an order that isn't reproducable by other developers, so bad tests that have isolation issues can be very tricky to track down.

Just wrapping the os.listdir() in sorted() would be sufficient to make this robust and repeatable, and avoid the headache.

----------
components: Library (Lib)
messages: 177675
nosy: ezio.melotti, michael.foord, pitrou, rbcollins
priority: normal
severity: normal
status: open
title: unittest discover order is filesystem specific - hard to reproduce
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Dec 18 10:39:03 2012
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCT0LDQstGA0LjQu9C40L0=?=)
Date: Tue, 18 Dec 2012 09:39:03 +0000
Subject: [New-bugs-announce] [issue16710] json encode/decode error
Message-ID: <1355823543.95.0.422130341622.issue16710@psf.upfronthosting.co.za>


New submission from ?????? ????????:

I sent this.

{24: (0, ''), 27: (0, ''), 19: (0, ''), 28: (0, '')}

{"tasks": {"24": [0, ""], "27": [0, ""], "19": [0, ""], "28": [0, ""]}, "uuid": "8798b4dfbe3646e5ab05106f6f9af6fe", "delay": 3, "task_limit": 10, "arch": ["ARM", "i386", "x86_64"], "build_env": "fedora"}

And I've got this.

{"tasks": {"24": [0, ""], "27": [0, ""], "19": [0, ""], "28": [0, ""]}, "uuid": "8798b4dfbe3646e5ab05106f6f9af6fe", "delay": 3, "task_limit": 10, "arch": ["ARM", "i386", "x86_64"], "build_env": "fedora"}

{u'tasks': {u'24': [0, u''], u'19': [0, u''], u'27': [0, u''], u'28': [0, u'']}, u'uuid': u'8798b4dfbe3646e5ab05106f6f9af6fe', u'delay': 3, u'task_limit': 10, u'arch': [u'ARM', u'i386', u'x86_64'], u'build_env': u'rosa'}

{u'24': [0, u''], u'19': [0, u''], u'27': [0, u''], u'28': [0, u'']}

It must contain digits.


{24: (0, ''), 27: (0, ''), 19: (0, ''), 28: (0, '')}

{u'24': [0, u''], u'19': [0, u''], u'27': [0, u''], u'28': [0, u'']}

----------
messages: 177679
nosy: ??????.????????
priority: normal
severity: normal
status: open
title: json encode/decode error
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec 18 11:16:56 2012
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 18 Dec 2012 10:16:56 +0000
Subject: [New-bugs-announce] [issue16711] s/next()/__next__/ in
	collections.abc.Iterator document.
Message-ID: <1355825815.83.0.808882740221.issue16711@psf.upfronthosting.co.za>


New submission from INADA Naoki:

http://docs.python.org/3/library/collections.abc.html#collections.abc.Iterator

>     ABC for classes that provide the __iter__() and next() methods.

"next()" should be "__next__()" for Python 3.

----------
assignee: docs at python
components: Documentation
messages: 177681
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: s/next()/__next__/ in collections.abc.Iterator document.
versions: Python 3.3

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

From report at bugs.python.org  Tue Dec 18 13:56:01 2012
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 18 Dec 2012 12:56:01 +0000
Subject: [New-bugs-announce] [issue16712] collections.abc.Sequence should
	not provide __reversed__
Message-ID: <1355835361.63.0.373231585566.issue16712@psf.upfronthosting.co.za>


New submission from INADA Naoki:

http://docs.python.org/3.3/reference/datamodel.html#object.__reversed__
>  Objects that support the sequence protocol should only provide __reversed__() if they can provide an implementation that is more efficient than the one provided by reversed().

collections.abc.Sequence can't provide more efficient method.
It only make `reversed()` slower.

----------
components: Library (Lib)
messages: 177688
nosy: naoki
priority: normal
severity: normal
status: open
title: collections.abc.Sequence should not provide __reversed__
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Dec 18 15:30:24 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Dec 2012 14:30:24 +0000
Subject: [New-bugs-announce] [issue16713] "tel" URIs should support params
Message-ID: <1355841024.52.0.600019146787.issue16713@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

RFC 3966 (http://tools.ietf.org/html/rfc3966) defines the tel URI and its parameters. However, urlparse / urllib.parse doesn't recognize "tel" URIs as taking parameters:

>>> urlparse.urlparse('tel:7042;phone-context=example.com')
ParseResult(scheme='tel', netloc='', path='7042;phone-context=example.com', params='', query='', fragment='')

----------
components: Library (Lib)
messages: 177692
nosy: orsenthil, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: "tel" URIs should support params
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec 18 19:11:29 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Dec 2012 18:11:29 +0000
Subject: [New-bugs-announce] [issue16714] Raise exceptions, don't throw
Message-ID: <1355854289.26.0.789629634493.issue16714@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch fixes wording of documentation, comments, etc which use the term 'throw' instead of 'raise' in context of exception raising.

----------
assignee: docs at python
components: Documentation
files: raise-3.3.patch
keywords: patch
messages: 177698
nosy: asvetlov, docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Raise exceptions, don't throw
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28347/raise-3.3.patch

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

From report at bugs.python.org  Tue Dec 18 20:36:56 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 18 Dec 2012 19:36:56 +0000
Subject: [New-bugs-announce] [issue16715] Get rid of IOrror. Use OSError
	instead
Message-ID: <1355859416.59.0.0780309826509.issue16715@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
assignee: asvetlov
components: Library (Lib)
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Get rid of IOrror. Use OSError instead
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec 18 21:07:22 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 18 Dec 2012 20:07:22 +0000
Subject: [New-bugs-announce] [issue16716] Deprecate OSError aliases in the
	doc
Message-ID: <1355861242.44.0.0203808398116.issue16716@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

The list of aliases is: IOError, EnvironmentError, WindowsError, mmap.error, socket.error, os.error and select.error

Documentation should have deprecation message guessing to use OSError instead.

----------
messages: 177704
nosy: asvetlov
priority: normal
severity: normal
stage: needs patch
status: open
title: Deprecate OSError aliases in the doc
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec 18 21:13:46 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 18 Dec 2012 20:13:46 +0000
Subject: [New-bugs-announce] [issue16717] Get rid of socket.error. Use
	OSError instead
Message-ID: <1355861626.7.0.653509506755.issue16717@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
assignee: asvetlov
components: Documentation
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Get rid of socket.error. Use OSError instead
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec 18 21:35:40 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 18 Dec 2012 20:35:40 +0000
Subject: [New-bugs-announce] [issue16718] Mysterious atexit fail
Message-ID: <1355862940.68.0.167478798513.issue16718@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Weird bug. Attached are two files: wow.py and wy.py
When wow.py is executed - it fails with single ImportError.
But when wy.py is executed (which is a simple "import wow" statement) it fails with one ImportError and TypeError exceptions.

----------
components: Interpreter Core, Library (Lib)
messages: 177707
nosy: techtonik
priority: normal
severity: normal
status: open
title: Mysterious atexit fail
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Dec 18 22:32:35 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Dec 2012 21:32:35 +0000
Subject: [New-bugs-announce] [issue16719] Get rid of WindowsError. Use
	OSError instead
Message-ID: <1355866355.61.0.0791773762565.issue16719@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch.

----------
components: Extension Modules, Interpreter Core, Library (Lib)
files: windowserror2oserror.patch
keywords: patch
messages: 177719
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Get rid of WindowsError. Use OSError instead
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28355/windowserror2oserror.patch

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

From report at bugs.python.org  Tue Dec 18 23:07:36 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Dec 2012 22:07:36 +0000
Subject: [New-bugs-announce] [issue16720] Get rid of os.error. Use OSError
	instead
Message-ID: <1355868456.72.0.79747952931.issue16720@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch.

----------
components: Library (Lib)
files: os.error2oserror.diff
keywords: patch
messages: 177721
nosy: asvetlov, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Get rid of os.error. Use OSError instead
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28356/os.error2oserror.diff

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

From report at bugs.python.org  Tue Dec 18 23:08:17 2012
From: report at bugs.python.org (Vladimir Timofeev)
Date: Tue, 18 Dec 2012 22:08:17 +0000
Subject: [New-bugs-announce] [issue16721] configure incorrectly adds
	-OPT:Olimit=0 for clang
Message-ID: <1355868497.91.0.141324882263.issue16721@psf.upfronthosting.co.za>


New submission from Vladimir Timofeev:

Similar to http://bugs.python.org/issue1162001

But some differences, issue exposed only when first -OPT:Olimit=0 followed by correct -On option. clang simple do not check correctness of first occurences of -O:

$ clang -OPT:Olimit=0 test.c; echo $?
error: invalid integral value 'PT:Olimit=0' in '-OPT:Olimit=0'
error: invalid integral value 'PT:Olimit=0' in '-OPT:Olimit=0'
1

$ clang -OPT:Olimit=0 -O2 test.c; echo $?                                                                                                                                                                
0

This leads to normal compilation of python itself, but some dependant software built by gcc fails (see http://www.freebsd.org/cgi/query-pr.cgi?pr=174525 )

----------
components: Build
messages: 177722
nosy: Vladimir.Timofeev
priority: normal
severity: normal
status: open
title: configure incorrectly adds -OPT:Olimit=0 for clang
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec 19 06:42:52 2012
From: report at bugs.python.org (=?utf-8?b?0KDRg9GB0LvQsNC9INCY0LbQsdGD0LvQsNGC0L7Qsg==?=)
Date: Wed, 19 Dec 2012 05:42:52 +0000
Subject: [New-bugs-announce] [issue16722] __index__() overrides __bytes__()
	when bytes() is called
Message-ID: <1355895772.21.0.287047855702.issue16722@psf.upfronthosting.co.za>


New submission from ?????? ?????????:

If a class implements both __index__() and __bytes__(), the built-in bytes() constructor uses __index__() in place of __bytes__(), including the assumption that __index__() returns a bytes object.

Attaching a simple example (leads to overflow when big integer is casted to bytes).

----------
components: None
files: testb.py
messages: 177725
nosy: LRN
priority: normal
severity: normal
status: open
title: __index__() overrides __bytes__() when bytes() is called
versions: Python 3.3
Added file: http://bugs.python.org/file28357/testb.py

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

From report at bugs.python.org  Wed Dec 19 07:42:14 2012
From: report at bugs.python.org (Michiel de Hoon)
Date: Wed, 19 Dec 2012 06:42:14 +0000
Subject: [New-bugs-announce] [issue16723] io.TextIOWrapper on
	urllib.request.urlopen terminates	prematurely
Message-ID: <1355899334.66.0.683261774989.issue16723@psf.upfronthosting.co.za>


New submission from Michiel de Hoon:

I am trying to use io.TextIOWrapper to wrap a handle returned by urllib.request.urlopen. Reading line-by-line from the wrapped handle terminates prematurely.

As an example, consider this script:

import urllib.request
import io

url = "http://www.python.org"
handle = urllib.request.urlopen(url)
wrapped_handle = io.TextIOWrapper(handle, encoding='utf-8')
for line in wrapped_handle:
    pass

This gives:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file.

This happens after 335 out of the 430 lines have been read (the last line read is "<p>The <a class="reference external" href="/psf/">Python Software Foundation</a> holds the intellectual property\n", which is line 335 on the www.python.org website.

----------
messages: 177726
nosy: mdehoon
priority: normal
severity: normal
status: open
title: io.TextIOWrapper on urllib.request.urlopen terminates prematurely
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Dec 19 10:36:38 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 19 Dec 2012 09:36:38 +0000
Subject: [New-bugs-announce] [issue16724] Rename `data` argument names to
	`bytes`
Message-ID: <1355909798.33.0.519653926366.issue16724@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

http://docs.python.org/3/library/binascii

- binascii.hexlify(data)
+ binascii.hexlify(bytes)

tag:easy

----------
assignee: docs at python
components: Documentation
messages: 177727
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Rename `data` argument names to `bytes`
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Dec 19 11:36:58 2012
From: report at bugs.python.org (Jakob Eriksson)
Date: Wed, 19 Dec 2012 10:36:58 +0000
Subject: [New-bugs-announce] [issue16725] Add 'ident' property to
	SysLogHandler like in Python 3.x
Message-ID: <1355913418.22.0.692856202576.issue16725@psf.upfronthosting.co.za>


New submission from Jakob Eriksson:

Can we have the same ident property for the SysLogHandler in the Python 2.7 library, like it was introduced in the 3.x library?


( Like http://hg.python.org/cpython/rev/6baa90fa2b6d )

----------
components: Library (Lib)
hgrepos: 165
messages: 177732
nosy: b-jakob-v
priority: normal
severity: normal
status: open
title: Add 'ident' property to SysLogHandler like in Python 3.x
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec 19 11:56:49 2012
From: report at bugs.python.org (Michiel de Hoon)
Date: Wed, 19 Dec 2012 10:56:49 +0000
Subject: [New-bugs-announce] [issue16726] expat ParseFile expects bytes,
	not string
Message-ID: <1355914609.66.0.723053050254.issue16726@psf.upfronthosting.co.za>


New submission from Michiel de Hoon:

The expat parser in xml.parsers.expat has a Parse method and a ParseFile method. The Parse method parses a string, however the ParseFile method wants bytes.

This is a minimal example of the Parse method:

>>> import xml.parsers.expat
>>> p = xml.parsers.expat.ParserCreate()
>>> p.Parse('<?xml version="1.0"?>')

which runs fine. Note that argument to p.Parse is a string, not bytes.

This is the corresponding example of ParseFile:

>>> import xml.parsers.expat
>>> handle = open("test.xml")
>>> p = xml.parsers.expat.ParserCreate()
>>> p.ParseFile(handle)

where the file test.xml only contains <?xml version="1.0"?>
This gives an error:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: read() did not return a bytes object (type=str)

Opening the file test.xml in binary raises an Error:

>>> import xml.parsers.expat
>>> handle = open("test.xml", "rb")
>>> p = xml.parsers.expat.ParserCreate()
>>> p.ParseFile(handle)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
xml.parsers.expat.ExpatError: no element found: line 2, column 0

suggesting that in reality, the expat Parser needs a string, not bytes.
(the same error appears with a more meaningful XML file).

I would expect that both Parse and ParseFile accept strings, but not bytes.

----------
messages: 177733
nosy: mdehoon
priority: normal
severity: normal
status: open
title: expat ParseFile expects bytes, not string
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Dec 19 12:30:49 2012
From: report at bugs.python.org (Keith Sabine)
Date: Wed, 19 Dec 2012 11:30:49 +0000
Subject: [New-bugs-announce] [issue16727] Windows installers for 2.7.3 don't
	install python27.dll	correctly
Message-ID: <1355916649.59.0.0223605375699.issue16727@psf.upfronthosting.co.za>


New submission from Keith Sabine:

The windows installers for Python 2.7.3 do not install the required python27.dll correctly.

The Windows x86 MSI Installer (2.7.3) does not install a 32 bit python27.dll in windows\system32 at all.

The Windows x86-64 MSI Installer (2.7.3) installs a 64 bit python27.dll in windows\system32, NOT in windows\SysWOW64 as it should.

The python27.dll should be kept in the python DLLs directory for both 32 and 64 bit versions, so users can clean up the mess if they need to...

----------
components: Windows
messages: 177736
nosy: keith969
priority: normal
severity: normal
status: open
title: Windows installers for 2.7.3 don't install python27.dll correctly
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec 19 13:14:49 2012
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 19 Dec 2012 12:14:49 +0000
Subject: [New-bugs-announce] [issue16728] collections.abc.Sequence shoud
	provide __subclasshook__
Message-ID: <1355919289.81.0.186820029813.issue16728@psf.upfronthosting.co.za>


New submission from INADA Naoki:

http://docs.python.org/3.3/glossary.html#term-sequence

__getitem__ and __len__ are required for sequence type.
(__iter__ is not required because types having __getitem__ are already iterator.)

.__contains__(), .index() and .count() is not required for sequence.

For example, following class should be sequence.

class Foo:
    def __getitem__(self, index):
        if not isinstance(index, int):
            raise TypeError
        if index >= 3:
            raise IndexError
        return index

    def __len__(self):
        return 3

----------
components: Library (Lib)
messages: 177737
nosy: naoki
priority: normal
severity: normal
status: open
title: collections.abc.Sequence shoud provide __subclasshook__
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Dec 19 14:44:01 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 19 Dec 2012 13:44:01 +0000
Subject: [New-bugs-announce] [issue16729] Document how to provide defaults
	for setup.py commands	options
Message-ID: <1355924641.52.0.160418711028.issue16729@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

The way to override defaults for setup.py commands is not documented. For example, to change to name of build and dist dirs from setup.py, the following entry should be added to setup parameters:

    options={
        'build': {'build_base': '__build__'},
        'sdist': {'dist_dir': '__build__/dist'},
    }

An example would be extremely helpful at
http://docs.python.org/2/install/index.html#how-building-works

tag:easy
http://thread.gmane.org/gmane.comp.python.distutils.devel/16434
issue16299

----------
assignee: eric.araujo
components: Distutils, Distutils2, Documentation
messages: 177742
nosy: alexis, eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: Document how to provide defaults for setup.py commands options
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Dec 19 15:55:01 2012
From: report at bugs.python.org (David Pritchard)
Date: Wed, 19 Dec 2012 14:55:01 +0000
Subject: [New-bugs-announce] [issue16730] _fill_cache in _bootstrap.py
	crashes without directory	execute permissions
Message-ID: <1355928901.47.0.243119596238.issue16730@psf.upfronthosting.co.za>


New submission from David Pritchard:

In importlib/_bootstrap.py, there is a function _fill_cache which crashes when you try to run Python in any environment that is so restricted that write permissions are not allowed. You get a trace like:

Traceback (most recent call last):
  In line:
    [the import statement]
  File "<frozen importlib._bootstrap>", line 1558, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1516, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1470, in _find_module
  File "<frozen importlib._bootstrap>", line 1305, in find_module
  File "<frozen importlib._bootstrap>", line 1284, in _get_loader
  File "<frozen importlib._bootstrap>", line 1356, in find_loader
  File "<frozen importlib._bootstrap>", line 1392, in _fill_cache
PermissionError: [Errno 13] Permission denied: '[the directory name]'

This was not an issue when I was using Python 3.2 and I suspect it has to do with the OS error refactoring. I believe it can be fixed with a two-line patch, attached. (Sorry if it is the wrong format, it's the first one I've submitted.) The patch simply treats the case of PermissionError the same was as it does when there is a FileNotFoundError. I've tested the patch and it fixes the problem.

----------
components: Interpreter Core
files: _bootstrap.py.patch
keywords: patch
messages: 177745
nosy: David.Pritchard
priority: normal
severity: normal
status: open
title: _fill_cache in _bootstrap.py crashes without directory execute permissions
versions: Python 3.3
Added file: http://bugs.python.org/file28359/_bootstrap.py.patch

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

From report at bugs.python.org  Wed Dec 19 20:50:46 2012
From: report at bugs.python.org (Daniel Shahaf)
Date: Wed, 19 Dec 2012 19:50:46 +0000
Subject: [New-bugs-announce] [issue16731] xxlimited/xxmodule docstrings
	ambiguous
Message-ID: <1355946646.69.0.259699636535.issue16731@psf.upfronthosting.co.za>


New submission from Daniel Shahaf:

Tweak the docstrings of xxmodule and xxlimited to clarify the difference between them (as derived from setup.py).  While at it also add a defensive coding guard to xxlimited to ensure it remains Py_LIMITED_API-safe.

----------
assignee: docs at python
components: Documentation, Extension Modules
files: xxdocstrings.diff
keywords: patch
messages: 177774
nosy: danielsh, docs at python
priority: normal
severity: normal
status: open
title: xxlimited/xxmodule docstrings ambiguous
versions: Python 3.4
Added file: http://bugs.python.org/file28367/xxdocstrings.diff

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

From report at bugs.python.org  Wed Dec 19 21:01:23 2012
From: report at bugs.python.org (Daniel Shahaf)
Date: Wed, 19 Dec 2012 20:01:23 +0000
Subject: [New-bugs-announce] [issue16732] setup.py support for xxmodule
	without tkinker
Message-ID: <1355947283.43.0.495525141996.issue16732@psf.upfronthosting.co.za>


New submission from Daniel Shahaf:

In setup.py, the logic or enabling xxmodule/xxlimited is currently in detect_tkinker(), so it's not run when one of the 'return' statements in the latter is executed.  On a box without tk installed, xxmodule.o gets built with the attached patch but not without.

----------
components: Build
files: setupxxmodule.diff
keywords: patch
messages: 177775
nosy: danielsh
priority: normal
severity: normal
status: open
title: setup.py support for xxmodule without tkinker
versions: Python 3.4
Added file: http://bugs.python.org/file28368/setupxxmodule.diff

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

From report at bugs.python.org  Thu Dec 20 00:24:47 2012
From: report at bugs.python.org (yippi)
Date: Wed, 19 Dec 2012 23:24:47 +0000
Subject: [New-bugs-announce] [issue16733] Solaris ctypes_test failures
Message-ID: <1355959487.2.0.457059136813.issue16733@psf.upfronthosting.co.za>


New submission from yippi:

Note I am building Python 3.3 with the Sun Studio compiler on Solaris 11.  When I run the tests, I get these 2 ctypes errors:

======================================================================
FAIL: test_ints (ctypes.test.test_bitfields.C_Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builds/bacamero/ul/components/python/python33/Python-3.3.0/Lib/ctypes/test/test_bitfields.py", line 40, in test_ints
    self.assertEqual(getattr(b, name), func(byref(b), name.encode('ascii')))
AssertionError: -1 != 1
======================================================================
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builds/bacamero/ul/components/python/python33/Python-3.3.0/Lib/ctypes/test/test_bitfields.py", line 47, in test_shorts
    self.assertEqual(getattr(b, name), func(byref(b), name.encode('ascii')))
AssertionError: -32 != 32
----------------------------------------------------------------------

I see almost identical errors in Python 2.6 and 2.7.  The same two tests fail, though the format of the error message is a bit different.  For example it looks like this in 2.7:
AssertionError: Tuples differ: ('A', 1, -1) != ('A', 1, 1)
AssertionError: Tuples differ: ('R', 32, -32) != ('R', 32, 32)

I made a simple standalone test program that prints out all the values
instead of stopping on first failure.  The script and output is attached
for reference. 

I think this might be related to issue #16275.  On Solaris 11 we are building Python with the configure --with -system-ffi argument.  On Solaris 11, libffi 3.0.9 is used.  I tried updating libffi to the latest 3.0.11 version and rebuilding, but that did not help.

Any pointers about how to debug this would be helpful.  It is not clear to me if this is a libffi issue, a compiler issue, a problem in Python or something else.  Is there any additional information I could provide to help track this down?

----------
components: Tests
files: ctypes.out
messages: 177792
nosy: yippi
priority: normal
severity: normal
status: open
title: Solaris ctypes_test failures
type: behavior
versions: Python 2.6, Python 2.7, Python 3.3
Added file: http://bugs.python.org/file28371/ctypes.out

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

From report at bugs.python.org  Thu Dec 20 06:55:26 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 20 Dec 2012 05:55:26 +0000
Subject: [New-bugs-announce] [issue16734] Delay interpreter startup phase
	until script is read
Message-ID: <1355982926.73.0.55538190201.issue16734@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Currently, when interpreter is launched it returns immediately to parent process without waiting to read the entrypoint script. This causes problem when you need to remove this script after executing.

Is it possible to delay return to child process until the entrypoint script is read?

See test case in attach.

----------
components: Interpreter Core
files: sub_race_removal.py
messages: 177800
nosy: techtonik
priority: normal
severity: normal
status: open
title: Delay interpreter startup phase until script is read
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file28375/sub_race_removal.py

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

From report at bugs.python.org  Thu Dec 20 09:30:11 2012
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Thu, 20 Dec 2012 08:30:11 +0000
Subject: [New-bugs-announce] [issue16735] zipfile.is_zipfile wrongly
	recognizes non-zip as zip
Message-ID: <1355992211.63.0.283559299274.issue16735@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

When I use zipfile.is_zipfile on file fastjar (sample uploaded at [1]) from libgcj, I get True, while I should get False (reproducible with fastjar from libgcj 4.7.2 on Fedora 18).
This is caused by stringEndArchive string being present in the file, but the file still isn't zip. Would it be possible to add some further checks to eliminate this kind of errors? I'd like to submit a patch but I'm not sure what to check for, maybe some other constants mentioned in the ZIP format definition?

Thanks a lot.

[1] http://bkabrda.fedorapeople.org/fastjar

----------
components: Library (Lib)
messages: 177804
nosy: bkabrda
priority: normal
severity: normal
status: open
title: zipfile.is_zipfile wrongly recognizes non-zip as zip
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Dec 20 13:12:44 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 20 Dec 2012 12:12:44 +0000
Subject: [New-bugs-announce] [issue16736] select.poll() converts long to int
	without checking for	overflow
Message-ID: <1356005564.78.0.448488855242.issue16736@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

Relevant code:

    int timeout = 0, poll_result, i, j;
    ...
        tout = PyNumber_Long(tout);
        if (!tout)
            return NULL;
        timeout = PyLong_AsLong(tout);  <-- implicit cast to int

----------
messages: 177811
nosy: sbt
priority: normal
severity: normal
status: open
title: select.poll() converts long to int without checking for overflow
type: behavior

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

From report at bugs.python.org  Thu Dec 20 14:37:02 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 20 Dec 2012 13:37:02 +0000
Subject: [New-bugs-announce] [issue16737] Different behaviours in script run
	directly and via	runpy.run_module
Message-ID: <1356010622.32.0.479096681415.issue16737@psf.upfronthosting.co.za>


New submission from Vinay Sajip:

If a script is run directly, the value of __file__ in it is relative to the current directory. If run via runpy.run_module, the value of __file__ is an absolute path. This is a problem in certain scenarios - e.g. if the script is a distribution's setup.py, a lot of distributions (rightly or wrongly) assume that the __file__ in setup.py will be relative, and mess up if it's absolute.

Example:
# script.py
print(__file__, __name__)

#runscript.py
import runpy
runpy.run_module('script', run_name='__main__')

Example output (2.7):
$ python script.py
('script.py', '__main__')
$ python runscript.py
('/home/vinay/projects/scratch/script.py', '__main__')

Example output (3.2):
$ python3.2 script.py
script.py __main__
$ python3.2 runscript.py
/home/vinay/projects/scratch/script.py __main__

----------
components: Library (Lib)
messages: 177814
nosy: ncoghlan, vinay.sajip
priority: normal
severity: normal
status: open
title: Different behaviours in script run directly and via runpy.run_module
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Dec 20 14:49:38 2012
From: report at bugs.python.org (Ivan Bykov)
Date: Thu, 20 Dec 2012 13:49:38 +0000
Subject: [New-bugs-announce] [issue16738] Comparisons difference: bytes with
	bytes, str with str
Message-ID: <1356011378.26.0.0858380724322.issue16738@psf.upfronthosting.co.za>


New submission from Ivan Bykov:

Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> b = b't'
>>> b[0] in [b]
False
>>> u = 't'
>>> u[0] in [u]
True

----------
messages: 177817
nosy: ivb
priority: normal
severity: normal
status: open
title: Comparisons difference: bytes with bytes, str with str
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Dec 20 17:16:21 2012
From: report at bugs.python.org (Leo Arias)
Date: Thu, 20 Dec 2012 16:16:21 +0000
Subject: [New-bugs-announce] [issue16739] texttestresult should decorate the
	stream with	_WritelnDecorator
Message-ID: <1356020181.84.0.076442170736.issue16739@psf.upfronthosting.co.za>


New submission from Leo Arias:

Using the unittest's texttestresult with stdout and verbosity 2 will fail because that stream doesn't have a writeln method.

  File "/usr/lib/python2.7/unittest/suite.py", line 108, in run
    test(result)
  File "/usr/lib/python2.7/unittest/suite.py", line 70, in __call__
    return self.run(*args, **kwds)
  File "/usr/lib/python2.7/unittest/suite.py", line 108, in run
    test(result)
  File "/usr/lib/python2.7/unittest/suite.py", line 70, in __call__
    return self.run(*args, **kwds)
  File "/usr/lib/python2.7/unittest/suite.py", line 108, in run
    test(result)
  File "/usr/lib/python2.7/dist-packages/unittest2/case.py", line 398, in __call__
    return self.run(*args, **kwds)
  File "/usr/lib/python2.7/dist-packages/unittest2/case.py", line 375, in run
    result.addSuccess(self)
  File "/home/elopio/canonical/ubuntuone/photos-acceptance-2/lib/testtools/testresult/real.py", line 253, in addSuccess
    return self._dispatch('addSuccess', test, details=details)
  File "/home/elopio/canonical/ubuntuone/photos-acceptance-2/lib/testtools/testresult/real.py", line 231, in _dispatch
    for result in self._results)
  File "/home/elopio/canonical/ubuntuone/photos-acceptance-2/lib/testtools/testresult/real.py", line 231, in <genexpr>
    for result in self._results)
  File "/home/elopio/canonical/ubuntuone/photos-acceptance-2/lib/testtools/testresult/real.py", line 555, in addSuccess
    return self.decorated.addSuccess(test)
  File "/usr/lib/python2.7/unittest/runner.py", line 60, in addSuccess
    self.stream.writeln("ok")
AttributeError: 'file' object has no attribute 'writeln'

It would be nice if the stream is decorated with _WritelnDecorator, as it is done on TextTestRunner.

----------
components: Library (Lib)
messages: 177833
nosy: elopio
priority: normal
severity: normal
status: open
title: texttestresult should decorate the stream with _WritelnDecorator
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Dec 21 00:23:29 2012
From: report at bugs.python.org (Bradley Froehle)
Date: Thu, 20 Dec 2012 23:23:29 +0000
Subject: [New-bugs-announce] [issue16740] Types created with PyType_FromSpec
	lack a __module__	attribute.
Message-ID: <1356045809.14.0.050460489719.issue16740@psf.upfronthosting.co.za>


New submission from Bradley Froehle:

Types created using PyType_FromSpec do not have a __module__ attribute by default.  This caught me off guard.

$ python3
Python 3.2.3 (default, Oct 19 2012, 20:10:41) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xxlimited
>>> xxlimited.Null.__module__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: __module__

Do we expect module authors to set the __module__ attribute immediately after calling PyType_FromSpec?

To refresh your memory, non-heap types determine the module/name combo according to something like::

    try:
        __module__, __name__ = tp_name.rsplit('.', 1)
    except ValueError:
        __module__, __name__ = 'builtins', tp_name 

whereas heap types use something like::

    __name__ = tp_name
    @property
    def __module__(self):
        return self.__dict__['__module__']

I think this is unnecessarily confusing, and, as far as I know, not documented anywhere.

I see from reading the commit logs that it was felt that by allowing users to set __name__ (and therefore tp_name), it could have an unintended impact on the value __module__.  If so, why didn't we just disallow setting __name__?

There are likely some unintended impacts of this decision, for example weird error message in other library functions:

>>> import inspect
>>> inspect.getfile(xxlimited.Null)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/inspect.py", line 415, in getfile
    object = sys.modules.get(object.__module__)
AttributeError: __module__

Is there anything we can do here?

----------
components: Interpreter Core
messages: 177860
nosy: bfroehle
priority: normal
severity: normal
status: open
title: Types created with PyType_FromSpec lack a __module__ attribute.
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec 21 00:37:21 2012
From: report at bugs.python.org (ganges master)
Date: Thu, 20 Dec 2012 23:37:21 +0000
Subject: [New-bugs-announce] [issue16741] `int()`, `float()`,
	etc think python strings are null-terminated
Message-ID: <1356046641.74.0.314140910069.issue16741@psf.upfronthosting.co.za>


New submission from ganges master:

I'm not sure if it's a bug or just an inconvenience, but when a string containing \x00 is passed to int/float/etc, they return a misleading exception:

    >>> int("abc")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: invalid literal for int() with base 10: 'abc'
    >>> int("\x00abc")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: invalid literal for int() with base 10: ''
    >>> float("\x00abc")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: could not convert string to float:

I noticed the code does actually try to handle it:
http://hg.python.org/cpython/file/39803c20c9bf/Objects/intobject.c#l1066

but still, the reported error is very misleading.

----------
components: Interpreter Core
messages: 177863
nosy: gangesmaster
priority: normal
severity: normal
status: open
title: `int()`, `float()`, etc think python strings are null-terminated
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Dec 21 11:39:50 2012
From: report at bugs.python.org (Trent Nelson)
Date: Fri, 21 Dec 2012 10:39:50 +0000
Subject: [New-bugs-announce] [issue16742] PyOS_Readline drops GIL and calls
	PyOS_StdioReadline, which isn't thread safe
Message-ID: <1356086390.48.0.327620937355.issue16742@psf.upfronthosting.co.za>


New submission from Trent Nelson:

Relevant thread: http://mail.python.org/pipermail/python-dev/2012-December/123225.html

PyOS_StdioReadline features numerous calls that require the GIL to be held.  Ideally, the GIL drop-take should be moved closer to the actual underlying read system call.

----------
assignee: trent
components: Interpreter Core
messages: 177874
nosy: trent
priority: normal
severity: normal
stage: needs patch
status: open
title: PyOS_Readline drops GIL and calls PyOS_StdioReadline, which isn't thread safe
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec 21 15:43:31 2012
From: report at bugs.python.org (Marc Schlaich)
Date: Fri, 21 Dec 2012 14:43:31 +0000
Subject: [New-bugs-announce] [issue16743] mmap accepts files > 1 GB,
	but processes only 1 GB
Message-ID: <1356101011.63.0.640174538358.issue16743@psf.upfronthosting.co.za>


New submission from Marc Schlaich:

Platform: Windows 7 64 bit
Interpreter: Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit Intel)] on win32

Here are the steps to reproduce:

1. Create a big file (5 GB):

with open('big', 'wb') as fobj:
    for _ in xrange(1024 * 1024 * 5):
        fobj.write('1' + '0' * 1023)

2. Open and process it with `mmap`:

import mmap
import re
import sys

with open('big', 'rb') as fobj:
    data = mmap.mmap(fobj.fileno(), 0, access=mmap.ACCESS_READ)
    print data.size()
    try:
        counter = 0
        for match in re.finditer('1' + '0' * 1023, data):
            counter += 1
        print len(data[1073740800:1073741824]) # (1 GB - 1024, 1 GB)
        print len(data[1073741824:1073742848]) # (1 GB, 1 GB + 1024)
    finally:
        data.close()

    print counter

This returns the following lines:

    5368709120
    1024
    0
    1048576

So this is a behavioral issue. `mmap` accepts a file which cannot fit in the interpreter memory but fits in the system memory. On processing the data, it only reads data until the maximum interpreter memory is reached (1 GB).

----------
components: None
messages: 177879
nosy: schlamar
priority: normal
severity: normal
status: open
title: mmap accepts files > 1 GB, but processes only 1 GB
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Dec 21 18:04:11 2012
From: report at bugs.python.org (rappy)
Date: Fri, 21 Dec 2012 17:04:11 +0000
Subject: [New-bugs-announce] [issue16744] sys.path.append causes wrong
	behaviour
Message-ID: <1356109451.75.0.486337776247.issue16744@psf.upfronthosting.co.za>


New submission from rappy:

In bug.py print gives

['C:\\Users\\Glenn\\Desktop', 'C:\\Windows\\system32\\python27.zip', C:\\Python27\\DLLs', 'C:\\Python27\\lib', 'C:\\Python27\\lib\\plat-win', 'C:\\Python27\\lib\\lib-tk', 'C:\\Python27', 'C:\\Python27\\lib\\site-packages', 'C:\\Users\\Glenn\\Documents\\ua\\mosis\x07ssignment6']

What it should give is

['C:\\Users\\Glenn\\Desktop', 'C:\\Windows\\system32\\python27.zip', C:\\Python27\\DLLs', 'C:\\Python27\\lib', 'C:\\Python27\\lib\\plat-win', 'C:\\Python27\\lib\\lib-tk', 'C:\\Python27', 'C:\\Python27\\lib\\site-packages', 'C:\\Users\\Glenn\\Documents\\ua\\mosis\assignment6']

----------
components: Library (Lib)
files: bug.py
messages: 177881
nosy: rappy
priority: normal
severity: normal
status: open
title: sys.path.append causes wrong behaviour
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file28384/bug.py

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

From report at bugs.python.org  Fri Dec 21 18:15:33 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 21 Dec 2012 17:15:33 +0000
Subject: [New-bugs-announce] [issue16745] Hide symbols in _decimal.so
Message-ID: <1356110133.55.0.310128337459.issue16745@psf.upfronthosting.co.za>


New submission from Stefan Krah:

This issue is for the _decimal specific parts from #4555. The patch
depends on _Pragma (C99) and gcc >= 4.0 for the contents of the pragma.
I think it will work for clang, too.

Should the libmpdec API symbols (i.e. the ones starting with mpd_*)
be hidden for _decimal.c, too?

----------
assignee: skrah
components: Extension Modules
files: libmpdec-hide-non-api-symbols.diff
keywords: patch
messages: 177883
nosy: skrah
priority: normal
severity: normal
status: open
title: Hide symbols in _decimal.so
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28385/libmpdec-hide-non-api-symbols.diff

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

From report at bugs.python.org  Fri Dec 21 22:27:03 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 21 Dec 2012 21:27:03 +0000
Subject: [New-bugs-announce] [issue16746] clarify what should be sent to
	peps@
Message-ID: <1356125223.11.0.663199729281.issue16746@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Currently, PEP 1 can be read to mean that <peps at python.org> should be CC'ed on all e-mails related to PEPs.  However, this isn't the intent because, for example, it is okay to have discussions about PEPs on python-dev or python-ideas without involving <peps at python.org>.

I'm attaching a patch to clarify this language.

[This issue is from: http://mail.python.org/pipermail/python-dev/2012-December/123251.html ]

----------
keywords: easy
messages: 177897
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: clarify what should be sent to peps@

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

From report at bugs.python.org  Sat Dec 22 01:06:53 2012
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 22 Dec 2012 00:06:53 +0000
Subject: [New-bugs-announce] [issue16747] Remove 'file' type reference from
	'iterable' glossary	entry
Message-ID: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's a patch that changes the reference to :class:`file` in the iterable entry in Doc/glossary.rst to :term:`file objects <file object>`, along with minor grammatical fixes to make it fit, and reflowing of the text.

----------
assignee: docs at python
components: Documentation
files: iterable_glossary.diff
keywords: patch
messages: 177911
nosy: docs at python, zach.ware
priority: normal
severity: normal
status: open
title: Remove 'file' type reference from 'iterable' glossary entry
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28392/iterable_glossary.diff

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

From report at bugs.python.org  Sat Dec 22 02:02:27 2012
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 22 Dec 2012 01:02:27 +0000
Subject: [New-bugs-announce] [issue16748] Ensure test discovery doesn't
	break for modules testing	C and Python implementations
Message-ID: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za>


New submission from Zachary Ware:

As pointed out by ?ric Araujo in msg177908 of issue16694, tests using the idiom presented in PEP 399 are subject to breakage of test discovery.  This issue's goal is to root out and fix all usages of this idiom.

So far, only test_heapq is known to be affected.

As for fixing the issue, each module get its own mixin class, or should a simple class such as:

class TestPyAndCMixin:
    module = None

be added to test.support?

----------
components: Tests
messages: 177913
nosy: eric.araujo, zach.ware
priority: normal
severity: normal
status: open
title: Ensure test discovery doesn't break for modules testing C and Python implementations
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Dec 22 03:04:16 2012
From: report at bugs.python.org (Leonardo DaVinci)
Date: Sat, 22 Dec 2012 02:04:16 +0000
Subject: [New-bugs-announce] [issue16749] Fatal Python Error
In-Reply-To: <CAP6pXG_qzo=q+QcCx-BeqMeWibR6Uu6Xwhd8F_9wrcbn3bagQQ@mail.gmail.com>
Message-ID: <CAP6pXG-8d8iJBWTezgMXx_KuHzJkyWjZQ16PBEL8v+h=v5G7HA@mail.gmail.com>


New submission from Leonardo DaVinci:

I'm running the Solidoodle 2 printer with Python 2.7.3 (as recommended by
Solidoodle). I keep getting the "Fatal Python Error" message. I've tried
several Python versions, many installs without success.

I'm running Windows 7 x64 Ultimate sp1 on a MacBook pro with an i7, 8gigs
of Ram. I've installed all the softwares in x86 (32 bit) mode.

I'd like to know where the problem originates from.

Regards
Ciro

----------
files: Python Error.JPG
messages: 177917
nosy: DaVinci
priority: normal
severity: normal
status: open
title: Fatal Python Error
Added file: http://bugs.python.org/file28393/Python Error.JPG

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16749>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Python Error.JPG
Type: image/jpeg
Size: 111746 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20121222/295b0f09/attachment-0001.jpe>

From report at bugs.python.org  Sat Dec 22 07:17:34 2012
From: report at bugs.python.org (pleed)
Date: Sat, 22 Dec 2012 06:17:34 +0000
Subject: [New-bugs-announce] [issue16750] Python Code module implements
	uncomputable function
Message-ID: <1356157054.86.0.248139493582.issue16750@psf.upfronthosting.co.za>


New submission from pleed:

The "code" class implements the __eq__ operator which is known to be uncomputable.

----------
messages: 177923
nosy: pleed
priority: normal
severity: normal
status: open
title: Python Code module implements uncomputable function
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Dec 22 09:34:03 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Dec 2012 08:34:03 +0000
Subject: [New-bugs-announce] [issue16751] Using modern unittest asserts in
	the documentation
Message-ID: <1356165243.99.0.0485025285676.issue16751@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch update the documentation examples to use more modern unittest asserts.

----------
assignee: docs at python
components: Documentation, Tests
files: docs_unittest_assert.patch
keywords: easy, patch
messages: 177924
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Using modern unittest asserts in the documentation
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28394/docs_unittest_assert.patch

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

From report at bugs.python.org  Sat Dec 22 20:45:48 2012
From: report at bugs.python.org (Thomas Heller)
Date: Sat, 22 Dec 2012 19:45:48 +0000
Subject: [New-bugs-announce] [issue16752] Missing import in modulefinder.py
Message-ID: <1356205548.55.0.954996181109.issue16752@psf.upfronthosting.co.za>


New submission from Thomas Heller:

It seems the statement
    import importlib
is missing in 3.3's modulefinder.py

----------
components: Library (Lib)
messages: 177951
nosy: theller
priority: normal
severity: normal
status: open
title: Missing import in modulefinder.py
versions: Python 3.3

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

From report at bugs.python.org  Sun Dec 23 11:35:15 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 23 Dec 2012 10:35:15 +0000
Subject: [New-bugs-announce] [issue16753] #include <ctype.h> broken on
	FreeBSD 9.1-RELEASE
Message-ID: <1356258915.36.0.46771608396.issue16753@psf.upfronthosting.co.za>


New submission from Stefan Krah:

This is strictly a buildbot issue. #include <ctype.h> seems broken on

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.3/builds/248/steps/compile/logs/stdio



In file included from /usr/include/ctype.h:83,
                 from /usr/home/buildbot/python/3.3.koobs-freebsd/build/Modules/_decimal/libmpdec/io.c:33:
/usr/include/xlocale/_ctype.h:56:38: error: operator '!' has no right operand


Also note that the buildbot software reports success (i.e. the compile step is green) despite the error.

----------
keywords: buildbot
messages: 177971
nosy: koobs, skrah
priority: normal
severity: normal
status: open
title: #include <ctype.h> broken on FreeBSD 9.1-RELEASE
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Dec 23 13:36:06 2012
From: report at bugs.python.org (Sandro Mani)
Date: Sun, 23 Dec 2012 12:36:06 +0000
Subject: [New-bugs-announce] [issue16754] Incorrect shared library extension
	on linux
Message-ID: <1356266166.76.0.178044154393.issue16754@psf.upfronthosting.co.za>


New submission from Sandro Mani:

I'm using Python3 as available in Fedora rawhide 
(python3-3.3.0-2.fc19.x86_64).

Attempting to build a project using python3/distutils, I noticed that 
find_library_file would not find any library at all. Some investigation 
showed that this was due to the fact that libraries were searched with 
the ".cpython-33m.so" extension. Even more investigation showed that the 
library extension was read being overridden by the one defined in the 
/usr/lib64/python3.3/config-3.3m/Makefile shipped by python3-libs. See 
below for the detailed analysis. The python-versioned extension 
obviously makes no sense for regular shared objects which are not python 
binary modules, so this is clearly wrong. As a workaround I patched 
sysconfig.py to comment out customize_compiler::235 (compiler.shared_lib_extension = 
so_ext, see below), recompiled python (all tests still pass), and things seem to work.


Detailed analysis:

setup.py:
def _find_library_file(self, library):
     return self.compiler.find_library_file(self.compiler.library_dirs, 
library)

---
In function 
/usr/lib64/python3.3/distutils/unixcompiler.py at find_library_file::266:
shared_f = self.library_filename(lib, lib_type='shared')

In function 
/usr/lib64/python3.3/distutils/ccompiler.py at library_filename::882:
ext = getattr(self, lib_type + "_lib_extension")

-> Where does shared_lib_extension get defined?
* At /usr/lib64/python3.3/distutils/ccompiler.py::66
shared_lib_extension = None   -> default for abstract class
* At /usr/lib64/python3.3/distutils/unixcompiler.py::77
shared_lib_extension = ".so"  -> this is the correct value
* In function 
/usr/lib64/python3.3/distutils/sysconfig.py at customize_compiler::235
by /usr/lib64/python3.3/distutils/sysconfig.py at customize_compiler::235
         compiler.shared_lib_extension = so_ext
by /usr/lib64/python3.3/distutils/sysconfig.py at customize_compiler::194
(cc, cxx, opt, cflags, ccshared, ldshared, so_ext, ar, ar_flags) = \
             get_config_vars('CC', 'CXX', 'OPT', 'CFLAGS',
                             'CCSHARED', 'LDSHARED', 'SO', 'AR', 'ARFLAGS'))
by /usr/lib64/python3.3/distutils/sysconfig.py at get_config_vars::530
526 global _config_vars
527     if _config_vars is None:
528         func = globals().get("_init_" + os.name)  # -> os.name = posix
529         if func:
530             func()  # -> _init_posix, populates _config_vars
by /usr/lib64/python3.3/distutils/sysconfig.py at _init_posix::439
435     g = {}
436     # load the installed Makefile:
437     try:
438         filename = get_makefile_filename()  # 
/usr/lib64/python3.3/config-3.3m/Makefile
439         parse_makefile(filename, g)
...
476     global _config_vars
477     _config_vars = g  # -> _config_vars["SO"] = ".cpython-33m.so"
by /usr/lib64/python3.3/config-3.3m/Makefile::122
SO=             .cpython-33m.so

----------
assignee: eric.araujo
components: Distutils
messages: 177979
nosy: eric.araujo, smani, tarek
priority: normal
severity: normal
status: open
title: Incorrect shared library extension on linux
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Dec 23 16:04:42 2012
From: report at bugs.python.org (Volodymyr Hotsyk)
Date: Sun, 23 Dec 2012 15:04:42 +0000
Subject: [New-bugs-announce] [issue16755] Distutils2 incorrectly works with
	unicode package names
Message-ID: <1356275082.9.0.0209714500898.issue16755@psf.upfronthosting.co.za>


New submission from Volodymyr Hotsyk:

While testing #13178, found that Distutils2 incorrectly works with the package names containing unicode symbols. Please check test attached.

----------
assignee: eric.araujo
components: Distutils2
files: unicode_test.diff
keywords: patch
messages: 177991
nosy: alexis, asvetlov, eric.araujo, hotsyk, tarek
priority: normal
severity: normal
status: open
title: Distutils2 incorrectly works with unicode package names
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file28406/unicode_test.diff

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

From report at bugs.python.org  Sun Dec 23 17:33:03 2012
From: report at bugs.python.org (jp)
Date: Sun, 23 Dec 2012 16:33:03 +0000
Subject: [New-bugs-announce] [issue16756] buggy assignment to items of a
	list created by a *	operator
Message-ID: <1356280383.46.0.680609909291.issue16756@psf.upfronthosting.co.za>


New submission from jp:

The following code: 

li = [[1,0]]*5
a = [[1,10], [2,20], [3,30]]
for line in a:
    li[line[0]][0] = 2
print(li)

prints [[2,0],[2,0],[2,0],[2,0],[2,0]], but should print [[1,0],[2,0],[2,0],[2,0],[1,0]]. 

The output is correct if you, instead of using li = [[1,0]]*5, initialize the array as follows:

li = []
for i in range(5): li.append([1,0])

----------
components: Interpreter Core
messages: 177995
nosy: jenda.petrov at gmail.com
priority: normal
severity: normal
status: open
title: buggy assignment to items of a list created by a * operator
versions: Python 3.3

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

From report at bugs.python.org  Sun Dec 23 17:50:35 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Dec 2012 16:50:35 +0000
Subject: [New-bugs-announce] [issue16757] Faster _PyUnicode_FindMaxChar()
Message-ID: <1356281435.93.0.623434455043.issue16757@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch optimizes _PyUnicode_FindMaxChar(). This affects string formatting of long patterns (speedup to 15-25% for classic formatting and 5-8% for new style formatting).

----------
components: Interpreter Core, Unicode
files: unicode_findmaxchar.patch
keywords: patch
messages: 177997
nosy: ezio.melotti, haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Faster _PyUnicode_FindMaxChar()
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file28407/unicode_findmaxchar.patch

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

From report at bugs.python.org  Sun Dec 23 18:58:50 2012
From: report at bugs.python.org (Lieutenant Commander Mohd Nazri Mohd Nasir RMN)
Date: Sun, 23 Dec 2012 17:58:50 +0000
Subject: [New-bugs-announce] [issue16758] SubprocessStartupError
Message-ID: <1356285530.15.0.755787775309.issue16758@psf.upfronthosting.co.za>


New submission from Lieutenant Commander Mohd Nazri Mohd Nasir RMN:

I always get this message lately, when I try to run python in IDLE.

----------
components: IDLE
files: SubprocessStartupErrorMessage.jpg
messages: 178000
nosy: Lieutenant.Commander.Mohd.Nazri.Mohd.Nasir.RMN
priority: normal
severity: normal
status: open
title: SubprocessStartupError
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file28409/SubprocessStartupErrorMessage.jpg

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

From report at bugs.python.org  Mon Dec 24 01:16:51 2012
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 24 Dec 2012 00:16:51 +0000
Subject: [New-bugs-announce] [issue16759] winreg.QueryValueEx returns signed
	32bit value instead	of unsigned
Message-ID: <1356308211.5.0.474246954205.issue16759@psf.upfronthosting.co.za>


New submission from Brian Curtin:

Making this its own issue from msg156935 on #14420:

"Likewise, the winreg.QueryValueEx method returns a signed 32 bit value, instead of a 32 bit unsigned value."

----------
assignee: brian.curtin
components: Extension Modules, Windows
messages: 178023
nosy: RoSanford, brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: winreg.QueryValueEx returns signed 32bit value instead of unsigned
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Dec 24 09:35:55 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 24 Dec 2012 08:35:55 +0000
Subject: [New-bugs-announce] [issue16760] Get rid of MatchObject in regex
	HOWTO
Message-ID: <1356338155.64.0.700591517206.issue16760@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

MatchObject is not defined anywhere and is not used except HOWTO (see issue6538).

----------
assignee: docs at python
components: Documentation, Regular Expressions
messages: 178036
nosy: asvetlov, docs at python, ezio.melotti, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Get rid of MatchObject in regex HOWTO
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec 24 11:16:19 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 24 Dec 2012 10:16:19 +0000
Subject: [New-bugs-announce] [issue16761] Fix int(base=X)
Message-ID: <1356344179.57.0.256003858099.issue16761@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently int() ignores base keyword argument if first string argument omitted. Such usage is no other than bug. The proposed patch raises TypeError in such case.

See also discussion at Python-Dev: http://comments.gmane.org/gmane.comp.python.cvs/92290 .

----------
components: Interpreter Core
files: int_without_x.patch
keywords: patch
messages: 178043
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix int(base=X)
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28414/int_without_x.patch

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

From report at bugs.python.org  Mon Dec 24 11:23:55 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 24 Dec 2012 10:23:55 +0000
Subject: [New-bugs-announce] [issue16762] test_subprocess failure on
	OpenBSD/NetBSD buildbots
Message-ID: <1356344635.01.0.0408386674119.issue16762@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

test_subprocess fails on OpenBSD/NetBSD buildbots:
http://buildbot.python.org/all/builders/AMD64 NetBSD 5.1.2 [SB] 2.7/builds/158/steps/test/logs/stdio
"""

======================================================================
ERROR: test_kill_dead (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/2.7.snakebite-netbsd51-amd64-1/build/Lib/test/test_subprocess.py", line 940, in test_kill_dead
    self._kill_dead_process('kill')
  File "/home/cpython/buildslave/2.7.snakebite-netbsd51-amd64-1/build/Lib/test/test_subprocess.py", line 913, in _kill_dead_process
    getattr(p, method)(*args)
  File "/home/cpython/buildslave/2.7.snakebite-netbsd51-amd64-1/build/Lib/subprocess.py", line 1506, in kill
    self.send_signal(signal.SIGKILL)
  File "/home/cpython/buildslave/2.7.snakebite-netbsd51-amd64-1/build/Lib/subprocess.py", line 1496, in send_signal
    os.kill(self.pid, sig)
OSError: [Errno 3] No such process

======================================================================
ERROR: test_send_signal_dead (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/2.7.snakebite-netbsd51-amd64-1/build/Lib/test/test_subprocess.py", line 936, in test_send_signal_dead
    self._kill_dead_process('send_signal', signal.SIGINT)
  File "/home/cpython/buildslave/2.7.snakebite-netbsd51-amd64-1/build/Lib/test/test_subprocess.py", line 913, in _kill_dead_process
    getattr(p, method)(*args)
  File "/home/cpython/buildslave/2.7.snakebite-netbsd51-amd64-1/build/Lib/subprocess.py", line 1496, in send_signal
    os.kill(self.pid, sig)
OSError: [Errno 3] No such process

======================================================================
ERROR: test_terminate_dead (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/2.7.snakebite-netbsd51-amd64-1/build/Lib/test/test_subprocess.py", line 944, in test_terminate_dead
    self._kill_dead_process('terminate')
  File "/home/cpython/buildslave/2.7.snakebite-netbsd51-amd64-1/build/Lib/test/test_subprocess.py", line 913, in _kill_dead_process
    getattr(p, method)(*args)
  File "/home/cpython/buildslave/2.7.snakebite-netbsd51-amd64-1/build/Lib/subprocess.py", line 1501, in terminate
    self.send_signal(signal.SIGTERM)
  File "/home/cpython/buildslave/2.7.snakebite-netbsd51-amd64-1/build/Lib/subprocess.py", line 1496, in send_signal
    os.kill(self.pid, sig)
OSError: [Errno 3] No such process
"""

According to POSIX, kill shoudln't fail with ESRCH on a zombie processes:
"""
Existing implementations vary on the result of a kill() with pid indicating an inactive process (a terminated process that has not been waited for by its parent). Some indicate success on such a call (subject to permission checking), while others give an error of [ESRCH]. Since the definition of process lifetime in this volume of POSIX.1-2008 covers inactive processes, the [ESRCH] error as described is inappropriate in this case. In particular, this means that an application cannot have a parent process check for termination of a particular child with kill(). (Usually this is done with the null signal; this can be done reliably with waitpid().)
"""

----------
components: Tests
keywords: buildbot, needs review, patch
messages: 178045
nosy: neologix
priority: low
severity: normal
stage: patch review
status: open
title: test_subprocess failure on OpenBSD/NetBSD buildbots
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec 24 12:41:48 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 24 Dec 2012 11:41:48 +0000
Subject: [New-bugs-announce] [issue16763] test_ssl with connect_ex don't
	handle unreachable server	correctly
Message-ID: <1356349308.1.0.276929202525.issue16763@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

test_ssl tests calling connect_ex don't handle unreachable servers properly:
"""
test_ssl
Resource 'svn.python.org' is not available
Resource 'svn.python.org' is not available
test test_ssl failed -- Traceback (most recent call last):
  File "/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Lib/test/test_ssl.py", line 246, in test_connect_ex
    self.assertEqual(0, s.connect_ex(("svn.python.org", 443)))
AssertionError: 0 != None
"""

support.transient doesn't help here since no exception is raised.
Note that I'm not sure that connect_ex returning None is normal in the first place...

There's a related failure on OpenBSD/NetBSD  buildbots:
"""
test_timeout_connect_ex (test.test_ssl.NetworkedTests) ... ok

======================================================================
ERROR: test_non_blocking_connect_ex (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/3.x.snakebite-openbsd51-amd64-1/build/Lib/test/test_ssl.py", line 685, in test_non_blocking_connect_ex
    select.select([], [s], [], 5.0)
OSError: [Errno 22] Invalid argument
"""

I guess that connect() can't succeed because of an unreachable host/connection refused, and the subsequent select() fails with EINVAL. This is most likely a kernel bug, select should report the socket as ready for write (one could then use getsockopt() to find the actual error).

----------
components: Tests
messages: 178051
nosy: neologix, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ssl with connect_ex don't handle unreachable server correctly
type: behavior

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

From report at bugs.python.org  Mon Dec 24 13:45:08 2012
From: report at bugs.python.org (Lukas Lueg)
Date: Mon, 24 Dec 2012 12:45:08 +0000
Subject: [New-bugs-announce] [issue16764] Make zlib accept keyword-arguments
Message-ID: <1356353108.66.0.0747083241018.issue16764@psf.upfronthosting.co.za>


New submission from Lukas Lueg:

The patch "zlib_keywords.patch" makes zlib's classes and functions accept keyword arguments as documented. It also fixes two cases in which the docstring differ from the documentation (decompress(data) vs. decompress(string) and compressobj(memlevel) vs. compressobj(memLevel)). Additional tests are provided.

----------
components: Library (Lib)
files: zlib_keywords.patch
keywords: patch
messages: 178053
nosy: ebfe
priority: normal
severity: normal
status: open
title: Make zlib accept keyword-arguments
versions: Python 3.4
Added file: http://bugs.python.org/file28418/zlib_keywords.patch

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

From report at bugs.python.org  Mon Dec 24 13:53:37 2012
From: report at bugs.python.org (Michiel Holtkamp)
Date: Mon, 24 Dec 2012 12:53:37 +0000
Subject: [New-bugs-announce] [issue16765] Superfluous import in cgi module
Message-ID: <1356353617.65.0.761345333654.issue16765@psf.upfronthosting.co.za>


New submission from Michiel Holtkamp:

The standard module cgi.py from Python 2.x imports urllib, but urllib is not used. This causes a little bit of extra memory usage and a small increase in load time. It's not much, but it was enough for me to notice when I was profiling my program.

I think the urllib import can be safely removed in 2.6 and 2.7. I've tested without the import and it works as expected in my case.

In Python 3.2 (other 3.x versions not checked), urllib.parse is imported but here it is actually used, so no problem there.

PS. first time submitting a bug here, so if I'm doing something wrong, please be gentle :)

----------
components: Library (Lib)
messages: 178055
nosy: mjholtkamp
priority: normal
severity: normal
status: open
title: Superfluous import in cgi module
type: performance
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Dec 24 15:39:58 2012
From: report at bugs.python.org (Al Korgun)
Date: Mon, 24 Dec 2012 14:39:58 +0000
Subject: [New-bugs-announce] [issue16766] small disadvantage of
	htmlentitydefs
Message-ID: <1356359998.55.0.0415174560622.issue16766@psf.upfronthosting.co.za>


New submission from Al Korgun:

>>> import htmlentitydefs
>>> htmlentitydefs.name2codepoint.get("quot")  # ok
34
>>> htmlentitydefs.name2codepoint.get("apos", "null")  # &apos; -> chr(39)
'null'

----------
components: Library (Lib)
messages: 178060
nosy: WitcherGeralt
priority: normal
severity: normal
status: open
title: small disadvantage of htmlentitydefs
versions: Python 2.7

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

From report at bugs.python.org  Mon Dec 24 15:53:51 2012
From: report at bugs.python.org (Joe Borg)
Date: Mon, 24 Dec 2012 14:53:51 +0000
Subject: [New-bugs-announce] [issue16767] Cannot install Python 2.7 in Wine
	1.4.1
Message-ID: <1356360831.52.0.153505228673.issue16767@psf.upfronthosting.co.za>


New submission from Joe Borg:

Trying to install Python 2.7 (in particular) under Wine 1.4.1, but keep getting the "Installer has ended prematurely" error.  I've also tried with 2.6 and 3.2 and different versions of wine; same error.  Also tried with winetricks; again, same error.

I've used the msiexec command to log the output of the installer and will attach.

Thanks.

----------
components: Windows
files: install.log
messages: 178061
nosy: Joe.Borg
priority: normal
severity: normal
status: open
title: Cannot install Python 2.7 in Wine 1.4.1
versions: Python 2.7
Added file: http://bugs.python.org/file28421/install.log

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

From report at bugs.python.org  Mon Dec 24 16:50:46 2012
From: report at bugs.python.org (Ziga)
Date: Mon, 24 Dec 2012 15:50:46 +0000
Subject: [New-bugs-announce] [issue16768] CTRL-Y, yank,
	behaves as CTRL-Z with curses on OS X
Message-ID: <1356364246.33.0.381686861789.issue16768@psf.upfronthosting.co.za>


New submission from Ziga:

`getch()` interprets CTRL-Y as CTRL-Z on OS X 10.7.3.
Tested with python 2.5, 2.6, 2.7 32-bit and 64-bit.

How to recreate behavior:
>>> import curses
>>> stdscr = curses.initscr()
# CTRL-Y works as expected until now.

>>> stdscr.getch()
# press <CTRL+Y>
$ [1]  + 407 suspended  python

----------
assignee: ronaldoussoren
components: Extension Modules, Library (Lib), Macintosh
messages: 178065
nosy: agiz, ronaldoussoren
priority: normal
severity: normal
status: open
title: CTRL-Y, yank, behaves as CTRL-Z with curses on OS X
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Dec 24 18:01:31 2012
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 24 Dec 2012 17:01:31 +0000
Subject: [New-bugs-announce] [issue16769] Remove some old Visual Studio
	versions from PC/ directory
Message-ID: <1356368491.28.0.606279812477.issue16769@psf.upfronthosting.co.za>


New submission from Brian Curtin:

While fixing #14470 to remove w9xpopen support, removing it from old Visual Studio projects came up.

1. I can't imagine anyone is attempting to use most of these.
2. Since we don't backport build changes to these older versions, some of them are very out of date and can't be that useful.

I propose to remove the following:
1. PC/VC6 - this version is from 1998 and is the last compiler to support Win9x, which we just removed support for with the w9xpopen change via PEP 11.
2. PC/VS7.1 - this version is from 2003 and still contains references to WISE installer, which IIRC has not been used since 2.3. On top of that, it's missing many of the current project files.

I'm skeptical of PC/VS8.0's use as Visual Studio 2005 is pretty old and it too is missing many current project files, but there is a conversion script that may help point someone in the right direction. I do remember Hirokazu Yamamoto mentioning using 2005 for some purposes, but this was years ago.

----------
assignee: brian.curtin
components: Build, Windows
messages: 178077
nosy: brian.curtin, loewis
priority: normal
severity: normal
status: open
title: Remove some old Visual Studio versions from PC/ directory
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec 24 19:32:04 2012
From: report at bugs.python.org (Irwin Jungreis)
Date: Mon, 24 Dec 2012 18:32:04 +0000
Subject: [New-bugs-announce] [issue16770] Selection in IDLE often skips
	first character
Message-ID: <1356373924.27.0.67520730715.issue16770@psf.upfronthosting.co.za>


New submission from Irwin Jungreis:

Often, when selecting text in IDLE, the first character of the selected region does not get selected. The problem occurs because sometimes, not always, when clicking on the left half of a character the insertion point gets put after the character, while other times it gets put before the character, even when clicking in the exact same spot. This can be consistently reproduced as follows. In IDLE, File | New Window. In the new window type the two characters 'M1' (without the quotes). Now position the cursor over the left half of the M. Slowly click several times without moving the cursor (with enough delay that it does not interpret it as a double-click). Note that after some clicks the insertion point is before the M and after others it is after the M, even though the cursor has not moved.

I am running Python 2.7.3, IDLE version 2.7.3, Tk version 8.5, on Mac OS X 10.6.8 Snow Leopard, on a MacBook Pro. (Same problem occurs on laptop screen and external monitor, and with USB mouse or built in trackpad)

----------
assignee: ronaldoussoren
components: IDLE, Macintosh
messages: 178088
nosy: jungreis, ronaldoussoren
priority: normal
severity: normal
status: open
title: Selection in IDLE often skips first character
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Dec 24 20:44:33 2012
From: report at bugs.python.org (Nurhusien Hasen)
Date: Mon, 24 Dec 2012 19:44:33 +0000
Subject: [New-bugs-announce] [issue16771] issuse
Message-ID: <CA+3n20KzZVT_2j10511bW0tSzFCCVCpiEpLVDMOycYBXWaWdvA@mail.gmail.com>


New submission from Nurhusien Hasen:

No find bug python any issuse masseg
Please not  find you masseg or I am out bug python Account

----------
messages: 178093
nosy: Nurhusien2
priority: normal
severity: normal
status: open
title: issuse

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

From report at bugs.python.org  Mon Dec 24 21:10:16 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 24 Dec 2012 20:10:16 +0000
Subject: [New-bugs-announce] [issue16772] int() accepts float number base
Message-ID: <1356379816.55.0.394159621293.issue16772@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

I'm not sure this is a bug. In 2.7 int() and long() with float number base raises TypeError. But in 3.x int() accepts float number base and truncate it to int.

----------
components: Interpreter Core
messages: 178095
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: int() accepts float number base
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec 24 21:15:15 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 24 Dec 2012 20:15:15 +0000
Subject: [New-bugs-announce] [issue16773] int() half-accepts UserString
Message-ID: <1356380115.98.0.739133485355.issue16773@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In Python 3 int() accepts UserString argument without explicit base and reject it with explicit base.

>>> from collections import UserString
>>> int(UserString('100'))
100
>>> int(UserString('100'), 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int() can't convert non-string with explicit base


In 2.7 the same behavior also for MutableString and bytearray.

----------
components: Interpreter Core
messages: 178096
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: int() half-accepts UserString
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec 24 21:40:15 2012
From: report at bugs.python.org (Alexey Kachayev)
Date: Mon, 24 Dec 2012 20:40:15 +0000
Subject: [New-bugs-announce] [issue16774] Additional recipes for itertools
	docs
Message-ID: <1356381615.1.0.91798699559.issue16774@psf.upfronthosting.co.za>


New submission from Alexey Kachayev:

Additional recipes for itertools documentation (widespread functions in other programming languages):
* drop
* split-at
* split-by

----------
assignee: docs at python
components: Documentation
files: itertools.doc.diff
keywords: patch
messages: 178098
nosy: asvetlov, docs at python, kachayev
priority: normal
severity: normal
status: open
title: Additional recipes for itertools docs
versions: Python 3.4
Added file: http://bugs.python.org/file28427/itertools.doc.diff

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

From report at bugs.python.org  Tue Dec 25 11:17:47 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 25 Dec 2012 10:17:47 +0000
Subject: [New-bugs-announce] [issue16775] Add test coverage for
	os.removedirs()
Message-ID: <1356430667.93.0.960297281672.issue16775@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
components: Library (Lib)
keywords: easy
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Add test coverage for os.removedirs()
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec 25 12:15:54 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 25 Dec 2012 11:15:54 +0000
Subject: [New-bugs-announce] [issue16776] Document PyCFunction_New and
	PyCFunction_NewEx functions
Message-ID: <1356434154.16.0.0981038830976.issue16776@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

c-api docs has no documentation for those public API functions.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 178115
nosy: asvetlov, docs at python
priority: normal
severity: normal
status: open
title: Document PyCFunction_New and PyCFunction_NewEx functions
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec 25 14:54:47 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 Dec 2012 13:54:47 +0000
Subject: [New-bugs-announce] [issue16777] "Evaluation order" doc section is
	wrong about dicts
Message-ID: <1356443687.99.0.545943442406.issue16777@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

http://docs.python.org/2/reference/expressions.html#evaluation-order
says that the dicts are evaluated in this order:
  {expr1: expr2, expr3: expr4}

however each value is evaluated before the respective key:
def f(x):
  print(x)
  return x

{f('k1'): f('v1'), f('k2'): f('v2')}

v1
k1
v2
k2
{'k1': 'v1', 'k2': 'v2'}

----------
assignee: ezio.melotti
components: Documentation
messages: 178127
nosy: chris.jerdonek, ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: "Evaluation order" doc section is wrong about dicts
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec 25 17:20:28 2012
From: report at bugs.python.org (Glynn Clements)
Date: Tue, 25 Dec 2012 16:20:28 +0000
Subject: [New-bugs-announce] [issue16778] Logger.findCaller needs to be
	smarter
Message-ID: <1356452428.01.0.563947098769.issue16778@psf.upfronthosting.co.za>


New submission from Glynn Clements:

The current behaviour of logging.Logger.findCaller() makes it awkward to add custom logging interfaces.

E.g. suppose that you define a custom logging level (NOTICE) then add a notice() function (analogous to logging.info() etc), the resulting LogRecord structure will have pathname, filename, module, funcName and lineno members which refer to the notice() function itself, rather than to its caller.

This can be hacked around e.g. by using code.compile_command to lie about the source filename, but that's ugly and highly unintuitive.

----------
components: Library (Lib)
messages: 178145
nosy: glynnc
priority: normal
severity: normal
status: open
title: Logger.findCaller needs to be smarter
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec 25 19:38:54 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Tue, 25 Dec 2012 18:38:54 +0000
Subject: [New-bugs-announce] [issue16779] Fix compiler warning when building
	extension modules on	64-bit Windows
Message-ID: <1356460734.84.0.660480375945.issue16779@psf.upfronthosting.co.za>


New submission from Jeremy Kloth:

The 64-bit linker doesn't mangle the dllexport'ed module init function (from PyMODINIT_FUNC) so it causes an exported name conflict.  We cannot just remove that name from export_symbols as the module may not have used PyMODINIT_FUNC on its init function.

The attached patch "fixes" the problem by suppressing the warning.

I personally would prefer the "pure" approach by assuming that the module initialization function would be required to be declared by PyMODINIT_FUNC and therefore the symbol would not need to be exported on the command line.

----------
assignee: eric.araujo
components: Build, Distutils
files: msvc9compiler.diff
keywords: patch
messages: 178160
nosy: eric.araujo, jkloth, tarek
priority: normal
severity: normal
status: open
title: Fix compiler warning when building extension modules on 64-bit Windows
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file28432/msvc9compiler.diff

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

From report at bugs.python.org  Tue Dec 25 22:54:11 2012
From: report at bugs.python.org (Lee Long)
Date: Tue, 25 Dec 2012 21:54:11 +0000
Subject: [New-bugs-announce] [issue16780] fail to compile python in msys
	with mingw
Message-ID: <1356472451.03.0.664575682974.issue16780@psf.upfronthosting.co.za>


New submission from Lee Long:

Hi all, 
  For some reason, I have to develop my software with mingw under windows. First of all, I need python installed in the msys but I try all my ways to install 2.6.x, 2.7.x, 3.2.x and 3.3.0, no one succeed. I search all issues and google the related information online, it seems that it doesn't support python on mingw? But what stranger is there are a few posts here with the patch presented, so is there any way to make the source compiled in mingw? I try all the available patches but again, it didn't solve the problem. Here are the error messages when I try to compile the 3.3.0 in mingw, 

  ./configure              ---> no problem
  make                     ---> errors shown below
  Objects/exceptions.c:2527:5: error: 'EALREADY' undeclared (first use in this function)
  Objects/exceptions.c:2527:5: note: each undeclared identifier is reported only once for each function it appears in
  Objects/exceptions.c:2528:5: error: 'EINPROGRESS' undeclared (first use in this function)
  Objects/exceptions.c:2529:5: error: 'EWOULDBLOCK' undeclared (first use in this function)
  Objects/exceptions.c:2532:5: error: 'ESHUTDOWN' undeclared (first use in this function)
  Objects/exceptions.c:2536:5: error: 'ECONNABORTED' undeclared (first use in this function)
  Objects/exceptions.c:2538:5: error: 'ECONNREFUSED' undeclared (first use in this function)
  Objects/exceptions.c:2540:5: error: 'ECONNRESET' undeclared (first use in this function)
  Objects/exceptions.c:2557:5: error: 'ETIMEDOUT' undeclared (first use in this function)
  make: *** [Objects/exceptions.o] Error 1

I've been working on these for two days, really has no idea what's wrong with these.

BTW, I saw in some similar posts, there are more then one patch uploaded in different time, I patch each at a time from old to new, is that the right order to do so or I only have to patch the latest one? 

Thanks.

----------
components: Build, Windows
messages: 178165
nosy: mwtree
priority: normal
severity: normal
status: open
title: fail to compile python in msys with mingw
versions: Python 3.3

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

From report at bugs.python.org  Wed Dec 26 01:15:50 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 26 Dec 2012 00:15:50 +0000
Subject: [New-bugs-announce] [issue16781] execfile/exec messes up with
	imports in executed file
Message-ID: <1356480950.95.0.0708133666827.issue16781@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

When a Python file is exec()uted, it magically fails to find names in imported modules. The most magical thing in the examples below (b3.py in attach for Python 3) is that first reference to wintypes.LONG in print statement is actually successfull.

--- a.py
from ctypes import wintypes

print(wintypes.LONG)

class LOGFONT(object):
  field = wintypes.LONG


--- b2.py (Python 2 version)
def main():
  execfile('a.py')
main()


--- Output
<class 'ctypes.c_long'>
Traceback (most recent call last):
  File "b2.py", line 4, in <module>
    main()
  File "b2.py", line 2, in main
    execfile('a.py')
  File "a.py", line 5, in <module>
    class LOGFONT(object):
  File "a.py", line 6, in LOGFONT
    field = wintypes.LONG
NameError: name 'wintypes' is not defined

----------
components: Interpreter Core
files: b3.py
messages: 178177
nosy: techtonik
priority: normal
severity: normal
status: open
title: execfile/exec messes up with imports in executed file
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28434/b3.py

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

From report at bugs.python.org  Wed Dec 26 03:49:02 2012
From: report at bugs.python.org (Thomas Ballinger)
Date: Wed, 26 Dec 2012 02:49:02 +0000
Subject: [New-bugs-announce] [issue16782] No curses.initwin: Incorrect
	package docstring for curses
Message-ID: <1356490142.44.0.537785717498.issue16782@psf.upfronthosting.co.za>


New submission from Thomas Ballinger:

Lib/curses/__init__.py has `curses.initwin()` in the docstring example code, but this function does not exist (should be `initscr()`)

Bad in at least back to 2.4

----------
assignee: docs at python
components: Documentation
files: docfix.patch
keywords: patch
messages: 178183
nosy: Thomas.Ballinger, docs at python
priority: normal
severity: normal
status: open
title: No curses.initwin: Incorrect package docstring for curses
versions: Python 3.3
Added file: http://bugs.python.org/file28437/docfix.patch

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

From report at bugs.python.org  Wed Dec 26 07:59:16 2012
From: report at bugs.python.org (William D. Colburn)
Date: Wed, 26 Dec 2012 06:59:16 +0000
Subject: [New-bugs-announce] [issue16783] sqlite3 accepts strings it cannot
	return
Message-ID: <1356505156.77.0.42259028203.issue16783@psf.upfronthosting.co.za>


New submission from William D. Colburn:

This seems to be just like issue6010, which is closed as "not as bug" which is simple irresponsible on the part of Python.

The problem is that I can store data into sqlite3 which cannot be retrieved.  The data I encountered was a string with a \xa0 in it that was read from urllib2.  I deposited that data into an sqlite3 database with no trouble at all.  Later, however, sqlite3 would throw an exception when I tried to retrieve the data.

Martin v. L?wis says this is user error because sqlite3 assumes UTF-8. It makes no sense that storeable data cannot be retrieved and that the failure of sqlite3 is a user-error.  If sqlite3 assumes UTF-8, then the error should have been caught when I did the store because I was not storing UTF-8 data.  Accepting bad input and blaming the user later down the line is bad bug handling, especially because the two events might be separated by a tremendous gap of time and code which makes debugging quite hard.  I was only able to find the errant character by popping the streamed webpage into emacs as both python and firefox showed me a normal looking string with nothing wrong with it.

----------
components: Unicode
messages: 178189
nosy: William.D..Colburn, ezio.melotti
priority: normal
severity: normal
status: open
title: sqlite3 accepts strings it cannot return
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec 26 11:33:21 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Dec 2012 10:33:21 +0000
Subject: [New-bugs-announce] [issue16784] Int tests enhancement and
	refactoring
Message-ID: <1356518001.26.0.44673058371.issue16784@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Int tests should be synchronized between different Python versions. Tests for int and long should be synchronized in 2.7. Common code for int and long tests should be shared in 2.7. CPython tests (i.e. small int identity) should be extracted to separated methods. Tests should be resorted by tested feature. Deprecated assertEquals should be replaced to assertEqual. And may be more.

----------
assignee: serhiy.storchaka
components: Tests
messages: 178197
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Int tests enhancement and refactoring
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Dec 26 12:35:12 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 26 Dec 2012 11:35:12 +0000
Subject: [New-bugs-announce] [issue16785] Document the fact that
	constructing OSError with erron	returns subclass if possible
Message-ID: <1356521712.57.0.0819210166931.issue16785@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

I mean adding examples for constructions like this:

>>> OSError(errno.ENOENT, 'error msg')
FileNotFoundError(2, 'error msg')

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 178204
nosy: asvetlov, docs at python
priority: normal
severity: normal
status: open
title: Document the fact that constructing OSError with erron returns subclass if possible
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Dec 26 14:19:58 2012
From: report at bugs.python.org (Thorsten Kampe)
Date: Wed, 26 Dec 2012 13:19:58 +0000
Subject: [New-bugs-announce] [issue16786] argparse doesn't offer
	localization interface for	"version" action
Message-ID: <1356527998.28.0.00679479762722.issue16786@psf.upfronthosting.co.za>


New submission from Thorsten Kampe:

The - deprecated - "version" keyword for argparse.ArgumentParser allowed for localization of the "show program's version number and exit" help text for -v/--version (output of "-h"/"--help")

The new version action for add_argument does not allow this - resulting in a partially translated output for the -v/--version option.

----------
components: Library (Lib)
messages: 178209
nosy: thorsten
priority: normal
severity: normal
status: open
title: argparse doesn't offer localization interface for "version" action
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Dec 26 14:51:05 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 26 Dec 2012 13:51:05 +0000
Subject: [New-bugs-announce] [issue16787] asyncore.dispatcher_with_send -
	increase the send buffer	size
Message-ID: <1356529865.78.0.746318746855.issue16787@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

As noted in issue #12498, asyncore.dispatcher_with_send only sends 512 bytes at a time: this is 1/3 of the Ethernet MTU, which reduces greatly the attainable bandwidth and increases the CPU usage.
Here's a patch bumping it to 8192 (and making it a class member so that derived classes can customize it if needed, although not documented).

Here's the result of a simplistic benchmark using asyncore.dispatcher_with_send to send data to a server:
Without patch:
"""
$ time ./python ~/test_asyncore.py localhost 4242

real    0m6.098s
user    0m4.472s
sys     0m1.436s
"""

With patch:
"""
$ time ./python ~/test_asyncore.py localhost 4242

real    0m0.937s
user    0m0.796s
sys     0m0.112s
"""

Of course, this is using the loopback interface, but it shows that the performance gain can non negligible. The test script is attached (use "netcat -l -p 4242" as server).

----------
components: Library (Lib)
files: asyncore_buffsize.diff
keywords: easy, needs review, patch
messages: 178212
nosy: giampaolo.rodola, neologix, xdegaye
priority: normal
severity: normal
stage: patch review
status: open
title: asyncore.dispatcher_with_send - increase the send buffer size
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file28442/asyncore_buffsize.diff

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

From report at bugs.python.org  Wed Dec 26 15:20:45 2012
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 26 Dec 2012 14:20:45 +0000
Subject: [New-bugs-announce] [issue16788] Add samestat to Lib/ntpath.py
	__all__
Message-ID: <1356531645.1.0.5490965013.issue16788@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
assignee: brian.curtin
components: Library (Lib), Windows
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: Add samestat to Lib/ntpath.py __all__
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Dec 26 16:01:05 2012
From: report at bugs.python.org (Dan Kenigsberg)
Date: Wed, 26 Dec 2012 15:01:05 +0000
Subject: [New-bugs-announce] [issue16789] :meth:`quit` links to constants
	instead of own module
Message-ID: <1356534065.91.0.932847817194.issue16789@psf.upfronthosting.co.za>


New submission from Dan Kenigsberg:

ftplib, poplib and smtplib modules define a "quit" function. But when it is refered by :meth:`quit` in the documentation, a reference to constants.quit is generated.

The suggested patch spells out the module-specific "quit" function.

----------
assignee: docs at python
components: Documentation
files: meth:quit.patch
keywords: patch
messages: 178222
nosy: danken, docs at python
priority: normal
severity: normal
status: open
title: :meth:`quit` links to constants instead of own module
type: behavior
Added file: http://bugs.python.org/file28445/meth:quit.patch

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

From report at bugs.python.org  Thu Dec 27 06:33:17 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 27 Dec 2012 05:33:17 +0000
Subject: [New-bugs-announce] [issue16790] provide ability to share tests
	between int and long tests
Message-ID: <1356586397.32.0.370409223096.issue16790@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Currently, adding new int() and long() tests that are common to both requires duplicating the tests in both test_int and test_long, which makes the tests harder to review and maintain and keep in synch.

Providing a simple way to share tests between test_int and test_long will simplify adding new tests for issues like issue 16784, issue 16761, and issue 16772.

This issue isn't applicable to 3.x because in 3.x test_int and test_long both test int(), so it doesn't make sense to repeat tests in both.

----------
components: Interpreter Core
keywords: easy
messages: 178271
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: provide ability to share tests between int and long tests
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec 27 13:30:02 2012
From: report at bugs.python.org (David Halter)
Date: Thu, 27 Dec 2012 12:30:02 +0000
Subject: [New-bugs-announce] [issue16791] itertools.chain.from_iterable
	doesn't stop
Message-ID: <1356611402.04.0.240264046705.issue16791@psf.upfronthosting.co.za>


New submission from David Halter:

The following lines run infinitely:

b = [1]
import itertools
b += itertools.chain.from_iterable([c] for c in b)

In my opinion this is a bug. Clearly you could say that this is an implementation detail. But afaik this is not documented and very misleading.

BTW: In PyPy b would be [1, 1].

----------
messages: 178296
nosy: davidhalter
priority: normal
severity: normal
status: open
title: itertools.chain.from_iterable doesn't stop
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Dec 27 16:34:19 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Dec 2012 15:34:19 +0000
Subject: [New-bugs-announce] [issue16792] Mark small ints test as
	CPython-only
Message-ID: <1356622459.12.0.786366680598.issue16792@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Small ints test should be extracted to a separate method and marked as CPython only. In additional it backported to 2.7.

----------
assignee: serhiy.storchaka
components: Tests
files: int_test_small_ints-3.3.patch
keywords: patch
messages: 178300
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Mark small ints test as CPython-only
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28454/int_test_small_ints-3.3.patch

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

From report at bugs.python.org  Thu Dec 27 18:12:36 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Dec 2012 17:12:36 +0000
Subject: [New-bugs-announce] [issue16793] Get rid of deprecated assertEquals
	etc in tests
Message-ID: <1356628356.95.0.286090339077.issue16793@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patches that replaces deprecated unittest assert aliases (such as assertEquals) to its nondeprecated counterpart (if such usage is not intended). This eliminates deprecation warnings.

----------
assignee: serhiy.storchaka
components: Tests
files: tests_deprecated_asserts-2.7.patch
keywords: patch
messages: 178304
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Get rid of deprecated assertEquals etc in tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28457/tests_deprecated_asserts-2.7.patch

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

From report at bugs.python.org  Thu Dec 27 19:56:46 2012
From: report at bugs.python.org (vertograd phrokhladny)
Date: Thu, 27 Dec 2012 18:56:46 +0000
Subject: [New-bugs-announce] [issue16794] Can't get a list of modules in
	Python's help system
Message-ID: <1356634606.34.0.441472301894.issue16794@psf.upfronthosting.co.za>


New submission from vertograd phrokhladny:

Ubuntu 12.4 LTS

----------
assignee: docs at python
components: Documentation
files: modules_command_crash.log
messages: 178310
nosy: docs at python, vertograd.phrokhladny
priority: normal
severity: normal
status: open
title: Can't get a list of modules in Python's help system
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file28460/modules_command_crash.log

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

From report at bugs.python.org  Thu Dec 27 22:44:43 2012
From: report at bugs.python.org (Sven Brauch)
Date: Thu, 27 Dec 2012 21:44:43 +0000
Subject: [New-bugs-announce] [issue16795] Patch: some changes to AST to make
	it more useful for	static language analysis
Message-ID: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za>


New submission from Sven Brauch:

Here's a patch doing some adjustments to the AST to make it more useful for static language analysis, as discussed in http://mail.python.org/pipermail/python-dev/2012-December/123320.html.

Changes done:
 * the described fix to attribute ranges
 * add location information for var / kwargs and arguments

Interestingly, this even fixes a bug; compare the locations of the error in the following situation:

>>> l = [1, 2, 3]
>>> l[
... 
... 2
... 
... ].Foo

Old error message:
Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
AttributeError: 'int' object has no attribute 'Foo'

New error message:
Traceback (most recent call last):
  File "<stdin>", line 5, in <module>
AttributeError: 'int' object has no attribute 'Foo'

The new message is obviously more accurate (one could even go as far as saying that the first one does not make any sense at all -- what does the expression in the slice have to do with the error?).
The same thing happens in similar situations, e.g. with line continuation characters, function calls, ... anything multi-line with an error related to attribute access.

I hope the patch is okay, if not please let me know what to change. I also hope I managed to include all important changes into the patch ;)

----------
components: None
files: python.diff
keywords: patch
messages: 178339
nosy: scummos
priority: normal
severity: normal
status: open
title: Patch: some changes to AST to make it more useful for static language analysis
versions: Python 3.4
Added file: http://bugs.python.org/file28462/python.diff

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

From report at bugs.python.org  Fri Dec 28 00:57:37 2012
From: report at bugs.python.org (Michael Schurter)
Date: Thu, 27 Dec 2012 23:57:37 +0000
Subject: [New-bugs-announce] [issue16796] Fix argparse docs typo: "an
	special action" to "a	special action"
Message-ID: <1356652657.93.0.879833521932.issue16796@psf.upfronthosting.co.za>


New submission from Michael Schurter:

Title says it all; patch has the fix. No need for an ACKS entry

----------
files: argparse-docs-typo.patch
keywords: patch
messages: 178348
nosy: schmichael
priority: normal
severity: normal
status: open
title: Fix argparse docs typo: "an special action" to "a special action"
Added file: http://bugs.python.org/file28463/argparse-docs-typo.patch

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

From report at bugs.python.org  Fri Dec 28 01:01:46 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 Dec 2012 00:01:46 +0000
Subject: [New-bugs-announce] [issue16797] sporadic test_faulthandler failure
Message-ID: <1356652906.67.0.440148655963.issue16797@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

http://buildbot.python.org/all/builders/AMD64%20Mountain%20Lion%20%5BSB%5D%203.x/builds/631

======================================================================
FAIL: test_dump_traceback_later_file (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Volumes/bay2/buildslave/cpython/3.x.snakebite-mountainlion-amd64/build/Lib/test/test_faulthandler.py", line 490, in test_dump_traceback_later_file
    self.check_dump_traceback_later(file=True)
  File "/Volumes/bay2/buildslave/cpython/3.x.snakebite-mountainlion-amd64/build/Lib/test/test_faulthandler.py", line 476, in check_dump_traceback_later
    filename, loops)
  File "/Volumes/bay2/buildslave/cpython/3.x.snakebite-mountainlion-amd64/build/Lib/test/test_faulthandler.py", line 460, in _check_dump_traceback_later
    self.assertRegex(trace, regex)
AssertionError: Regex didn't match: '^Timeout \\(0:00:00.500000\\)!\\nThread 0x[0-9a-f]+:\\n  File "<string>", line 9 in func\n  File "<string>", line 20 in <module>$' not found in 'Timeout (0:00:00.500000)!\nThread 0x00007fff7f242180:\n  File "<string>", line 10 in func\n  File "<string>", line 20 in <module>'

----------
components: Tests
messages: 178351
nosy: haypo, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: sporadic test_faulthandler failure
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec 28 02:37:09 2012
From: report at bugs.python.org (Javier Domingo)
Date: Fri, 28 Dec 2012 01:37:09 +0000
Subject: [New-bugs-announce] [issue16798] DTD not checked
Message-ID: <1356658629.79.0.632401126307.issue16798@psf.upfronthosting.co.za>


New submission from Javier Domingo:

Hi,

I am trying to find any tip on how to use minidom or etree xml implementations to check the xml syntax.

I just found that the only way to check xml syntax throught dtds is using lxml.

Would it be possible to implement this in the minidom or ElementTree default lib?

I have seen bug http://bugs.python.org/issue2124 that speaks about the dtds fetch, but didn't see any place where it speaks about them being checked.

----------
components: XML
messages: 178353
nosy: txomon
priority: normal
severity: normal
status: open
title: DTD not checked
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Dec 28 04:11:11 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 28 Dec 2012 03:11:11 +0000
Subject: [New-bugs-announce] [issue16799] switch regrtest from getopt-style
	options to argparse	Namespace object
Message-ID: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Issue 15302 switched regrtest from getopt to argparse for parsing options.  However, regrtest.main() still expects and operates on getopt-style options.

This issue is to continue the regrtest refactoring and replace the use of getopt-style options with an argparse Namespace object.

This issue should probably be a meta-issue with the transition happening over several issues/commits, as there are many command-line options that will probably have varying types and actions (in the sense of argparse).  Options can be switched over incrementally in groups (e.g. by having the _parse_args() function return the parsed options in both forms: in both getopt-style format and a Namespace object).

This issue will be completed when the namespace-to-getopt "bridge code" is removed -- probably along with the corresponding argparse-to-getopt tests.

----------
components: Tests
messages: 178356
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: switch regrtest from getopt-style options to argparse Namespace object
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Dec 28 06:37:37 2012
From: report at bugs.python.org (Amir Szekely)
Date: Fri, 28 Dec 2012 05:37:37 +0000
Subject: [New-bugs-announce] [issue16800] tempfile._get_default_tempdir()
	leaves files behind when	HD is full
Message-ID: <1356673057.72.0.476993951408.issue16800@psf.upfronthosting.co.za>


New submission from Amir Szekely:

tempfile._get_default_tempdir() tries to find a good temporary directory by attempting to create a file and write a string into it for all candidate directories. It deletes those files right after closing them. But if writing rather than creating them fails, the files get left behind. This can happen, for example, when the disk is full on Linux. It will let you create the file with open() and even write() to it. But as soon as close() is called, OSError is raised with errno 28 (No space left on device) and unlink() is never called.

On our system (Linux 2.6.32, ext3), after filling the disk by mistake, we suddenly found dozens of random empty files scattered across the file system. The candidate list, where they were all found, even includes the root directory so the issue is quite visible.

We noticed this problem on Python 2.4.4, but I have been able to reproduce it with today's tip.

A possible solution would be wrapping everything between open() and unlink() in a try-finally block. This way, no matter what happens, the file will get deleted. I have attached a patch implementing this solution and a new test case that reproduces the issue. Verified with `make test && make patchcheck`.

----------
components: Extension Modules
files: fix_tempfile_leaving_files_behind.patch
keywords: patch
messages: 178362
nosy: kichik
priority: normal
severity: normal
status: open
title: tempfile._get_default_tempdir() leaves files behind when HD is full
type: resource usage
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file28464/fix_tempfile_leaving_files_behind.patch

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

From report at bugs.python.org  Fri Dec 28 14:04:13 2012
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 28 Dec 2012 13:04:13 +0000
Subject: [New-bugs-announce] [issue16801] Preserve original representation
	for integers / floats	in docstrings
Message-ID: <1356699853.91.0.313275944642.issue16801@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The line declaring the function dbm.open looks like this:
    def open(file, flag='r', mode=0o666):

The docstring for dbm.open looks like this:
    open(file, flag='r', mode=438)

Obviously 438==0o666.  But the author used the octal representation because it's more readable.  Unfortunately Python throws that enhanced readability away when it round-trips the rvalue from a string into an integer and back into a string again for the docstring.

It might be an improvement if Python preserved the original source code's representation for integer (and perhaps float) default arguments for parameters.  I haven't looked at the code that does the parsing / builds the docstring, but I suspect we could hang the original representation on the AST node and retrieve it when building the docstring.

The only problem I can forsee: what about code that uses local variables, or computation including perhaps function calls, to calculate default values?  On the one hand, the local variable or the function call may be inscrutable--on the other, perhaps the magic integer value it replaced was no better.  Or we could have a heuristic, like if the original representation contains internal spaces or parentheses we use str(rvalue), otherwise we use the original representation.

----------
components: Interpreter Core
messages: 178383
nosy: larry
priority: normal
severity: normal
status: open
title: Preserve original representation for integers / floats in docstrings
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Dec 28 17:12:31 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 28 Dec 2012 16:12:31 +0000
Subject: [New-bugs-announce] [issue16802] fileno argument to socket.socket()
	undocumented
Message-ID: <1356711151.76.0.423836721045.issue16802@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

The actual signature is

    socket.socket(family=AF_INET, type=SOCK_STREAM, proto=0, fileno=None)

but the documented signature is

    socket.socket([family[, type[, proto]]])

Should the fileno argument be documented or is it considered an implementation detail?

----------
messages: 178387
nosy: sbt
priority: normal
severity: normal
status: open
title: fileno argument to socket.socket() undocumented
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec 28 19:07:49 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Dec 2012 18:07:49 +0000
Subject: [New-bugs-announce] [issue16803] Make time_importlib run tests
	under both	_frozen_importlib and importlib._bootstrap
Message-ID: <1356718069.62.0.143946538677.issue16803@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Need to do some work on the importlib tests such that they get run using both _frozen_importlib and importlib._bootstrap to prevent any drift between importlib/_bootstrap.py and import.c (and to make it easier to develop).

----------
components: Tests
messages: 178409
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Make time_importlib run tests under both _frozen_importlib and importlib._bootstrap
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Dec 28 21:22:43 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 Dec 2012 20:22:43 +0000
Subject: [New-bugs-announce] [issue16804] python3 -S -m site fails
Message-ID: <1356726163.27.0.125833225728.issue16804@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

$ python3.4 -S -m site
sys.path = [
    '',
    '/home/antoine/opt/lib/python34.zip',
    '/home/antoine/opt/lib/python3.4/',
    '/home/antoine/opt/lib/python3.4/plat-linux',
    '/home/antoine/opt/lib/python3.4/lib-dynload',
]
Traceback (most recent call last):
  File "/home/antoine/opt/lib/python3.4/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/antoine/opt/lib/python3.4/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/antoine/opt/lib/python3.4/site.py", line 640, in <module>
    _script()
  File "/home/antoine/opt/lib/python3.4/site.py", line 612, in _script
    "exists" if os.path.isdir(USER_BASE) else "doesn't exist"))
  File "/home/antoine/opt/lib/python3.4/genericpath.py", line 42, in isdir
    st = os.stat(s)
TypeError: stat: can't specify None for path argument

----------
components: Library (Lib)
messages: 178424
nosy: ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: python3 -S -m site fails
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Dec 29 01:03:55 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 29 Dec 2012 00:03:55 +0000
Subject: [New-bugs-announce] [issue16805] when building docs on Debian 7 -->
	ERROR: Error in	"note" directive
Message-ID: <1356739435.76.0.304211925624.issue16805@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

I am running Debian 7, which has sphinx is1.1.3+dfsg-4.

When I run

$ python tools/sphinx-build.py -bhtml . build/

I get a whole bunch of errors:

Making output directory...
Running Sphinx v1.1.3
loading pickled environment... not yet created
building [html]: targets for 435 source files that are out of date
updating environment: 435 added, 0 changed, 0 removed
reading sources... [100%] whatsnew/index                                                                                                                                
/home/wena/src/python/cpython/Doc/c-api/arg.rst:47: ERROR: Error in "note" directive:
invalid option block.

.. note::
   For all ``#`` variants of formats (``s#``, ``y#``, etc.), the type of
   the length argument (int or :c:type:`Py_ssize_t`) is controlled by
   defining the macro :c:macro:`PY_SSIZE_T_CLEAN` before including
   :file:`Python.h`.  If the macro was defined, length is a
   :c:type:`Py_ssize_t` rather than an :c:type:`int`. This behavior will change
   in a future Python version to only support :c:type:`Py_ssize_t` and
   drop :c:type:`int` support. It is best to always define :c:macro:`PY_SSIZE_T_CLEAN`.
/home/wena/src/python/cpython/Doc/c-api/init.rst:547: ERROR: Error in "note" directive:
invalid option block.

.. note::
   When only the main thread exists, no GIL operations are needed. This is a
   common situation (most Python programs do not use threads), and the lock
   operations slow the interpreter down a bit. Therefore, the lock is not
   created initially.  This situation is equivalent to having acquired the lock:
   when there is only a single thread, all object accesses are safe.  Therefore,
   when this function initializes the global interpreter lock, it also acquires
   it.  Before the Python :mod:`_thread` module creates a new thread, knowing
   that either it has the lock or the lock hasn't been created yet, it calls
   :c:func:`PyEval_InitThreads`.  When this call returns, it is guaranteed that
   the lock has been created and that the calling thread has acquired it.

   It is **not** safe to call this function when it is unknown which thread (if
   any) currently has the global interpreter lock.

   This function is not available when thread support is disabled at compile time.
/home/wena/src/python/cpython/Doc/faq/library.rst:513: ERROR: Error in "note" directive:
invalid option block.

.. note::
   To read and write binary data, it is mandatory to open the file in
   binary mode (here, passing ``"rb"`` to :func:`open`).  If you use
   ``"r"`` instead (the default), the file will be open in text mode
   and ``f.read()`` will return :class:`str` objects rather than
   :class:`bytes` objects.
/home/wena/src/python/cpython/Doc/library/fractions.rst:93: ERROR: Error in "note" directive:
invalid option block.

.. note:: From Python 3.2 onwards, you can also construct a
   :class:`Fraction` instance directly from a :class:`float`.
/home/wena/src/python/cpython/Doc/library/fractions.rst:102: ERROR: Error in "note" directive:
invalid option block.

.. note:: From Python 3.2 onwards, you can also construct a
   :class:`Fraction` instance directly from a :class:`decimal.Decimal`
   instance.
/home/wena/src/python/cpython/Doc/library/getopt.rst:12: ERROR: Error in "note" directive:
invalid option block.

.. note::
   The :mod:`getopt` module is a parser for command line options whose API is
   designed to be familiar to users of the C :c:func:`getopt` function. Users who
   are unfamiliar with the C :c:func:`getopt` function or who would like to write
   less code and get better help and error messages should consider using the
   :mod:`argparse` module instead.
/home/wena/src/python/cpython/Doc/library/io.rst:678: ERROR: Error in "warning" directive:
invalid option block.

.. warning::
   :class:`BufferedRWPair` does not attempt to synchronize accesses to
   its underlying raw streams.  You should not pass it the same object
   as reader and writer; use :class:`BufferedRandom` instead.
/home/wena/src/python/cpython/Doc/library/logging.config.rst:144: ERROR: Error in "note" directive:
invalid option block.

.. note:: Because portions of the configuration are passed through
   :func:`eval`, use of this function may open its users to a security risk.
   While the function only binds to a socket on ``localhost``, and so does
   not accept connections from remote machines, there are scenarios where
   untrusted code could be run under the account of the process which calls
   :func:`listen`. Specifically, if the process calling :func:`listen` runs
   on a multi-user machine where users cannot trust each other, then a
   malicious user could arrange to run essentially arbitrary code in a
   victim user's process, simply by connecting to the victim's
   :func:`listen` socket and sending a configuration which runs whatever
   code the attacker wants to have executed in the victim's process. This is
   especially easy to do if the default port is used, but not hard even if a
   different port is used). To avoid the risk of this happening, use the
   ``verify`` argument to :func:`listen` to prevent unrecognised
   configurations from being applied.
/home/wena/src/python/cpython/Doc/library/logging.config.rst:747: ERROR: Error in "note" directive:
invalid option block.

.. note:: Due to the use of :func:`eval` as described above, there are
   potential security risks which result from using the :func:`listen` to send
   and receive configurations via sockets. The risks are limited to where
   multiple users with no mutual trust run code on the same machine; see the
   :func:`listen` documentation for more information.
/home/wena/src/python/cpython/Doc/library/os.rst:263: ERROR: Error in "note" directive:
invalid option block.

.. note:: On Mac OS X, :func:`getgroups` behavior differs somewhat from
   other Unix platforms. If the Python interpreter was built with a
   deployment target of :const:`10.5` or earlier, :func:`getgroups` returns
   the list of effective group ids associated with the current user process;
   this list is limited to a system-defined number of entries, typically 16,
   and may be modified by calls to :func:`setgroups` if suitably privileged.
   If built with a deployment target greater than :const:`10.5`,
   :func:`getgroups` returns the current group access list for the user
   associated with the effective user id of the process; the group access
   list may change over the lifetime of the process, it is not affected by
   calls to :func:`setgroups`, and its length is not limited to 16.  The
   deployment target value, :const:`MACOSX_DEPLOYMENT_TARGET`, can be
   obtained with :func:`sysconfig.get_config_var`.
/home/wena/src/python/cpython/Doc/library/pkgutil.rst:148: ERROR: Error in "note" directive:
invalid option block.

.. note::
   Only works for a :term:`finder` which defines an ``iter_modules()``
   method. This interface is non-standard, so the module also provides
   implementations for :class:`importlib.machinery.FileFinder` and
   :class:`zipimport.zipimporter`.
/home/wena/src/python/cpython/Doc/library/pkgutil.rst:186: ERROR: Error in "note" directive:
invalid option block.

.. note::
   Only works for a :term:`finder` which defines an ``iter_modules()``
   method. This interface is non-standard, so the module also provides
   implementations for :class:`importlib.machinery.FileFinder` and
   :class:`zipimport.zipimporter`.
/home/wena/src/python/cpython/Doc/library/socket.rst:728: ERROR: Error in "note" directive:
invalid option block.

.. note::
   :meth:`close()` releases the resource associated with a connection but
   does not necessarily close the connection immediately.  If you want
   to close the connection in a timely fashion, call :meth:`shutdown()`
   before :meth:`close()`.
/home/wena/src/python/cpython/Doc/library/ssl.rst:609: ERROR: Error in "note" directive:
invalid option block.

.. note::
   To validate a certificate for a particular service, you can use the
   :func:`match_hostname` function.
/home/wena/src/python/cpython/Doc/library/sys.rst:245: ERROR: Error in "note" directive:
invalid option block.

.. note:: If a :ref:`virtual environment <venv-def>` is in effect, this
   value will be changed in ``site.py`` to point to the virtual environment.
   The value for the Python installation will still be available, via
   :data:`base_exec_prefix`.
/home/wena/src/python/cpython/Doc/library/test.rst:201: ERROR: Error in "note" directive:
invalid option block.

.. note::
   :mod:`test.support` is not a public module.  It is documented here to help
   Python developers write tests.  The API of this module is subject to change
   without backwards compatibility concerns between releases.
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
writing output... [100%] whatsnew/index                                                                                                                                 
writing additional files... genindex py-modindex search download index opensearch
copying images... [100%] library/turtle-star.png                                                                                                                        
copying static files... done
dumping search index... done
dumping object inventory... done
build succeeded, 16 warnings.

----------
assignee: docs at python
components: Documentation
messages: 178443
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: when building docs on Debian 7 --> ERROR: Error in "note" directive
versions: Python 3.4

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

From report at bugs.python.org  Sat Dec 29 01:08:22 2012
From: report at bugs.python.org (Carsten Klein)
Date: Sat, 29 Dec 2012 00:08:22 +0000
Subject: [New-bugs-announce] [issue16806] col_offset is -1 for multiline
	string expressions	resembling docstrings
Message-ID: <1356739702.66.0.625233113719.issue16806@psf.upfronthosting.co.za>


New submission from Carsten Klein:

Given an input module such as

class klass(object):
    """multi line comment
    continued on this line
    """

    """single line comment"""

    """
    Another multi
    line
    comment"""


and implementing a custom ast.NodeVisitor such as


import as

class CustomVisitor(ast.NodeVisitor):

    def visit_ClassDef(self, node):

        for childNode in node.body:

            self.visit(childNode)

    def visit_Expr(self, node):

        print(node.col_offset)
        print(node.value.col_offset)


and feeding it the compiled ast from the module above


f = open('./module.py')
source = f.read()
node = ast.parse(source, mode = 'exec')
visitor = CustomVisitor()
visitor.visit(node)


should yield -1/-1 for the docstring that is the first
child node expression of the classdef body.

it will, however, yield the correct col_offset of 4/4 for
the single line docstring following the first one.

the multi line docstring following that will again
yield a -1/-1 col_offset.



It believe that this behaviour is not correct and instead
the col_offset should be 4 for both the expression node
and its str value.

----------
components: Interpreter Core
messages: 178444
nosy: carsten.klein at axn-software.de
priority: normal
severity: normal
status: open
title: col_offset is -1 for multiline string expressions resembling docstrings
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Dec 29 02:39:27 2012
From: report at bugs.python.org (Dougal Sutherland)
Date: Sat, 29 Dec 2012 01:39:27 +0000
Subject: [New-bugs-announce] [issue16807] argparse group nesting lost on
	inheritance
Message-ID: <1356745167.13.0.671311915058.issue16807@psf.upfronthosting.co.za>


New submission from Dougal Sutherland:

If you wrap a mutually exclusive group inside an argument group in an argparse.ArgumentParser, and then use parents= to inherit from that parser, the non-exclusive argument group is forgotten in the help output, and the arguments move to the default "optional arguments" section. For example:

    # construct the parser with a mutually exclusive group
    >>> import argparse
    >>> parent = argparse.ArgumentParser(add_help=False)
    >>> group = parent.add_argument_group('the group')
    >>> group.add_argument('--foo') and None
    >>> mutex = group.add_mutually_exclusive_group()
    >>> mutex.add_argument('-a', action='store_true') and None
    >>> mutex.add_argument('-b', action='store_true') and None
    >>> parent.print_help()
    usage: [--foo FOO] [-a | -b]

    the group:
      --foo FOO
      -a
      -b

    # now try to inherit from it; "the group" is forgotten for
    # mutex arguments, but remains for others
    >>> argparse.ArgumentParser(add_help=False, parents=[parent]).print_help()
    usage: [--foo FOO] [-a | -b]

    optional arguments:
      -a
      -b

    the group:
      --foo FOO

I see the same behavior on 2.7.3 and 3.3.0.

The problem is that [`argparse._ActionsContainer._add_container_actions`](http://hg.python.org/releasing/2.7.3/file/7bb96963d067/Lib/argparse.py#l1331) always adds mutex groups to the top level, rather than to the equivalent of their `_container` attribute. The attached patch fixes this, and adds a test based on the formatted output (almost identical to the `test_groups_parents` test).

One thing about the patch: it assumes that the `_container` attribute of all the mutex groups will be either the `container` argument to `_add_container_actions` or an argument group that has been processed in `group_map`. If this is not the case, it'll fail with either an `AttributeError` or a `KeyError`. I don't know when this would happen, or if it's common enough that it's worth checking for more explicitly.

----------
components: Library (Lib)
files: argparse_mutex_parent.patch
keywords: patch
messages: 178459
nosy: Dougal.Sutherland, bethard
priority: normal
severity: normal
status: open
title: argparse group nesting lost on inheritance
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28473/argparse_mutex_parent.patch

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

From report at bugs.python.org  Sat Dec 29 04:02:29 2012
From: report at bugs.python.org (Daniel Shahaf)
Date: Sat, 29 Dec 2012 03:02:29 +0000
Subject: [New-bugs-announce] [issue16808] inspect.stack() should return list
	of named tuples
Message-ID: <1356750149.18.0.966123919893.issue16808@psf.upfronthosting.co.za>


New submission from Daniel Shahaf:

Currently inspect.stack() returns a list of 6-tuples.  I suggest to make it return a list of named tuples, so code that only needs one tuple element can get it by name.

Current behaviour:
% ./python -c 'import inspect; print(inspect.stack()[0])' 
(<frame object at 0x157fb38>, '<string>', 1, '<module>', None, None)

Suggested behaviour:
% ./python -c 'import inspect; print(inspect.stack()[0])'    
FrameInfo(frame=<frame object at 0xddab38>, filename='<string>', lineno=1, function='<module>', code_context=None, index=None)

----------
components: Library (Lib)
files: inspect-v1.diff
keywords: patch
messages: 178467
nosy: danielsh
priority: normal
severity: normal
status: open
title: inspect.stack() should return list of named tuples
versions: Python 3.4
Added file: http://bugs.python.org/file28475/inspect-v1.diff

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

From report at bugs.python.org  Sat Dec 29 07:38:27 2012
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 29 Dec 2012 06:38:27 +0000
Subject: [New-bugs-announce] [issue16809] Tk 8.6.0 introduces TypeError. (Tk
	8.5.13 works)
Message-ID: <1356763107.47.0.647000150457.issue16809@psf.upfronthosting.co.za>


New submission from Roger Serwy:

I am running Arch Linux with the latest Tcl/Tk 8.6.0 build with Python 2.7.3 and 3.3.0, and the latest 3.4.0a0 build from the repository.

Running the attached script fails when calling pack_info(). Here's is the script's output:

8.6
Traceback (most recent call last):
  File "tk_86_error.py", line 6, in <module>
    label.pack_info()
  File "/usr/lib/python3.3/tkinter/__init__.py", line 1884, in pack_info
    self.tk.call('pack', 'info', self._w))
TypeError: Can't convert '_tkinter.Tcl_Obj' object to str implicitly


This error did not occur when using Tk 8.5.13.

----------
components: Tkinter
files: tk_86_error.py
messages: 178475
nosy: serwy
priority: high
severity: normal
status: open
title: Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works)
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28476/tk_86_error.py

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

From report at bugs.python.org  Sat Dec 29 07:54:21 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Sat, 29 Dec 2012 06:54:21 +0000
Subject: [New-bugs-announce] [issue16810] inconsistency in weekday
Message-ID: <1356764061.7.0.32287825168.issue16810@psf.upfronthosting.co.za>


New submission from Glenn Linderman:

Docs say:

date.timetuple()

    Return a time.struct_time such as returned by time.localtime(). The hours, minutes and seconds are 0, and the DST flag is -1. d.timetuple() is equivalent to time.struct_time((d.year, d.month, d.day, 0, 0, 0, d.weekday(), yday, -1)), where yday = d.toordinal() - date(d.year, 1, 1).toordinal() + 1 is the day number within the current year starting with 1 for January 1st.

However, timetuple's 7th element has a range of 0-6 where 0 is Sunday, and d.weekday has a range of 0-6 where 0 is Monday. So the claim of equivalence is false.   "d.weekday()" in the above could be replaced by "( d.weekday() + 1 ) % 7"

I guess datetime consistently uses 0==Monday, and weeks starting on Monday, except for the timetuple (which probably has compatibility constraints which force it to return a different value, which I consider to be more correct).

----------
assignee: docs at python
components: Documentation
messages: 178477
nosy: docs at python, v+python
priority: normal
severity: normal
status: open
title: inconsistency in weekday
versions: Python 3.3

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

From report at bugs.python.org  Sat Dec 29 11:23:14 2012
From: report at bugs.python.org (Helmut Jarausch)
Date: Sat, 29 Dec 2012 10:23:14 +0000
Subject: [New-bugs-announce] [issue16811] email.message.Message flatten dies
	of list index out of	range
Message-ID: <1356776594.55.0.534961583044.issue16811@psf.upfronthosting.co.za>


New submission from Helmut Jarausch:

The following code triggers the bug:

#!/usr/bin/python3.3
#-*- coding: latin1 -*-
from email.message import Message
from email import policy
from email.parser import FeedParser

Parser= FeedParser(policy=policy.SMTP)
Parser.feed('From jarausch at igpm.rwth-aachen.de  Tue Apr 24 15:09:24 2012\n')
Parser.feed('X-Status:    \n')  # this triggers the bug
Parser.feed('From: Helmut Jarausch <jarausch at igpm.rwth-aachen.de>\n')

Msg= Parser.close()
Msg_as_str= Msg.as_string(unixfrom=True)

This triggers
  File "Email_Parse_Bug.py", line 13, in <module>
    Msg_as_str= Msg.as_string(unixfrom=True)
  File "/usr/lib64/python3.3/email/message.py", line 151, in as_string
    g.flatten(self, unixfrom=unixfrom)
  File "/usr/lib64/python3.3/email/generator.py", line 112, in flatten
    self._write(msg)
  File "/usr/lib64/python3.3/email/generator.py", line 171, in _write
    self._write_headers(msg)
  File "/usr/lib64/python3.3/email/generator.py", line 198, in _write_headers
    self.write(self.policy.fold(h, v))
  File "/usr/lib64/python3.3/email/policy.py", line 153, in fold
    return self._fold(name, value, refold_binary=True)
  File "/usr/lib64/python3.3/email/policy.py", line 176, in _fold
    (len(lines[0])+len(name)+2 > maxlen or
IndexError: list index out of range


If I strip the '\n' from the lines feeded to the Parser,
the bug does not occur.

Thanks for looking into it,
Helmut.

This is with  Python 3.3.0+ 3.3:ccc372b37fbb+

----------
components: Library (Lib)
messages: 178482
nosy: HJarausch
priority: normal
severity: normal
status: open
title: email.message.Message flatten dies of list index out of range
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Sat Dec 29 14:43:54 2012
From: report at bugs.python.org (Andrew)
Date: Sat, 29 Dec 2012 13:43:54 +0000
Subject: [New-bugs-announce] [issue16812] os.symlink can return wrong
	FileExistsError/WindowsError	information
Message-ID: <1356788634.61.0.928223501343.issue16812@psf.upfronthosting.co.za>


New submission from Andrew:

When attempting to make a symlink using a name that already exists, a FileExistsError is raised (and rightfully so), but it lists the source name rather than the destination name. However, the existing destination name is what causes the exception to be raised, not the existing source. Since the FileExistsError is WinError 183 and I haven't attempted this on another OS, I'm marking this as Windows-specific. Issue 13775 seems to be related.

----------
components: Windows
messages: 178493
nosy: IAmTheClaw
priority: normal
severity: normal
status: open
title: os.symlink can return wrong FileExistsError/WindowsError information
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Dec 29 15:05:58 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 29 Dec 2012 14:05:58 +0000
Subject: [New-bugs-announce] [issue16813] use paths relative to CPython root
Message-ID: <1356789958.56.0.310078512917.issue16813@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

I think it's a good idea to simply list the 'full' path.

----------
assignee: docs at python
components: Devguide, Documentation
files: use-paths-relative-to-root.diff
keywords: patch
messages: 178494
nosy: docs at python, ezio.melotti, tshepang
priority: normal
severity: normal
status: open
title: use paths relative to CPython root
Added file: http://bugs.python.org/file28479/use-paths-relative-to-root.diff

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

From report at bugs.python.org  Sat Dec 29 15:11:51 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 29 Dec 2012 14:11:51 +0000
Subject: [New-bugs-announce] [issue16814] use --directory option of make
Message-ID: <1356790311.86.0.00498941541992.issue16814@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

This avoids having to run 2 separate commands.

----------
components: Devguide
files: make-can-specify-build-directory.diff
keywords: patch
messages: 178495
nosy: ezio.melotti, tshepang
priority: normal
severity: normal
status: open
title: use --directory option of make
Added file: http://bugs.python.org/file28480/make-can-specify-build-directory.diff

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

From report at bugs.python.org  Sat Dec 29 18:18:01 2012
From: report at bugs.python.org (Bernie Keimel)
Date: Sat, 29 Dec 2012 17:18:01 +0000
Subject: [New-bugs-announce] [issue16815] Is all OK!!
Message-ID: <1356801481.74.0.612301045866.issue16815@psf.upfronthosting.co.za>


Changes by Bernie Keimel <unowned60 at gmail.com>:


----------
nosy: Bernie.Keimel
priority: normal
severity: normal
status: open
title: Is all OK!!

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

From report at bugs.python.org  Sat Dec 29 22:37:29 2012
From: report at bugs.python.org (=?utf-8?q?Domen_Ko=C5=BEar?=)
Date: Sat, 29 Dec 2012 21:37:29 +0000
Subject: [New-bugs-announce] [issue16816] Bug in hash randomization
Message-ID: <1356817049.81.0.823751474505.issue16816@psf.upfronthosting.co.za>


New submission from Domen Ko?ar:

Script to reproduce the issue https://gist.github.com/4409304

----------
components: Interpreter Core
messages: 178539
nosy: iElectric
priority: normal
severity: normal
status: open
title: Bug in hash randomization
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Dec 30 01:56:09 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 30 Dec 2012 00:56:09 +0000
Subject: [New-bugs-announce] [issue16817] test___all__ has to save and
	restore sys.modules while	it does all the importing
Message-ID: <1356828969.86.0.130125185831.issue16817@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

http://mail.python.org/pipermail/python-dev/2012-December/123368.html

This came up while investigating some test-order-dependency failures in
issue 16076.

test___all__ goes over modules that have `__all__` in them and does 'from
<module> import *' on them. This leaves a lot of modules in sys.modules,
which may interfere with some tests that do fancy things with sys,modules.
In particular, the ElementTree tests have trouble with it because they
carefully set up the imports to get the C or the Python version of etree
(see issues 15083 and 15075).

Would it make sense to save the sys.modules state and restore it in
test___all__ so that sys.modules isn't affected by this test?

----------
assignee: eli.bendersky
components: Tests
messages: 178547
nosy: eli.bendersky
priority: normal
severity: normal
stage: needs patch
status: open
title: test___all__ has to save and restore sys.modules while it does all the importing
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Dec 30 08:53:10 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 30 Dec 2012 07:53:10 +0000
Subject: [New-bugs-announce] [issue16818] Couple of mistakes in PEP 431
Message-ID: <1356853990.44.0.712764184905.issue16818@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

in PEP 431, Time zone support improvements
"NonExistentTimeError

This exception is raised when giving a datetime specification that are ambigious while setting is_dst to None:"
it should be "that is non-existent" or similar.
The same description is used for NonExistentTimeError.
The NonExistentTimeError description should be "... datetime specification that is ambigious ..."

----------
components: None
messages: 178555
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: Couple of mistakes in PEP 431

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

From report at bugs.python.org  Sun Dec 30 09:02:18 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 30 Dec 2012 08:02:18 +0000
Subject: [New-bugs-announce] [issue16819] IDLE b"" method completion
	incorrect
Message-ID: <1356854538.64.0.0309588990052.issue16819@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

To reproduce, type b"". and then press TAB.
The encode method is listed, that means that IDLE is listing the methods of "" (it should list the methods of b"").

----------
components: IDLE
messages: 178558
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: IDLE b"" method completion incorrect
type: behavior

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

From report at bugs.python.org  Sun Dec 30 18:12:53 2012
From: report at bugs.python.org (Wolfgang Scherer)
Date: Sun, 30 Dec 2012 17:12:53 +0000
Subject: [New-bugs-announce] [issue16820] configparser.ConfigParser.clean
	and .update bugs
Message-ID: <1356887573.11.0.450967441519.issue16820@psf.upfronthosting.co.za>


New submission from Wolfgang Scherer:

configparser.ConfigParser.clean() always fails:

    >>> cfg = configparser.ConfigParser()
    >>> if not hasattr(configparser.ConfigParser, 'clear'):
    ...     configparser.ConfigParser.clear = configparser_clear_compat
    >>> cfg.clear() #doctest: +ELLIPSIS
    Traceback (most recent call last):
    ...
    ValueError: Cannot remove the default section.

configparser.ConfigParser.update() overwrites all sections except DEFAULT instead of updating them.

See attached test file-

----------
components: Library (Lib)
files: bug_configparser.py
messages: 178588
nosy: wolfmanx
priority: normal
severity: normal
status: open
title: configparser.ConfigParser.clean and .update bugs
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file28493/bug_configparser.py

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

From report at bugs.python.org  Sun Dec 30 22:39:39 2012
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 30 Dec 2012 21:39:39 +0000
Subject: [New-bugs-announce] [issue16821] bundlebuilder broken in 2.7
Message-ID: <1356903579.79.0.644714985612.issue16821@psf.upfronthosting.co.za>


New submission from Barry Alan Scott:

bundlebuild in pytthon 2.7 fails to create usable applications.

After examining the code there are a number of coding errors:

1. optimize will puts the -O in the wrong place in the argv
2. Modules.zip is never added to the path

The bunderbuilder in 2.6 can be made to work with 2.7 by
applying the following patch to the 2.6 code.

--- bundlebuilder.py~   2012-12-30 21:32:40.000000000 +0000
+++ bundlebuilder.py    2012-12-30 21:32:40.000000000 +0000
@@ -337,7 +337,6 @@
     "Python",  # the Python core library
     "Resources/English.lproj",
     "Resources/Info.plist",
-    "Resources/version.plist",
 ]
 
 def isFramework():

----------
messages: 178616
nosy: barry-scott
priority: normal
severity: normal
status: open
title: bundlebuilder broken in 2.7
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Sun Dec 30 23:38:28 2012
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 30 Dec 2012 22:38:28 +0000
Subject: [New-bugs-announce] [issue16822] execv (et al.) should invoke
	atexit handlers before	executing new code
Message-ID: <1356907108.89.0.568486797575.issue16822@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

If I register an atexit handler, and then call os.execv, the handler is not invoked before my process changes over to the new program.  Shouldn't it be?  My program is ending, so my atexit handlers should be invoked.

This is based on this coverage.py bug:  https://bitbucket.org/ned/coveragepy/issue/43/coverage-measurement-fails-on-code  If the atexit handlers were invoked as part of os.execv, it would work properly.

----------
messages: 178623
nosy: nedbat
priority: normal
severity: normal
status: open
title: execv (et al.) should invoke atexit handlers before executing new code
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Dec 31 04:23:09 2012
From: report at bugs.python.org (Sarbjit singh)
Date: Mon, 31 Dec 2012 03:23:09 +0000
Subject: [New-bugs-announce] [issue16823] Python crashes on running tkinter
	code with threads
Message-ID: <1356924189.65.0.303016065786.issue16823@psf.upfronthosting.co.za>


New submission from Sarbjit singh:

I have written a python tkinter code using threads so as the tkinter wizard updates automatically by tkinter mainloop running in the main thread and background process running in separate thread. But I noticed, that python crashes after some time when running the code. Moreover its random in nature but python crashes most of the time. I have written a small test code which can show this problem (My original code is similar to this but having some real processes and many other features, so I am sharing the test code).

######################################################################
 # Test Code for Tkinter with threads
import Tkinter
import threading
import Queue
import time

# Data Generator which will generate Data
def GenerateData(q):
    for i in range(1000000):
        #print "Generating Some Data, Iteration %s" %(i)
        time.sleep(0.01)
        q.put("Some Data from iteration %s. Putting this data in the queue for testing" %(i))

# Queue which will be used for storing Data
q = Queue.Queue()

def QueueHandler(widinst, q):
    linecount = 0
    while True:
        print "Running"
        if not q.empty():
            str = q.get()
            linecount = linecount + 1
            widinst.configure(state="normal")
            str = str + "\n"
            widinst.insert("end", str)
            if linecount > 100:
                widinst.delete('1.0', '2.0')
                linecount = linecount - 1
            widinst.see('end')
            widinst.configure(state="disabled")

# Create a thread and run GUI & QueueHadnler in it
tk = Tkinter.Tk()
scrollbar = Tkinter.Scrollbar(tk)
scrollbar.pack(side='right', fill='y' )
text_wid = Tkinter.Text(tk,yscrollcommand=scrollbar.set)
text_wid.pack()
t1 = threading.Thread(target=GenerateData, args=(q,))
t2 = threading.Thread(target=QueueHandler, args=(text_wid,q))
t2.start()
t1.start()

tk.mainloop()
######################################################################


TO REPRODUCE:

If you open this code in IDLE and run it, it will sometimes appeared to be in hang state. So to reproduce, modify the sleep time to 0.1 from 0.01 and run it. After this stop the application, and modify it back to 0.01, do save and run it. This time it will run and after some time, python will stop working. I am using windows 7 (64 bit).

NOTE:

I am getting different stack trace's when it crashes on console:
Please refer to the attached file for the stack traces.

----------
components: Tkinter
files: debugstack.txt
messages: 178642
nosy: Sarbjit.singh
priority: normal
severity: normal
status: open
title: Python crashes on running tkinter code with threads
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file28503/debugstack.txt

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

From report at bugs.python.org  Mon Dec 31 09:26:55 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 31 Dec 2012 08:26:55 +0000
Subject: [New-bugs-announce] [issue16824] typo in test
Message-ID: <1356942415.38.0.154383781049.issue16824@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

Line 522 in test file Lib/test/test_pep380.py says:

                trace.append("Should not have yielded:", y)

However, 'trace' is a list and list.append() only takes one parameter, so this should read:

                trace.append("Should not have yielded: %r" % y)

I noticed it because Cython's type analysis refuses to compile this. This line is just a failure guard and is never reached in the normal test execution, that's why it doesn't show in CPython's test runs.

----------
components: Tests
messages: 178653
nosy: scoder
priority: normal
severity: normal
status: open
title: typo in test
type: compile error
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec 31 14:09:35 2012
From: report at bugs.python.org (Bernie Keimel)
Date: Mon, 31 Dec 2012 13:09:35 +0000
Subject: [New-bugs-announce] [issue16825] all OK!!!
Message-ID: <1356959375.36.0.223811420015.issue16825@psf.upfronthosting.co.za>


Changes by Bernie Keimel <unowned60 at gmail.com>:


----------
nosy: Bernie.Keimel
priority: normal
severity: normal
status: open
title: all OK!!!

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

From report at bugs.python.org  Mon Dec 31 15:34:51 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Dec 2012 14:34:51 +0000
Subject: [New-bugs-announce] [issue16826] Don't check for PYTHONCASEOK if
	interpreter started with	-E
Message-ID: <1356964491.55.0.198222992625.issue16826@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Importlib, when checking for PYTHONCASEOK, does not respect -E as it did in Python 3.2 and earlier (http://hg.python.org/cpython/file/0786dfc3b2b4/Python/import.c#l1933).

----------
components: Interpreter Core
keywords: 3.2regression
messages: 178679
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Don't check for PYTHONCASEOK if interpreter started with -E
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec 31 15:41:36 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 31 Dec 2012 14:41:36 +0000
Subject: [New-bugs-announce] [issue16827] Remove the relatively advanced
	content from section 2 in	tutorial
Message-ID: <1356964896.19.0.673901752517.issue16827@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

Most of the content in section 2 in the tutorial, http://docs.python.org/3/tutorial/interpreter.html , is relatively advanced and doesn't belong in, at least, the beginning of the tutorial.

Only 2.1. Invoking the Interpreter, and 2.2.3. Source Code Encoding should be in section 2. The rest can be moved outside the tutorial, or in later portions.

Thanks to Ezio Melotti for helping me overcome my laziness in filing this bug.

----------
assignee: docs at python
components: Documentation
messages: 178680
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: Remove the relatively advanced content from section 2 in tutorial

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

From report at bugs.python.org  Mon Dec 31 17:58:04 2012
From: report at bugs.python.org (Martin)
Date: Mon, 31 Dec 2012 16:58:04 +0000
Subject: [New-bugs-announce] [issue16828] bz2 error on compression of empty
	string
Message-ID: <1356973084.81.0.547571826956.issue16828@psf.upfronthosting.co.za>


New submission from Martin:

The fix from issue 14398 for >4GB inputs regressed the behaviour when compressing an empty string. Going by issue 853061 the expectation is this should work.

The problem was noticed when using the updated Python 2.7 package in Ubuntu Raring caused test failures in the Bazaar suite:

<https://bugs.launchpad.net/bzr/+bug/1090043>

----------
components: Extension Modules
messages: 178705
nosy: gz, nadeem.vawda
priority: normal
severity: normal
status: open
title: bz2 error on compression of empty string
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/issue16828>
_______________________________________

From report at bugs.python.org  Mon Dec 31 23:18:47 2012
From: report at bugs.python.org (Rod Nayfield)
Date: Mon, 31 Dec 2012 22:18:47 +0000
Subject: [New-bugs-announce] [issue16829] IDLE on Mac OSX can't print
	filenames with spaces
Message-ID: <1356992327.38.0.897045396627.issue16829@psf.upfronthosting.co.za>


New submission from Rod Nayfield:

Likely has the same issue on any platform which uses the same functionality (lpr filename to print).

----------
components: IDLE
messages: 178715
nosy: Rod.Nayfield
priority: normal
severity: normal
status: open
title: IDLE on Mac OSX can't print filenames with spaces
versions: Python 3.3

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