From report at bugs.python.org  Mon Oct  1 13:25:38 2012
From: report at bugs.python.org (Wael Al Jishi)
Date: Mon, 01 Oct 2012 11:25:38 +0000
Subject: [New-bugs-announce] [issue16097] Minor fix in comment in codecs.py
Message-ID: <1349090738.01.0.163694971359.issue16097@psf.upfronthosting.co.za>


New submission from Wael Al Jishi:

Minor fix to a comment in the read() function definition in codecs.py
Diff attached.

----------
components: None
files: comment-codecs-fix.patch
keywords: patch
messages: 171705
nosy: Wael.Al.Jishi
priority: normal
severity: normal
status: open
title: Minor fix in comment in codecs.py
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27371/comment-codecs-fix.patch

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

From report at bugs.python.org  Mon Oct  1 13:39:26 2012
From: report at bugs.python.org (Will Haldean Brown)
Date: Mon, 01 Oct 2012 11:39:26 +0000
Subject: [New-bugs-announce] [issue16098] Bisect optimization in
	heapq.nsmallest is never used
Message-ID: <1349091566.51.0.299551598321.issue16098@psf.upfronthosting.co.za>


New submission from Will Haldean Brown:

The implementation of nsmallest in heapq contains an optimization for when n is an order of magnitude less than the size of the data, which uses bisect to find the n-smallest elements. This optimization is guarded by a check to ensure that the data iterable has a length method.

This method is then decorated to add support for the key kwarg. The decorator creates a zip object and passes the zip object to the decorated nsmallest. As zip objects are generators, they do not have a __len__ attribute, and the bisect optimization is never used.

The attached patch file detects whether the data passed to the decorator has a length attribute, and if it does, it creates a list with the data before passing it to the decorated nsmallest. This is my first patch, so if I've done something wrong please let me know. Thanks!

----------
components: Library (Lib)
files: heapq-use-bisect.20121001.patch
keywords: patch
messages: 171706
nosy: haldean
priority: normal
severity: normal
status: open
title: Bisect optimization in heapq.nsmallest is never used
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file27372/heapq-use-bisect.20121001.patch

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

From report at bugs.python.org  Mon Oct  1 14:58:25 2012
From: report at bugs.python.org (Nikolay Bogoychev)
Date: Mon, 01 Oct 2012 12:58:25 +0000
Subject: [New-bugs-announce] [issue16099] robotparser doesn't support
	request rate and crawl delay	parameters
Message-ID: <1349096305.17.0.983395980337.issue16099@psf.upfronthosting.co.za>


New submission from Nikolay Bogoychev:

Robotparser doesn't support two quite important optional parameters from the robots.txt file. I have implemented those in the following way:
(Robotparser should be initialized in the usual way:
rp = robotparser.RobotFileParser()
rp.set_url(..)
rp.read
)

crawl_delay(useragent) - Returns time in seconds that you need to wait for crawling
if none is specified, or doesn't apply to this user agent, returns -1
request_rate(useragent) - Returns a list in the form [request,seconds].
if none is specified, or doesn't apply to this user agent, returns -1

----------
components: Library (Lib)
files: robotparser.patch
keywords: patch
messages: 171711
nosy: XapaJIaMnu
priority: normal
severity: normal
status: open
title: robotparser doesn't support request rate and crawl delay parameters
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file27373/robotparser.patch

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

From report at bugs.python.org  Mon Oct  1 16:45:58 2012
From: report at bugs.python.org (Sascha)
Date: Mon, 01 Oct 2012 14:45:58 +0000
Subject: [New-bugs-announce] [issue16100] Compiling vim with Python 3.3
	support fails
Message-ID: <1349102758.43.0.280298808198.issue16100@psf.upfronthosting.co.za>


New submission from Sascha:

Hello there,
I hope I'm right here.

I tried to compile vim with Python 3.3 32bit support.
OS: Windows 7 64bit
Compiler: MinGW
Compiling vim with Python 3.2 32bit support works!

The error message:
obj/if_python3.o:if_python3.c:(.text+0x739): undefined reference to `__imp__PyUnicode_AsUnicode'

----------
components: Windows
messages: 171722
nosy: v_core
priority: normal
severity: normal
status: open
title: Compiling vim with Python 3.3 support fails
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Mon Oct  1 18:47:08 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 01 Oct 2012 16:47:08 +0000
Subject: [New-bugs-announce] [issue16101] Verify all imported modules at
	startup are needed
Message-ID: <1349110028.76.0.413324569089.issue16101@psf.upfronthosting.co.za>


New submission from Brett Cannon:

It's probably time to examine what modules are imported at startup and whether they are necessary or if some can be trimmed off so as to avoid the overhead.

----------
messages: 171733
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Verify all imported modules at startup are needed
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct  1 19:33:29 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Oct 2012 17:33:29 +0000
Subject: [New-bugs-announce] [issue16102] uuid._netbios_getnode() is outdated
Message-ID: <1349112809.97.0.499056156586.issue16102@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Function uuid._netbios_getnode() in Lib/uuid.py is not properly ported from Python 2. At least it uses indexing on map result. Perhaps there are other errors. The function obviously not been tested for years.

----------
components: Library (Lib), Windows
messages: 171736
nosy: storchaka
priority: normal
severity: normal
status: open
title: uuid._netbios_getnode() is outdated
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Oct  1 22:01:13 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 01 Oct 2012 20:01:13 +0000
Subject: [New-bugs-announce] [issue16103] Help() fails at raw_input readline
	(IDLE 2.7.3, Win7, pythonw)
Message-ID: <1349121673.49.0.0542189425732.issue16103@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Problem is only 2.7.3 (not 3.2.3, 3.3.0), tested on Windows

Command Line Window
>>> help()
...
help> _

The _ is blinking, waiting for input.

IDLE Shell
>>> help()
...
help> 
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    help()
  File "C:\Programs\Python27\lib\site.py", line 467, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Programs\Python27\lib\pydoc.py", line 1750, in __call__
    self.interact()
  File "C:\Programs\Python27\lib\pydoc.py", line 1762, in interact
    request = self.getline('help> ')
  File "C:\Programs\Python27\lib\pydoc.py", line 1773, in getline
    return raw_input(prompt)
UnsupportedOperation: readline

There is no blinking _, at that is from the raw_input() call that failed. There is no problem with help() in IDLE for 3.2, 3.3.

I see two possibilities:
1. This has nothing to do with Idle directly, but is a problem with pythonw and raw_input/readline that was later fixed.
2. This is a result of how stdin is proxied by Idle and that there is a difference between 2.7 and 3.x.

builtin_raw_input in bltinmodule.c calls
  s = PyOS_Readline(PyFile_AsFile(fin), PyFile_AsFile(fout), prompt);
and I presume PyOS_Readline eventually calls fin.readline()

UnsupportedOperation is defined (in 2.7, at least) in _pyio.py
_pyio._unsupported(self, name) raises it with names.
That in turn is the default body for every operation. In particular,
    def readline(self):
        self._unsupported("readline")

So I presume 2. is the problem and the proxy in the pythonw process is an io subclass that needs readline defined for help() to work.
(Is proxying same on all OSes? Or would problem be Windows only?)

----------
components: IDLE, Windows
messages: 171743
nosy: serwy, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Help() fails at raw_input readline (IDLE 2.7.3, Win7, pythonw)
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Oct  1 22:46:54 2012
From: report at bugs.python.org (Daniel Holth)
Date: Mon, 01 Oct 2012 20:46:54 +0000
Subject: [New-bugs-announce] [issue16104] Use multiprocessing in compileall
	script
Message-ID: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za>


New submission from Daniel Holth:

compileall would benefit approximately linearly from additional CPU cores.  There should be an option.

The noisy output would have to change. Right now it prints "compiling" and then "done" synchronously with doing the actual work.

----------
messages: 171744
nosy: dholth
priority: normal
severity: normal
status: open
title: Use multiprocessing in compileall script

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

From report at bugs.python.org  Mon Oct  1 23:05:59 2012
From: report at bugs.python.org (Felipe Cruz)
Date: Mon, 01 Oct 2012 21:05:59 +0000
Subject: [New-bugs-announce] [issue16105] Pass read only FD to
	signal.set_wakeup_fd
Message-ID: <1349125559.77.0.651840030069.issue16105@psf.upfronthosting.co.za>


New submission from Felipe Cruz:

It's possible to set a read only FD to signal.set_wakeup_fd(fd)

Since write call[1] inside 'trip_signal' return code is ignored, no error will be raised.


An untested solution is to call fcntl in this FD to check presence of write flags.

1 - http://hg.python.org/cpython/file/fb90e2ff95b7/Modules/signalmodule.c#l187

----------
components: Library (Lib)
messages: 171745
nosy: felipecruz
priority: normal
severity: normal
status: open
title: Pass read only FD to signal.set_wakeup_fd
type: behavior
versions: Python 2.6, Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Oct  2 01:36:41 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Oct 2012 23:36:41 +0000
Subject: [New-bugs-announce] [issue16106] antigravity tests
Message-ID: <1349134601.26.0.544681268044.issue16106@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

The attached patch adds tests for antigravity.

----------
assignee: ezio.melotti
components: Library (Lib)
files: antigravity_tests.diff
keywords: patch
messages: 171762
nosy: ezio.melotti, michael.foord
priority: normal
severity: normal
stage: patch review
status: open
title: antigravity tests
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27379/antigravity_tests.diff

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

From report at bugs.python.org  Tue Oct  2 02:33:01 2012
From: report at bugs.python.org (Richard Jones)
Date: Tue, 02 Oct 2012 00:33:01 +0000
Subject: [New-bugs-announce] [issue16107] distutils2.version doesn't str()
	"1.0.post1" correctly
Message-ID: <1349137981.25.0.324290338592.issue16107@psf.upfronthosting.co.za>


New submission from Richard Jones:

The attached simple patch demonstrates the problem:

>>> str(NormalizedVersion('1.0.post1'))
'1.0.post1.z'

and includes a fix.

----------
assignee: eric.araujo
components: Distutils2
files: post-fix.patch
keywords: patch
messages: 171765
nosy: alexis, eric.araujo, richard, tarek
priority: normal
severity: normal
stage: patch review
status: open
title: distutils2.version doesn't str() "1.0.post1" correctly
type: behavior
Added file: http://bugs.python.org/file27381/post-fix.patch

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

From report at bugs.python.org  Tue Oct  2 07:04:00 2012
From: report at bugs.python.org (Richard Jones)
Date: Tue, 02 Oct 2012 05:04:00 +0000
Subject: [New-bugs-announce] [issue16108] Include maintainer information in
	register/upload
Message-ID: <1349154240.01.0.151032575778.issue16108@psf.upfronthosting.co.za>


New submission from Richard Jones:

The attached patch includes the maintainer information in the data sent to PyPI in a register or upload submission.

----------
assignee: eric.araujo
components: Distutils2
files: maintainer.patch
keywords: patch
messages: 171774
nosy: alexis, eric.araujo, richard, tarek
priority: normal
severity: normal
stage: patch review
status: open
title: Include maintainer information in register/upload
type: behavior
Added file: http://bugs.python.org/file27383/maintainer.patch

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

From report at bugs.python.org  Tue Oct  2 17:15:08 2012
From: report at bugs.python.org (Christian Fertig)
Date: Tue, 02 Oct 2012 15:15:08 +0000
Subject: [New-bugs-announce] [issue16109] urllib2.urlopen throws HTTP Error
	in python 2.7.2, 2.7.3, but not in python 2.7
Message-ID: <1349190908.23.0.357086619983.issue16109@psf.upfronthosting.co.za>


New submission from Christian Fertig:

wespe:/tmp/python2.7 # cat /etc/SuSE-release
openSUSE 12.1 (x86_64)
VERSION = 12.1
CODENAME = Asparagus
wespe:/tmp/python2.7 # rpm -q python
python-2.7.2-7.17.1.x86_64


wespe:/tmp/python2.7 # python
Python 2.7.2 (default, Aug 19 2011, 20:41:43) [GCC] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2; print urllib2.urlopen('https://172.23.6.222/') # not working
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "urllib2.py", line 397, in open
    response = meth(req, response)
  File "urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "urllib2.py", line 435, in error
    return self._call_chain(*args)
  File "urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "urllib2.py", line 518, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 405: Method Not Allowed

>>> import urllib; print urllib.urlopen('https://172.23.6.222/') # working
<addinfourl at 10613608 whose fp = <socket._fileobject object at 0x7f7c20a41d50>>


Other machine:

hornisse:/usr/lib64 # cat /etc/SuSE-release
openSUSE 11.4 (x86_64)
VERSION = 11.4
CODENAME = Celadon
hornisse:/usr/lib64 # rpm -q python
python-2.7-9.40.1.x86_64

hornisse:/usr/lib64 # python
Python 2.7 (r27:82500, Aug 07 2010, 16:54:59) [GCC] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2; print urllib2.urlopen('https://172.23.6.222/') # working
<addinfourl at 7832424 whose fp = <socket._fileobject object at 0x756a50>>
>>> import urllib; print urllib.urlopen('https://172.23.6.222/') # working
<addinfourl at 10130856 whose fp = <socket._fileobject object at 0x756850>>



Sometimes the HTTP Error is a 400 Bad Request, but 99% of the time a 405. I've testet openSuSE 12.2 with python 2.7.3 too, not working.

I don't know, what to provide more on information, please contact me, if you need more.

----------
messages: 171811
nosy: fertig
priority: normal
severity: normal
status: open
title: urllib2.urlopen throws HTTP Error in python 2.7.2, 2.7.3, but not in python 2.7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct  2 17:27:11 2012
From: report at bugs.python.org (thbach)
Date: Tue, 02 Oct 2012 15:27:11 +0000
Subject: [New-bugs-announce] [issue16110] Provide
	logging.config.configParserConfig
Message-ID: <1349191631.16.0.42047016451.issue16110@psf.upfronthosting.co.za>


New submission from thbach:

Currently logging.config provides a fileConfig function which reads a ini-style file via configparser.ConfigParser. I would like to have a function e.g. configParserConfig which accepts a ConfigParser instance and configures logging directly from the settings found in there. The main reasons for this are:

1) I think it is rather common for an application that provides an interface to configure its logging via an ini file to use this ini file also for further application configuration. With the current implementation the file is read twice and ConfigParser is initialized two times.

2) Currently it is not idiomatic how to alter an ini-file configuration e.g. by options passed in via command-line. The new function provides a clear solution: create a ConfigParser instance, parse the ini file, alter the configuration and pass it on to logging.config.configParserConfig.

In fact, the new functionality is easy to achieve by refactoring logging.config a bit (see attached patch).

----------
components: Library (Lib)
files: configParserConfig.patch
keywords: patch
messages: 171812
nosy: thbach
priority: normal
severity: normal
status: open
title: Provide logging.config.configParserConfig
Added file: http://bugs.python.org/file27386/configParserConfig.patch

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

From report at bugs.python.org  Tue Oct  2 20:16:20 2012
From: report at bugs.python.org (Ganesh R.)
Date: Tue, 02 Oct 2012 18:16:20 +0000
Subject: [New-bugs-announce] [issue16111] Python 2.7.3 Windows MSI installer
	installs the VC++ 9	dlls directly to WinSxS folder
Message-ID: <1349201780.49.0.563700308951.issue16111@psf.upfronthosting.co.za>


New submission from Ganesh R.:

Python 2.7.3 Windows MSI installer installs the VC++ 9 dlls directly to WinSxS folder. The recommended way to distribute VC++ dlls is to either install the VC++ Redistributable as a pre-requisite or just add the dll to local folder.

Directly installing the VC++ dlls to the WinSxS is not a recommended practice and can lead to problems.

I am not sure if it even checks if the dll is present in the WinSxS folder. 

The dll shipped with Python is the RTM version. SP1 and later many security fixes were released by Microsoft. But python has not upgraded the dll.

Also many machines have VC++ already installed and of higher version. So there is a manifest file that redirects all requests to a newer version. So adding an older file is futile.

----------
components: Installation
messages: 171820
nosy: freaksterrao
priority: normal
severity: normal
status: open
title: Python 2.7.3 Windows MSI installer installs the VC++ 9 dlls directly to WinSxS folder
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct  2 21:15:16 2012
From: report at bugs.python.org (David Benjamin)
Date: Tue, 02 Oct 2012 19:15:16 +0000
Subject: [New-bugs-announce] [issue16112] platform.architecture does not
	correctly escape argument	to /usr/bin/file
Message-ID: <1349205316.95.0.274773533894.issue16112@psf.upfronthosting.co.za>


New submission from David Benjamin:

The implementation of platform.architecture shells out to the file command. It tries to escape quotes by replacing " with \", but that's not sufficient.

$ python3.2 -c 'import platform; platform.architecture("foo\\\"; echo Hi there > /tmp/Z; echo \\\"")' && cat /tmp/Z
Hi there

Here's a patch to make it use subprocess instead. I haven't tested it thoroughly building everything from trunk and running tests, but I verified it works by replacing the platform.py in my system Python install.

----------
components: Library (Lib)
files: fix-platform-architecture.patch
keywords: patch
messages: 171825
nosy: David.Benjamin
priority: normal
severity: normal
status: open
title: platform.architecture does not correctly escape argument to /usr/bin/file
type: security
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/file27391/fix-platform-architecture.patch

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

From report at bugs.python.org  Wed Oct  3 05:10:04 2012
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 03 Oct 2012 03:10:04 +0000
Subject: [New-bugs-announce] [issue16113] Add SHA-3 (Keccak) support
Message-ID: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Today the latest crypto hash function was announced by NIST [1]. I suggest that we include the new hash algorithm in 3.4 once it lands in OpenSSL.

The Keccak site also has a reference implementation in C and Assembler [2]. It may take some effort to integrate the reference implementation as it contains several optimized backends for X86, X86_64, SIMD and various ARM platforms.

[1] http://www.nist.gov/itl/csd/sha-100212.cfm
[2] http://keccak.noekeon.org/

----------
components: Extension Modules
messages: 171848
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Add SHA-3 (Keccak) support
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct  3 06:16:47 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 03 Oct 2012 04:16:47 +0000
Subject: [New-bugs-announce] [issue16114] incorrect path in
	subprocess.Popen() FileNotFoundError	message
Message-ID: <1349237807.22.0.592724343556.issue16114@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The error message in the FileNotFoundError error raised by subprocess.Popen() displays the wrong path when the bad path is due to the executable argument rather than args.  The message gives the path for args[0] rather than for the executable argument.

For example, this--

import subprocess, sys
python_path = sys.executable
p = subprocess.Popen([python_path, "-c", "import sys; sys.exit(1)"])
p.wait()
p = subprocess.Popen([python_path, "-c", "import sys; sys.exit(1)"],
                     executable="foo")
p.wait()

gives--

Traceback (most recent call last):
  File "test-subprocess.py", line 6, in <module>
    executable="foo")
  File ".../Lib/subprocess.py", line 818, in __init__
    restore_signals, start_new_session)
  File ".../Lib/subprocess.py", line 1416, in _execute_child
    raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: '.../python.exe'

The path in the last line should read "foo" since '.../python.exe' is obviously found as evidenced from the previous Popen() invocation.

----------
components: Library (Lib)
messages: 171850
nosy: asvetlov, chris.jerdonek
priority: normal
severity: normal
stage: test needed
status: open
title: incorrect path in subprocess.Popen() FileNotFoundError message
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Oct  3 08:19:47 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 03 Oct 2012 06:19:47 +0000
Subject: [New-bugs-announce] [issue16115] test that executable arg to
	Popen() takes precedence	over args[0] arg
Message-ID: <1349245187.63.0.540491490276.issue16115@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The executable argument to Popen() takes precedence over args[0] when the executable argument is provided.  The test suite should include a test of this that runs on all systems.  The test suite does not currently include such a test.  This test is a precursor to more specific, platform-specific tests that will be added for issue 16114.

----------
assignee: chris.jerdonek
components: Library (Lib)
keywords: easy
messages: 171856
nosy: asvetlov, chris.jerdonek
priority: normal
severity: normal
stage: test needed
status: open
title: test that executable arg to Popen() takes precedence over args[0] arg
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Oct  3 11:09:08 2012
From: report at bugs.python.org (Masami HIRATA)
Date: Wed, 03 Oct 2012 09:09:08 +0000
Subject: [New-bugs-announce] [issue16116] Can not install C extension
	modules to inside a venv on	Python 3.3.0 for Win32
Message-ID: <1349255348.78.0.798397625136.issue16116@psf.upfronthosting.co.za>


New submission from Masami HIRATA:

I'm trying to install C extension modules inside a venv.
It works outside a venv and inside a virtualenv-1.8.2 but breaks inside the venv.

OS: Windows 7 Starter Edition SP1 (32-bit)
Python: 3.3.0 (python-3.3.0.msi)
Compiler: Microsoft Visual C++ 2010 Express SP1

----------
components: Library (Lib)
files: Python33_with_venv.txt
messages: 171875
nosy: msmhrt
priority: normal
severity: normal
status: open
title: Can not install C extension modules to inside a venv on Python 3.3.0 for Win32
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file27397/Python33_with_venv.txt

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

From report at bugs.python.org  Wed Oct  3 11:30:39 2012
From: report at bugs.python.org (Roland Lezuo)
Date: Wed, 03 Oct 2012 09:30:39 +0000
Subject: [New-bugs-announce] [issue16117] python2.7.3 struct misaligned when
	returned
Message-ID: <1349256639.78.0.287581020931.issue16117@psf.upfronthosting.co.za>


New submission from Roland Lezuo:

class Int(ctypes.Structure):
           _fields_ = [ ("_i", ctypes.c_uint64),
                                   ("undef", ctypes.c_bool)]

class Int {
        public:
                Int();
                Int(uint64_t i);

                uint64_t _i;
                bool undef;
};

extern "C" Int foo(const Int& a , const Int& b , const Int& c)
{
    ret = ...
    return Int(ret);
}

(gdb) p ret
$3 = 16
(gdb) fin
Run till exit from #0  BVSignExtend (a=..., b=..., c=...) at foo.hpp:130
0x00007ffff784eea4 in ffi_call_unix64 () from /usr/lib/python2.7/lib-dynload/_ctypes.so
Value returned is $4 = {_i = 18577824, undef = 16}

My guess: The value 18577824 was not expected to be on the stack.

The following actions "solve" the problem:

1) add another int the class Int (after bool) and adopt _fields_ accordingly.
2) in foo C++ function:
   Int reti = Int(ret);
   return reti;

Because of the "above" solutions I strongly suspect a bug in ctypes.

----------
components: ctypes
messages: 171876
nosy: iroli
priority: normal
severity: normal
status: open
title: python2.7.3 struct misaligned when returned
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct  3 13:22:29 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 03 Oct 2012 11:22:29 +0000
Subject: [New-bugs-announce] [issue16118] Implement SHA-3
Message-ID: <1349263349.35.0.658604929583.issue16118@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

We have a #sha3 winner!! Keccak - https://en.wikipedia.org/wiki/Keccak

----------
components: Extension Modules
messages: 171879
nosy: jcea
priority: normal
severity: normal
stage: needs patch
status: open
title: Implement SHA-3
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct  3 15:59:27 2012
From: report at bugs.python.org (Spiros K.)
Date: Wed, 03 Oct 2012 13:59:27 +0000
Subject: [New-bugs-announce] [issue16119] Python 2.7 IDLE not working in
	WinVista
Message-ID: <1349272767.13.0.710278986958.issue16119@psf.upfronthosting.co.za>


New submission from Spiros K.:

Hello.

I intalled EPD Free 7.3-2 WIN x86 a few hours ago and idle script doesn't work. When i try to run IDLE from cmd (c:\Python27\Lib\idlelib>idle.py) i take the following output:

Traceback (most recent call last):
  File "C:\Python27\Lib\idlelib\idle.py", line 10, in <module>
    import idlelib.PyShell
  File "C:\Python27\Lib\idlelib\PyShell.py", line 9, in <module>
    import socket
  File "C:\Python27\Lib\socket.py", line 47, in <module>
    import _socket
ImportError: DLL load failed: ??? ???? ?????? ?? ?????????? ? ??????????? ??????
.

My operating system is WinVista HomePremium SP2. Is there any way to solve this problem?

----------
components: IDLE
messages: 171884
nosy: sk7
priority: normal
severity: normal
status: open
title: Python 2.7 IDLE not working in WinVista
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct  3 18:18:18 2012
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 03 Oct 2012 16:18:18 +0000
Subject: [New-bugs-announce] [issue16120] Use |yield from| in stdlib
Message-ID: <1349281098.96.0.245155104268.issue16120@psf.upfronthosting.co.za>


New submission from Berker Peksag:

Related changesets:

- http://hg.python.org/cpython/rev/33a221662f39
- http://hg.python.org/cpython/rev/fb90e2ff95b7

----------
components: Library (Lib)
files: yield-from_v1.diff
keywords: patch
messages: 171894
nosy: berker.peksag
priority: normal
severity: normal
status: open
title: Use |yield from| in stdlib
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27403/yield-from_v1.diff

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

From report at bugs.python.org  Wed Oct  3 22:10:18 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 03 Oct 2012 20:10:18 +0000
Subject: [New-bugs-announce] [issue16121] shlex.shlex.error_leader() reports
	incorrect line number
Message-ID: <1349295018.27.0.805550020258.issue16121@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

shlex.shlex.error_leader() reports incorrect line number with posix=True or when last token is not quoted.
This bug occurs in all versions of Python.

The attached script shows this bug:
$ ./shlex_test.py
### text1 posix=False
('var1', '"None", line 1: ')
('=', '"None", line 1: ')
('"x"', '"None", line 1: ')
('var2', '"None", line 2: ')
('=', '"None", line 2: ')
('"y"', '"None", line 2: ')
('var3', '"None", line 3: ')
('=', '"None", line 3: ')
('"z"', '"None", line 3: ')
### text1 posix=True
('var1', '"None", line 1: ')
('=', '"None", line 1: ')
('x', '"None", line 2: ')
('var2', '"None", line 2: ')
('=', '"None", line 2: ')
('y', '"None", line 3: ')
('var3', '"None", line 3: ')
('=', '"None", line 3: ')
('z', '"None", line 3: ')
### text2 posix=False
('var1', '"None", line 1: ')
('=', '"None", line 1: ')
('x', '"None", line 2: ')
('var2', '"None", line 2: ')
('=', '"None", line 2: ')
('y', '"None", line 3: ')
('var3', '"None", line 3: ')
('=', '"None", line 3: ')
('z', '"None", line 3: ')
### text2 posix=True
('var1', '"None", line 1: ')
('=', '"None", line 1: ')
('x', '"None", line 2: ')
('var2', '"None", line 2: ')
('=', '"None", line 2: ')
('y', '"None", line 3: ')
('var3', '"None", line 3: ')
('=', '"None", line 3: ')
('z', '"None", line 3: ')
### text3 posix=False
('"x"', '"None", line 1: ')
('"y"', '"None", line 2: ')
('"z"', '"None", line 3: ')
### text3 posix=True
('x', '"None", line 2: ')
('y', '"None", line 3: ')
('z', '"None", line 3: ')
### text4 posix=False
('x', '"None", line 2: ')
('y', '"None", line 3: ')
('z', '"None", line 3: ')
### text4 posix=True
('x', '"None", line 2: ')
('y', '"None", line 3: ')
('z', '"None", line 3: ')

Only "text1 posix=False" and "text3 posix=False" have all correct line numbers.

----------
components: Library (Lib)
files: shlex_test.py
messages: 171905
nosy: Arfrever, zmedico
priority: normal
severity: normal
status: open
title: shlex.shlex.error_leader() reports incorrect line number
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27404/shlex_test.py

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

From report at bugs.python.org  Wed Oct  3 23:30:08 2012
From: report at bugs.python.org (samwyse)
Date: Wed, 03 Oct 2012 21:30:08 +0000
Subject: [New-bugs-announce] [issue16122] Allow *open* to accept file-like
	objects
Message-ID: <1349299808.15.0.576554890473.issue16122@psf.upfronthosting.co.za>


New submission from samwyse:

I'm once again frustrated by a third-party module that only accepts filenames, not already-opened file-like objects.  This prevents me from passing in StringIO objects or any of the standard file streams.  Currently, *open()* function accepts strings or (in Python 3.X) integers.  I propose that *open()* accept "file-like" objects, either returning them unchanged, or by returning a wrapper object.  While there are many different types of file-like objects, they all have one characteristic in common: the presence of a .close() method.

A non-wrapped version of open() could be as simple as this:

  try:
    file = original_open(name, mode, buffering)
  except TypeError:
    if hasattr(name, 'close'):
        return name
    raise

Returning a wrapper object would be slightly more complicated, but would allow the wrapped object to remain open even after the wrapper is closed.

----------
components: IO
messages: 171908
nosy: samwyse
priority: normal
severity: normal
status: open
title: Allow *open* to accept file-like objects
type: enhancement
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Thu Oct  4 00:13:49 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 03 Oct 2012 22:13:49 +0000
Subject: [New-bugs-announce] [issue16123] IDLE - deprecate running without a
	subprocess
Message-ID: <1349302429.82.0.0807471180715.issue16123@psf.upfronthosting.co.za>


New submission from Roger Serwy:

Removing the option of running IDLE without a subprocess would simplify the maintenance of IDLE. This should be deprecated for 3.4 and then fully removed in 3.5.

Here's a link to a brief discussion on IDLE-dev: http://mail.python.org/pipermail/idle-dev/2012-June/003124.html

Attached is an initial patch to issue a deprecation message.

----------
files: idle_deprecate.patch
keywords: patch
messages: 171911
nosy: ned.deily, serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - deprecate running without a subprocess
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file27405/idle_deprecate.patch

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

From report at bugs.python.org  Thu Oct  4 05:46:54 2012
From: report at bugs.python.org (Garrett Cooper)
Date: Thu, 04 Oct 2012 03:46:54 +0000
Subject: [New-bugs-announce] [issue16124] fcntl_ioctl still not 100% sane
	with unsigned longs
Message-ID: <1349322414.95.0.371484313067.issue16124@psf.upfronthosting.co.za>


New submission from Garrett Cooper:

As discussed in ID # 1471, the type for request is not 100% correct on some platforms (FreeBSD, NetBSD, and OpenBSD, for instance) and the custom platform that I'm using unfortunately uses non-32-bit int ioctls. An autoconf test needs to be added for these platforms and the request parameter needs to be handled properly (I'll take charge of doing that).

----------
components: Extension Modules
messages: 171918
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: fcntl_ioctl still not 100% sane with unsigned longs
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct  4 08:11:32 2012
From: report at bugs.python.org (Robert Xiao)
Date: Thu, 04 Oct 2012 06:11:32 +0000
Subject: [New-bugs-announce] [issue16125] open accepts arbitrary mode
	strings as long as they	contain U
Message-ID: <1349331092.45.0.724908738028.issue16125@psf.upfronthosting.co.za>


New submission from Robert Xiao:

This issue affects Python 2.5 through 2.7, but not Python 3.

open accepts basically anything for the second argument, so long as it either starts with r, w, or a, or contains U somewhere in the string. Therefore, the following are all legal in Python 2.7.3:

>>> open('/tmp/a', 'wail')
<open file '/tmp/a', mode 'wail' at 0x100468ed0>
>>> open('/tmp/a', 'PAIL')
<open file '/tmp/a', mode 'PAIL' at 0x100468270>
>>> open('/tmp/a', 'rabid')
<open file '/tmp/a', mode 'rabid' at 0x100468ed0>
>>> open('/tmp/a', 'alpha[]')
<open file '/tmp/a', mode 'alpha[]' at 0x100468270>
>>> open('/tmp/a', 'raw')
<open file '/tmp/a', mode 'raw' at 0x100468270>

Because the mode string is literally a copy of the passed-in mode, it is not clear at all what the mode of the file actually is. For example, in the last case, I cannot write to the file even though the mode contains 'w', because the mode is actually 'r'. 

I think there are two ways to fix this: either fix the whole mode parsing logic in Objects/fileobject.c to resemble that in Modules/_io/fileio.c from Python 3 (which does proper validation), or just build and store the calculated mode (e.g. "rb") so it's at least possible to determine the file mode.

----------
components: IO
messages: 171922
nosy: nneonneo
priority: normal
severity: normal
status: open
title: open accepts arbitrary mode strings as long as they contain U
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Oct  4 09:11:10 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Oct 2012 07:11:10 +0000
Subject: [New-bugs-announce] [issue16126] PyErr_Format format mismatch in
	_testcapimodule.c
Message-ID: <1349334670.64.0.839384857123.issue16126@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

PyErr_Format in Modules/_testcapimodule.c uses illegal format specifier (%s) for Py_ssize_t argument. It causes crash:

import _testcapi
_testcapi.parse_tuple_and_keywords( (), {}, b'', [42])

----------
components: Extension Modules, Tests
files: testcapi_error_format_mismatch.patch
keywords: 3.3regression, patch
messages: 171923
nosy: storchaka
priority: normal
severity: normal
status: open
title: PyErr_Format format mismatch in _testcapimodule.c
type: crash
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27409/testcapi_error_format_mismatch.patch

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

From report at bugs.python.org  Thu Oct  4 09:17:48 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Oct 2012 07:17:48 +0000
Subject: [New-bugs-announce] [issue16127] Correct mentions of narrow build
	in documentation and	comments
Message-ID: <1349335068.5.0.242255338591.issue16127@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In some places in the documentation and in the comments still left incorrect mention of the narrow build. Suggested patch fixes this.

----------
assignee: docs at python
components: Documentation, Unicode
files: doc_narrow_build.patch
keywords: patch
messages: 171924
nosy: docs at python, ezio.melotti, storchaka
priority: normal
severity: normal
status: open
title: Correct mentions of narrow build in documentation and comments
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27410/doc_narrow_build.patch

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

From report at bugs.python.org  Thu Oct  4 13:37:14 2012
From: report at bugs.python.org (Max)
Date: Thu, 04 Oct 2012 11:37:14 +0000
Subject: [New-bugs-announce] [issue16128] hashable documentation error
Message-ID: <1349350634.9.0.571993653286.issue16128@psf.upfronthosting.co.za>


New submission from Max:

http://docs.python.org/dev/glossary.html?highlight=hashable says:

Objects which are instances of user-defined classes are hashable by default; they all compare unequal, and their hash value is their id().

Since x == x returns True by default, so "they all compare unequal" isn't quite right.

In addition, both the above paragraph and http://docs.python.org/dev/reference/datamodel.html?highlight=__eq__#object.__hash__ say:

User-defined classes have __eq__() and __hash__() methods by default; with them, all objects compare unequal (except with themselves) and x.__hash__() returns an appropriate value such that x == y implies both that x is y and hash(x) == hash(y).

This is correct, but may leave some confusion with the reader about what happens to a subclass of a built-in class (which doesn't use the default behavior, but instead simply inherits the parent's __hash__ and __eq__).

----------
assignee: docs at python
components: Documentation
messages: 171935
nosy: docs at python, max
priority: normal
severity: normal
status: open
title: hashable documentation error
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Thu Oct  4 14:58:15 2012
From: report at bugs.python.org (Campbell Barton)
Date: Thu, 04 Oct 2012 12:58:15 +0000
Subject: [New-bugs-announce] [issue16129] No good way to set
	'PYTHONIOENCODING' when embedding	python.
Message-ID: <1349355495.01.0.406130423626.issue16129@psf.upfronthosting.co.za>


New submission from Campbell Barton:

note, I was asked to report this issue, posted on the py dev mailing list: see - http://code.activestate.com/lists/python-dev/118015/

---

We've run into an issue recently with blender3d on ms-windows where we
want to enforce the encoding is UTF-8 with the embedded python
interpreter.
(the encoding defaults to cp437).

I naively thought setting the environment variable before calling
Py_Initialize() would work, but the way python DLL loads, it gets its
own environment variables that cant be modified directly [1].
eg, _putenv("PYTHONIOENCODING=utf-8:surrogateescape");

We had bug reports by windows users not able to export files because
the stdout errors on printing paths with unsupported encoding. [2],[3]

---

Of course we could distribute blender with a bat file launcher that
sets env variables, or ask the user to set their env variable - but I
dont think this is really a good option.

I tried overriding the stderr & stdout, but this caused another bug on exiting, giving an assert in MSVCR90.DLL's write.c (called from python32_d.dll):
_VALIDATE_CLEAR_OSSERR_RETURN((_osfile(fh) & FOPEN), EBADF, -1);

import sys, io
sys.__stdout__ = sys.stdout =
io.TextIOWrapper(io.open(sys.stdout.fileno(), "wb", -1),
encoding='utf-8', errors='surrogateescape', newline="\n",
line_buffering=True)
sys.__stderr__ = sys.stderr =
io.TextIOWrapper(io.open(sys.stderr.fileno(), "wb", -1),
encoding='utf-8', errors='surrogateescape', newline="\n",
line_buffering=True)



IMHO either of these solutions would be fine.

* have a PyOS_PutEnv() function, gettext has gettext_putenv() to
workaround this problem.

* manage this the same as Py_GetPythonHome(), which can be defined by
the embedding application to override the default.


[1] http://stackoverflow.com/questions/5153547/environment-variables-are-different-for-dll-than-exe
[2] http://projects.blender.org/tracker/index.php?func=detail&aid=32750
[3] http://projects.blender.org/tracker/index.php?func=detail&aid=31555

----------
components: Windows
messages: 171938
nosy: ideasman42
priority: normal
severity: normal
status: open
title: No good way to set 'PYTHONIOENCODING' when embedding python.
versions: Python 3.4

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

From report at bugs.python.org  Thu Oct  4 16:09:13 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Thu, 04 Oct 2012 14:09:13 +0000
Subject: [New-bugs-announce] [issue16130] "Porting to Python 3.3" needs to
	be fixed in "What's new	In Python 3.4"
Message-ID: <1349359753.54.0.0183920912001.issue16130@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

"Porting to Python 3.3" should be "Porting to Python 3.4" in "What's new In Python 3.4" [0]

http://docs.python.org/dev/whatsnew/3.4.html#porting-to-python-3-3

----------
assignee: docs at python
components: Documentation
messages: 171951
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: "Porting to Python 3.3" needs to be fixed in "What's new In Python 3.4"
versions: Python 3.4

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

From report at bugs.python.org  Thu Oct  4 16:53:41 2012
From: report at bugs.python.org (Piotr Dobrogost)
Date: Thu, 04 Oct 2012 14:53:41 +0000
Subject: [New-bugs-announce] [issue16131] Pylauncher is being installed in
	Windows system folder
Message-ID: <1349362421.53.0.33140427567.issue16131@psf.upfronthosting.co.za>


New submission from Piotr Dobrogost:

Pylauncher in Python 3.3 is being installed in Windows system folder instead of Program Files folder. That's against platform rules. It should be installed in the same folder Python is installed or in its own folder under Program Files folder. In the former case this folder starting from Python 3.3 is added to PATH, in the latter case there should be an option in installer to add Pylauncher's folder to PATH.

See https://groups.google.com/forum/?hl=en&fromgroups=#!topic/comp.lang.python/-fCFFmpQ8aI

----------
components: Windows
messages: 171959
nosy: piotr.dobrogost
priority: normal
severity: normal
status: open
title: Pylauncher is being installed in Windows system folder
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Oct  4 17:35:06 2012
From: report at bugs.python.org (David Beazley)
Date: Thu, 04 Oct 2012 15:35:06 +0000
Subject: [New-bugs-announce] [issue16132] ctypes incorrectly encodes .format
	attribute of memory	views
Message-ID: <1349364906.03.0.586114989306.issue16132@psf.upfronthosting.co.za>


New submission from David Beazley:

This is somewhat related to an earlier bug report concerning memory views, but as far as I can tell, ctypes is not encoding the '.format' attribute correctly in most cases.   Consider this example:

First, create a ctypes array:

>>> a = (ctypes.c_double * 3)(1,2,3)
>>> len(a)
3
>>> a[0]
1.0
>>> a[1]
2.0
>>> 

Now, create a memory view for it:

>>> m = memoryview(a)
>>> len(m)
3
>>> m.itemsize
8
>>> m.ndim
1
>>> m.shape
(3,)
>>> 

All looks well.  However, if you try to do anything with the .format or access the items, it's completely broken:

>>> m.format
'(3)<d'
>>> m[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotImplementedError: memoryview: unsupported format (3)<d
>>> 

This is quite inconsistent with the behavior observed elsewhere. For example:

>>> import array
>>> b = array.array('d',[1,2,3])
>>> memoryview(b).format
'd'
>>> import numpy
>>> c = numpy.array([1,2,3],dtype='d')
>>> memoryview(c).format
'd'
>>> 

As you can see, array libraries are using .format to encode the format of a single array item.  ctypes is encoding the format of the entire array (all items).  ctypes also includes endianness which presents additional difficulties.

This behavior affects both Python code that wants to use memoryviews, but also C extension code that wants to use the underlying buffer protocol to work with arrays in a generic way. Essentially, it cuts the use of ctypes off entirely unless you modify the underlying buffer handling code to special case it. 

Suggested fix:  Have ctypes only encode the format for a single item in the case of arrays.  Also, for items that are encoded using the native byte ordering, don't include an endianness modifier ('<','>', etc.).  Including the byte order just complicates all of the handling code because it has to be modified to a) know what the native byte ordering is and b) to check multiple cases such as for "d" and "<d".

----------
messages: 171965
nosy: dabeaz
priority: normal
severity: normal
status: open
title: ctypes incorrectly encodes .format attribute of memory views
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Oct  4 18:06:32 2012
From: report at bugs.python.org (Nidan)
Date: Thu, 04 Oct 2012 16:06:32 +0000
Subject: [New-bugs-announce] [issue16133] asyncore.dispatcher.recv doesn't
	handle EAGAIN /	EWOULDBLOCK
Message-ID: <1349366792.42.0.417654527681.issue16133@psf.upfronthosting.co.za>


New submission from Nidan:

I recently had lots of the following exception:
error: uncaptured python exception, closing channel <servercore_persistent.ConnectionHandler connected 127.0.0.1:53609 at 0x8d27eec> (<class 'socket.error'>:[Errno 11] Resource temporarily unavailable [/usr/lib/python2.7/asynchat.py|handle_read|110] [/usr/lib/python2.7/asyncore.py|recv|384])

Error 11 is EAGAIN or EWOULDBLOCK, so asyncore/asynchat tries to read from a nonblocking socket which has no data available. Since this is a temporary error the socket shouldn't be closed.

The bug can be fixed by changing asyncore.dispatcher.recv to
    def recv(self, buffer_size):
        try:
            data = self.socket.recv(buffer_size)
            if not data:
                # a closed connection is indicated by signaling
                # a read condition, and having recv() return 0.
                self.handle_close()
                return ''
            else:
                return data
        except socket.error, why:
            # winsock sometimes throws ENOTCONN
            if why.args[0] in _DISCONNECTED:
                self.handle_close()
                return ''
            elif why.args[0] in (EAGAIN, EWOULDBLOCK):
                return ''
            else:
                raise

While looking at the source I also saw that asyncore.dispatcher.send and .connect check against EWOULDBLOCK but not against EAGAIN. Since both constants may have different values and POSIX allows to return either of them these functions should check against both error constants.

----------
components: Library (Lib)
messages: 171967
nosy: Nidan
priority: normal
severity: normal
status: open
title: asyncore.dispatcher.recv doesn't handle EAGAIN / EWOULDBLOCK
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Oct  4 20:39:21 2012
From: report at bugs.python.org (Jorge Gomes)
Date: Thu, 04 Oct 2012 18:39:21 +0000
Subject: [New-bugs-announce] [issue16134] Add support for RTMP schemes to
	urlparse
Message-ID: <1349375961.84.0.319840553089.issue16134@psf.upfronthosting.co.za>


New submission from Jorge Gomes:

Please add support in urlparse for the family of RTMP schemes:
rtmp
rtmpe
rtmps
rtmpt

I believe these schemes should be added to the following module variables:
uses_relative
uses_netloc
uses_params
uses_query
[essentially, the one where rtsp already is]

The RTMP spec is hosted at http://www.adobe.com/devnet/rtmp.html which describes the format as "protocol://servername:port/"
The example provided there is rtmp://localhost:1935/test

An example YouTube RTMP *service* URL looks like:
rtmp://a.rtmp.youtube.com/videolive?ns=yt-live&id=123456&itag=35&signature=blahblahblah

Please let me know if further information is required.

Thanks!

========================================
Footnote:

A full YouTube RTMP stream URL may look like this:

rtmp://a.rtmp.youtube.com/videolive?ns=yt-live&id=123456&itag=35&signature=blahblahblah/yt-live.123456.35

i.e. it is the stream service url suffixed with '/' + the_stream_name. 

When one uses urlparse (extended with the 'rtmp' scheme), the stream name part gets lumped in with the last query value.
I think it's reasonable to expect the user of the urlparse library to strip the stream name off, thus returning just the service URL, which can be parsed normally. However, if urlparse could handle this sort use-case generically, then that would be great.

----------
messages: 171984
nosy: Jorge.Gomes
priority: normal
severity: normal
status: open
title: Add support for RTMP schemes to urlparse
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/issue16134>
_______________________________________

From report at bugs.python.org  Fri Oct  5 00:20:07 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 04 Oct 2012 22:20:07 +0000
Subject: [New-bugs-announce] [issue16135] Removal of OS/2 support
Message-ID: <1349389207.71.0.143036356134.issue16135@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

According to PEP-11, We have to remove OS/2 support for 3.4.

----------
messages: 172000
nosy: jcea
priority: normal
severity: normal
status: open
title: Removal of OS/2 support
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct  5 00:21:03 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 04 Oct 2012 22:21:03 +0000
Subject: [New-bugs-announce] [issue16136] Removal of VMS support
Message-ID: <1349389263.57.0.925729224322.issue16136@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

According to PEP-11, we have to remove VMS support.

----------
messages: 172001
nosy: jcea
priority: normal
severity: normal
status: open
title: Removal of VMS support
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct  5 00:35:43 2012
From: report at bugs.python.org (Viktor Chynarov)
Date: Thu, 04 Oct 2012 22:35:43 +0000
Subject: [New-bugs-announce] [issue16137] Using time.asctime() with an array
	with negative tm_hour	causes Python Crash.
Message-ID: <1349390143.92.0.685174043431.issue16137@psf.upfronthosting.co.za>


New submission from Viktor Chynarov:

If a that has a negative tm_hour is passed as an argument to time.asctime(), Python crashes. 

>>> initial_struct_time = [tm for tm in time.localtime()]
>>> initial_struct_time[3] = -1
>>> faulty_time = time.asctime(initial_struct_time)

----------
components: Library (Lib)
messages: 172005
nosy: Viktor.Chynarov
priority: normal
severity: normal
status: open
title: Using time.asctime() with an array with negative tm_hour causes Python Crash.
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct  5 00:46:19 2012
From: report at bugs.python.org (py.user)
Date: Thu, 04 Oct 2012 22:46:19 +0000
Subject: [New-bugs-announce] [issue16138] In the glossary there is a small
	typo about __len__() in	the sequence definition
Message-ID: <1349390779.55.0.0497820141471.issue16138@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/py3k/glossary.html#term-sequence

"and defines a len() method that returns the length of the sequence" 

change to

"and defines a __len__() special method that returns the length of the sequence"

----------
assignee: docs at python
components: Documentation
messages: 172013
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In the glossary there is a small typo about __len__() in the sequence definition
versions: Python 3.3

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

From report at bugs.python.org  Fri Oct  5 01:53:00 2012
From: report at bugs.python.org (Andrew Gallagher)
Date: Thu, 04 Oct 2012 23:53:00 +0000
Subject: [New-bugs-announce] [issue16139] Python 3.3 fails when starting
	from read-only FS
Message-ID: <1349394780.28.0.923022645672.issue16139@psf.upfronthosting.co.za>


New submission from Andrew Gallagher:

This occurs when python is installed on a read-only mount AND all the .pyc files are out-of-date.  Therefore, when python starts and attempts to write a new .pyc file, _write_atomic in "Lib/importlib/_bootstrap.py" throws an OSError with an errno of EROFS, which is not handled (and ignored) and kills the interpreter.

$ python
Fatal Python error: Py_Initialize: Unable to get the locale encoding
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 1558, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1525, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 586, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1023, in load_module
  File "<frozen importlib._bootstrap>", line 1004, in load_module
  File "<frozen importlib._bootstrap>", line 562, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 854, in _load_module
  File "<frozen importlib._bootstrap>", line 990, in get_code
  File "<frozen importlib._bootstrap>", line 1051, in _cache_bytecode
  File "<frozen importlib._bootstrap>", line 1074, in set_data
  File "<frozen importlib._bootstrap>", line 128, in _write_atomic
OSError: [Errno 30] Read-only file system: '<read-only-mount-path>/lib/python3.3/encodings/__pycache__/__init__.cpython-33.pyc.139872939267056'
Aborted (core dumped)

The following (hacky) patch fixes the issue for me:

--- a/Python-3.3.0/Lib/importlib/_bootstrap.py
+++ b/Python-3.3.0/Lib/importlib/_bootstrap.py
@@ -1070,6 +1070,10 @@ class SourceFileLoader(FileLoader, SourceLoader):
                 # If can't get proper access, then just forget about writing
                 # the data.
                 return
+            except OSError as e:
+                if e.errno != 30:  # ignore EROFS
+                    raise
+                return
         try:
             _write_atomic(path, data, _mode)
             _verbose_message('created {!r}', path)
@@ -1077,6 +1081,9 @@ class SourceFileLoader(FileLoader, SourceLoader):
             # Don't worry if you can't write bytecode or someone is writing
             # it at the same time.
             pass
+        except OSError as e:
+            if e.errno != 30:  # ignore EROFS
+                raise

----------
components: Library (Lib)
messages: 172029
nosy: andrewjcg
priority: normal
severity: normal
status: open
title: Python 3.3 fails when starting from read-only FS
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Oct  5 08:59:21 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 05 Oct 2012 06:59:21 +0000
Subject: [New-bugs-announce] [issue16140] subprocess.Popen the os.close
	calls in _execute_child	can raise an EBADF exception
Message-ID: <1349420361.8.0.0219880030745.issue16140@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

Ben Leslie writes this on python-dev:

Hi all,

I have a Python program where I have many threads each calling Popen, and I was hitting some trouble.

I've been seeing this on 3.2.3, however I believe the same issue is still potentially a problem on head.

The error manifests itself when a call to os.close(errpipe_read) fails with EBADF (http://hg.python.org/releasing/3.2.3/file/86d1421a552c/Lib/subprocess.py#l1314)

I believe the root cause of this problem is due to a double close() on a different file descriptor (which is then reused as errpipe_read).

The file descriptors: p2cwrite, c2pread and errread are all closed at the end of the _execute_child method:

http://hg.python.org/releasing/3.2.3/file/86d1421a552c/Lib/subprocess.py#l1351

However, these filedescriptors are wrapped up into file objects during __init__ (see: http://hg.python.org/releasing/3.2.3/file/86d1421a552c/Lib/subprocess.py#l725)

As far as I can tell at the point where the garbage collector kicks in  Popen.{stdin,stdout,stderr} all go out of scope, and will be deallocated, and the underlying filedescriptor closed.

However because the filedescriptor is already closed, and by this time is actually reused, this deallocation closes what ends up being an incorrect file-descriptor.

Since closing a file object where the underlying fd is already closed is silenced (http://hg.python.org/releasing/3.2.3/file/86d1421a552c/Modules/_io/iobase.c#l235) this would not normally be very apparent.

This race between a new filedescriptor being allocated and the garbage collector deallocating the file descriptors certainly hits when using a few threads, but I guess depending on the exact behaviour of the garbage collector it could potentially also occur in a single threaded case as well.

I think a fix would be to remove the explicit close of these file descriptors at the end of _execute_child, and let the garbage collector close them. Of course that may leak file descriptors, if the GC doesn't kick in for a while, so the other option would be to close the file object, rather than just the file descriptor.

Hopefully someone more intimately familiar with the module can point me in the right direction to verify this, and provide a fix.

Thanks,

Benno

----------
assignee: gregory.p.smith
messages: 172053
nosy: gregory.p.smith
priority: high
severity: normal
stage: test needed
status: open
title: subprocess.Popen the os.close calls in _execute_child can raise an EBADF exception
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Oct  5 16:46:26 2012
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 05 Oct 2012 14:46:26 +0000
Subject: [New-bugs-announce] [issue16141] Possible simplification for
	logging.StreamHandler	exception handling
Message-ID: <1349448386.51.0.852233729423.issue16141@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

I just noticed that StreamHandler contains the following fragment in its emit() method:

  try:
    <do some writing>
  except (KeyboardInterrupt, SystemExit): #pragma: no cover                
    raise
  except:
    self.handleError(record)

Couldn't this be simplified to the following?

  try:
    <do some writing>
  except Exception:
    self.handleError(record)

I.e. instead of manually catching and re-raising a few BaseExceptions, just don't catch anything that derives from BaseException but not from Exception?

(I noticed because we have an internal clone of this class that occasionally gets augmented with yet another base exception that shouldn't be handled.

----------
components: Library (Lib)
messages: 172087
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Possible simplification for logging.StreamHandler exception handling
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct  5 16:53:21 2012
From: report at bugs.python.org (Idan Kamara)
Date: Fri, 05 Oct 2012 14:53:21 +0000
Subject: [New-bugs-announce] [issue16142] ArgumentParser inconsistent with
	parse_known_args
Message-ID: <1349448801.58.0.783623579173.issue16142@psf.upfronthosting.co.za>


New submission from Idan Kamara:

When known and unknown options are given together in the same option string (e.g. -xy) then ArgumentParser behaves in a strange way:

- if the known option is given first (so -k is known and the parser is fed with ['-ku']) then the parsing aborts with "error: argument -k/--known: ignored explicit argument 'u'"

- if the unknown option is given first then both options are treated as unknown and returned in the list of remaining arguments.

This makes it impossible to use parse_known_args for its intended purpose because every single letter option might be interleaved with other unknown options.

I attached a test script that demonstrates this.

----------
components: Library (Lib)
files: aparse.py
messages: 172088
nosy: idank
priority: normal
severity: normal
status: open
title: ArgumentParser inconsistent with parse_known_args
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file27434/aparse.py

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

From report at bugs.python.org  Fri Oct  5 18:45:16 2012
From: report at bugs.python.org (Gregory Andersen)
Date: Fri, 05 Oct 2012 16:45:16 +0000
Subject: [New-bugs-announce] [issue16143] Building with configure option
	"--without-doc-strings"	crashes first time through
	PyUnicode_DecodeUTF8Stateful
Message-ID: <1349455516.0.0.465126799391.issue16143@psf.upfronthosting.co.za>


New submission from Gregory Andersen:

Seems unicode_empty is still NULL at this point.

A gdb backtrace from an x86_64 build.  Reproduced on i686 and mips build as well.

Program received signal SIGSEGV, Segmentation fault.
0x000000000044f61e in PyUnicode_DecodeUTF8Stateful (s=0x59a767 "", size=0, errors=0x0, consumed=0x0) at Objects/unicodeobject.c:4726
4726	        Py_INCREF(unicode_empty);
(gdb) bt
#0  0x000000000044f61e in PyUnicode_DecodeUTF8Stateful (s=0x59a767 "", size=0, errors=0x0, consumed=0x0) at Objects/unicodeobject.c:4726
#1  0x0000000000433087 in PyType_Ready (type=0x7d5340) at Objects/typeobject.c:4235
#2  0x00000000004332ae in PyType_Ready (type=<optimized out>) at Objects/typeobject.c:4116
#3  PyType_Ready (type=0x7d54e0) at Objects/typeobject.c:4146
#4  0x000000000041bbfe in _Py_ReadyTypes () at Objects/object.c:1576
#5  0x00000000004a6eb0 in _Py_InitializeEx_Private (install_sigs=<optimized out>, install_importlib=<optimized out>) at Python/pythonrun.c:301
#6  Py_InitializeEx (install_sigs=<optimized out>) at Python/pythonrun.c:401
#7  Py_Initialize () at Python/pythonrun.c:407
#8  0x00000000004bb9fc in Py_Main (argc=1, argv=0x82f010) at Modules/main.c:646
#9  0x000000000041949e in main (argc=1, argv=0x7fffffffe658) at ./Modules/python.c:66

----------
components: Interpreter Core
messages: 172097
nosy: Gregory.Andersen
priority: normal
severity: normal
status: open
title: Building with configure option "--without-doc-strings" crashes first time through PyUnicode_DecodeUTF8Stateful
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Fri Oct  5 19:50:59 2012
From: report at bugs.python.org (=?utf-8?q?Manuel_P=C3=A9gouri=C3=A9-Gonnard?=)
Date: Fri, 05 Oct 2012 17:50:59 +0000
Subject: [New-bugs-announce] [issue16144] misleading sentence in
	reference/import
Message-ID: <1349459459.97.0.290795741864.issue16144@psf.upfronthosting.co.za>


New submission from Manuel P?gouri?-Gonnard:

I find the following sentences, from import.rst, section "Finders and loaders", misleading: "Python includes a number of default finders and importers. One knows how to locate frozen modules, and another knows how to locate built-in modules." in that one may think frozen comes before built-in, while the converse is true.

Attached is a patch with a hopefully clearer version. While at it, the patch also turns into links the references to PEPs in the introduction.

----------
assignee: docs at python
components: Documentation
files: import-doc-fixes.patch
keywords: patch
messages: 172105
nosy: docs at python, mpg
priority: normal
severity: normal
status: open
title: misleading sentence in reference/import
versions: Python 3.4
Added file: http://bugs.python.org/file27436/import-doc-fixes.patch

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

From report at bugs.python.org  Fri Oct  5 20:48:17 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 05 Oct 2012 18:48:17 +0000
Subject: [New-bugs-announce] [issue16145] Abort in _csv module
Message-ID: <1349462897.28.0.00319785734087.issue16145@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Commit f2adbb1065eb introduced abort in _csv module in debug builds in Python 3.3, when using APSW shell.

(You need to have SQLite >=3.7.14 installed.)

$ cd /tmp
$ wget http://apsw.googlecode.com/files/apsw-3.7.14-r2.zip
$ unzip apsw-3.7.14-r2.zip
$ cd apsw-3.7.14-r2
$ python3.3dm setup.py build
...
$ PYTHONPATH="$(ls -d build/lib*)" python3.3dm tools/shell.py
SQLite version 3.7.14.1 (APSW 3.7.14-r2)
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .output output_file
sqlite> .mode csv
sqlite> select "a";
python3.3dm: /tmp/cpython/Modules/_csv.c:1111: join_append: Assertion `(((PyASCIIObject*)field)->state.ready)' failed.
Aborted
$ 

In bash shell:
$ PYTHONPATH="$(ls -d build/lib*)" python3.3dm tools/shell.py <<< $'.output output_file\n.mode csv\nselect "a";'
python3.3dm: /tmp/cpython/Modules/_csv.c:1111: join_append: Assertion `(((PyASCIIObject*)field)->state.ready)' failed.
Aborted
$

----------
keywords: 3.3regression
messages: 172110
nosy: Arfrever, pitrou, rogerbinns
priority: normal
severity: normal
status: open
title: Abort in _csv module
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Oct  5 22:10:49 2012
From: report at bugs.python.org (yinian1992)
Date: Fri, 05 Oct 2012 20:10:49 +0000
Subject: [New-bugs-announce] [issue16146] MIMEApplication cannot access
Message-ID: <1349467849.56.0.764914408405.issue16146@psf.upfronthosting.co.za>


New submission from yinian1992:

I have a python 2.7.3 installation both on Debian 6 and Windows 7. And under both environment email.mime.application cannot access.

>>> email.mime.application
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'application'

It seems that the import list of email module's __init__.py doesn't include it.

----------
components: Library (Lib)
files: __init__.patch
keywords: patch
messages: 172126
nosy: yinian1992
priority: normal
severity: normal
status: open
title: MIMEApplication cannot access
versions: Python 2.7
Added file: http://bugs.python.org/file27439/__init__.patch

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

From report at bugs.python.org  Fri Oct  5 22:44:19 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Oct 2012 20:44:19 +0000
Subject: [New-bugs-announce] [issue16147] Rewrite PyUnicode_FromFormatV() to
	use the	_PyUnicodeWriter API
Message-ID: <1349469859.85.0.180138981213.issue16147@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch rewrites PyUnicode_FromFormatV():
 * simplify the code: replace 4 steps with one unique step. PyUnicode_Format() has the same design. It avoids to store intermediate results which require to allocate an array of pointers in the heap.
 * use the _PyUnicodeWriter API for speed (and its convinient API): overallocate the buffer to reduce the number of "realloc()"
 * Implement "width" and "precision" in Python, don't rely on sprintf(). It avoids to need of a temporary buffer allocated on the heap: only use a small buffer allocated in the stack.
 * Detect integer overflow when parsing width and precision, as done in PyUnicode_Format()
 * Add _PyUnicodeWriter_WriteCstr() function
 * Split PyUnicode_FromFormatV() into smaller functions: add unicode_fromformat_arg(). It requires to copy vargs using Py_VA_COPY: without Py_VA_COPY, the function does crash. I don't understand why.
 * Inline parse_format_flags(): the format of an argument is now only parsed once, it's no more needed to have a subfunction.
 * Optimize PyUnicode_FromFormatV() for characters between two arguments: search the next "%" and copy the substring in one chunk, instead of copying character per character.
 * Replace "prec too big" with "precision too big" in error messages

_tescapi.test_string_from_format() is 20% faster with the patch according to timeit. I don't know how to write better benchmarks because PyUnicode_FromV() is not exposed in Python. I wrote a benchmark using ctypes to call the function, but it looks like the ctypes overhead is too high.

I wrote the patch to simplify the code, but it may be faster thanks to the _PyUnicodeWriter API and some optimizations implemented in the patch.

----------
files: unicode_fromformat.patch
keywords: patch
messages: 172138
nosy: haypo
priority: normal
severity: normal
status: open
title: Rewrite PyUnicode_FromFormatV() to use the _PyUnicodeWriter API
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file27440/unicode_fromformat.patch

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

From report at bugs.python.org  Sat Oct  6 12:46:13 2012
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 06 Oct 2012 10:46:13 +0000
Subject: [New-bugs-announce] [issue16148] Implement PEP 424
Message-ID: <1349520373.44.0.657178870535.issue16148@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

The attached patch implements PEP 424. The implementation of this demonstrated a need for a few small modifications to the PEP, they will follow shortly.

----------
components: Interpreter Core
files: length_hint.diff
keywords: patch
messages: 172176
nosy: alex
priority: normal
severity: normal
status: open
title: Implement PEP 424
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27447/length_hint.diff

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

From report at bugs.python.org  Sat Oct  6 13:18:49 2012
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 06 Oct 2012 11:18:49 +0000
Subject: [New-bugs-announce] [issue16149] "Decimal(2) != float(2)"
	documentation bug
Message-ID: <1349522329.87.0.691698812157.issue16149@psf.upfronthosting.co.za>


New submission from Michele Orr?:

Follows from the discussion on python-dev:
http://mail.python.org/pipermail/python-dev/2012-September/121871.html

----------
assignee: docs at python
components: Documentation
messages: 172182
nosy: docs at python, maker, terry.reedy
priority: normal
severity: normal
status: open
title: "Decimal(2) != float(2)" documentation bug
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Oct  6 16:52:28 2012
From: report at bugs.python.org (pyos)
Date: Sat, 06 Oct 2012 14:52:28 +0000
Subject: [New-bugs-announce] [issue16150] Implement generator interface in
	itertools.chain.
Message-ID: <1349535148.95.0.484121382755.issue16150@psf.upfronthosting.co.za>


New submission from pyos:

Since "yield from" made it into Python 3.3, I think it would be useful to chain multiple generators and still get a generator, not an iterator. That is, the following code:

def f():
    yield from itertools.chain(A, B, C)

should be (at least roughly) equivalent to

def f():
    yield from A
    yield from B
    yield from C

while still allowing to send() values to whichever subgenerator is currently running or throw() exceptions inside them.

The attached patch adds this functionality to itertools.chain objects.

----------
components: Extension Modules
files: itertools-chain-send-throw-and-close.diff
keywords: patch
messages: 172204
nosy: pyos, rhettinger
priority: normal
severity: normal
status: open
title: Implement generator interface in itertools.chain.
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file27455/itertools-chain-send-throw-and-close.diff

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

From report at bugs.python.org  Sat Oct  6 21:32:42 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Oct 2012 19:32:42 +0000
Subject: [New-bugs-announce] [issue16151] Deferred KeyboardInterrupt in
	interactive mode
Message-ID: <1349551962.43.0.949416732292.issue16151@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here are some strange behavior I see (on Linux).

Run Python in interactive mode. Press <Tab><Tab>. Message "Display all XXX possibilities? (y or n)" showed. Press <Ctrl-C>, then <n>. Prompt showed. Enter any text (or none) and press <Enter>. KeyboardInterrupt exception raised.

In Python 2.7:
Traceback (most recent call last):
  File "/usr/lib/python2.7/encodings/utf_8.py", line 15, in decode
    def decode(input, errors='strict'):
KeyboardInterrupt

In Python 3.x:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyboardInterrupt

In Python 2.6 exception not raised.

It does not lead to any detrimental consequences (entered text saved in history and can be restored), but it looks very strange. Possibly for this must be some bug.

----------
components: Interpreter Core
messages: 172238
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Deferred KeyboardInterrupt in interactive mode
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/issue16151>
_______________________________________

From report at bugs.python.org  Sat Oct  6 23:09:21 2012
From: report at bugs.python.org (Ned Batchelder)
Date: Sat, 06 Oct 2012 21:09:21 +0000
Subject: [New-bugs-announce] [issue16152] Trailing whitespace makes
	tokenize.generate_tokens	pathological
Message-ID: <1349557761.41.0.537472367724.issue16152@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

When tokenizing with tokenize.generate_tokens, if the code ends with whitespace (no newline), the tokenizer produces an ERRORTOKEN for each space.  Additionally, the regex that fails to find tokens in those spaces is linear in the number of spaces, so the overall performance is O(n**2).

I found this while tokenizing code samples uploaded to a public web site.  One sample for some reason ended with 40,000 spaces, which was taking two hours to tokenize.

Demonstration:

{{{
import token
import tokenize

try:
    from cStringIO import StringIO
except:
    from io import StringIO

code = "@"+" "*10000
code_reader = StringIO(code).readline

for num, (ttyp, ttok, _, _, _) in enumerate(tokenize.generate_tokens(code_reader)):
    print("%5d %15s %r" % (num, token.tok_name[ttyp], ttok))
}}}

----------
components: Library (Lib)
messages: 172244
nosy: nedbat
priority: normal
severity: normal
stage: patch review
status: open
title: Trailing whitespace makes tokenize.generate_tokens pathological
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Oct  6 23:56:21 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Oct 2012 21:56:21 +0000
Subject: [New-bugs-announce] [issue16153] PyUnicode_FromFormatV() must fail
	if the format string	is invalid
Message-ID: <1349560581.01.0.621984773801.issue16153@psf.upfronthosting.co.za>


New submission from STINNER Victor:

If the format string is invalid, PyUnicode_FromFormatV() formats the valid arguments and then copies the raw format string. Errors are silently ignored.

I propose to raise a ValueError if the format string is invalid. This change may "break" existing applications, but I hope that nobody relies on this "bug" :-)

Attached patch implements my proposition.

----------
files: invalid_format.patch
keywords: patch
messages: 172250
nosy: haypo
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormatV() must fail if the format string is invalid
versions: Python 3.4
Added file: http://bugs.python.org/file27461/invalid_format.patch

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

From report at bugs.python.org  Sun Oct  7 00:25:25 2012
From: report at bugs.python.org (Ravi Sinha)
Date: Sat, 06 Oct 2012 22:25:25 +0000
Subject: [New-bugs-announce] [issue16154] Some minor doc fixes in Doc/library
Message-ID: <1349562325.82.0.0767622542031.issue16154@psf.upfronthosting.co.za>


New submission from Ravi Sinha:

- Doc/library/math.rst - fsum will pass if 'from math import fsum' is done before it, but I've left such issues for now since there seems to be a debate about how to go about that
        - some seem unfixable too - e.g. Doc/library/filecmp.rst - 'dir1' and 'dir2' do not exist, and so the print_diff_files() fails, but there seems to be no reason to fix this; the same for Doc/library/imghdr.rst - there is no /tmp/bass.gif, so it fails
        - some fail for inexplicable reasons - Doc/library/string.rst - the table of numbers does not match, though it is exactly the same. No idea why.

----------
assignee: docs at python
components: Documentation
files: doc_lib.patch
keywords: patch
messages: 172253
nosy: Ravi.Sinha, chris.jerdonek, docs at python, r.david.murray, terry.reedy
priority: normal
severity: normal
status: open
title: Some minor doc fixes in Doc/library
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27462/doc_lib.patch

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

From report at bugs.python.org  Sun Oct  7 00:29:12 2012
From: report at bugs.python.org (Ravi Sinha)
Date: Sat, 06 Oct 2012 22:29:12 +0000
Subject: [New-bugs-announce] [issue16155] Some minor doc fixes in Doc/faq
Message-ID: <1349562552.07.0.641735051076.issue16155@psf.upfronthosting.co.za>


New submission from Ravi Sinha:

- help(fn) which in the REPL leads to a new pager/ display - seems to be difficult to test with doctest - it does not seem to pick the whitespace in the docs and does not match - Doc/faq/general.rst
        - os.path.isdir returns True or False, not 0 or 1 as in the docs, but I didn't know if I should change that - Doc/faq/windows.rst

----------
assignee: docs at python
components: Documentation
files: doc_faq.patch
keywords: patch
messages: 172254
nosy: Ravi.Sinha, chris.jerdonek, docs at python, r.david.murray, terry.reedy
priority: normal
severity: normal
status: open
title: Some minor doc fixes in Doc/faq
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27463/doc_faq.patch

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

From report at bugs.python.org  Sun Oct  7 02:00:47 2012
From: report at bugs.python.org (Raymond Costantini)
Date: Sun, 07 Oct 2012 00:00:47 +0000
Subject: [New-bugs-announce] [issue16156] Crash every time I copy or paste
	any code in IDLE
Message-ID: <1349568047.3.0.403538451245.issue16156@psf.upfronthosting.co.za>


New submission from Raymond Costantini:

Process:         Python [20738]
Path:            /Applications/Python 3.2/IDLE.app/Contents/MacOS/Python
Identifier:      org.python.IDLE
Version:         3.2.3 (3.2.3)
Code Type:       X86-64 (Native)
Parent Process:  launchd [239]
User ID:         501

Date/Time:       2012-10-06 16:56:07.254 -0700
OS Version:      Mac OS X 10.8.2 (12C60)
Report Version:  10

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

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   Tk                            	0x000000010138a12a TkpMakeWindow + 306
1   Tk                            	0x000000010130482f Tk_MakeWindowExist + 130
2   Tk                            	0x00000001012e2ed9 TkClipInit + 129
3   Tk                            	0x00000001012e2f77 Tk_ClipboardClear + 43
4   Tk                            	0x00000001012e35fe Tk_ClipboardObjCmd + 996
5   Tcl                           	0x00000001011dd8ad TclEvalObjvInternal + 782
6   Tcl                           	0x0000000101216e51 TclExecuteByteCode + 4488
7   Tcl                           	0x0000000101250c16 TclObjInterpProcCore + 1001
8   Tcl                           	0x00000001011dd8ad TclEvalObjvInternal + 782
9   Tcl                           	0x00000001011de4bf TclEvalEx + 2183
10  Tcl                           	0x00000001011de88f Tcl_EvalEx + 26
11  Tk                            	0x00000001012e1c7d Tk_BindEvent + 4994
12  Tk                            	0x00000001012e4eac TkBindEventProc + 342
13  Tk                            	0x00000001012eb7bb Tk_HandleEvent + 1431
14  Tk                            	0x00000001012e01b8 Tk_EventObjCmd + 4666
15  Tcl                           	0x00000001011dd8ad TclEvalObjvInternal + 782
16  Tcl                           	0x00000001011dea9f Tcl_EvalObjv + 66
17  _tkinter.so                   	0x00000001011c268e Tkapp_Call + 190
18  org.python.python             	0x00000001000b4034 PyEval_EvalFrameEx + 29204
19  org.python.python             	0x00000001000b4ffa PyEval_EvalCodeEx + 1770
20  org.python.python             	0x00000001000b4167 PyEval_EvalFrameEx + 29511
21  org.python.python             	0x00000001000b4321 PyEval_EvalFrameEx + 29953
22  org.python.python             	0x00000001000b4ffa PyEval_EvalCodeEx + 1770
23  org.python.python             	0x0000000100039d0a function_call + 186
24  org.python.python             	0x000000010000c828 PyObject_Call + 104
25  org.python.python             	0x00000001000af2ae PyEval_EvalFrameEx + 9358
26  org.python.python             	0x00000001000b4ffa PyEval_EvalCodeEx + 1770
27  org.python.python             	0x0000000100039d0a function_call + 186
28  org.python.python             	0x000000010000c828 PyObject_Call + 104
29  org.python.python             	0x00000001000261aa method_call + 138
30  org.python.python             	0x000000010000c828 PyObject_Call + 104
31  org.python.python             	0x00000001000ab5e7 PyEval_CallObjectWithKeywords + 87
32  _tkinter.so                   	0x00000001011c09c8 PythonCmd + 456
33  Tcl                           	0x00000001011da53b TclInvokeStringCommand + 105
34  Tcl                           	0x00000001011dd8ad TclEvalObjvInternal + 782
35  Tcl                           	0x0000000101216e51 TclExecuteByteCode + 4488
36  Tcl                           	0x000000010121de3b Tcl_ExprObj + 705
37  Tcl                           	0x00000001011da159 Tcl_ExprBooleanObj + 35
38  Tcl                           	0x00000001011ea61f Tcl_IfObjCmd + 123
39  Tcl                           	0x00000001011dd8ad TclEvalObjvInternal + 782
40  Tcl                           	0x00000001011de4bf TclEvalEx + 2183
41  Tcl                           	0x00000001011de88f Tcl_EvalEx + 26
42  Tk                            	0x00000001012e1c7d Tk_BindEvent + 4994
43  Tk                            	0x00000001012e4eac TkBindEventProc + 342
44  Tk                            	0x00000001012eb7bb Tk_HandleEvent + 1431
45  Tk                            	0x00000001012eb88c WindowEventProc + 92
46  Tcl                           	0x000000010124312f Tcl_ServiceEvent + 147
47  Tcl                           	0x000000010124329f Tcl_ServiceAll + 163
48  Tcl                           	0x0000000101276ace UpdateWaitingListAndServiceEvents + 255
49  com.apple.CoreFoundation      	0x00007fff8f0b89b7 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
50  com.apple.CoreFoundation      	0x00007fff8f0b8921 __CFRunLoopDoObservers + 369
51  com.apple.CoreFoundation      	0x00007fff8f093e51 __CFRunLoopRun + 929
52  com.apple.CoreFoundation      	0x00007fff8f0936b2 CFRunLoopRunSpecific + 290
53  com.apple.AppKit              	0x00007fff98e9d32c -[NSCarbonMenuImpl performMenuAction:withTarget:] + 269
54  com.apple.AppKit              	0x00007fff98e2120d -[NSMenu _performKeyEquivalentWithDelegate:] + 634
55  com.apple.AppKit              	0x00007fff98e21190 -[NSMenu _performKeyEquivalentWithDelegate:] + 509
56  com.apple.AppKit              	0x00007fff98e20cf7 -[NSMenu performKeyEquivalent:] + 70
57  com.apple.AppKit              	0x00007fff98e20283 -[NSApplication _handleKeyEquivalent:] + 829
58  com.apple.AppKit              	0x00007fff98cdd243 -[NSApplication sendEvent:] + 4480
59  Tk                            	0x000000010139567f -[TKApplication(TKNotify) sendEvent:] + 122
60  Tk                            	0x0000000101395a12 TkMacOSXEventsCheckProc + 411
61  Tcl                           	0x0000000101243412 Tcl_DoOneEvent + 297
62  _tkinter.so                   	0x00000001011bff71 Tkapp_MainLoop + 177
63  org.python.python             	0x00000001000b4034 PyEval_EvalFrameEx + 29204
64  org.python.python             	0x00000001000b4ffa PyEval_EvalCodeEx + 1770
65  org.python.python             	0x00000001000b4167 PyEval_EvalFrameEx + 29511
66  org.python.python             	0x00000001000b4321 PyEval_EvalFrameEx + 29953
67  org.python.python             	0x00000001000b4ffa PyEval_EvalCodeEx + 1770
68  org.python.python             	0x00000001000b530f PyEval_EvalCode + 63
69  org.python.python             	0x00000001000dc6ab PyRun_FileExFlags + 187
70  org.python.python             	0x00000001000dc979 PyRun_SimpleFileExFlags + 521
71  org.python.python             	0x00000001000f1e65 Py_Main + 3237
72  Python                        	0x0000000100000e0b 0x100000000 + 3595
73  Python                        	0x0000000100000c94 0x100000000 + 3220

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib        	0x00007fff90883d16 kevent + 10
1   libdispatch.dylib             	0x00007fff8f755dea _dispatch_mgr_invoke + 883
2   libdispatch.dylib             	0x00007fff8f7559ee _dispatch_mgr_thread + 54

Thread 2:
0   libsystem_kernel.dylib        	0x00007fff908836d6 __workq_kernreturn + 10
1   libsystem_c.dylib             	0x00007fff8fb1feec _pthread_workq_return + 25
2   libsystem_c.dylib             	0x00007fff8fb1fcb3 _pthread_wqthread + 412
3   libsystem_c.dylib             	0x00007fff8fb0a171 start_wqthread + 13

Thread 3:
0   libsystem_kernel.dylib        	0x00007fff90883322 __select + 10
1   Tcl                           	0x0000000101276d1e NotifierThreadProc + 558
2   libsystem_c.dylib             	0x00007fff8fb1d742 _pthread_start + 327
3   libsystem_c.dylib             	0x00007fff8fb0a181 thread_start + 13

Thread 4:
0   libsystem_kernel.dylib        	0x00007fff908836d6 __workq_kernreturn + 10
1   libsystem_c.dylib             	0x00007fff8fb1feec _pthread_workq_return + 25
2   libsystem_c.dylib             	0x00007fff8fb1fcb3 _pthread_wqthread + 412
3   libsystem_c.dylib             	0x00007fff8fb0a171 start_wqthread + 13

Thread 5:
0   libsystem_kernel.dylib        	0x00007fff908836d6 __workq_kernreturn + 10
1   libsystem_c.dylib             	0x00007fff8fb1feec _pthread_workq_return + 25
2   libsystem_c.dylib             	0x00007fff8fb1fcb3 _pthread_wqthread + 412
3   libsystem_c.dylib             	0x00007fff8fb0a171 start_wqthread + 13

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0072006f005f0074  rbx: 0x0000000101ba5e10  rcx: 0x0000000101ba5e00  rdx: 0x0000000000000000
  rdi: 0x0000000000000000  rsi: 0x0000000101ba5e18  rbp: 0x00007fff5fbf9650  rsp: 0x00007fff5fbf9630
   r8: 0x0000000000002060   r9: 0x00007fff5fbf9680  r10: 0x0000000000000004  r11: 0x0000000000001000
  r12: 0x0000000101ba6a10  r13: 0x0000000101ba5e10  r14: 0xffffffffffffffff  r15: 0x00000001018a2410
  rip: 0x000000010138a12a  rfl: 0x0000000000010246  cr2: 0x0000000100c1c490
Logical CPU: 1

Binary Images:
       0x100000000 -        0x100000ff7 +Python (???) <1768148D-C54D-CDEA-E308-66DD6F981E49> /Applications/Python 3.2/IDLE.app/Contents/MacOS/Python
       0x100003000 -        0x100184ff7 +org.python.python (3.2.3, [c] 2004-2012 Python Software Foundation. - 3.2.3) <C51CBDD9-D8AA-2CF6-8C0F-B3138193D6D0> /Library/Frameworks/Python.framework/Versions/3.2/Python
       0x100570000 -        0x100570fff +_bisect.so (???) <78CC2A47-24FF-F895-B747-95A8E082C933> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_bisect.so
       0x1005a1000 -        0x1005a2ff7 +_heapq.so (???) <9E377F57-15D4-FA5A-C33F-79EE16CEFFAE> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_heapq.so
       0x1005e6000 -        0x1005eefff +_socket.so (???) <139F676E-9155-AFC9-1AD3-A782BEAC8C6B> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_socket.so
       0x1005f8000 -        0x1005fafff +time.so (???) <FEFA964F-DEA4-AB47-3CDC-60ADC96AF0DF> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/time.so
       0x1007c0000 -        0x1007c3fff +select.so (???) <A93F61B7-A7BA-5EB0-A30C-BA764CD83797> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/select.so
       0x1007c9000 -        0x1007caff7 +fcntl.so (???) <56137A5B-9D40-321A-EA04-BA3BC276F687> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/fcntl.so
       0x1007cd000 -        0x1007d1fff +_struct.so (???) <4146D1DF-404C-17A5-91BD-4D0EA49CA1A9> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_struct.so
       0x1007d8000 -        0x1007e7fff +_pickle.so (???) <201C5209-AB7F-A512-307F-8D2F0B5BA7A9> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_pickle.so
       0x1007f1000 -        0x1007f2ff7 +_posixsubprocess.so (???) <D3BCDF7D-3760-8332-D574-6C385D481588> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_posixsubprocess.so
       0x1007f9000 -        0x1007fbff7 +_hashlib.so (???) <BA8F08DF-300B-1A18-AEE9-0FE0160ABF6E> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_hashlib.so
       0x1011bd000 -        0x1011c4ff7 +_tkinter.so (???) <885013A0-8BE8-E15A-1150-94172642D585> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_tkinter.so
       0x1011cd000 -        0x1012aafe7 +Tcl (8.5.12 - 8.5.12) <BEEA747D-37D2-E8A1-3F8A-89BFC1087A1E> /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
       0x1012d6000 -        0x1013e4fef +Tk (8.5.12 - 8.5.12) <C6928E4B-8867-75D8-9E7C-2DF562FB6244> /Library/Frameworks/Tk.framework/Versions/8.5/Tk
       0x1014fc000 -        0x1014fdff7 +_random.so (???) <D676ED48-1790-C021-514E-A29775BF5CB0> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_random.so
       0x1017c3000 -        0x1017c8fe7 +math.so (???) <5EE93FAE-A0BF-5D9D-7B68-F1BA2D893EAC> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/math.so
       0x1020c3000 -        0x1020c9fe7 +array.so (???) <93D44AE8-82E4-1541-2172-0ECB419847E6> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/array.so
       0x1020ec000 -        0x1020f5fe7  libcldcpuengine.dylib (2.1.19) <50800DA2-7233-32E5-9553-A02171B68399> /System/Library/Frameworks/OpenCL.framework/Libraries/libcldcpuengine.dylib
       0x1020fd000 -        0x1020fdff3 +cl_kernels (???) <AC28CA1E-7A21-49B5-BD70-ECAFC90CA95E> cl_kernels
       0x1025f2000 -        0x1025f5ff7  libCoreFSCache.dylib (24.4) <C375CAA0-F91F-3D9F-AF90-DB951BD86983> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib
       0x104efa000 -        0x104f95fef +unicodedata.so (???) <001D04E6-0D6B-34D3-1DD9-A33C55E86885> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/unicodedata.so
       0x106900000 -        0x10699bff7  unorm8_bgra.dylib (2.1.19) <904EA51D-225A-38AF-B66C-84493C55C065> /System/Library/Frameworks/OpenCL.framework/Libraries/ImageFormats/unorm8_bgra.dylib
    0x7fff6e242000 -     0x7fff6e27693f  dyld (210.2.3) <A40597AA-5529-3337-8C09-D8A014EB1578> /usr/lib/dyld
    0x7fff8dfd7000 -     0x7fff8dfeefff  com.apple.GenerationalStorage (1.1 - 132.2) <3F5C87BD-D866-3732-8CB9-D23ED9784D6E> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage
    0x7fff8dfef000 -     0x7fff8dff3fff  com.apple.IOSurface (86.0.3 - 86.0.3) <C121DE83-ED12-3DC1-BDB3-4FCB29AB0571> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
    0x7fff8dff4000 -     0x7fff8e014fff  libPng.dylib (845) <C3CDD2B4-3CB0-3F6D-8411-DAAF267E952B> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
    0x7fff8e015000 -     0x7fff8e0daff7  com.apple.coreui (2.0 - 181.1) <83D2C92D-6842-3C9D-9289-39D5B4554C3A> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
    0x7fff8e123000 -     0x7fff8e358ff7  com.apple.CoreData (106.1 - 407.7) <24E0A6B4-9ECA-3D12-B26A-72B9DCF09768> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
    0x7fff8e359000 -     0x7fff8e35aff7  libsystem_sandbox.dylib (220) <3C3B03CF-C525-3CB3-8557-62E91B93AC95> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff8e35b000 -     0x7fff8e35bffd  com.apple.audio.units.AudioUnit (1.8 - 1.8) <29E2C990-3617-3FA2-BDD7-DB7DF493E443> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
    0x7fff8e43b000 -     0x7fff8e442fff  libcopyfile.dylib (89) <876573D0-E907-3566-A108-577EAD1B6182> /usr/lib/system/libcopyfile.dylib
    0x7fff8e443000 -     0x7fff8e443fff  com.apple.Cocoa (6.7 - 19) <1F77945C-F37A-3171-B22E-F7AB0FCBB4D4> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
    0x7fff8e444000 -     0x7fff8e47afff  com.apple.DebugSymbols (98 - 98) <14E788B1-4EB2-3FD7-934B-849534DFC198> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
    0x7fff8e4bf000 -     0x7fff8e4c3fff  libCoreVMClient.dylib (24.4) <55F71158-ADEE-3863-92E9-4772DCEA8E31> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
    0x7fff8e506000 -     0x7fff8e56eff7  libc++.1.dylib (65.1) <20E31B90-19B9-3C2A-A9EB-474E08F9FE05> /usr/lib/libc++.1.dylib
    0x7fff8e56f000 -     0x7fff8e671fff  libcrypto.0.9.8.dylib (47) <74F165AD-4572-3B26-B0E2-A97477FE59D0> /usr/lib/libcrypto.0.9.8.dylib
    0x7fff8e672000 -     0x7fff8e677fff  com.apple.OpenDirectory (10.8 - 151.10) <CF44120B-9B01-32DD-852E-C9C0E1243FC0> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
    0x7fff8e678000 -     0x7fff8e699ff7  libCRFSuite.dylib (33) <736ABE58-8DED-3289-A042-C25AF7AE5B23> /usr/lib/libCRFSuite.dylib
    0x7fff8e69d000 -     0x7fff8e6d4ff7  libssl.0.9.8.dylib (47) <923945E6-C489-3406-903B-A362410753F8> /usr/lib/libssl.0.9.8.dylib
    0x7fff8e6d5000 -     0x7fff8e7ed92f  libobjc.A.dylib (532.2) <90D31928-F48D-3E37-874F-220A51FD9E37> /usr/lib/libobjc.A.dylib
    0x7fff8e7ee000 -     0x7fff8e83fff7  com.apple.SystemConfiguration (1.12.2 - 1.12.2) <E095637C-457F-3D8F-AE32-A032F9D5A46C> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
    0x7fff8e840000 -     0x7fff8e84eff7  libsystem_network.dylib (77.10) <0D99F24E-56FE-380F-B81B-4A4C630EE587> /usr/lib/system/libsystem_network.dylib
    0x7fff8e84f000 -     0x7fff8e85dff7  libkxld.dylib (2050.18.24) <7027CE49-007D-3553-8FFA-3E3B428B2316> /usr/lib/system/libkxld.dylib
    0x7fff8e85e000 -     0x7fff8e91bff7  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
    0x7fff8e91c000 -     0x7fff8e91fff7  libdyld.dylib (210.2.3) <F59367C9-C110-382B-A695-9035A6DD387E> /usr/lib/system/libdyld.dylib
    0x7fff8e93e000 -     0x7fff8eab2fff  com.apple.CFNetwork (596.2.3 - 596.2.3) <6A16C2BD-1035-30F9-AE96-D9E3BB54A976> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
    0x7fff8eab3000 -     0x7fff8eb1cfff  libstdc++.6.dylib (56) <EAA2B53E-EADE-39CF-A0EF-FB9D4940672A> /usr/lib/libstdc++.6.dylib
    0x7fff8eb1d000 -     0x7fff8eb9ffff  com.apple.Heimdal (3.0 - 2.0) <660A6C64-4912-32C8-A332-B64164032A2D> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
    0x7fff8eba2000 -     0x7fff8ec53fff  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
    0x7fff8ec54000 -     0x7fff8ec5ffff  libsystem_notify.dylib (98.5) <C49275CC-835A-3207-AFBA-8C01374927B6> /usr/lib/system/libsystem_notify.dylib
    0x7fff8ec60000 -     0x7fff8ec64ff7  com.apple.TCC (1.0 - 1) <F2F3B753-FC73-3543-8BBE-859FDBB4D6A6> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
    0x7fff8ec65000 -     0x7fff8ec65fff  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
    0x7fff8ec66000 -     0x7fff8ec68fff  libquarantine.dylib (52) <4BE2E642-A14F-340A-B482-5BD2AEFD9C24> /usr/lib/system/libquarantine.dylib
    0x7fff8ec69000 -     0x7fff8ec6bfff  com.apple.TrustEvaluationAgent (2.0 - 23) <A97D348B-32BF-3E52-8DF2-59BFAD21E1A3> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
    0x7fff8ec6c000 -     0x7fff8ee07fef  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
    0x7fff8ee08000 -     0x7fff8ee1efff  com.apple.MultitouchSupport.framework (235.28 - 235.28) <BD78B16E-9B5A-3E07-93B4-13AD1A538CAC> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
    0x7fff8ee88000 -     0x7fff8ee8bfff  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
    0x7fff8eec4000 -     0x7fff8eed8fff  libGL.dylib (8.6.1) <2E00615F-97F5-34EB-BE07-75A24F3C18D7> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
    0x7fff8efa4000 -     0x7fff8efb1fff  com.apple.AppleFSCompression (49 - 1.0) <5508344A-2A7E-3122-9562-6F363910A80E> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
    0x7fff8efbc000 -     0x7fff8f013ff7  com.apple.ScalableUserInterface (1.0 - 1) <F1D43DFB-1796-361B-AD4B-39F1EED3BE19> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface
    0x7fff8f014000 -     0x7fff8f04efff  com.apple.GSS (3.0 - 2.0) <0BDF8090-5EF4-3759-94DE-8521D74188AA> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
    0x7fff8f04f000 -     0x7fff8f05eff7  com.apple.opengl (1.8.6 - 1.8.6) <720CC06C-0D01-37AE-BB3D-D7F0242B262A> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
    0x7fff8f05f000 -     0x7fff8f248fff  com.apple.CoreFoundation (6.8 - 744.12) <EF002794-DAEF-31C6-866C-E3E3AC387A9F> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff8f249000 -     0x7fff8f27ffff  libsystem_info.dylib (406.17) <4FFCA242-7F04-365F-87A6-D4EFB89503C1> /usr/lib/system/libsystem_info.dylib
    0x7fff8f280000 -     0x7fff8f370ff7  com.apple.DiskImagesFramework (10.8 - 344) <3A30B9B5-5099-35E2-9DCD-C96764FA2D26> /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages
    0x7fff8f371000 -     0x7fff8f372ff7  libremovefile.dylib (23.1) <DBBFAF35-AC78-3856-92F6-6E4FD9DF14A2> /usr/lib/system/libremovefile.dylib
    0x7fff8f49c000 -     0x7fff8f4a7fff  com.apple.CommonAuth (3.0 - 2.0) <74A86DDD-57D0-3178-AB74-E1F31DBFFC39> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
    0x7fff8f4a8000 -     0x7fff8f4acfff  libGIF.dylib (845) <2690CE83-E934-3EF8-A30A-996EDADCE3E4> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
    0x7fff8f4ad000 -     0x7fff8f4c4fff  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
    0x7fff8f721000 -     0x7fff8f721fff  com.apple.ApplicationServices (45 - 45) <A3ABF20B-ED3A-32B5-830E-B37831A45A80> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
    0x7fff8f722000 -     0x7fff8f750fff  com.apple.CoreServicesInternal (154.2 - 154.2) <3E6196E6-F3B4-316F-9E1F-13B6B9694C7E> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal
    0x7fff8f751000 -     0x7fff8f766ff7  libdispatch.dylib (228.23) <D26996BF-FC57-39EB-8829-F63585561E09> /usr/lib/system/libdispatch.dylib
    0x7fff8f7a4000 -     0x7fff8f7e8fff  libcups.2.dylib (327) <9B3F3321-D2BC-3195-BF20-4008FC52A390> /usr/lib/libcups.2.dylib
    0x7fff8f7e9000 -     0x7fff8f7eefff  libcompiler_rt.dylib (30) <08F8731D-5961-39F1-AD00-4590321D24A9> /usr/lib/system/libcompiler_rt.dylib
    0x7fff8f80d000 -     0x7fff8f859ff7  libauto.dylib (185.1) <73CDC482-16E3-3FC7-9BB4-FBA2DA44DBC2> /usr/lib/libauto.dylib
    0x7fff8f85a000 -     0x7fff8f877fff  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
    0x7fff8fafb000 -     0x7fff8fb08ff7  com.apple.NetAuth (4.0 - 4.0) <F5BC7D7D-AF28-3C83-A674-DADA48FF7810> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
    0x7fff8fb09000 -     0x7fff8fbd5fe7  libsystem_c.dylib (825.25) <8CBCF9B9-EBB7-365E-A3FF-2F3850763C6B> /usr/lib/system/libsystem_c.dylib
    0x7fff8fbd6000 -     0x7fff90566c67  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
    0x7fff905ae000 -     0x7fff9064cff7  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
    0x7fff9064d000 -     0x7fff90654fff  com.apple.NetFS (5.0 - 4.0) <82E24B9A-7742-3DA3-9E99-ED267D98C05E> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
    0x7fff90655000 -     0x7fff9065dff7  libsystem_dnssd.dylib (379.32.1) <62AA0B84-188A-348B-8F9E-3E2DB08DB93C> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff9065e000 -     0x7fff9065ffff  libsystem_blocks.dylib (59) <D92DCBC3-541C-37BD-AADE-ACC75A0C59C8> /usr/lib/system/libsystem_blocks.dylib
    0x7fff906bb000 -     0x7fff906e5ff7  com.apple.CoreVideo (1.8 - 99.3) <C424838A-889C-39E5-8108-FD05C93D26A0> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
    0x7fff90871000 -     0x7fff9088cff7  libsystem_kernel.dylib (2050.18.24) <C0535565-35D1-31A7-A744-63D9F10F12A4> /usr/lib/system/libsystem_kernel.dylib
    0x7fff9088d000 -     0x7fff9090efff  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
    0x7fff90911000 -     0x7fff90915fff  libpam.2.dylib (20) <C8F45864-5B58-3237-87E1-2C258A1D73B8> /usr/lib/libpam.2.dylib
    0x7fff909a1000 -     0x7fff90a1fff7  com.apple.securityfoundation (6.0 - 55115.4) <C5461971-E455-31A6-99B8-AF80C4BC26DD> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
    0x7fff90a20000 -     0x7fff90a22fff  libCVMSPluginSupport.dylib (8.6.1) <7EFDA31E-E463-3897-A8DC-7FD266EB713E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
    0x7fff90a6b000 -     0x7fff90ac1fff  com.apple.HIServices (1.20 - 417) <A1129272-FEC8-350B-BA26-5A97F23C413D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
    0x7fff90aea000 -     0x7fff90aeeff7  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
    0x7fff90aef000 -     0x7fff90af0fff  liblangid.dylib (116) <864C409D-D56B-383E-9B44-A435A47F2346> /usr/lib/liblangid.dylib
    0x7fff91e80000 -     0x7fff91e89fff  com.apple.CommerceCore (1.0 - 26) <997CD214-BC78-3C61-A1B8-813EA1CB9997> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore
    0x7fff91e8a000 -     0x7fff91eb1ff7  com.apple.PerformanceAnalysis (1.16 - 16) <E4888388-F41B-313E-9CBB-5807D077BDA9> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
    0x7fff91eb2000 -     0x7fff91f84ff7  com.apple.CoreText (260.0 - 275.16) <5BFC1D67-6A6F-38BC-9D90-9C712684EDAC> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
    0x7fff91f85000 -     0x7fff91fb3ff7  libsystem_m.dylib (3022.6) <B434BE5C-25AB-3EBD-BAA7-5304B34E3441> /usr/lib/system/libsystem_m.dylib
    0x7fff91fb4000 -     0x7fff9213afff  libBLAS.dylib (1073.4) <C102C0F6-8CB6-3B49-BA6B-2EB61F0B2784> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
    0x7fff9213b000 -     0x7fff9213bfff  com.apple.Carbon (154 - 155) <372716D2-6FA1-3611-8501-3DD1D4A6E8C8> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
    0x7fff92163000 -     0x7fff921b2ff7  libcorecrypto.dylib (106.2) <CE0C29A3-C420-339B-ADAA-52F4683233CC> /usr/lib/system/libcorecrypto.dylib
    0x7fff921b3000 -     0x7fff921d8ff7  libc++abi.dylib (24.4) <E7BD9363-1D25-3551-A68A-2E2FF6ABECD7> /usr/lib/libc++abi.dylib
    0x7fff9244e000 -     0x7fff92489fff  com.apple.LDAPFramework (2.4.28 - 194.5) <0190B746-F684-3F43-B4D0-148EFE386CA4> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP
    0x7fff9248a000 -     0x7fff924f2fff  libvDSP.dylib (380.6) <CD4C5EEB-9E63-30C4-8103-7A5EAEA0BE60> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
    0x7fff92553000 -     0x7fff92553fff  libOpenScriptingUtil.dylib (148.2) <B8061D13-C1B2-38D5-A723-9A98D64E67AC> /usr/lib/libOpenScriptingUtil.dylib
    0x7fff92554000 -     0x7fff92561ff7  com.apple.HelpData (2.1.4 - 85) <EE68BDCC-AF2E-34D3-8E4F-87379E3A4D8E> /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData
    0x7fff92d23000 -     0x7fff92dc9ff7  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
    0x7fff92dd6000 -     0x7fff92dd6fff  libkeymgr.dylib (25) <CC9E3394-BE16-397F-926B-E579B60EE429> /usr/lib/system/libkeymgr.dylib
    0x7fff92dd7000 -     0x7fff92dd8ff7  libSystem.B.dylib (169.3) <365477AB-D641-389D-B8F4-A1FAE9657EEE> /usr/lib/libSystem.B.dylib
    0x7fff92e06000 -     0x7fff92e60fff  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
    0x7fff92e61000 -     0x7fff92e74ff7  libbsm.0.dylib (32) <F497D3CE-40D9-3551-84B4-3D5E39600737> /usr/lib/libbsm.0.dylib
    0x7fff92e83000 -     0x7fff92ea5ff7  com.apple.Kerberos (2.0 - 1) <C49B8820-34ED-39D7-A407-A3E854153556> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
    0x7fff92f7d000 -     0x7fff92f8bfff  com.apple.Librarian (1.1 - 1) <1635162F-239A-341E-83C7-710C55E254AF> /System/Library/PrivateFrameworks/Librarian.framework/Versions/A/Librarian
    0x7fff92f8c000 -     0x7fff92fe1ff7  libTIFF.dylib (845) <ADCB4683-69EB-318B-8BE7-5FDF38BCADAF> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
    0x7fff92fe2000 -     0x7fff93031ff7  libFontRegistry.dylib (100) <2E03D7DA-9B8F-31BB-8FB5-3D3B6272127F> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
    0x7fff93032000 -     0x7fff9303efff  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
    0x7fff93096000 -     0x7fff93116ff7  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
    0x7fff93117000 -     0x7fff93121fff  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
    0x7fff93122000 -     0x7fff93141ff7  com.apple.ChunkingLibrary (2.0 - 133.2) <D2A746DE-002A-3C6C-961E-BE94E71DB835> /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary
    0x7fff93145000 -     0x7fff931dffff  libvMisc.dylib (380.6) <714336EA-1C0E-3735-B31C-19DFDAAF6221> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
    0x7fff932df000 -     0x7fff93314ff7  libTrueTypeScaler.dylib (84.5) <DF2335F3-07BE-30BA-B73C-3204E95B42C3> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib
    0x7fff93315000 -     0x7fff9334dfff  libtidy.A.dylib (15.10) <9009156B-84F5-3781-BFCB-B409B538CD18> /usr/lib/libtidy.A.dylib
    0x7fff93350000 -     0x7fff93363ff7  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
    0x7fff93364000 -     0x7fff9336afff  libCGXCoreImage.A.dylib (324.6) <45864BEA-B2EA-3F5F-9D04-F9832AB67A00> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXCoreImage.A.dylib
    0x7fff9336b000 -     0x7fff93468fff  libsqlite3.dylib (138.1) <ADE9CB98-D77D-300C-A32A-556B7440769F> /usr/lib/libsqlite3.dylib
    0x7fff93469000 -     0x7fff93574fff  libFontParser.dylib (84.5) <617A7D30-C7BC-39FC-A1FE-59367B4A5719> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
    0x7fff93575000 -     0x7fff9359cfff  com.apple.framework.familycontrols (4.1 - 410) <AE49B2AB-7D2B-3D52-8E21-60EBEA1A38E6> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
    0x7fff9359d000 -     0x7fff938cdff7  com.apple.HIToolbox (2.0 - 625) <317F75F7-4B0F-35F5-89A7-F20BA60AC944> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
    0x7fff938db000 -     0x7fff939d8ff7  libxml2.2.dylib (22.3) <47B09CB2-C636-3024-8B55-6040F7829B4C> /usr/lib/libxml2.2.dylib
    0x7fff93acb000 -     0x7fff93acdff7  libunc.dylib (25) <92805328-CD36-34FF-9436-571AB0485072> /usr/lib/system/libunc.dylib
    0x7fff93ace000 -     0x7fff93eebfff  FaceCoreLight (2.4.1) <A34C9575-C4C1-31B1-809B-7751070B4E8B> /System/Library/PrivateFrameworks/FaceCoreLight.framework/Versions/A/FaceCoreLight
    0x7fff93eec000 -     0x7fff93f59fff  com.apple.datadetectorscore (4.0 - 269.1) <C94C372B-3821-3A46-A8C2-091AB1CFF7F4> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
    0x7fff94bb7000 -     0x7fff94cb9fff  libJP2.dylib (845) <405CAF25-0AA5-3C6B-A4A6-94471A1EDD2F> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
    0x7fff95046000 -     0x7fff95166fff  com.apple.desktopservices (1.7.2 - 1.7.2) <CDE8C2C2-C505-31B0-8C61-E40E4EA364A5> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
    0x7fff95b70000 -     0x7fff95b72ff7  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
    0x7fff95b84000 -     0x7fff95c79fff  libiconv.2.dylib (34) <FEE8B996-EB44-37FA-B96E-D379664DEFE1> /usr/lib/libiconv.2.dylib
    0x7fff95caa000 -     0x7fff95dc3ff7  com.apple.ImageIO.framework (3.2.0 - 845) <553B9828-A7D9-3AE4-A214-1C33417545FD> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
    0x7fff96088000 -     0x7fff960aaff7  libxpc.dylib (140.41) <FAC04D8B-680E-325F-8F0C-DD69859D0E01> /usr/lib/system/libxpc.dylib
    0x7fff960ab000 -     0x7fff960d9fff  com.apple.shortcut (2.2 - 2.2) <C573DB65-37FB-3DDC-AB19-525094346D9B> /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut
    0x7fff96883000 -     0x7fff96889fff  libmacho.dylib (829) <BF332AD9-E89F-387E-92A4-6E1AB74BD4D9> /usr/lib/system/libmacho.dylib
    0x7fff96ad2000 -     0x7fff96b2ffff  com.apple.audio.CoreAudio (4.1.0 - 4.1.0) <B3198BD6-EA1D-3E5E-ADD4-37D8E6B72678> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
    0x7fff96b30000 -     0x7fff96bcafff  com.apple.CoreSymbolication (3.0 - 87) <75F2C0DD-549A-36F6-BD9E-FB40A924344F> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
    0x7fff96bcb000 -     0x7fff96e9bfff  com.apple.security (7.0 - 55179.1) <639641EF-8156-3190-890C-1053658E044A> /System/Library/Frameworks/Security.framework/Versions/A/Security
    0x7fff96e9c000 -     0x7fff96ea1fff  libcache.dylib (57) <65187C6E-3FBF-3EB8-A1AA-389445E2984D> /usr/lib/system/libcache.dylib
    0x7fff96ea2000 -     0x7fff96eaafff  liblaunch.dylib (442.26.2) <2F71CAF8-6524-329E-AC56-C506658B4C0C> /usr/lib/system/liblaunch.dylib
    0x7fff96ef1000 -     0x7fff96f00ff7  libxar.1.dylib (105) <370ED355-E516-311E-BAFD-D80633A84BE1> /usr/lib/libxar.1.dylib
    0x7fff96f01000 -     0x7fff96f03fff  com.apple.securityhi (4.0 - 55002) <34E45C60-DC7E-3FCC-A1ED-EBF48B77C559> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
    0x7fff971a1000 -     0x7fff971ccfff  libxslt.1.dylib (11.3) <441776B8-9130-3893-956F-39C85FFA644F> /usr/lib/libxslt.1.dylib
    0x7fff971cd000 -     0x7fff97450fff  com.apple.RawCamera.bundle (4.00 - 658) <6786E9E0-3197-30A3-A0F4-22A6064B3EF2> /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera
    0x7fff97451000 -     0x7fff975a2fff  com.apple.audio.toolbox.AudioToolbox (1.8 - 1.8) <833DA682-A3C1-39E7-AEC3-9EDC734DE2A9> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
    0x7fff976cd000 -     0x7fff978cdfff  libicucore.A.dylib (491.11.1) <CC318A27-878A-38CE-9292-1B98353FA9C7> /usr/lib/libicucore.A.dylib
    0x7fff97953000 -     0x7fff97c6aff7  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
    0x7fff97cfb000 -     0x7fff97d23fff  libJPEG.dylib (845) <A32618D7-FB91-3EE2-A105-5407B2F3F8D8> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
    0x7fff97d24000 -     0x7fff97d2aff7  libunwind.dylib (35.1) <21703D36-2DAB-3D8B-8442-EAAB23C060D3> /usr/lib/system/libunwind.dylib
    0x7fff97e0f000 -     0x7fff97e0ffff  com.apple.vecLib (3.8 - vecLib 3.8) <794317C7-4E38-338A-A874-5E18001C8503> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fff97e10000 -     0x7fff97e6cff7  com.apple.Symbolication (1.3 - 93) <F2C7E0B6-B241-3020-B30A-0636D0FA3378> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
    0x7fff97e6d000 -     0x7fff97eb0ff7  com.apple.bom (12.0 - 192) <0BF1F2D2-3648-36B7-BE4B-551A0173209B> /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom
    0x7fff97eb1000 -     0x7fff97ebdfff  com.apple.CrashReporterSupport (10.8.2 - 415) <55783BF9-125E-3F9C-A412-6A095ECD9353> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport
    0x7fff97ee7000 -     0x7fff97ee7fff  com.apple.CoreServices (57 - 57) <9DD44CB0-C644-35C3-8F57-0B41B3EC147D> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
    0x7fff97f88000 -     0x7fff97fc7ff7  com.apple.QD (3.42 - 285) <8DF36FCA-C06B-30F4-A631-7BE2FF7E56D1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
    0x7fff97fc8000 -     0x7fff98324fff  com.apple.Foundation (6.8 - 945.11) <A5D41956-A354-3ACC-9355-BE200072223B> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
    0x7fff985d4000 -     0x7fff986a7ff7  com.apple.DiscRecording (7.0 - 7000.2.4) <49FD2D2F-4F2C-39B6-877B-6E3172577D18> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording
    0x7fff986a8000 -     0x7fff986b9ff7  libsasl2.2.dylib (166) <649CAE0E-8FFE-3C60-A849-BE6300E4B726> /usr/lib/libsasl2.2.dylib
    0x7fff986ba000 -     0x7fff986c0fff  com.apple.DiskArbitration (2.5.1 - 2.5.1) <F7DAF7CC-5893-3F06-9168-3B0192B66D15> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
    0x7fff986c1000 -     0x7fff986c2fff  libDiagnosticMessagesClient.dylib (8) <8548E0DC-0D2F-30B6-B045-FE8A038E76D8> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff987a4000 -     0x7fff987d0ff7  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
    0x7fff989cc000 -     0x7fff98aa6ff7  com.apple.backup.framework (1.4.1 - 1.4.1) <A3CFCA9E-717C-302D-821B-16FD35E6673F> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup
    0x7fff98aa7000 -     0x7fff996d4ff7  com.apple.AppKit (6.8 - 1187.34) <1FF64844-EB62-3F96-AED7-6525B7CCEC23> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
    0x7fff996d5000 -     0x7fff996e7ff7  libz.1.dylib (43) <2A1551E8-A272-3DE5-B692-955974FE1416> /usr/lib/libz.1.dylib
    0x7fff996e8000 -     0x7fff99730fff  libcurl.4.dylib (69.2) <EBDBF42D-E4A6-3D05-A76B-2817D79D59E2> /usr/lib/libcurl.4.dylib
    0x7fff99731000 -     0x7fff99732ff7  libdnsinfo.dylib (453.18) <E7595861-ECF9-336E-9901-BED2620FAA80> /usr/lib/system/libdnsinfo.dylib
    0x7fff99733000 -     0x7fff997a0ff7  com.apple.framework.IOKit (2.0 - 755.18.10) <142E19DD-1C8D-3D61-ABC8-83994A73279F> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
    0x7fff997ed000 -     0x7fff9981eff7  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
    0x7fff99c52000 -     0x7fff99ca8ff7  com.apple.opencl (2.1.20 - 2.1.20) <AF142CA4-EA1D-31B0-A48F-AA2B75D4309E> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
    0x7fff9a0f1000 -     0x7fff9a0fcff7  com.apple.bsd.ServiceManagement (2.0 - 2.0) <C12962D5-85FB-349E-AA56-64F4F487F219> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
    0x7fff9a0fd000 -     0x7fff9a0fdfff  com.apple.Accelerate (1.8 - Accelerate 1.8) <6AD48543-0864-3D40-80CE-01F184F24B45> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
    0x7fff9a0fe000 -     0x7fff9a102fff  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
    0x7fff9a103000 -     0x7fff9a140fe7  libGLImage.dylib (8.6.1) <7F31DD61-3110-3541-A9BB-035CD1262E50> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
    0x7fff9a141000 -     0x7fff9a162fff  com.apple.Ubiquity (1.2 - 243.10) <F97D3A33-2C8B-3CFF-AF75-A74866D42853> /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity
    0x7fff9a1f6000 -     0x7fff9a203fff  libbz2.1.0.dylib (29) <CE9785E8-B535-3504-B392-82F0064D9AF2> /usr/lib/libbz2.1.0.dylib
    0x7fff9a204000 -     0x7fff9a24eff7  libGLU.dylib (8.6.1) <DF45C1E3-3884-3991-B84F-F39B482E8BF8> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
    0x7fff9a24f000 -     0x7fff9a3fdfff  com.apple.QuartzCore (1.8 - 304.0) <BDC66714-F60C-386D-A773-F897D1E87AB6> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
    0x7fff9a3fe000 -     0x7fff9a441fff  com.apple.RemoteViewServices (2.0 - 80.5) <F3A897C9-A277-3B56-8FB3-2BC2C10C33BF> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices
    0x7fff9a442000 -     0x7fff9a4cfff7  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
    0x7fff9a4d3000 -     0x7fff9a4e1fff  libcommonCrypto.dylib (60026) <2D6537F5-1B5E-305C-A1CF-D1FA80CA3939> /usr/lib/system/libcommonCrypto.dylib
    0x7fff9a4e2000 -     0x7fff9a8d9fff  libLAPACK.dylib (1073.4) <D632EC8B-2BA0-3853-800A-20DA00A1091C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
    0x7fff9a8f6000 -     0x7fff9a915ff7  libresolv.9.dylib (51) <0882DC2D-A892-31FF-AD8C-0BB518C48B23> /usr/lib/libresolv.9.dylib
    0x7fff9a916000 -     0x7fff9a91cfff  libGFXShared.dylib (8.6.1) <CF55E720-1B9E-3E24-A1DA-7FA8B261CD8E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
    0x7fff9a91d000 -     0x7fff9abc1fff  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
    0x7fff9abde000 -     0x7fff9abf2fff  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
    0x7fff9abf3000 -     0x7fff9ac33fff  com.apple.MediaKit (13 - 659) <0C56D7FF-0430-3199-9952-CF8577519449> /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit
    0x7fff9ac38000 -     0x7fff9ac95ff7  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
    0x7fff9ac96000 -     0x7fff9ac99fff  libRadiance.dylib (845) <E8956A35-494E-3014-8B86-362D32576116> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
    0x7fff9ac9a000 -     0x7fff9acaffff  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

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: 42677
    thread_create: 1
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=157.0M resident=117.4M(75%) swapped_out_or_unallocated=39.6M(25%)
Writable regions: Total=66.8M written=17.9M(27%) resident=43.7M(65%) swapped_out=0K(0%) unallocated=23.1M(35%)
 
REGION TYPE                      VIRTUAL
===========                      =======
CG backing stores                  2960K
CG image                            572K
CG shared images                   1248K
CoreImage                             4K
CoreServices                       2048K
MALLOC                             34.9M
MALLOC guard page                    48K
MALLOC_LARGE (reserved)             384K        reserved VM address space (unallocated)
Memory tag=240                        4K
Memory tag=242                       12K
Memory tag=251                        8K
OpenCL                                8K
STACK GUARD                        56.0M
Stack                              10.1M
VM_ALLOCATE                        16.1M
__DATA                             11.9M
__IMAGE                             528K
__LINKEDIT                         54.4M
__TEXT                            102.6M
__UNICODE                           544K
mapped file                        42.2M
shared memory                       308K
===========                      =======
TOTAL                             336.6M
TOTAL, minus reserved VM space    336.3M

Model: iMac8,1, BootROM IM81.00C1.B00, 2 processors, Intel Core 2 Duo, 2.8 GHz, 4 GB, SMC 1.30f1
Graphics: ATI Radeon HD 2600 Pro, ATI Radeon HD 2600 Pro, PCIe, 256 MB
Memory Module: BANK 0/DIMM0, 2 GB, DDR2 SDRAM, 800 MHz, 0x7F7F7F7F7F9B0000, 0x4354323536363441433830302E4B31364600
Memory Module: BANK 1/DIMM1, 2 GB, DDR2 SDRAM, 800 MHz, 0x7F7F7F7F7F9B0000, 0x4354323536363441433830302E4B31364600
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8C), Broadcom BCM43xx 1.0 (5.10.131.36.16)
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: Hitachi HDP725032GLA380, 320.07 GB
Parallel ATA Device: MATSHITADVD-R   UJ-875
USB Device: iPod, apple_vendor_id, 0x1302, 0xfa400000 / 3
USB Device: FreeAgent, 0x0bc2  (Seagate LLC), 0x3008, 0xfa200000 / 2
USB Device: Built-in iSight, apple_vendor_id, 0x8502, 0xfd400000 / 3
USB Device: USB2.0 Hub, 0x05e3  (Genesys Logic, Inc.), 0x0608, 0xfd100000 / 2
USB Device: USB2.0 Hub, 0x05e3  (Genesys Logic, Inc.), 0x0608, 0xfd140000 / 5
USB Device: iPhone, apple_vendor_id, 0x1294, 0xfd144000 / 10
USB Device: USB2.0 Hub, 0x05e3  (Genesys Logic, Inc.), 0x0608, 0xfd142000 / 7
USB Device: Flash Disk, 0x058f  (Alcor Micro, Corp.), 0x6387, 0xfd142100 / 8
USB Device: Keyboard Hub, apple_vendor_id, 0x1006, 0xfd141000 / 6
USB Device: Apple Keyboard, apple_vendor_id, 0x0220, 0xfd141200 / 9
USB Device: My Book 1110, 0x1058  (Western Digital Technologies, Inc.), 0x1110, 0xfd130000 / 4
USB Device: BRCM2046 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0x1a100000 / 2
USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x820f, 0x1a110000 / 5
USB Device: IR Receiver, apple_vendor_id, 0x8242, 0x5d100000 / 2

----------
components: IDLE
messages: 172268
nosy: Raymond.Costantini
priority: normal
severity: normal
status: open
title: Crash every time I copy or paste any code in IDLE
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Sun Oct  7 18:54:12 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Oct 2012 16:54:12 +0000
Subject: [New-bugs-announce] [issue16157] Irrelevant references to Misc/News
Message-ID: <1349628852.45.0.324394497616.issue16157@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Older versions (3.2 for 3.3, 3.2 and 3.3 for 3.4) whatsnew refers to Misc/News which contains changes only for currect version ("For full details, see the :source:`Misc/NEWS <Misc/NEWS>` file.").

http://docs.python.org/3.3/whatsnew/3.2.html
http://docs.python.org/3.4/whatsnew/3.2.html
http://docs.python.org/3.4/whatsnew/3.3.html

----------
assignee: docs at python
components: Documentation
messages: 172321
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Irrelevant references to Misc/News
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Oct  7 19:55:36 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 07 Oct 2012 17:55:36 +0000
Subject: [New-bugs-announce] [issue16158] sporadic test_multiprocessing
	failure
Message-ID: <1349632536.58.0.00638810333077.issue16158@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Seen on a buildbot:

======================================================================
FAIL: test_mymanager_context_prestarted (test.test_multiprocessing.WithManagerTestMyManager)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Volumes/bay2/buildslave/cpython/3.3.snakebite-mountainlion-amd64/build/Lib/test/test_multiprocessing.py", line 1911, in test_mymanager_context_prestarted
    self.assertEqual(manager._process.exitcode, 0)
AssertionError: None != 0

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

----------
components: Library (Lib), Tests
messages: 172325
nosy: pitrou, sbt, trent
priority: normal
severity: normal
status: open
title: sporadic test_multiprocessing failure
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Oct  8 01:19:18 2012
From: report at bugs.python.org (jimbo1qaz)
Date: Sun, 07 Oct 2012 23:19:18 +0000
Subject: [New-bugs-announce] [issue16159] Closing Debugger freezes IDLE shell
Message-ID: <1349651958.95.0.104247306241.issue16159@psf.upfronthosting.co.za>


New submission from jimbo1qaz:

Open a Python file with IDLE and F5 it. Turn on debugger ([DEBUG ON]), F5 again ([DEBUG ON]), and close the debugger ([DEBUG OFF]). The shell is now completely locked and must be closed (with a 'The program is still running, want to kill it?' message).

----------
components: IDLE
messages: 172352
nosy: jimbo1qaz
priority: normal
severity: normal
status: open
title: Closing Debugger freezes IDLE shell
versions: Python 3.3

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

From report at bugs.python.org  Mon Oct  8 03:10:07 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Oct 2012 01:10:07 +0000
Subject: [New-bugs-announce] [issue16160] subclassing types.SimpleNamespace
	does not work
Message-ID: <1349658607.29.0.0643105543226.issue16160@psf.upfronthosting.co.za>


New submission from R. David Murray:

Python 3.3.0+ (3.3:152d85b2da3a, Oct  6 2012, 13:17:54) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from types import SimpleNamespace
>>> class Foo(SimpleNamespace):
...   pass
... 
>>> y = Foo(bar=8, foo=9)
>>> y
namespace()

It doesn't work to define an __init__ method, either, which is what I really wanted to do.  (I was subclassing to get the nice repr).

----------
messages: 172355
nosy: eric.snow, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: subclassing types.SimpleNamespace does not work
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Oct  8 11:06:24 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 08 Oct 2012 09:06:24 +0000
Subject: [New-bugs-announce] [issue16161] broken link to Visual Studio 2008
	in devguide
Message-ID: <1349687184.47.0.215855262473.issue16161@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The link to Visual Studio 2008 in the devguide doesn't seem to work:

http://docs.python.org/devguide/setup.html#windows
https://www.microsoft.com/visualstudio/en-us/products/2008-editions/express

This seems to be a better link:

http://www.microsoft.com/en-us/download/details.aspx?id=14597

----------
components: Devguide
keywords: easy
messages: 172367
nosy: chris.jerdonek, ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: broken link to Visual Studio 2008 in devguide
type: behavior

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

From report at bugs.python.org  Mon Oct  8 13:53:07 2012
From: report at bugs.python.org (Michael Vogt)
Date: Mon, 08 Oct 2012 11:53:07 +0000
Subject: [New-bugs-announce] [issue16162] Py_FileSystemDefaultEncoding
	should be updated on	locale.setlocale()
Message-ID: <1349697187.89.0.133420695321.issue16162@psf.upfronthosting.co.za>


New submission from Michael Vogt:

The Py_FileSystemDefaultEncoding is very static right now and only set on interpreter statup AFAICT. There appears to be no way to switch that later.

I think that Py_FileSystemDefaultEncoding should get updated when locale.setlocale() is run automatically and attach a proof-of-concept patch for this. 

The reason is that if a python application is started without a environment (dbus activation will do that for example) its impossible to work with utf8 encoded filenames. The only workaround is to setup a environment and then os.execv() which seems not ideal.

----------
components: Unicode
files: alllow-chaning-of-Py_FileSystemDefaultEncoding.diff
keywords: patch
messages: 172373
nosy: ezio.melotti, mvo
priority: normal
severity: normal
status: open
title: Py_FileSystemDefaultEncoding should be updated on locale.setlocale()
versions: Python 3.2
Added file: http://bugs.python.org/file27486/alllow-chaning-of-Py_FileSystemDefaultEncoding.diff

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

From report at bugs.python.org  Mon Oct  8 13:54:06 2012
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 08 Oct 2012 11:54:06 +0000
Subject: [New-bugs-announce] [issue16163] Wrong name in
	Lib/pkgutil.py:iter_importers
Message-ID: <1349697246.97.0.772309039282.issue16163@psf.upfronthosting.co.za>


New submission from Berker Peksag:

Name "pkg" is not defined.

Related changeset: http://hg.python.org/cpython/rev/3987667bf98f#l2.89

----------
components: Library (Lib)
files: pkgutil-name.diff
keywords: patch
messages: 172374
nosy: berker.peksag
priority: normal
severity: normal
status: open
title: Wrong name in Lib/pkgutil.py:iter_importers
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27487/pkgutil-name.diff

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

From report at bugs.python.org  Mon Oct  8 13:58:20 2012
From: report at bugs.python.org (Alexander Belchenko)
Date: Mon, 08 Oct 2012 11:58:20 +0000
Subject: [New-bugs-announce] [issue16164] there is no easy way to force
	unittest.main to use	stdout rather than stderr
Message-ID: <1349697500.62.0.333745951917.issue16164@psf.upfronthosting.co.za>


New submission from Alexander Belchenko:

Why by default unittest.main (which uses unittest.TextTestRunner) prints everything to stderr. What the reason behind this behavior?
It makes very inconvenient to run big test suite with less, i.e.

python test.py | less 

or

python test.py > test.log

does not show me failed tests. They all go to stderr. Why?

Another thing: there is no easy way to override this. I have to subclass either TestProgram or TextTestRunner and force sys.stdout rather than sys.stderr. E.g.

class TestProgram(unittest.TestProgram):

    def runTests(self):
        if self.testRunner is None:
            self.testRunner = unittest.TextTestRunner(stream=sys.stdout, verbosity=self.verbosity)
        result = self.testRunner.run(self.test)
        sys.exit(not result.wasSuccessful())

if __name__ == '__main__':
    TestProgram()

Although it works for me I feel there is something wrong. Am I the only person who needs test output on stdout?

----------
components: Library (Lib)
messages: 172375
nosy: bialix
priority: normal
severity: normal
status: open
title: there is no easy way to force unittest.main to use stdout rather than stderr
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Oct  8 14:05:24 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Oct 2012 12:05:24 +0000
Subject: [New-bugs-announce] [issue16165] sched.scheduler.run() blocks
	scheduler
Message-ID: <1349697924.22.0.927523590696.issue16165@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

sched.scheduler.run() blocks scheduler and prevents the addition of new events until all events added before start will not be processed. Canceling does not work too.

Here is test script which reproduces the behavior differences.

Output in Python 3.2:

Adding
adding 0
added 0
adding 1
added 1
adding 2
added 2
event 0
event 1
start event
event 2
Canceling

Output in Python 3.3:

Adding
adding 0
start event
added 0
adding 1
added 1
adding 2
added 2
Canceling
event 0
event 1
event 2
Traceback (most recent call last):
  File "schedtest.py", line 20, in <module>
    s.cancel(e)
  File "/home/serhiy/py/cpython/Lib/sched.py", line 93, in cancel
    self._queue.remove(event)
ValueError: list.remove(x): x not in list

----------
components: Library (Lib)
files: schedtest.py
keywords: 3.3regression
messages: 172376
nosy: giampaolo.rodola, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: sched.scheduler.run() blocks scheduler
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27488/schedtest.py

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

From report at bugs.python.org  Mon Oct  8 16:33:27 2012
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 08 Oct 2012 14:33:27 +0000
Subject: [New-bugs-announce] [issue16166] Add PY_BYTE_ORDER macro to get
	endianess of platform
Message-ID: <1349706807.82.0.556520783402.issue16166@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I propose the addition of three new macros in pyport.h

#define PY_LITTLE_ENDIAN 1234
#define PY_BIG_ENDIAN 4321
#define PY_BYTE_ORDER <either little or big endian>

that are either set by a configure test or implemented like brg_endian.h. pyconfig.h has WORDS_BIGENDIAN which just checks for __BIG_ENDIAN__. The sysmodule has its own C code that checks the first byte of a long to detect the endianess.

http://hg.python.org/cpython/file/dd5e98ddcd39/Modules/_sha3/keccak/brg_endian.h

I'd like to remove Keccak's brg_endian.h (#16113 SHA-3 module) for something more official and useful to other code. I had to re-add the file because the tests were failing on a big endian Solaris (Sparc) machine.

----------
components: Build
messages: 172381
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: Add PY_BYTE_ORDER macro to get endianess of platform
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct  8 18:58:20 2012
From: report at bugs.python.org (Radu Dan)
Date: Mon, 08 Oct 2012 16:58:20 +0000
Subject: [New-bugs-announce] [issue16167] Allow printing of str-derived
	classes
Message-ID: <1349715500.68.0.716080336788.issue16167@psf.upfronthosting.co.za>


New submission from Radu Dan:

Classes that extend the builtin 'str' cannot be printed as is, and are automatically converted to string.

#!/bin/env python
class newstring(str):
        def __str__(self):
                return self

a = newstring("hello world")
print a

Running this returns:

Traceback (most recent call last):
  File "./test.py", line 7, in <module>
    print a
RuntimeError: print recursion

Given that instances of 'str' are immutable, I see no reason why this should not work.

----------
components: Library (Lib)
messages: 172396
nosy: Radu.Dan
priority: normal
severity: normal
status: open
title: Allow printing of str-derived classes
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Oct  9 00:03:03 2012
From: report at bugs.python.org (Vitaly)
Date: Mon, 08 Oct 2012 22:03:03 +0000
Subject: [New-bugs-announce] [issue16168] SysLogHandler constructor ignores
	socktype arg when	address refers to a Unix Domain Socket
Message-ID: <1349733783.87.0.737164149869.issue16168@psf.upfronthosting.co.za>


New submission from Vitaly:

_connect_unixsocket() (see below) does not use socktype value that was passed into SysLogHandler.__init__():

    def _connect_unixsocket(self, address):
        self.socket = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM)
        # syslog may require either DGRAM or STREAM sockets
        try:
            self.socket.connect(address)
        except socket.error:
            self.socket.close()
            self.socket = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
            self.socket.connect(address)

----------
components: Library (Lib)
messages: 172418
nosy: vitaly
priority: normal
severity: normal
status: open
title: SysLogHandler constructor ignores socktype arg when address refers to a Unix Domain Socket
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Oct  9 00:08:17 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 08 Oct 2012 22:08:17 +0000
Subject: [New-bugs-announce] [issue16169] ctypes.WinError() confuses errno
	with winerror
Message-ID: <1349734097.4.0.108959559992.issue16169@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

ctypes.WinError() is defined as

    def WinError(code=None, descr=None):
        if code is None:
            code = GetLastError()
        if descr is None:
            descr = FormatError(code).strip()
        return WindowsError(code, descr)

Since WindowsError became an alias for OSError, this means that if e is the exception raised, e.errno == GetLastError() and e.winerror == None.

I think the last line should be

        return WindowsError(None, descr, None, code)

----------
messages: 172419
nosy: sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: ctypes.WinError() confuses errno with winerror
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Oct  9 03:41:15 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 09 Oct 2012 01:41:15 +0000
Subject: [New-bugs-announce] [issue16170] remove Linux skip from
	test_subprocess's	test_executable() test
Message-ID: <1349746875.36.0.803736287299.issue16170@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to make whatever changes are necessary to remove the skip from test_subprocess's test_executable() test (currently skipping machines that are neither Windows nor Mac):

http://hg.python.org/cpython/file/ef90c5e482f4/Lib/test/test_subprocess.py#l203

The test currently fails on several Linux buildbots, but the test succeeds on Mac and Windows.  Perhaps this points to a different, underlying issue that needs to be fixed.

Either way, we should be able to test Popen()'s executable argument on Linux machines.  This issue seems closely related to closed issue #7774.

Below is more information from a buildbot about the failure (the AMD64 Ubuntu LTS buildbot):

http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.3/builds/38/steps/test/logs/stdio

FAIL: test_executable (test.test_subprocess.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_subprocess.py", line 205, in test_executable
    self._assert_python(["doesnotexist", "-c"], executable=sys.executable)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_subprocess.py", line 201, in _assert_python
    self.assertEqual(47, p.returncode)
AssertionError: 47 != -6

======================================================================
FAIL: test_executable (test.test_subprocess.ProcessTestCaseNoPoll)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_subprocess.py", line 205, in test_executable
    self._assert_python(["doesnotexist", "-c"], executable=sys.executable)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_subprocess.py", line 201, in _assert_python
    self.assertEqual(47, p.returncode)
AssertionError: 47 != -6

test_executable (test.test_subprocess.ProcessTestCase) ... Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ImportError: No module named 'encodings'
FAIL

----------
components: Library (Lib), Tests
keywords: buildbot
messages: 172432
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: remove Linux skip from test_subprocess's test_executable() test
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Oct  9 10:23:55 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Oct 2012 08:23:55 +0000
Subject: [New-bugs-announce] [issue16171] "do nothing" load_tests could be
	improved
Message-ID: <1349771035.38.0.947966701241.issue16171@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

unittest docs suggest the following "load_tests" for a __main__.py:

def load_tests(loader, standard_tests, pattern):
    # top level directory cached on loader instance
    this_dir = os.path.dirname(__file__)
    package_tests = loader.discover(start_dir=this_dir, pattern=pattern)
    standard_tests.addTests(package_tests)
    return standard_tests

This function fails with a weird error message when no pattern is given on the command line. A better alternative would be:

def load_tests(loader, standard_tests, pattern):
    # top level directory cached on loader instance
    this_dir = os.path.dirname(__file__)
    pattern = pattern or "test_*.py"
    package_tests = loader.discover(start_dir=this_dir, pattern=pattern)
    standard_tests.addTests(package_tests)
    return standard_tests

----------
assignee: docs at python
components: Documentation
messages: 172460
nosy: docs at python, ezio.melotti, michael.foord, pitrou
priority: low
severity: normal
status: open
title: "do nothing" load_tests could be improved
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Oct  9 11:54:54 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 09 Oct 2012 09:54:54 +0000
Subject: [New-bugs-announce] [issue16172] Fix is/== misuse
Message-ID: <1349776494.9.0.428146020554.issue16172@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here are two patches written on the discussion in Python-Ideas [1].

The first patch fixes incorrect use of "x is 0" or "x is 'foo'". Result of this operations is implementation details.

The second patch changes non-idiomatic use of "x == None" or "x == True".

[1] http://comments.gmane.org/gmane.comp.python.ideas/16547

----------
files: is_int_or_str.patch
keywords: patch
messages: 172467
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix is/== misuse
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27503/is_int_or_str.patch

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

From report at bugs.python.org  Tue Oct  9 12:23:53 2012
From: report at bugs.python.org (Baptiste Mispelon)
Date: Tue, 09 Oct 2012 10:23:53 +0000
Subject: [New-bugs-announce] [issue16173] Wrong offset on SyntaxError when
	identifier contains	non-ascii characters
Message-ID: <1349778233.78.0.111302090144.issue16173@psf.upfronthosting.co.za>


New submission from Baptiste Mispelon:

When a syntax error happens, the exception that gets printed has an extra line with a caret that helps locate the error.

If the line also contains an identifier with non-ascii characters, then this caret is misaligned (too far on the right).

I've investigated briefly and it seems that the offset attribute on the SyntaxError has a wrong value:

    for varname in ['a', '?', '?']: # 1, 2 and 3 bytes
        try:
            exec("%s$" % varname) # SyntaxError
        except SyntaxError as e:
            print(e.offset) # should be 2

The example above prints 2, 3, and 4 when it should be printing 2 every time.

It seems that the calculation of the offset takes into account the size in bytes instead of the size in characters.

I've tested and reproduced the issue on 3.2.2 and on a recent clone of the mercurial repository (dd5e98ddcd39).

----------
components: Interpreter Core
messages: 172470
nosy: bmispelon
priority: normal
severity: normal
status: open
title: Wrong offset on SyntaxError when identifier contains non-ascii characters
type: behavior
versions: Python 3.2, Python 3.4

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

From report at bugs.python.org  Tue Oct  9 12:32:30 2012
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 09 Oct 2012 10:32:30 +0000
Subject: [New-bugs-announce] [issue16174] Fix suggested usage of
	dummy_threading module
Message-ID: <1349778750.52.0.861421391329.issue16174@psf.upfronthosting.co.za>


New submission from Berker Peksag:

The suggested usage should be like this:

    try:
        import threading
    except ImportError:
        import dummy_threading as threading

See:
- http://hg.python.org/cpython/file/ce0d0d052494/Lib/queue.py#l3
- http://hg.python.org/cpython/file/ce0d0d052494/Lib/sched.py#l34
- http://hg.python.org/cpython/file/ce0d0d052494/Lib/socketserver.py#l137

----------
assignee: docs at python
components: Documentation
files: fix-dummy-threading-usage.diff
keywords: patch
messages: 172472
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Fix suggested usage of dummy_threading module
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27505/fix-dummy-threading-usage.diff

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

From report at bugs.python.org  Tue Oct  9 18:09:14 2012
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 09 Oct 2012 16:09:14 +0000
Subject: [New-bugs-announce] [issue16175] Add I/O Completion Ports wrapper
Message-ID: <1349798954.84.0.328560890888.issue16175@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Guido has expressed [1] that he like to see IOCP support in the stdlib for the grant unified asyncore interface.

Quote from MSDN [2]:
---
I/O completion ports provide an efficient threading model for processing multiple asynchronous I/O requests on a multiprocessor system. When a process creates an I/O completion port, the system creates an associated queue object for requests whose sole purpose is to service these requests. Processes that handle many concurrent asynchronous I/O requests can do so more quickly and efficiently by using I/O completion ports in conjunction with a pre-allocated a  thread pool than by creating threads at the time they receive an I/O request.
---

I've found a couple of interfaces to IOCP in Python projects. Twisted [3] has a Cython based interface to the IOCP API, Cogen [4] uses ctypes wrapper. I couldn't find IOCP support in Tornado. I favor a C implementation over ctypes. What's our attitude to Cython? Personally I like Cython and use it in several projects but I'm not sure if we shall use it in core development.

Christian

[1] http://mail.python.org/pipermail/python-ideas/2012-October/016539.html
[2] http://msdn.microsoft.com/en-us/library/aa365198%28VS.85%29.aspx
[3] http://twistedmatrix.com/trac/browser/trunk/twisted/internet/iocpreactor/iocpsupport/
[4] http://code.google.com/p/cogen/source/browse/trunk/cogen/core/proactors

----------
components: Extension Modules, Windows
messages: 172489
nosy: christian.heimes, exarkun, gvanrossum
priority: normal
severity: normal
status: open
title: Add I/O Completion Ports wrapper
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct  9 18:12:22 2012
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Oct 2012 16:12:22 +0000
Subject: [New-bugs-announce] [issue16176] platform.platform() identifies
	Windows 8 as	post2008Server
Message-ID: <1349799142.95.0.909627211255.issue16176@psf.upfronthosting.co.za>


New submission from Brian Curtin:

>>> platform.platform()
'Windows-post2008Server-6.2.9200'

The change is trivial, just accounting for a point release of 2 (from the major release 6).

--- a/Lib/platform.py
+++ b/Lib/platform.py
@@ -595,8 +595,13 @@
                     release = '7'
                 else:
                     release = '2008ServerR2'
+            elif min == 2:
+                if product_type == VER_NT_WORKSTATION:
+                    release = '8'
+                else:
+                    release = '2012Server'
             else:
-                release = 'post2008Server'
+                release = 'post2012Server'

----------
assignee: brian.curtin
components: Library (Lib), Windows
messages: 172490
nosy: brian.curtin
priority: normal
severity: normal
status: open
title: platform.platform() identifies Windows 8 as post2008Server
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/issue16176>
_______________________________________

From report at bugs.python.org  Tue Oct  9 18:38:55 2012
From: report at bugs.python.org (Brian Keegan)
Date: Tue, 09 Oct 2012 16:38:55 +0000
Subject: [New-bugs-announce] [issue16177] IDLE Crash on Open Parens
Message-ID: <1349800735.66.0.856769538072.issue16177@psf.upfronthosting.co.za>


New submission from Brian Keegan:

I am running IDLE on Mac OS X 10.8.2. Since a recent XCode update, every time I type an open parentheses into either the IDLE shell or an IDLE script, the program hangs and crashes. Uninstalling and re-installing Python 2.7.3 and IDLE have not solved the problem. 

Thank you for your help.

Here is the stack trace:

===

Process:         Python [939]
Path:            /Applications/Python 2.7/IDLE.app/Contents/MacOS/Python
Identifier:      org.python.IDLE
Version:         2.7.3 (2.7.3)
Code Type:       X86 (Native)
Parent Process:  launchd [244]
User ID:         501

Date/Time:       2012-10-09 12:35:26.330 -0400
OS Version:      Mac OS X 10.8.2 (12C60)
Report Version:  10

Interval Since Last Report:          3854 sec
Crashes Since Last Report:           2
Per-App Interval Since Last Report:  414 sec
Per-App Crashes Since Last Report:   2
Anonymous UUID:                      D6AA1A7A-720D-AF63-8D8A-D288BC5CC1FC

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

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

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

Application Specific Backtrace 1:
0   CoreFoundation                      0x94d6012b __raiseError + 219
1   libobjc.A.dylib                     0x9a3c652e objc_exception_throw + 230
2   CoreFoundation                      0x94cbfbbb +[NSException raise:format:] + 139
3   AppKit                              0x91f4a68c _NXCreateWindowWithStyleMask + 302
4   AppKit                              0x91fe11f5 _NSCreateWindow + 57
5   AppKit                              0x91e5f033 -[NSWindow _commonAwake] + 2066
6   AppKit                              0x91f0a4c0 -[NSWindow _makeKeyRegardlessOfVisibility] + 104
7   AppKit                              0x91f0a416 -[NSWindow makeKeyAndOrderFront:] + 35
8   Tk                                  0x00643e0c XMapWindow + 149
9   Tk                                  0x0064aaac TkWmMapWindow + 289
10  Tk                                  0x005a37c3 Tk_MapWindow + 89
11  Tk                                  0x005ad80e MapFrame + 72
12  Tcl                                 0x00513858 TclServiceIdle + 61
13  Tcl                                 0x004f5b6b Tcl_DoOneEvent + 342
14  Tk                                  0x0057f536 Tk_UpdateObjCmd + 190
15  Tcl                                 0x004868a3 TclEvalObjvInternal + 763
16  Tcl                                 0x004878c6 Tcl_EvalObjv + 72
17  _tkinter.so                         0x002d1a62 Tkapp_Call + 210
18  Python                              0x000c20d0 PyEval_EvalFrameEx + 26112
19  Python                              0x000c334b PyEval_EvalFrameEx + 30843
20  Python                              0x000c334b PyEval_EvalFrameEx + 30843
21  Python                              0x000c442c PyEval_EvalCodeEx + 1996
22  Python                              0x0003efbb function_call + 139
23  Python                              0x0000d855 PyObject_Call + 85
24  Python                              0x000bf937 PyEval_EvalFrameEx + 15975
25  Python                              0x000c442c PyEval_EvalCodeEx + 1996
26  Python                              0x0003efbb function_call + 139
27  Python                              0x0000d855 PyObject_Call + 85
28  Python                              0x000bf937 PyEval_EvalFrameEx + 15975
29  Python                              0x000c442c PyEval_EvalCodeEx + 1996
30  Python                              0x0003efbb function_call + 139
31  Python                              0x0000d855 PyObject_Call + 85
32  Python                              0x0001fda5 instancemethod_call + 389
33  Python                              0x0000d855 PyObject_Call + 85
34  Python                              0x000ba85e PyEval_CallObjectWithKeywords + 78
35  _tkinter.so                         0x002cfa24 PythonCmd + 340
36  Tcl                                 0x004830c1 TclInvokeStringCommand + 96
37  Tcl                                 0x004868a3 TclEvalObjvInternal + 763
38  Tcl                                 0x004c35a7 TclExecuteByteCode + 4691
39  Tcl                                 0x004cc82c TclCompEvalObj + 448
40  Tcl                                 0x00487cd0 TclEvalObjEx + 877
41  Tcl                                 0x00487dd1 Tcl_EvalObjEx + 47
42  Tcl                                 0x00513b22 AfterProc + 83
43  Tcl                                 0x005139fc TimerHandlerEventProc + 87
44  Tcl                                 0x004f5867 Tcl_ServiceEvent + 160
45  Tcl                                 0x004f5b5a Tcl_DoOneEvent + 325
46  _tkinter.so                         0x002cf5e2 Tkapp_MainLoop + 450
47  Python                              0x000c20d0 PyEval_EvalFrameEx + 26112
48  Python                              0x000c442c PyEval_EvalCodeEx + 1996
49  Python                              0x000c1ddb PyEval_EvalFrameEx + 25355
50  Python                              0x000c334b PyEval_EvalFrameEx + 30843
51  Python                              0x000c442c PyEval_EvalCodeEx + 1996
52  Python                              0x000c4577 PyEval_EvalCode + 87
53  Python                              0x000e8b2c PyRun_FileExFlags + 172
54  Python                              0x000e8e94 PyRun_SimpleFileExFlags + 596
55  Python                              0x00100efc Py_Main + 3404
56  Python                              0x00001f65 start + 53

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.CoreFoundation      	0x94d60947 ___TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION___ + 7
1   libobjc.A.dylib               	0x9a3c652e objc_exception_throw + 230
2   com.apple.CoreFoundation      	0x94cbfbbb +[NSException raise:format:] + 139
3   com.apple.AppKit              	0x91f4a68c _NXCreateWindowWithStyleMask + 302
4   com.apple.AppKit              	0x91fe11f5 _NSCreateWindow + 57
5   com.apple.AppKit              	0x91e5f033 -[NSWindow _commonAwake] + 2066
6   com.apple.AppKit              	0x91f0a4c0 -[NSWindow _makeKeyRegardlessOfVisibility] + 104
7   com.apple.AppKit              	0x91f0a416 -[NSWindow makeKeyAndOrderFront:] + 35
8   Tk                            	0x00643e0c XMapWindow + 149
9   Tk                            	0x0064aaac TkWmMapWindow + 289
10  Tk                            	0x005a37c3 Tk_MapWindow + 89
11  Tk                            	0x005ad80e MapFrame + 72
12  Tcl                           	0x00513858 TclServiceIdle + 61
13  Tcl                           	0x004f5b6b Tcl_DoOneEvent + 342
14  Tk                            	0x0057f536 Tk_UpdateObjCmd + 190
15  Tcl                           	0x004868a3 TclEvalObjvInternal + 763
16  Tcl                           	0x004878c6 Tcl_EvalObjv + 72
17  _tkinter.so                   	0x002d1a62 Tkapp_Call + 210
18  org.python.python             	0x000c20d0 PyEval_EvalFrameEx + 26112
19  org.python.python             	0x000c334b PyEval_EvalFrameEx + 30843
20  org.python.python             	0x000c334b PyEval_EvalFrameEx + 30843
21  org.python.python             	0x000c442c PyEval_EvalCodeEx + 1996
22  org.python.python             	0x0003efbb function_call + 139
23  org.python.python             	0x0000d855 PyObject_Call + 85
24  org.python.python             	0x000bf937 PyEval_EvalFrameEx + 15975
25  org.python.python             	0x000c442c PyEval_EvalCodeEx + 1996
26  org.python.python             	0x0003efbb function_call + 139
27  org.python.python             	0x0000d855 PyObject_Call + 85
28  org.python.python             	0x000bf937 PyEval_EvalFrameEx + 15975
29  org.python.python             	0x000c442c PyEval_EvalCodeEx + 1996
30  org.python.python             	0x0003efbb function_call + 139
31  org.python.python             	0x0000d855 PyObject_Call + 85
32  org.python.python             	0x0001fda5 instancemethod_call + 389
33  org.python.python             	0x0000d855 PyObject_Call + 85
34  org.python.python             	0x000ba85e PyEval_CallObjectWithKeywords + 78
35  _tkinter.so                   	0x002cfa24 PythonCmd + 340
36  Tcl                           	0x004830c1 TclInvokeStringCommand + 96
37  Tcl                           	0x004868a3 TclEvalObjvInternal + 763
38  Tcl                           	0x004c35a7 TclExecuteByteCode + 4691
39  Tcl                           	0x004cc82c TclCompEvalObj + 448
40  Tcl                           	0x00487cd0 TclEvalObjEx + 877
41  Tcl                           	0x00487dd1 Tcl_EvalObjEx + 47
42  Tcl                           	0x00513b22 AfterProc + 83
43  Tcl                           	0x005139fc TimerHandlerEventProc + 87
44  Tcl                           	0x004f5867 Tcl_ServiceEvent + 160
45  Tcl                           	0x004f5b5a Tcl_DoOneEvent + 325
46  _tkinter.so                   	0x002cf5e2 Tkapp_MainLoop + 450
47  org.python.python             	0x000c20d0 PyEval_EvalFrameEx + 26112
48  org.python.python             	0x000c442c PyEval_EvalCodeEx + 1996
49  org.python.python             	0x000c1ddb PyEval_EvalFrameEx + 25355
50  org.python.python             	0x000c334b PyEval_EvalFrameEx + 30843
51  org.python.python             	0x000c442c PyEval_EvalCodeEx + 1996
52  org.python.python             	0x000c4577 PyEval_EvalCode + 87
53  org.python.python             	0x000e8b2c PyRun_FileExFlags + 172
54  org.python.python             	0x000e8e94 PyRun_SimpleFileExFlags + 596
55  org.python.python             	0x00100efc Py_Main + 3404
56  Python                        	0x00001f65 start + 53

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib        	0x92c879ae kevent + 10
1   libdispatch.dylib             	0x9874bc71 _dispatch_mgr_invoke + 993
2   libdispatch.dylib             	0x9874b7a9 _dispatch_mgr_thread + 53

Thread 2:
0   libsystem_kernel.dylib        	0x92c86be6 __select + 10
1   Tcl                           	0x0052dddc NotifierThreadProc + 628
2   libsystem_c.dylib             	0x90024557 _pthread_start + 344
3   libsystem_c.dylib             	0x9000ecee thread_start + 34

Thread 3:
0   libsystem_kernel.dylib        	0x92c870ee __workq_kernreturn + 10
1   libsystem_c.dylib             	0x9002704c _pthread_workq_return + 45
2   libsystem_c.dylib             	0x90026e19 _pthread_wqthread + 448
3   libsystem_c.dylib             	0x9000ecca start_wqthread + 30

Thread 4:
0   libsystem_kernel.dylib        	0x92c870ee __workq_kernreturn + 10
1   libsystem_c.dylib             	0x9002704c _pthread_workq_return + 45
2   libsystem_c.dylib             	0x90026e19 _pthread_wqthread + 448
3   libsystem_c.dylib             	0x9000ecca start_wqthread + 30

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x00000001  ebx: 0x91f4a56c  ecx: 0x00000000  edx: 0x00000000
  edi: 0x9a3c6459  esi: 0x01344420  ebp: 0xbfffc778  esp: 0xbfffc770
   ss: 0x00000023  efl: 0x00000282  eip: 0x94d60947   cs: 0x0000001b
   ds: 0x00000023   es: 0x00000023   fs: 0x00000000   gs: 0x0000000f
  cr2: 0x03e28000
Logical CPU: 0

Binary Images:
    0x1000 -     0x1ff7 +Python (???) <29B5B804-F1D9-9479-C323-93A3CDC57AFB> /Applications/Python 2.7/IDLE.app/Contents/MacOS/Python
    0x4000 -   0x143fef +org.python.python (2.7.3, [c] 2004-2012 Python Software Foundation. - 2.7.3) <FD99E7D3-6074-3407-CDCA-60325EEF10B0> /Library/Frameworks/Python.framework/Versions/2.7/Python
  0x2cb000 -   0x2d2ff7 +_tkinter.so (???) <2203E5FF-8BB5-890A-AADE-D6A2DD3660C8> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so
  0x2f9000 -   0x2faff7 +_functools.so (???) <16121BC9-08BF-E95C-B0B5-0658E1C35A6E> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_functools.so
  0x2fd000 -   0x2fdff7 +_bisect.so (???) <FCF7A934-E8FC-5758-F03E-367FACD849B4> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_bisect.so
  0x476000 -   0x547ff7 +Tcl (8.5.12 - 8.5.12) <00EBD0B6-82ED-061A-624C-5B6CF37404A7> /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
  0x571000 -   0x66fff7 +Tk (8.5.12 - 8.5.12) <F87FEF34-B94E-1885-7B8F-951C9CF49D58> /Library/Frameworks/Tk.framework/Versions/8.5/Tk
  0x71c000 -   0x71fff7 +strop.so (???) <F29398D5-4ACC-6CA8-23CB-E8AF85FCCE1B> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/strop.so
  0x724000 -   0x72bff7 +_socket.so (???) <B9C33EDF-B2FB-FB9D-5959-85B3F23E66A7> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_socket.so
  0x733000 -   0x737ff7 +_ssl.so (???) <4D9F69F6-22BE-925B-0DE2-4543AC97670B> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_ssl.so
  0x73c000 -   0x73dff7 +cStringIO.so (???) <B648D1B6-1840-82FA-55B1-D110674480F1> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cStringIO.so
  0x741000 -   0x742ff7 +time.so (???) <D442DC31-686C-258A-22C8-7D392C764AE0> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/time.so
  0x787000 -   0x78aff7 +_collections.so (???) <B2C89359-7BED-B145-B18D-B0BBA2C71922> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_collections.so
  0x78f000 -   0x792ff7 +operator.so (???) <500ED0D7-8256-9177-FFBE-A062C8D4B5B1> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/operator.so
  0x798000 -   0x79dff7 +itertools.so (???) <0AF90C35-D9B1-ED5D-D858-1EE69365C494> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/itertools.so
  0x7a5000 -   0x7a6ff7 +_heapq.so (???) <5EADF056-B563-A561-7233-80BA83EB32FD> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_heapq.so
  0x7aa000 -   0x7acff7 +select.so (???) <D467F68F-253A-8C39-E47E-4B32C89E572B> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/select.so
  0x7b1000 -   0x7b2ff7 +fcntl.so (???) <7088363F-1775-BA36-C287-17FD8AF19CA3> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/fcntl.so
  0x7f5000 -   0x7f8ff7 +_struct.so (???) <D316ACA7-7AE6-9231-F29C-C31C480FCAEC> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_struct.so
 0x1760000 -  0x1762fe7 +binascii.so (???) <0D4871C8-B6E6-CC90-A85F-69C3237D20A8> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/binascii.so
 0x17e6000 -  0x17eaff7 +math.so (???) <8D0974C4-045D-7BAA-49A3-9F0EEEA93FF1> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/math.so
 0x17ef000 -  0x17f0ff7 +_hashlib.so (???) <77A9F87D-DD81-778A-2F30-103E258B42C0> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_hashlib.so
 0x17f4000 -  0x17f5ff7 +_random.so (???) <9AED8CAA-DAB6-4C13-4C48-5D6D19D84976> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_random.so
 0x17f8000 -  0x17f9ff7 +_locale.so (???) <1E2000E4-CA1B-1FE1-4196-10CDBA41FEDE> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_locale.so
 0x2240000 -  0x224eff7 +cPickle.so (???) <42F1F3CA-20AA-D04F-62ED-833137B12B6D> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cPickle.so
 0x22ba000 -  0x22c7ff3  com.apple.Librarian (1.1 - 1) <88A55A5E-40FF-3234-8394-2317120B79AB> /System/Library/PrivateFrameworks/Librarian.framework/Versions/A/Librarian
 0x22f2000 -  0x22f4fff  libCoreFSCache.dylib (24.4) <A089ED2E-0156-3937-BE32-5BED76DF4066> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib
 0x22fb000 -  0x22fbff7 +cl_kernels (???) <73336EEE-EACC-468C-887B-2CE5E1754497> cl_kernels
 0x3e15000 -  0x3e1dffc  libcldcpuengine.dylib (2.1.19) <E5429AB3-FE28-3C0C-8942-686BB4191A9E> /System/Library/Frameworks/OpenCL.framework/Libraries/libcldcpuengine.dylib
 0x57fa000 -  0x57fbff5 +cl_kernels (???) <463016D5-EB14-4B36-8313-A61656D10AE2> cl_kernels
 0x68f2000 -  0x68f3ff1 +cl_kernels (???) <0795B9F8-EECA-4C88-83D3-2D44F9092462> cl_kernels
 0x7c0f000 -  0x7ca1ff7  unorm8_bgra.dylib (2.1.19) <A2C66114-F581-3D86-9BC9-9994156640AF> /System/Library/Frameworks/OpenCL.framework/Libraries/ImageFormats/unorm8_bgra.dylib
 0x7ff9000 -  0x7ffaffd +cl_kernels (???) <9C926F47-0EC5-49C9-83F6-516C4A596F6E> cl_kernels
 0xa000000 -  0xa092ff7  unorm8_argb.dylib (2.1.19) <1B67DB26-5B5D-3600-8049-D744F133BEB1> /System/Library/Frameworks/OpenCL.framework/Libraries/ImageFormats/unorm8_argb.dylib
0x8fefb000 - 0x8ff2de57  dyld (210.2.3) <23516BE4-29BE-350C-91C9-F36E7999F0F1> /usr/lib/dyld
0x90007000 - 0x9000dfff  com.apple.phonenumbers (1.1 - 47) <DD22B3D1-DA4B-3794-9D73-E90D49A1F88E> /System/Library/PrivateFrameworks/PhoneNumbers.framework/Versions/A/PhoneNumbers
0x9000e000 - 0x900cbfeb  libsystem_c.dylib (825.25) <B1F6916A-F558-38B5-A18C-D9733625FDC9> /usr/lib/system/libsystem_c.dylib
0x900cc000 - 0x90130ff3  libstdc++.6.dylib (56) <F8FA490A-8F3C-3645-ABF5-78926CE9C62C> /usr/lib/libstdc++.6.dylib
0x90131000 - 0x90137fff  libGFXShared.dylib (8.6.1) <E32A7266-FCDD-352C-9C2A-8939265974AF> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
0x90138000 - 0x90162ff9  com.apple.framework.Apple80211 (8.0.1 - 801.17) <8A8BBBFD-496B-35A6-A26E-ADF8D672D908> /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Apple80211
0x90163000 - 0x902dbff5  com.apple.QuartzCore (1.8 - 304.0) <0B0EC55A-9084-3E28-9A84-1813CE3FAA9B> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x902dc000 - 0x90333ff3  com.apple.Suggestions (2.0 - 102.1) <AA369EDE-913D-3C0D-8CE1-92C1C171CCA7> /System/Library/PrivateFrameworks/Suggestions.framework/Versions/A/Suggestions
0x90334000 - 0x90350ff7  libPng.dylib (845) <14C43094-C670-3575-BF9B-3A967E05EAC0> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
0x90351000 - 0x90656ff7  com.apple.CoreServices.CarbonCore (1037.3 - 1037.3) <4571EDDC-704A-3FB1-B9A6-59870AA6165F> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x90657000 - 0x9070bfff  com.apple.coreui (2.0 - 181.1) <C15ABF35-B7F5-34ED-A461-386DAF65D96B> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
0x9070c000 - 0x90767ff7  com.apple.AppleVAFramework (5.0.18 - 5.0.18) <4BA2AAEA-4936-375C-B4D8-4BBE2EDC7FF5> /System/Library/PrivateFrameworks/AppleVA.framework/Versions/A/AppleVA
0x90768000 - 0x907c2fff  com.apple.Symbolication (1.3 - 93) <684ECF0D-D416-3DF8-8B5B-3902953853A8> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
0x907c3000 - 0x9080aff3  com.apple.CoreMedia (1.0 - 926.62) <69B3835E-C02F-3935-AD39-83F8E81FB780> /System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia
0x9080b000 - 0x9080cffd  com.apple.TrustEvaluationAgent (2.0 - 23) <E42347C0-2D3C-36A4-9200-757FFA61B388> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
0x9080d000 - 0x90851fff  libGLU.dylib (8.6.1) <06BAFDCA-800C-35E3-B1A3-F05E105B86AB> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x90852000 - 0x90c35ff3  com.apple.HIToolbox (2.0 - 625) <5A312E41-9940-363E-B891-90C4672E6850> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x90c36000 - 0x90cbefff  com.apple.PDFKit (2.7.2 - 2.7.2) <7AE7BAE9-4C21-3BFB-919E-5C6EEBBDFF75> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/PDFKit.framework/Versions/A/PDFKit
0x90ce5000 - 0x90cfcff4  com.apple.CoreMediaAuthoring (2.1 - 914) <37C0A2C7-73B3-39BC-8DE1-4A6B75F115FC> /System/Library/PrivateFrameworks/CoreMediaAuthoring.framework/Versions/A/CoreMediaAuthoring
0x91405000 - 0x91406fff  libdnsinfo.dylib (453.18) <41C7B8E2-2A81-31DE-BD8B-F0C29E169D4F> /usr/lib/system/libdnsinfo.dylib
0x91407000 - 0x914a7ff7  com.apple.QD (3.42 - 285) <1B8307C6-AFA8-312E-BA5B-679070EF2CA1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
0x914a8000 - 0x914b4ffa  com.apple.CrashReporterSupport (10.8.2 - 415) <BAE9900A-51E7-3AD4-A7FB-7E6CCFFB2F21> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport
0x914b5000 - 0x914b5fff  libkeymgr.dylib (25) <D5E93F7F-9315-3AD6-92C7-941F7B54C490> /usr/lib/system/libkeymgr.dylib
0x914b6000 - 0x914bcfff  com.apple.print.framework.Print (8.0 - 258) <12AEAD24-6924-3923-9E4A-C5D21231E639> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
0x914cb000 - 0x914ccfff  libremovefile.dylib (23.1) <98622D14-DAAB-3AD8-A5D9-C322BF572A98> /usr/lib/system/libremovefile.dylib
0x914d3000 - 0x914deffb  com.apple.DirectoryService.Framework (10.8 - 151.10) <234F4A14-60ED-300B-93B2-D5052878558F> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
0x914df000 - 0x914edfff  com.apple.opengl (1.8.6 - 1.8.6) <1AD1AE7B-B57B-35B5-B571-32A34F0DA737> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
0x914ee000 - 0x914fbff7  com.apple.AppleFSCompression (49 - 1.0) <166AA1F8-E50A-3533-A3B5-8737C5118CC3> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
0x914fc000 - 0x914fdfff  libsystem_sandbox.dylib (220) <4E42390B-25EC-3530-AF01-337E430C16EB> /usr/lib/system/libsystem_sandbox.dylib
0x914fe000 - 0x91505fff  liblaunch.dylib (442.26.2) <310C99F8-0811-314D-9BB9-D0ED6DFA024B> /usr/lib/system/liblaunch.dylib
0x91506000 - 0x91508fff  libdyld.dylib (210.2.3) <05D6FF2A-F09B-309D-95F7-7AF10259C707> /usr/lib/system/libdyld.dylib
0x91509000 - 0x9150afff  libDiagnosticMessagesClient.dylib (8) <39B3D25A-148A-3936-B800-0D393A00E64F> /usr/lib/libDiagnosticMessagesClient.dylib
0x9150b000 - 0x91515fff  libCSync.A.dylib (324.6) <D2E8AC70-C6D1-3C40-8A82-E50422EDCFBF> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
0x91516000 - 0x9188eff3  com.apple.FinderKit (1.1.1 - 1.1.1) <5868FEF0-E512-3E22-91FF-7AFE4F7580A1> /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit
0x91899000 - 0x91913ff7  com.apple.securityfoundation (6.0 - 55115.4) <A959B2F5-9D9D-3C93-A62A-7399594CF238> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
0x91914000 - 0x91962ffb  libFontRegistry.dylib (100) <3B8350C2-4D8F-38C4-A22E-2F855D7E83D1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
0x91963000 - 0x91988ff7  com.apple.CoreVideo (1.8 - 99.3) <5B872AC0-E82D-3475-A3F9-FD95F380560D> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
0x91989000 - 0x9198cff7  libcompiler_rt.dylib (30) <CE5DBDB4-0124-3E2B-9105-989DF98DD108> /usr/lib/system/libcompiler_rt.dylib
0x91991000 - 0x91accff7  libBLAS.dylib (1073.4) <FF74A147-05E1-37C4-BC10-7DEB57FE5326> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x91acd000 - 0x91b0cff7  com.apple.bom (12.0 - 192) <0637E52C-D151-37B3-904F-8656B2FD44DD> /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom
0x91b0d000 - 0x91be1fff  com.apple.backup.framework (1.4.1 - 1.4.1) <55F2A679-9B21-3F43-A580-4C2ECF6A5FC5> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup
0x91be2000 - 0x91be2ffe  com.apple.AOSMigrate (1.0 - 1) <4EA0829E-6AE5-3877-A5B6-032AFDF28D39> /System/Library/PrivateFrameworks/AOSMigrate.framework/Versions/A/AOSMigrate
0x91bf2000 - 0x91c1fffe  libsystem_m.dylib (3022.6) <9975D9C3-3B71-38E3-AA21-C5C5F9D9C431> /usr/lib/system/libsystem_m.dylib
0x91c20000 - 0x91c88fe7  libvDSP.dylib (380.6) <55780308-4DCA-3B10-9703-EAFC3E13A3FA> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
0x91cb8000 - 0x91ce7ff7  com.apple.securityinterface (6.0 - 55024.4) <7C5E28DC-F8BE-3238-883F-E1646A2AF895> /System/Library/Frameworks/SecurityInterface.framework/Versions/A/SecurityInterface
0x91ce8000 - 0x91cf2fff  com.apple.speech.recognition.framework (4.1.5 - 4.1.5) <B855E8B4-2EE3-3BFF-8547-98A0F084F9AF> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
0x91cf3000 - 0x928afffb  com.apple.AppKit (6.8 - 1187.34) <06EDB1D1-3B8A-3699-8E3A-D8F50A27AB7C> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x928b0000 - 0x928b7fff  libsystem_dnssd.dylib (379.32.1) <6A505284-2382-3F27-B96F-15FFDACF004E> /usr/lib/system/libsystem_dnssd.dylib
0x928ba000 - 0x928d9ff3  com.apple.Ubiquity (1.2 - 243.10) <D2C9F356-1681-31D2-B292-5227E2DDEB0B> /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity
0x928da000 - 0x928dcffb  libRadiance.dylib (845) <3F87840F-217D-3074-A29D-919BAAED2F4A> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x928dd000 - 0x928ddfff  com.apple.ApplicationServices (45 - 45) <677C4ACC-9D12-366F-8A87-B898AC806DD9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
0x928de000 - 0x92c71ffb  com.apple.MediaToolbox (1.0 - 926.62) <7290B07B-4D03-3B46-809C-64C8FB97B40C> /System/Library/Frameworks/MediaToolbox.framework/Versions/A/MediaToolbox
0x92c72000 - 0x92c8cffc  libsystem_kernel.dylib (2050.18.24) <C17D49D0-7961-3B67-B443-C788C6E5AA76> /usr/lib/system/libsystem_kernel.dylib
0x92c8d000 - 0x92c9ffff  libbsm.0.dylib (32) <DADD385E-FE53-3458-94FB-E316A6345108> /usr/lib/libbsm.0.dylib
0x92ca0000 - 0x92d06ffc  com.apple.ISSupport (1.9.8 - 56) <D2AC4E10-0B3C-3194-AEB7-1E9964CBC0D0> /System/Library/PrivateFrameworks/ISSupport.framework/Versions/A/ISSupport
0x92d07000 - 0x92d8cff7  com.apple.SearchKit (1.4.0 - 1.4.0) <454E950F-291C-3E95-8F35-05CA0AD6B327> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x92d8d000 - 0x92d90ff7  com.apple.TCC (1.0 - 1) <437D76CD-6437-3B55-BE2C-A53508858256> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
0x92d91000 - 0x92de0ff6  libTIFF.dylib (845) <989A2EB9-3A49-3157-8E9C-B16E6005BC64> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x92e0d000 - 0x92e0dffd  libOpenScriptingUtil.dylib (148.2) <907E25B1-4F50-3461-B8D5-733C687EB534> /usr/lib/libOpenScriptingUtil.dylib
0x92e0e000 - 0x92e5cff3  com.apple.SystemConfiguration (1.12.2 - 1.12.2) <7BA6C58B-0357-356F-BB69-17ACB5E35988> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x92e5d000 - 0x92e90ff5  libssl.0.9.8.dylib (47) <3224FBB3-3074-3022-AD9A-187703680C03> /usr/lib/libssl.0.9.8.dylib
0x92edd000 - 0x92ee9ff7  com.apple.NetAuth (4.0 - 4.0) <4983C4B8-9D95-3C4D-897E-07743326487E> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
0x92eea000 - 0x92f63ff0  com.apple.CorePDF (2.0 - 2) <6B5BF755-F336-359C-9A99-F006F61442CF> /System/Library/PrivateFrameworks/CorePDF.framework/Versions/A/CorePDF
0x92f64000 - 0x92f81fff  libCRFSuite.dylib (33) <C9D72D0C-871A-39A2-8AFB-682D11AE7D0D> /usr/lib/libCRFSuite.dylib
0x92f82000 - 0x9309aff7  com.apple.coreavchd (5.6.0 - 5600.4.16) <F024C78B-4FAA-38F1-A182-AD0A0A596CBE> /System/Library/PrivateFrameworks/CoreAVCHD.framework/Versions/A/CoreAVCHD
0x9309b000 - 0x930c4fff  libxslt.1.dylib (11.3) <0DE17DAA-66FF-3195-AADB-347BEB5E2EFA> /usr/lib/libxslt.1.dylib
0x930c5000 - 0x930f8ff3  com.apple.GSS (3.0 - 2.0) <B1D719C1-B000-3BE3-B747-329D608585DD> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
0x93136000 - 0x93366fff  com.apple.QuartzComposer (5.1 - 284) <4E8682B7-EBAE-3C40-ABDB-8705EC7952BD> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuartzComposer.framework/Versions/A/QuartzComposer
0x93367000 - 0x9336aff3  com.apple.AppleSystemInfo (2.0 - 2) <4639D755-8A68-31C9-95C4-7E7F70C233FA> /System/Library/PrivateFrameworks/AppleSystemInfo.framework/Versions/A/AppleSystemInfo
0x9336b000 - 0x9336bfff  com.apple.Cocoa (6.7 - 19) <354094F0-F36B-36F9-BF5F-FD60590FBEB9> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
0x9339d000 - 0x933a6ffd  com.apple.audio.SoundManager (4.0 - 4.0) <ABC5FE40-B222-36EB-9905-5C8C4BFD8C87> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound
0x933a7000 - 0x933d3ff7  libsystem_info.dylib (406.17) <AA5611DB-A944-3072-B6BE-ACAB08689547> /usr/lib/system/libsystem_info.dylib
0x933d4000 - 0x9362cff1  com.apple.JavaScriptCore (8536 - 8536.26.7) <75629E05-65FE-3699-8CDC-80C95015CF42> /System/Library/Frameworks/JavaScriptCore.framework/Versions/A/JavaScriptCore
0x9362d000 - 0x9368afff  com.apple.audio.CoreAudio (4.1.0 - 4.1.0) <9549B81F-4425-34EE-802B-F462068DC0C5> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x93697000 - 0x936d9ff7  libauto.dylib (185.1) <B2B5B639-6778-352A-828D-FD8B64A3E8B3> /usr/lib/libauto.dylib
0x93778000 - 0x937a5ffb  com.apple.CoreServicesInternal (154.2 - 154.2) <DCCF604B-1DB8-3F09-8122-545E2E7F466D> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal
0x937a6000 - 0x937cbffb  com.apple.framework.familycontrols (4.1 - 410) <5A8504E7-D95D-3101-8E20-38EADE8DEAE1> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
0x937cc000 - 0x937d6fff  libsystem_notify.dylib (98.5) <7EEE9475-18F8-3099-B0ED-23A3E528ABE0> /usr/lib/system/libsystem_notify.dylib
0x937d7000 - 0x938cbff3  com.apple.QuickLookUIFramework (4.0 - 555.4) <D66F61A6-2C4C-359F-A2E3-7D023C33CB5A> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuickLookUI.framework/Versions/A/QuickLookUI
0x938cc000 - 0x93f58feb  com.apple.CoreAUC (6.16.00 - 6.16.00) <654A0AB8-F24F-3489-8F70-F0A22414FE08> /System/Library/PrivateFrameworks/CoreAUC.framework/Versions/A/CoreAUC
0x93f59000 - 0x93f79ffd  com.apple.ChunkingLibrary (2.0 - 133.2) <FE5F0F1E-B15D-3F76-8655-DC2FE19BF56E> /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary
0x93f7a000 - 0x93f7dfff  com.apple.help (1.3.2 - 42) <AD7EB1F0-A068-3A2C-9D59-38E59CEC0D96> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
0x93faf000 - 0x93fbdff7  libz.1.dylib (43) <245F1B61-2276-3BBB-9891-99934116D833> /usr/lib/libz.1.dylib
0x93fbe000 - 0x93fe3ff7  com.apple.quartzfilters (1.8.0 - 1.7.0) <F6A88D89-AB4A-3217-9D65-C2C259B5F09B> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuartzFilters.framework/Versions/A/QuartzFilters
0x93fe4000 - 0x93febff3  com.apple.NetFS (5.0 - 4.0) <1F7041F2-4E97-368C-8F5D-24153D81BBDB> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
0x93fec000 - 0x94015ff7  libRIP.A.dylib (324.6) <7976E6A2-A489-33F5-A727-7634DDE3B761> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
0x94016000 - 0x94023fff  libGL.dylib (8.6.1) <C7A3917A-C444-33CC-8599-BB9CD8C12BC4> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x94024000 - 0x940a0ff3  com.apple.Metadata (10.7.0 - 707.3) <6B6A6216-23D0-34CE-8099-BEE9BA42501E> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x940a1000 - 0x940acfff  libcommonCrypto.dylib (60026) <A6C6EDB8-7E69-3827-81F3-9A74D0935461> /usr/lib/system/libcommonCrypto.dylib
0x940ad000 - 0x94104ff7  com.apple.ScalableUserInterface (1.0 - 1) <2B5E454B-BC49-3E85-B54D-1950397C448C> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface
0x94105000 - 0x9410fffe  com.apple.bsd.ServiceManagement (2.0 - 2.0) <9732BA61-D6F6-3644-82DA-FF0D6FEEFC69> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
0x94110000 - 0x941e6fff  com.apple.DiscRecording (7.0 - 7000.2.4) <C14E99B9-DEFA-3812-89E5-464653B729F4> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording
0x941e7000 - 0x945e3feb  com.apple.VideoToolbox (1.0 - 926.62) <B09EEF06-CB3C-3EAA-8B0E-22A1801F3CAE> /System/Library/Frameworks/VideoToolbox.framework/Versions/A/VideoToolbox
0x945e4000 - 0x946dcff9  libsqlite3.dylib (138.1) <AD7C5914-35F0-37A3-9238-A29D2E26C755> /usr/lib/libsqlite3.dylib
0x9475a000 - 0x9475effe  libcache.dylib (57) <834FDCA7-FE3B-33CC-A12A-E11E202477EC> /usr/lib/system/libcache.dylib
0x9475f000 - 0x94761fff  libCVMSPluginSupport.dylib (8.6.1) <8A174BD9-992E-351D-8F9A-DF6991723ABE> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
0x94762000 - 0x949deff7  com.apple.QuickTime (7.7.1 - 2599.13) <FE609160-E1EF-341D-9B6A-205D3E03A4D2> /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime
0x949df000 - 0x949e2ffd  libCoreVMClient.dylib (24.4) <C54E8FD0-61EC-3DC8-8631-54288AC66AC8> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
0x949e3000 - 0x94b9fffd  libicucore.A.dylib (491.11.1) <B19E450A-BAF1-3967-9C95-7F77DC0B4639> /usr/lib/libicucore.A.dylib
0x94ba0000 - 0x94bc4fff  com.apple.PerformanceAnalysis (1.16 - 16) <18DE0F9F-1264-394D-AC56-6B2A1771DFBE> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
0x94bd3000 - 0x94c23ff7  com.apple.CoreMediaIO (301.0 - 4147) <F13FA9D4-BD1D-3297-BDD5-5858B231D738> /System/Library/Frameworks/CoreMediaIO.framework/Versions/A/CoreMediaIO
0x94c24000 - 0x94e0cff3  com.apple.CoreFoundation (6.8 - 744.12) <E939CEA0-493C-3233-9983-5070981BB350> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x94e0d000 - 0x9522afff  FaceCoreLight (2.4.1) <571DE3F8-CA8A-3E71-9AF4-F06FFE721CE6> /System/Library/PrivateFrameworks/FaceCoreLight.framework/Versions/A/FaceCoreLight
0x95232000 - 0x9554fff3  com.apple.Foundation (6.8 - 945.11) <03B242AC-519C-3683-AA52-E73536B3D55F> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x95550000 - 0x956adffb  com.apple.QTKit (7.7.1 - 2599.13) <2DC9E2BB-9895-3D02-A318-88431052E70B> /System/Library/Frameworks/QTKit.framework/Versions/A/QTKit
0x956ae000 - 0x95806ffb  com.apple.audio.toolbox.AudioToolbox (1.8 - 1.8) <9205DFC2-8DAE-354E-AD87-46E229B5F2F1> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
0x95807000 - 0x9582bfff  libJPEG.dylib (845) <547FA9A5-0BBB-3E39-BACA-F3E2DAE57DB0> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
0x9582e000 - 0x958c5ff7  com.apple.ink.framework (10.8.2 - 150) <D90FF7BC-6B90-39F1-AC52-670269947C58> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
0x958c6000 - 0x958caffc  libGIF.dylib (845) <714E9F0D-D7A3-3F58-B46E-FCBE0F144B23> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
0x958cb000 - 0x958cffff  com.apple.IOSurface (86.0.3 - 86.0.3) <E3A4DB0A-1C1A-31E3-A550-5C0E1C874509> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
0x958d0000 - 0x958e6fff  com.apple.CFOpenDirectory (10.8 - 151.10) <56C3F276-BD1F-3031-8CF9-8F4F481A534E> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
0x958e7000 - 0x958ebfff  com.apple.CommonPanels (1.2.5 - 94) <6B3E7E53-7708-3DA2-8C50-59C2B4735DE1> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
0x958ec000 - 0x9594efff  libc++.1.dylib (65.1) <C0CFF9FF-5D52-3EAE-B921-6AE1DA00A135> /usr/lib/libc++.1.dylib
0x9594f000 - 0x95991fff  libcurl.4.dylib (69.2) <8CC566A0-0B25-37E8-A6EC-30074C3CDB8C> /usr/lib/libcurl.4.dylib
0x959e9000 - 0x95a83fff  com.apple.CoreSymbolication (3.0 - 87) <6A27BBE5-6EF0-3D5D-A485-2145826B9796> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
0x95a84000 - 0x95a8cfff  com.apple.DiskArbitration (2.5.1 - 2.5.1) <25A7232F-9B6A-3746-A3A8-12479D086B1E> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x95a8d000 - 0x95d18ff3  com.apple.RawCamera.bundle (4.00 - 658) <53F1DB23-B58B-3EAF-9D1E-95C34E669DDB> /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera
0x95d19000 - 0x95d62ff7  com.apple.framework.CoreWLAN (3.0.1 - 301.11) <ABA6A926-34C2-3C09-AD9F-A87A8A35536A> /System/Library/Frameworks/CoreWLAN.framework/Versions/A/CoreWLAN
0x95d63000 - 0x95da8ff5  com.apple.opencl (2.1.20 - 2.1.20) <41C4AE6E-67B6-33E2-A9B6-BF6F01580B16> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
0x95da9000 - 0x96069fff  com.apple.security (7.0 - 55179.1) <CB470E48-621B-34D9-9E78-8B773358CB6B> /System/Library/Frameworks/Security.framework/Versions/A/Security
0x9606a000 - 0x96102fff  com.apple.CoreServices.OSServices (557.4 - 557.4) <C724AB29-A596-3E1E-9FF1-A4E509AD843A> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x96103000 - 0x96221ff7  com.apple.MediaControlSender (1.4.5 - 145.3) <E0931EE7-4ACA-3538-9658-B9B2AC1E6A80> /System/Library/PrivateFrameworks/MediaControlSender.framework/Versions/A/MediaControlSender
0x96222000 - 0x96320ff7  libFontParser.dylib (84.5) <B3006327-7B2D-3966-A56A-BD85F1D71641> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
0x96321000 - 0x9632fff3  libsystem_network.dylib (77.10) <7FBF5A15-97BA-3721-943E-E77F0C40DBE1> /usr/lib/system/libsystem_network.dylib
0x96330000 - 0x96343ff9  com.apple.MultitouchSupport.framework (235.28 - 235.28) <5C8CFA21-D4FC-32E8-B199-0F7155E6ED9A> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
0x96344000 - 0x9639dff7  com.apple.ImageCaptureCore (5.0.1 - 5.0.1) <541529F7-063E-370B-9EB2-DF5BE39073E6> /System/Library/Frameworks/ImageCaptureCore.framework/Versions/A/ImageCaptureCore
0x9639e000 - 0x9639efff  com.apple.quartzframework (1.5 - 1.5) <9018BE5B-4070-320E-8091-6584CC17F798> /System/Library/Frameworks/Quartz.framework/Versions/A/Quartz
0x963a2000 - 0x963a2fff  libsystem_blocks.dylib (59) <3A743C5D-CFA5-37D8-80A8-B6795A9DB04F> /usr/lib/system/libsystem_blocks.dylib
0x963a3000 - 0x96418ff7  com.apple.ApplicationServices.ATS (332 - 341.1) <95206704-F9C9-33C4-AF25-FE9890E160B2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
0x96419000 - 0x96502ff7  libxml2.2.dylib (22.3) <015A4FA6-5BB9-3F95-AFB8-B9281E22685B> /usr/lib/libxml2.2.dylib
0x96503000 - 0x96534fff  com.apple.DictionaryServices (1.2 - 184.4) <0D5BE86F-F40A-3E39-8569-19FCA5EDF9D3> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
0x96535000 - 0x96626ffc  libiconv.2.dylib (34) <B096A9B7-83A6-31B3-8D2F-87D91910BF4C> /usr/lib/libiconv.2.dylib
0x96627000 - 0x96668ff7  libcups.2.dylib (327) <F46F8703-FEAE-3442-87CB-45C8BF98BEE5> /usr/lib/libcups.2.dylib
0x96669000 - 0x96669fff  com.apple.CoreServices (57 - 57) <956C6C6D-A5DD-314F-9C57-4A61D41F30CE> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x9666a000 - 0x96aacfff  com.apple.CoreGraphics (1.600.0 - 324.6) <66556166-F9A7-3EEC-A562-46061C7A79E4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
0x96aad000 - 0x96b13fff  com.apple.print.framework.PrintCore (8.1 - 387.1) <F8CF762B-B707-3021-958F-BB8D33DB3576> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x96b14000 - 0x96b55ff7  com.apple.framework.CoreWiFi (1.0 - 100.10) <944B3FAE-F901-3276-A676-9D52295DA817> /System/Library/Frameworks/CoreWiFi.framework/Versions/A/CoreWiFi
0x96b56000 - 0x96b5fff3  com.apple.DisplayServicesFW (2.6.1 - 353) <50D0BBF0-F911-380F-B470-E59B5E48E520> /System/Library/PrivateFrameworks/DisplayServices.framework/Versions/A/DisplayServices
0x97899000 - 0x97b84ff7  com.apple.AOSKit (1.05 - 151) <F470C45E-620C-3FF2-AB1C-2D57FCD215E7> /System/Library/PrivateFrameworks/AOSKit.framework/Versions/A/AOSKit
0x97b85000 - 0x97b9afff  com.apple.ImageCapture (8.0 - 8.0) <B8BD421F-D5A9-3FB4-8E89-AD5CFC0D4030> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
0x97b9b000 - 0x97bb8fff  libxpc.dylib (140.41) <1BFE3149-C242-3A77-9729-B00DEDC8CCF2> /usr/lib/system/libxpc.dylib
0x97bb9000 - 0x97beeff7  com.apple.framework.internetaccounts (2.1 - 210) <8F2D0EB8-C997-3833-AA80-95AF7AA377BE> /System/Library/PrivateFrameworks/InternetAccounts.framework/Versions/A/InternetAccounts
0x97bef000 - 0x97c34ff7  com.apple.NavigationServices (3.7 - 200) <F6531764-6E43-3AF3-ACDD-8A5551EF016A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices
0x984b2000 - 0x984cbfff  com.apple.Kerberos (2.0 - 1) <9BDE8F4D-DBC3-34D1-852C-898D3655A611> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
0x984cc000 - 0x984d5ffe  com.apple.aps.framework (3.0 - 3.0) <09D5F4F3-03FD-3077-A51D-B368F18ED1D4> /System/Library/PrivateFrameworks/ApplePushService.framework/Versions/A/ApplePushService
0x984d6000 - 0x98516fff  com.apple.MediaKit (13 - 659) <37B8C1E3-B67D-3FE6-8A14-7FFD9F31C556> /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit
0x9855a000 - 0x98573ffb  com.apple.frameworks.preferencepanes (15.0 - 15.0) <802C922C-CF94-357F-B1AE-4244AA025C04> /System/Library/Frameworks/PreferencePanes.framework/Versions/A/PreferencePanes
0x98574000 - 0x985affe7  libGLImage.dylib (8.6.1) <A3442557-18D5-332E-8859-423D5A20EBBE> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x985b2000 - 0x9861aff7  com.apple.framework.IOKit (2.0 - 755.18.10) <9A80E97E-544F-3A45-916D-6DB7ED217E33> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x9861b000 - 0x98630fff  com.apple.speech.synthesis.framework (4.1.12 - 4.1.12) <DE68CEB5-4959-3652-83B8-D2B00D3B932D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x98631000 - 0x9868afff  com.apple.AE (645.3 - 645.3) <6745659F-006D-3F25-94D6-DF944E9A01FD> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x9868d000 - 0x9873cff7  com.apple.CoreText (260.0 - 275.16) <873ADCD9-D361-3753-A220-CDD289196AD8> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
0x9873d000 - 0x98746ff9  com.apple.CommonAuth (3.0 - 2.0) <A1A6CC3D-AA88-3519-A305-9B5D76C5D63B> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
0x98747000 - 0x98759ff7  libdispatch.dylib (228.23) <86EF7D45-2D97-3465-A449-95038AE5DABA> /usr/lib/system/libdispatch.dylib
0x9875a000 - 0x9875afff  com.apple.Carbon (154 - 155) <604ADD9D-5835-3294-842E-3A4AEBCCB548> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x9875b000 - 0x98972fff  com.apple.CoreData (106.1 - 407.7) <17FD06D6-AD7C-345A-8FA4-1F0FBFF4DAE1> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
0x98973000 - 0x98c0cff3  com.apple.AddressBook.framework (7.1 - 1167) <AF7B18F2-D0FF-33AA-9CE9-4106B1CDAE1D> /System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook
0x98c0d000 - 0x98c1dff7  libsasl2.2.dylib (166) <D9080BA2-A365-351E-9FF2-7E0D4E8B1339> /usr/lib/libsasl2.2.dylib
0x98c1e000 - 0x98c35fff  com.apple.GenerationalStorage (1.1 - 132.2) <93694E0D-35D3-3633-976E-F354CBD92F54> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage
0x98c36000 - 0x98cc8ffb  libvMisc.dylib (380.6) <6DA3A03F-20BE-300D-A664-B50A7B4E4B1A> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x98cc9000 - 0x98ccaffd  libunc.dylib (25) <58599CBF-E262-3CEA-AFE1-35560E0177DC> /usr/lib/system/libunc.dylib
0x98cd0000 - 0x98cd0fff  com.apple.Accelerate (1.8 - Accelerate 1.8) <4EC0548E-3A3F-310D-A366-47B51D5B6398> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x98cd1000 - 0x98ceeff7  libresolv.9.dylib (51) <B9742A2A-DF15-3F6E-8FCE-778A58214B3A> /usr/lib/libresolv.9.dylib
0x98cef000 - 0x98cf0fff  libquarantine.dylib (52) <D526310F-DC77-37EA-8F5F-83928EFA3262> /usr/lib/system/libquarantine.dylib
0x98eba000 - 0x9915dffb  com.apple.CoreImage (8.2.2 - 1.0.1) <85BFFB09-D765-3F5F-AF65-FB136DDCAEF3> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage
0x9915e000 - 0x9927aff7  com.apple.desktopservices (1.7.2 - 1.7.2) <8E74D101-8398-34F1-A463-B4950680A597> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
0x9927b000 - 0x99404ff7  com.apple.vImage (6.0 - 6.0) <1D1F67FE-4F75-3689-BEF6-4A46C8039E70> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x99405000 - 0x99460fff  com.apple.htmlrendering (77 - 1.1.4) <5C0C669F-AE07-3983-B38F-EB829B5CE609> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
0x99461000 - 0x9947fff3  com.apple.openscripting (1.3.6 - 148.2) <55738D66-CC15-3F43-9265-00C3322D39C4> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
0x99484000 - 0x99487ff9  libCGXType.A.dylib (324.6) <3004616B-51F6-3B9D-8B85-DCCA3DF9BC10> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib
0x99488000 - 0x99569fff  libcrypto.0.9.8.dylib (47) <D4EFFCFB-206D-3E3D-ADB5-CBAF04EB8838> /usr/lib/libcrypto.0.9.8.dylib
0x9956a000 - 0x995cefff  com.apple.datadetectorscore (4.0 - 269.1) <4D155F09-1A60-325A-BCAC-1B858C2C051B> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
0x995cf000 - 0x995d6ffb  libunwind.dylib (35.1) <E1E8D8B3-3C78-3AB1-B398-C180DC6DCF05> /usr/lib/system/libunwind.dylib
0x995d7000 - 0x99681fff  com.apple.LaunchServices (539.7 - 539.7) <AF33EBD3-BC0B-30B5-B7DA-5CCCF12D7EDD> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x99682000 - 0x996f1ffb  com.apple.Heimdal (3.0 - 2.0) <1ABF438B-30E6-3165-968C-E2EA1A9DF1FD> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
0x996fa000 - 0x996fcfff  com.apple.securityhi (4.0 - 55002) <62E3AE75-61CB-341E-B2A0-CFC985A2BF7F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
0x996fd000 - 0x99732fff  libTrueTypeScaler.dylib (84.5) <2598F930-5E6B-37D7-B1E6-18181A972C6E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib
0x99733000 - 0x99755fff  libc++abi.dylib (24.4) <06479DA4-BC23-34B6-BAFC-A885814261D0> /usr/lib/libc++abi.dylib
0x99756000 - 0x99757fff  liblangid.dylib (116) <E13CC8C5-5034-320A-A210-41A2BDE4F846> /usr/lib/liblangid.dylib
0x99758000 - 0x9978effb  com.apple.DebugSymbols (98 - 98) <9A9ADA0A-E487-3C8F-9998-286EE04C235A> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
0x99827000 - 0x9982bff7  libmacho.dylib (829) <5280A013-4F74-3F74-BE0C-7F612C49F1DC> /usr/lib/system/libmacho.dylib
0x9982c000 - 0x9982fffc  libpam.2.dylib (20) <FCF74195-A99E-3B07-8E49-688D4A6F1E18> /usr/lib/libpam.2.dylib
0x99830000 - 0x9993bff7  libJP2.dylib (845) <D409C913-6FA4-3D60-BFE0-B9FC6A02FEE0> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
0x9993c000 - 0x99948ff8  libbz2.1.0.dylib (29) <7031A4C0-784A-3EAA-93DF-EA1F26CC9264> /usr/lib/libbz2.1.0.dylib
0x99949000 - 0x99a45ff3  com.apple.DiskImagesFramework (10.8 - 344) <98C16F91-9D3E-3FD0-A30B-BD49EE4ED9A4> /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages
0x99a46000 - 0x99a4efff  com.apple.CommerceCore (1.0 - 26) <AF0D1990-8CBF-3AB4-99DF-8B7AE14FB0D5> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore
0x99a4f000 - 0x99aa6ff3  com.apple.HIServices (1.20 - 417) <561A770B-8523-3D09-A763-11F872779A4C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
0x99aa7000 - 0x99aabfff  com.apple.OpenDirectory (10.8 - 151.10) <A1858D81-086F-3BF5-87E3-9B70409FFDF6> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
0x99aac000 - 0x99aacffd  com.apple.audio.units.AudioUnit (1.8 - 1.8) <4C13DEA2-1EB0-3D06-901A-DB93184C06F0> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x99aad000 - 0x99aadfff  com.apple.vecLib (3.8 - vecLib 3.8) <83160DD1-5614-3E34-80EB-97041016EF1F> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
0x99aae000 - 0x99afafff  libcorecrypto.dylib (106.2) <20EBADBA-D6D6-36F0-AE80-168E9AF13DB6> /usr/lib/system/libcorecrypto.dylib
0x99afb000 - 0x99b07ffe  libkxld.dylib (2050.18.24) <48A75AF6-9D5A-3552-948E-30A1682D3664> /usr/lib/system/libkxld.dylib
0x99b08000 - 0x99b08fff  libSystem.B.dylib (169.3) <81C58EAB-0E76-3EAB-BDFD-C5A6FE95536F> /usr/lib/libSystem.B.dylib
0x99b09000 - 0x99ec1ffa  libLAPACK.dylib (1073.4) <9A6E5EAD-F2F2-3D5C-B655-2B536DB477F2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
0x99ec2000 - 0x99f80ff3  com.apple.ColorSync (4.8.0 - 4.8.0) <EFEDCB37-4F20-3CEC-A185-5D2976E11BAC> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
0x99f83000 - 0x99fdcfff  com.apple.QuickLookFramework (4.0 - 555.4) <96911441-FDD4-3B68-9E0C-51BA11A97C2E> /System/Library/Frameworks/QuickLook.framework/Versions/A/QuickLook
0x99fdd000 - 0x9a0eaff3  com.apple.ImageIO.framework (3.2.0 - 845) <BF959BCB-C30A-3680-B7C2-91B327B2B63B> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
0x9a0eb000 - 0x9a358fff  com.apple.imageKit (2.2 - 667) <3F5F92DB-C0C0-3C5F-98C6-B84AB9E28B55> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/ImageKit.framework/Versions/A/ImageKit
0x9a359000 - 0x9a390ffa  com.apple.LDAPFramework (2.4.28 - 194.5) <8368FAE7-2B89-3A7D-B6EE-7184B522CB66> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP
0x9a391000 - 0x9a39ffff  libxar.1.dylib (105) <343E4A3B-1D04-34A3-94C2-8C7C9A8F736B> /usr/lib/libxar.1.dylib
0x9a3a3000 - 0x9a3a3fff  com.apple.Accelerate.vecLib (3.8 - vecLib 3.8) <908B8D40-3FB5-3047-B482-3DF95025ECFC> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x9a3a4000 - 0x9a3b4ff2  com.apple.LangAnalysis (1.7.0 - 1.7.0) <875363E7-6D02-3229-A9DD-E5A5568A7D61> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
0x9a3b5000 - 0x9a4c2057  libobjc.A.dylib (532.2) <FA455371-7395-3D58-A89B-D1520612D1BC> /usr/lib/libobjc.A.dylib
0x9a4c3000 - 0x9a610ffb  com.apple.CFNetwork (596.2.3 - 596.2.3) <1221EF86-659B-3136-AB57-0CC6B130CDA2> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
0x9a651000 - 0x9a659fff  libcopyfile.dylib (89) <4963541B-0254-371B-B29A-B6806888949B> /usr/lib/system/libcopyfile.dylib
0x9a65a000 - 0x9a69cffb  com.apple.RemoteViewServices (2.0 - 80.5) <60E04F2F-AFD8-3B1F-BF07-8A3A7EABB8E9> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices

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

VM Region Summary:
ReadOnly portion of Libraries: Total=168.7M resident=90.6M(54%) swapped_out_or_unallocated=78.2M(46%)
Writable regions: Total=122.9M written=11.4M(9%) resident=41.1M(33%) swapped_out=0K(0%) unallocated=81.8M(67%)
 
REGION TYPE                      VIRTUAL
===========                      =======
CG backing stores                  6624K
CG image                             92K
CG shared images                   1184K
CoreServices                       3180K
MALLOC                             89.0M
MALLOC guard page                    48K
Memory tag=240                        4K
Memory tag=242                       12K
Memory tag=35                      3404K
OpenCL                               44K
Stack                              65.6M
VM_ALLOCATE                        16.2M
__DATA                             8164K
__DATA/__OBJC                       176K
__IMAGE                             528K
__LINKEDIT                         32.2M
__OBJC                             3060K
__OBJC/__DATA                        64K
__PAGEZERO                            4K
__TEXT                            136.5M
__UNICODE                           544K
mapped file                        79.2M
shared memory                      5928K
===========                      =======
TOTAL                             451.0M

Model: MacBookPro9,1, BootROM MBP91.00D3.B08, 4 processors, Intel Core i7, 2.6 GHz, 8 GB, SMC 2.1f170
Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In, 512 MB
Graphics: NVIDIA GeForce GT 650M, NVIDIA GeForce GT 650M, PCIe, 1024 MB
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54333531533643465238432D50422020
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54333531533643465238432D50422020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xF5), Broadcom BCM43xx 1.0 (5.106.98.81.22)
Bluetooth: Version 4.0.9f33 10885, 2 service, 11 devices, 1 incoming serial ports
Network Service: Ethernet, Ethernet, en0
Network Service: Wi-Fi, AirPort, en1
Serial ATA Device: APPLE SSD SM256E, 251 GB
Serial ATA Device: MATSHITADVD-R   UJ-8A8
USB Device: hub_device, 0x8087  (Intel Corporation), 0x0024, 0x1a100000 / 2
USB Device: hub_device, 0x0424  (SMSC), 0x2514, 0x1a120000 / 4
USB Device: hub_device, 0x0424  (SMSC), 0x2640, 0x1a121000 / 5
USB Device: Dell KM632 Wireless Keyboard and Mouse, 0x413c  (Dell Inc.), 0x2501, 0x1a121300 / 7
USB Device: Ultra Fast Media Reader, 0x0424  (SMSC), 0x4060, 0x1a121100 / 6
USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8509, 0x1a110000 / 3
USB Device: hub_device, 0x8087  (Intel Corporation), 0x0024, 0x1d100000 / 2
USB Device: hub_device, 0x0424  (SMSC), 0x2513, 0x1d180000 / 3
USB Device: BRCM20702 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0x1d181000 / 6
USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x821d, 0x1d181300 / 8
USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0252, 0x1d183000 / 5
USB Device: IR Receiver, apple_vendor_id, 0x8242, 0x1d182000 / 4

----------
components: IDLE
messages: 172493
nosy: brianckeegan
priority: normal
severity: normal
status: open
title: IDLE Crash on Open Parens
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct  9 21:02:52 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 09 Oct 2012 19:02:52 +0000
Subject: [New-bugs-announce] [issue16178] atexit._run_exitfuncs should be a
	public API
Message-ID: <1349809372.69.0.332686923103.issue16178@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

The atexit module's _run_exitfuncs() function needs to be a public API.  In Python 2.x it was exposed through a disgusting hack as "sys.exitfunc()" that the atexit module monkeypatched into place at import time.

This monkeypatching was cleaned up in Python 3.

But it is still useful to expose this to users who need to write their own program shutdown code that ultimately calls os._exit or similar (avoiding atexit hooks that way) but also need to make sure the atexit exit functions get called.

----------
messages: 172505
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: atexit._run_exitfuncs should be a public API
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct  9 21:11:23 2012
From: report at bugs.python.org (=?utf-8?b?Um9iaW4gw4Vzw6lu?=)
Date: Tue, 09 Oct 2012 19:11:23 +0000
Subject: [New-bugs-announce] [issue16179] hashlib.md5 / json inconsistency
Message-ID: <1349809883.96.0.199738834001.issue16179@psf.upfronthosting.co.za>


New submission from Robin ?s?n:

I am getting inconsistent behavior when getting an md5 hexdigest on a json structure that's converted to a string.
Am I doing something wrong here?

    import json
    import hashlib

    data = '''{"key1":"value1","key2":"value2"}'''

    print(hashlib.md5(data.encode()).hexdigest())
    jsonData = json.loads(data)
    print(hashlib.md5(str(jsonData).encode()).hexdigest())
    print(hashlib.md5(str(jsonData).encode()).hexdigest())

When I run this code everything seems just fine at a first glance. However, when it is run again I get different md5 checksums.
The first md5 checksum on the data string seems consistent every time.
The two last md5 checksums never seems to contradict each other during the same run, but between each run I often get different values.
Here are some outputs I'm getting:

ff45cc3835165307ef414c23ca2c6f67
423b2b4d92c0947e3d99d207c7c06175
423b2b4d92c0947e3d99d207c7c06175

ff45cc3835165307ef414c23ca2c6f67
101d66cd2878eacf47c618cea6862125
101d66cd2878eacf47c618cea6862125

ff45cc3835165307ef414c23ca2c6f67
423b2b4d92c0947e3d99d207c7c06175
423b2b4d92c0947e3d99d207c7c06175

ff45cc3835165307ef414c23ca2c6f67
101d66cd2878eacf47c618cea6862125
101d66cd2878eacf47c618cea6862125


(If it makes any difference, I'm running on Windows XP SP3)

----------
components: Interpreter Core
messages: 172506
nosy: poppe1219
priority: normal
severity: normal
status: open
title: hashlib.md5 / json inconsistency
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Oct  9 21:33:24 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 09 Oct 2012 19:33:24 +0000
Subject: [New-bugs-announce] [issue16180] cannot quit pdb when there is a
	syntax error in the	debuggee (must kill it)
Message-ID: <1349811204.12.0.797224741983.issue16180@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

$ tmp=`mktemp /tmp/foo.XXXXXXXXXX`; echo 'def foo: pass' > $tmp; python3 -m pdb $tmp; rm $tmp
Traceback (most recent call last):
  File "/usr/local/lib/python3.2/pdb.py", line 1556, in main
    pdb._runscript(mainpyfile)
  File "/usr/local/lib/python3.2/pdb.py", line 1437, in _runscript
    self.run(statement)
  File "/usr/local/lib/python3.2/bdb.py", line 392, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "/tmp/foo.iLhPYHBZrF", line 1
    def foo: pass
           ^
SyntaxError: invalid syntax
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> <string>(1)<module>()
(Pdb) quit
Post mortem debugger finished. The /tmp/foo.iLhPYHBZrF will be restarted
Traceback (most recent call last):
  File "/usr/local/lib/python3.2/pdb.py", line 1556, in main
    pdb._runscript(mainpyfile)
  File "/usr/local/lib/python3.2/pdb.py", line 1437, in _runscript
    self.run(statement)
  File "/usr/local/lib/python3.2/bdb.py", line 392, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "/tmp/foo.iLhPYHBZrF", line 1
    def foo: pass
           ^
SyntaxError: invalid syntax
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> <string>(1)<module>()
(Pdb) --KeyboardInterrupt--
(Pdb)

----------
components: Library (Lib)
messages: 172508
nosy: xdegaye
priority: normal
severity: normal
status: open
title: cannot quit pdb when there is a syntax error in the debuggee (must kill it)
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Oct  9 22:06:52 2012
From: report at bugs.python.org (Charles Jones)
Date: Tue, 09 Oct 2012 20:06:52 +0000
Subject: [New-bugs-announce] [issue16181] cookielib.http2time raises
	ValueError for invalid date.
Message-ID: <1349813212.28.0.59101014442.issue16181@psf.upfronthosting.co.za>


New submission from Charles Jones:

The docs for http2time state that "None is returned if [...] the time is outside the representable range". However, it is raising a ValueError when a year larger than datetime.MAXYEAR is provided (actually raised downstream by calendar.date()).

To reproduce:
import cookielib
print cookielib.http2time("08-Oct-3697739")

Expected Result:
Should return None

Actual Result:
Raises ValueError: year is out of range

----------
components: Library (Lib)
messages: 172515
nosy: Charles.Jones
priority: normal
severity: normal
status: open
title: cookielib.http2time raises ValueError for invalid date.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct  9 22:09:44 2012
From: report at bugs.python.org (Kaarle Ritvanen)
Date: Tue, 09 Oct 2012 20:09:44 +0000
Subject: [New-bugs-announce] [issue16182] readline: Wrong tab completion
	scope indices in Unicode	terminals
Message-ID: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za>


New submission from Kaarle Ritvanen:

Tab completion in the readline module does not seem to work well with Unicode terminals. The get_line_buffer function converts the line buffer to the str type (which are Unicode strings in Python 3), but the indices returned by get_begidx and get_endidx are not adjusted with respect to possible wide characters in the buffer, and hence are not very useful. The documentation is a bit vague on the index functions, but I think they should be relative to code points, regardless of the encoding used by the C library. The suggested correction is attached.

My second point of complaint is related to the use of PyUnicode_FromString in the module. The strings returned by the readline library use the current locale encoding, which is not necessarily UTF-8. I wonder if PyUnicode_DecodeLocale should be used instead for more portable code.

----------
components: Library (Lib)
files: readline-wide-char-index.patch
keywords: patch
messages: 172517
nosy: kunkku
priority: normal
severity: normal
status: open
title: readline: Wrong tab completion scope indices in Unicode terminals
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27508/readline-wide-char-index.patch

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

From report at bugs.python.org  Wed Oct 10 10:59:12 2012
From: report at bugs.python.org (V.E.O)
Date: Wed, 10 Oct 2012 08:59:12 +0000
Subject: [New-bugs-announce] [issue16183] ZipExtFile object close without
	file handle closed
Message-ID: <1349859552.28.0.331403312725.issue16183@psf.upfronthosting.co.za>


New submission from V.E.O:

Hi, I tried to open file-like object ZipExtFile in one zip file, after operations, I close it and after all, close ZipFile.
But I still can not remove the zip file immediately.

This problem happens on Windows, error msg:
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: ......

Sample code as below:

z = ZipFile('D:\\1', 'r')
zlist = z.infolist()
for zi in zlist:
    zf = z.open(zi)
    zf.close()

z.close()
os.remove(attach)

----------
components: Library (Lib)
messages: 172555
nosy: V.E.O
priority: normal
severity: normal
status: open
title: ZipExtFile object close without file handle closed
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 10 13:18:48 2012
From: report at bugs.python.org (Yury)
Date: Wed, 10 Oct 2012 11:18:48 +0000
Subject: [New-bugs-announce] [issue16184] Attack against the pseudorandom
	number generator
Message-ID: <1349867928.2.0.793137893285.issue16184@psf.upfronthosting.co.za>


New submission from Yury:

---[ Vulnerability description]

Positive Research experts have detected a vulnerability "Predictable pseudorandom numbers in Python" caused by random.random() output in Python.

By default, Mersenne Twister initialization is done during random module import and then after 312 random.random() calls that allows attackers to predict 313 random number with 2^8 accuracy based on 1, 2, 199, 200, 511, 625 random numbers.

--[Solution]
 
We recommend you to initialize random.seed() after every 312 calls that guarantees enough entropy of Mersenne Twister element statuses.

---[Credits]

Vulnerability was detected by Timur Yunusov, Positive Research Center (Positive Technologies Company)

---

1. In spite of the fact that MT states are initialized correctly, there is a practical method to exploit the vulnerability because of Python web framework peculiarities.
2. The possibility that a random number is among described 256 variants is 12,5% because there are two methods to round off numbers to the certain accuracy. This provides 8 possible variants of existing state_1[2], state_1[397], state_2[397].
You can find the code necessary to demonstrate the vulnerability (vuln.py) and exploit it (brute.py) attached.

----------
components: None
files: POC.zip
messages: 172566
nosy: ymaryshev
priority: normal
severity: normal
status: open
title: Attack against the pseudorandom number generator
type: security
versions: Python 3.3
Added file: http://bugs.python.org/file27514/POC.zip

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

From report at bugs.python.org  Wed Oct 10 14:21:22 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 10 Oct 2012 12:21:22 +0000
Subject: [New-bugs-announce] [issue16185] include path in subprocess.Popen()
	file not found error	messages on Windows
Message-ID: <1349871682.42.0.803066776149.issue16185@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Currently, when subprocess.Popen() raises a FileNotFoundError on POSIX systems, the error message helpfully includes the path not found.  But it does not do so on Windows.

This issue is to include the path also in the messages of the corresponding errors on Windows.

See also the related issue 16114.

----------
components: Library (Lib)
messages: 172569
nosy: asvetlov, chris.jerdonek, gregory.p.smith
priority: normal
severity: normal
status: open
title: include path in subprocess.Popen() file not found error messages on Windows
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 10 15:47:04 2012
From: report at bugs.python.org (jamesf)
Date: Wed, 10 Oct 2012 13:47:04 +0000
Subject: [New-bugs-announce] [issue16186] shlex bug?
Message-ID: <1349876824.59.0.894274371181.issue16186@psf.upfronthosting.co.za>


New submission from jamesf:

In [112]: def test_ws(s):
   .....:     sl = shlex.shlex(s)
   .....:     sl.whitespace = "|"
   .....:     sl.whitespace_split = True
   .....:     print list(sl)


In [114]: test_ws("h w")   # works fine
['h w']

In [115]: test_ws("'h' w")  # i expected ["'h' w"] here, but why?
["'h'", ' w']

----------
messages: 172573
nosy: jwfang
priority: normal
severity: normal
status: open
title: shlex bug?
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 10 16:46:32 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 10 Oct 2012 14:46:32 +0000
Subject: [New-bugs-announce] [issue16187] incoming.irker hook raised an
	exception: [Errno 111]	Connection refused
Message-ID: <1349880392.26.0.557812672186.issue16187@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

I got the following irker-related errors when committing about 20 minutes ago:

remote: added 3 changesets with 2 changes to 1 files
remote: buildbot: change(s) sent successfully
remote: sent email to roundup at report at bugs.python.org
remote: notified python-checkins at python.org of incoming changeset 00555659253d
remote: error: incoming.irker hook raised an exception: [Errno 111] Connection refused
remote: notified python-checkins at python.org of incoming changeset 467c9f663b77
remote: error: incoming.irker hook raised an exception: [Errno 111] Connection refused
remote: notified python-checkins at python.org of incoming changeset 15bfa778ec21
remote: error: incoming.irker hook raised an exception: [Errno 111] Connection refused

----------
components: None
messages: 172577
nosy: chris.jerdonek, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: incoming.irker hook raised an exception: [Errno 111] Connection refused
type: behavior

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

From report at bugs.python.org  Wed Oct 10 17:06:31 2012
From: report at bugs.python.org (rlinscheer)
Date: Wed, 10 Oct 2012 15:06:31 +0000
Subject: [New-bugs-announce] [issue16188] Windows C Runtime Library Mismatch
Message-ID: <1349881591.31.0.873714475408.issue16188@psf.upfronthosting.co.za>


New submission from rlinscheer:

When installing python-2.7.3.amd64.msi or python-2.7.3.msi and selecting for single-user (as opposed to for all users), an incorrect version of the microsoft C runtime library (msvcr90.dll) seems to be placed into the top-level directory along side the python executable.  This results in the message:

The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

The event log shows the error too:

Activation context generation failed for "C:\python_rob_32\pythonw.exe".Error in manifest or policy file "C:\python_rob_32\Microsoft.VC90.CRT.MANIFEST" on line 4. Component identity found in manifest does not match the identity of the component requested. Reference is Microsoft.VC90.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8". Definition is Microsoft.VC90.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.30729.1". Please use sxstrace.exe for detailed diagnosis.

Running the sxstrace tool shows the following:

INFO: Parsing Manifest File C:\python_rob_32\Microsoft.VC90.CRT.MANIFEST.
	INFO: Manifest Definition Identity is Microsoft.VC90.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.30729.1".
	ERROR: Component identity found in manifest does not match the identity of the component requested. Reference is Microsoft.VC90.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8". Definition is Microsoft.VC90.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.30729.1".
ERROR: Activation Context generation failed.

This would seem to be the relevant section of the trace, though I have attached the full output of the sxstrace if desired.

This leads me to the conclusion that a newer version of the C runtime library is being shipped with the python executable that was built with an older version.

This problem was mentioned with less detail in issue 14608, but closed without resolution as far as I can tell.

----------
components: Installation
files: rob_32.txt
messages: 172584
nosy: rlinscheer
priority: normal
severity: normal
status: open
title: Windows C Runtime Library Mismatch
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file27517/rob_32.txt

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

From report at bugs.python.org  Wed Oct 10 17:52:40 2012
From: report at bugs.python.org (Rainer Schaaf)
Date: Wed, 10 Oct 2012 15:52:40 +0000
Subject: [New-bugs-announce] [issue16189] ld_so_aix not found
Message-ID: <1349884360.41.0.476274191409.issue16189@psf.upfronthosting.co.za>


New submission from Rainer Schaaf:

When building an extension on AIX with distutils the build fails like this:

/usr/local/lib/python3.3/config/ld_so_aix xlc_r -bI:/usr/local/lib/python3.3/config/python.exp build/temp.aix-5.3-3.3/pdflib_py.o -L../../../libs/pdflib/.libs -L../../../libs/icu/lib -ls_libpdf -lC -o build/lib.aix-5.3-3.3/pdflib_py.so
unable to execute /usr/local/lib/python3.3/config/ld_so_aix: No such file or directory
error: command '/usr/local/lib/python3.3/config/ld_so_aix' failed with exit status 1

The problem can easily be fixed by:

ln -s /usr/local/lib/python3.3/config-3.3m  /usr/local/lib/python3.3/config

----------
assignee: eric.araujo
components: Distutils
messages: 172588
nosy: eric.araujo, rjs, tarek
priority: normal
severity: normal
status: open
title: ld_so_aix not found
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Wed Oct 10 18:13:10 2012
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 10 Oct 2012 16:13:10 +0000
Subject: [New-bugs-announce] [issue16190] Misleading warning in random
	module docs
Message-ID: <1349885590.41.0.193272073786.issue16190@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The documentation [1] of the random module contains a misleading warning 

---
Warning: The generators of the random module should not be used for security purposes. Use ssl.RAND_bytes() if you require a cryptographically secure pseudorandom number generator.
---

The warning should point users to os.urandom() and random.SystemRandom rather than ssl.RAND_bytes(). On Linux os.urandom() wraps /dev/urandom [2], on Windows it uses CryptGenRandom() [3]. Both are suitable for most cryptographic purposes except for long-lived keys (SSL, SSH, GPG certs etc.). ssl.RAND_bytes() should only be used for such long-lived data and not for salts, session ids and similar.

I like to see the warning box in Python 2.7, too. It's still the default for docs.python.org. My inquiry is motivated by #16184.

[1] http://docs.python.org/py3k/library/random.html
[2] http://linux.die.net/man/4/urandom
[3] http://msdn.microsoft.com/en-us/library/windows/desktop/aa379942%28v=vs.85%29.aspx

----------
assignee: docs at python
messages: 172589
nosy: christian.heimes, docs at python
priority: normal
severity: normal
status: open
title: Misleading warning in random module docs
type: security
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Oct 11 02:04:55 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 11 Oct 2012 00:04:55 +0000
Subject: [New-bugs-announce] [issue16191] ceval cleanup
Message-ID: <1349913895.1.0.124857708978.issue16191@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

The attached patch

- Puts every opcode in its own block
- Removes the infamous one variable names "x, v, w, u" and replaces them with local variables.
- forces every opcode to end in DISPATCH() or "goto error"
- cleans up a few minor other things

----------
files: ceval-better.patch
keywords: patch
messages: 172610
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: ceval cleanup
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27522/ceval-better.patch

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

From report at bugs.python.org  Thu Oct 11 04:42:49 2012
From: report at bugs.python.org (Brian Thorne)
Date: Thu, 11 Oct 2012 02:42:49 +0000
Subject: [New-bugs-announce] [issue16192] ctypes - documentation example
Message-ID: <1349923369.86.0.516068156992.issue16192@psf.upfronthosting.co.za>


New submission from Brian Thorne:

The Python docs for ctypes have embedded examples including:

>>> c_int()
c_long(0)

But on my machine I get the (more expected?):

>>> c_int()
c_int(0)

Perhaps if some machines expect otherwise that should be documented, otherwise might we change them.

----------
components: ctypes
files: ctypes_doc.diff
keywords: patch
messages: 172616
nosy: Thorney, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: ctypes - documentation example
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file27523/ctypes_doc.diff

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

From report at bugs.python.org  Thu Oct 11 07:24:49 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 11 Oct 2012 05:24:49 +0000
Subject: [New-bugs-announce] [issue16193] display full e-mail name in
	hg.python.org annotate pages
Message-ID: <1349933089.11.0.333803673424.issue16193@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to configure hg.python.org to display the full e-mail name on the "annotate" pages.  Currently, instead of displaying everything before the "@" symbol, the pages display only the portion of e-mail addresses up to the first "." or "@", for example "tim at 19837".

Information on how to configure hgweb this way is here:

http://bz.selenic.com/show_bug.cgi?id=2276

----------
messages: 172621
nosy: chris.jerdonek, ezio.melotti, georg.brandl, pitrou
priority: normal
severity: normal
status: open
title: display full e-mail name in hg.python.org annotate pages
type: enhancement

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

From report at bugs.python.org  Thu Oct 11 13:11:10 2012
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiDFoG1pbGF1ZXI=?=)
Date: Thu, 11 Oct 2012 11:11:10 +0000
Subject: [New-bugs-announce] [issue16194] imp.load_dynamic imports wrong
	module when called	several times on a multi-module .so
Message-ID: <1349953870.22.0.50760531633.issue16194@psf.upfronthosting.co.za>


New submission from V?clav ?milauer:

I have several compiled modules linked into one .so file and import them using imp.load_dynamic.

Only the first module imported with load_dynamic is imported properly, all subsequent calls of load_dynamic on the same file ignore the first argument (name) and return the first module again. The init function is also called only for the first module imported by load_dynamic.

The bug is reproducible for python 2.7.3 and 3.2.2. Test case is attached.

Here inline simplified source for 2.7:

foo.c:

	#include<stdio.h>
	#include<Python.h>
	PyMODINIT_FUNC initfoo(){
		(void) Py_InitModule("foo",NULL);
		printf("initfoo()\n");
	}
	PyMODINIT_FUNC initbar(void){
		(void) Py_InitModule("bar",NULL);
		printf("initbar()\n");
	}
	PyMODINIT_FUNC initbaz(void){
		(void) Py_InitModule("baz",NULL);
		printf("initbaz()\n");
	}

test.py:

	import sys,imp
	# import foo using the normal machinery
	sys.path.append('.')
	import foo
	# this is OK
	print imp.load_dynamic('bar','foo.so')
	# this imports *bar* again, but should import baz
	print imp.load_dynamic('baz','foo.so')
	# this imports *bar* again, although the module is not defined at all
	print imp.load_dynamic('nonsense','foo.so')

Compiled with

         gcc -shared -fPIC foo.c -o foo.so `pkg-config python --cflags --libs`

I get when running "python test.py" output:

        initfoo()
        initbar()
        <module 'bar' from 'foo.so'>
        <module 'bar' from 'foo.so'>
        <module 'bar' from 'foo.so'>

The module 'bar' is imported 3 times, although the 2nd import should import *baz* and the third import should fail ("nonsense" module does not exist).

----------
components: Library (Lib)
files: load_dynamic-test.zip
messages: 172632
nosy: eudoxos
priority: normal
severity: normal
status: open
title: imp.load_dynamic imports wrong module when called several times on a multi-module .so
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file27527/load_dynamic-test.zip

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

From report at bugs.python.org  Thu Oct 11 15:10:21 2012
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 11 Oct 2012 13:10:21 +0000
Subject: [New-bugs-announce] [issue16195] Difficult or impossible to figure
	out how garbage	collector and weak references should interact
	for user-defined	extension types
Message-ID: <1349961021.39.0.560161023056.issue16195@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone:

There appears to be very little, if any, documentation about how to handle the list at tp_weaklistoffset for types supporting being weak referenced, particularly with respect to garbage collection.

Who owns the list?  Who owns the objects in the list?  Should the list be traversed by the extension type's tp_traverse?  Should it ever be INCREF'd or DECREF'd?  Does tp_dealloc have any responsibilities with respect to it?

>From looking at CPython's own source, it appears that tp_traverse should not touch it (Yhg1s confirmed this on #python).  Cython, at least, appears to have come to an alternate conclusion though - it generates tp_traverse functions which visit the list (and provoke gc assertions to fail on Python 2.7 in debug mode).

Some documentation about what is correct to do would be excellent, and would make it easier to explain to Cython developers what they're doing wrong (or confirm that they're doing something right, in which case there are some more bugs to file against the CPython stdlib, since they do something different from Cython).

----------
assignee: docs at python
components: Documentation
messages: 172639
nosy: docs at python, exarkun
priority: normal
severity: normal
status: open
title: Difficult or impossible to figure out how garbage collector and weak references should interact for user-defined extension types

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

From report at bugs.python.org  Thu Oct 11 15:13:38 2012
From: report at bugs.python.org (Mike Hoy)
Date: Thu, 11 Oct 2012 13:13:38 +0000
Subject: [New-bugs-announce] [issue16196] Typo in devguide stdlibchanges.html
Message-ID: <1349961218.46.0.199078459868.issue16196@psf.upfronthosting.co.za>


New submission from Mike Hoy:

Typo in: http://docs.python.org/devguide/stdlibchanges.html#adding-to-the-stdlib

Reads:
This document it meant to explain...

Should read:
This document is meant to explain...

----------
components: Devguide
messages: 172640
nosy: ezio.melotti, mikehoy
priority: normal
severity: normal
status: open
title: Typo in devguide stdlibchanges.html

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

From report at bugs.python.org  Thu Oct 11 18:12:11 2012
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 11 Oct 2012 16:12:11 +0000
Subject: [New-bugs-announce] [issue16197] Several small errors in winreg
	documentation
Message-ID: <1349971931.7.0.721708893114.issue16197@psf.upfronthosting.co.za>


New submission from Zachary Ware:

There are several small inconsistencies in the winreg module documentation (docstrings and winreg.rst).  Mostly these are discrepancies between "res" and "reserved", "sam" and "access", and whether or not those two are keyword arguments, but there are some other missing pieces as well.

I'm happy to provide a patch to correct everything, but I'd like a little guidance beforehand.  I have no experience with docstrings in C code, so I've attached a patch that attempts to correct just the CreateKeyEx() docstring.  If it turns out to be ok, I'll go ahead and create a patch fixing the other ones.  I'm comfortable enough with ReST changes that I'll just include those with the final docstring patch.

Also, some of the changes are specific to 3.3+ (due to the WindowsError => OSError change).  Should I provide one patch against default, two against 3.2 and 3.3 (including the 3.2 changes), or two against 3.2 and 3.3 (after a local commit of the 3.2 changes)?  Any of the above is perfectly doable :)

Thanks,

Zach

----------
assignee: docs at python
components: Documentation
files: winreg_example.patch
keywords: patch
messages: 172655
nosy: brian.curtin, docs at python, stutzbach, zach.ware
priority: normal
severity: normal
status: open
title: Several small errors in winreg documentation
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27532/winreg_example.patch

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

From report at bugs.python.org  Thu Oct 11 18:48:41 2012
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 11 Oct 2012 16:48:41 +0000
Subject: [New-bugs-announce] [issue16198] IDLE - tabbing in a string always
	brings up file	completion window
Message-ID: <1349974121.21.0.319562901545.issue16198@psf.upfronthosting.co.za>


New submission from Roger Serwy:

Pressing <Tab> while the cursor is in a string will bring up the file completion dialog rather than inserting a tab (or 4 spaces). This behavior is rather annoying in a text editor especially when editing multiline doc strings.

This behavior is new to the 3.3 series as a consequence of issue14937. Arguably, it is a regression.

The logic for bringing up the file completion window when pressing Tab in a string needs to be revised. If the string already contains a partial match, then bring up the window when pressing Tab, otherwise insert a Tab character or spaces.

Alternatively, the Ctrl+Space key sequence will already bring up the file completion dialog, so having an automatic Tab completion behavior is not absolutely necessary.

This issue can also be triggered in the shell. Start a string and then press tab twice.

----------
components: IDLE
keywords: 3.3regression
messages: 172663
nosy: serwy, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE - tabbing in a string always brings up file completion window
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Oct 11 20:51:49 2012
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 11 Oct 2012 18:51:49 +0000
Subject: [New-bugs-announce] [issue16199] 2to3 very minor doc change
Message-ID: <1349981509.98.0.17661303063.issue16199@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

http://docs.python.org/library/2to3.html#using-2to3 second paragraph second sentence reads "The directories are to recursively traversed for Python sources."  The "to" is not needed.

----------
assignee: docs at python
components: Documentation
messages: 172673
nosy: BreamoreBoy, docs at python
priority: normal
severity: normal
status: open
title: 2to3 very minor doc change
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/issue16199>
_______________________________________

From report at bugs.python.org  Thu Oct 11 21:09:30 2012
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 11 Oct 2012 19:09:30 +0000
Subject: [New-bugs-announce] [issue16200] Setting .posix=True for shlex
	object causes infinite	loop in __next__
Message-ID: <1349982570.12.0.849029926696.issue16200@psf.upfronthosting.co.za>


New submission from Roger Serwy:

The documentation for shlex does not prohibit the user from setting .posix=True after creating a shlex object. When doing so, the .eof attribute is inconsistent, creating an infinite loop in the __next__ method.

Here's some sample code to recreate the issue:

import shlex
s = shlex.shlex(r"", posix=False)
s.posix = True
list(s)

One possible solution is to make .posix a read-only property. Another is to make .posix a property which sets .eof correctly.

----------
components: Library (Lib)
messages: 172677
nosy: serwy
priority: normal
severity: normal
status: open
title: Setting .posix=True for shlex object causes infinite loop in __next__
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Oct 11 21:31:03 2012
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Thu, 11 Oct 2012 19:31:03 +0000
Subject: [New-bugs-announce] [issue16201] socket.gethostbyname incorrectly
	parses ip
Message-ID: <1349983863.01.0.255097510924.issue16201@psf.upfronthosting.co.za>


New submission from Michele Orr?:

Buggy due to the use of scanf at Modueles/socketmodule.c:868
Broken from python2.7 to tip on my machine (GNU/Linux)

>>> import socket
[64481 refs]
>>> socket.gethostbyname('4294967306.4294967296.4294967296.1')
'10.0.0.1'
[67764 refs]
>>> socket.gethostbyname('192.168.1.1  ')
'192.168.1.1'
[67764 refs]
>>> socket.gethostbyname('  192.168.1.1')
'192.168.1.1'
[67764 refs]
>>> socket.gethostbyname('  192.168.1.1  ')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.gaierror: [Errno -2] Name or service not known
[67805 refs]

----------
components: Library (Lib)
messages: 172682
nosy: maker
priority: normal
severity: normal
status: open
title: socket.gethostbyname incorrectly parses ip
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/issue16201>
_______________________________________

From report at bugs.python.org  Thu Oct 11 22:10:23 2012
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 11 Oct 2012 20:10:23 +0000
Subject: [New-bugs-announce] [issue16202] sys.path[0] security issues
Message-ID: <1349986223.57.0.879834971708.issue16202@psf.upfronthosting.co.za>


New submission from Jeroen Demeyer:

There is a serious security problem with Python's default sys.path.  If I execute

$ python /tmp/somescript.py

then Python will add /tmp as sys.path[0], such that an "import foobar" will cause Python to read /tmp/foobar (or variations).  This vulnerability exists in particular in distutils.util.byte_compile() with direct=False.  Since the Python test suite calls this function, users running the Python test suite are vulnerable.

I think the root of this issue should be fixed: Python should not simply add stuff to sys.path without checking.  In prepared a patch for CPython-2.7 which only adds sys.path[0] if it seems secure to do so, by looking at file/directory permissions and ownership.  In particular, it would never add /tmp to sys.path, but it would still keep the current behaviour when running a script in a directory owned by the current user with 0755 permissions.  See the patch for details.

I realize this goes against documented Python behaviour, but I think that a broken spec needs to be fixed.  I also think that in most use cases, nothing is going to change because normally one doesn't need to import from /tmp.  In any case, users can still manipulate sys.path directly.

Feel free to fix this issue in a different way than my patch, but I hope you at least implement the spirit of my patch.  The patch has only been tested on Linux systems.

Credit goes to Volker Braun for first discovering this issue in Sage, see http://trac.sagemath.org/sage_trac/ticket/13579

----------
components: Interpreter Core
files: sys_path_security.patch
keywords: patch
messages: 172686
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: sys.path[0] security issues
type: security
versions: Python 2.7
Added file: http://bugs.python.org/file27536/sys_path_security.patch

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

From report at bugs.python.org  Thu Oct 11 23:30:42 2012
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 11 Oct 2012 21:30:42 +0000
Subject: [New-bugs-announce] [issue16203] Proposal: add re.fullmatch() method
Message-ID: <1349991042.0.0.875123830426.issue16203@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

I've noticed a subtle bug in some of our internal code.  Someone wants to ensure that a certain string (e.g. a URL path) matches a certain pattern in its entirety.  They use re.match() with a regex ending in $.  Fine.  Now someone else comes along and modifies the pattern.  Somehow the $ gets lost, or the pattern develops a set of toplevel choices that don't all end in $.  And now things that have a valid *prefix* suddenly (and unintentionally) start matching.

I think this is a common enough issue and propose a new API: a fullmatch() function and method that work just like the existing match() function and method but also check that the whole input string matches.  This can be implemented slightly awkwardly as follows in user code:

def fullmatch(regex, input, flags=0):
  m = re.match(regex, input, flags)
  if m is not None and m.end() == len(input):
    return m
  return None

(The corresponding method will have to be somewhat more complex because the underlying match() method takes optional pos and endpos arguments.)

----------
keywords: easy
messages: 172695
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Proposal: add re.fullmatch() method
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct 12 01:08:17 2012
From: report at bugs.python.org (Daniele Varrazzo)
Date: Thu, 11 Oct 2012 23:08:17 +0000
Subject: [New-bugs-announce] [issue16204] PyBuffer_FillInfo returns 'B'
	buffer, whose behavior has changed w.r.t. 3.1/3.2
Message-ID: <1349996897.29.0.414434111173.issue16204@psf.upfronthosting.co.za>


New submission from Daniele Varrazzo:

Definitely related to this change in Python 3.3:

    Accessing a memoryview element with format ?B? (unsigned bytes) now 
    returns an integer (in accordance with the struct module syntax). 
    For returning a bytes object the view must be cast to ?c? first.

The object returned by PyBuffer_FillInfo is 'B' format: this means that python code finds itself dealing in Py 3.3 with a different object respect to what returned in Py 3.1 and 3.2. Is this change in the behavior wanted? Wouldn't have been better having FillInfo return a 'c' buffer instead?

I'm adding support to Py 3.3 to psycopg2 and the B buffers make the test suite fail. I want psycopg to return consistent objects across 3.x. Is the change in this commit correct?

https://github.com/dvarrazzo/psycopg/commit/469b6f8aff4cafe203d851b19bedfab0128e795a

Is this a good way to return a 'c' buffer?

----------
messages: 172710
nosy: piro
priority: normal
severity: normal
status: open
title: PyBuffer_FillInfo returns 'B' buffer, whose behavior has changed w.r.t. 3.1/3.2
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Oct 12 04:15:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 12 Oct 2012 02:15:26 +0000
Subject: [New-bugs-announce] [issue16205] update :class:`str` references to
	link to the str type	section
Message-ID: <1350008126.16.0.898285675428.issue16205@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

3.3 added a dedicated section to the docs for the str type.  However, references to :class:`str` still link to the documentation of the built-in function str().

This issue is to update references to the str class to point to the new section on the str type.

We could use :ref:`str <textseq>`, but it would be nice to have a solution that makes "str" have the code-style font instead of italics.

----------
assignee: docs at python
components: Documentation
messages: 172713
nosy: chris.jerdonek, docs at python, ezio.melotti, ncoghlan
priority: normal
severity: normal
status: open
title: update :class:`str` references to link to the str type section
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Oct 12 09:09:33 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 12 Oct 2012 07:09:33 +0000
Subject: [New-bugs-announce] [issue16206] dict() docs should display
	multiple signatures
Message-ID: <1350025773.95.0.890132868145.issue16206@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The documentation for dict() (for both the built-in function and the class constructor) should display multiple signatures as do dict.__doc__ and the documentation for, say, str().

Currently, the dict() documentation just has one signature:

dict([arg])

Something more in line with the docstring would be better, for example:

dict(mapping={})
dict(iterable)
dict(**kwargs)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 172718
nosy: chris.jerdonek, docs at python, ezio.melotti
priority: normal
severity: normal
status: open
title: dict() docs should display multiple signatures
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Oct 12 09:22:47 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 12 Oct 2012 07:22:47 +0000
Subject: [New-bugs-announce] [issue16207] add class name to method
	signatures in stdtypes docs
Message-ID: <1350026567.26.0.190779940356.issue16207@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The method signatures for some of the classes documented in library/stdtypes lack the class name.  For example, the list, dict, set, and memoryview methods lack the class name.  Adding the class name will help to distinguish methods from functions.

----------
assignee: docs at python
components: Documentation
messages: 172720
nosy: chris.jerdonek, docs at python, ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: add class name to method signatures in stdtypes docs
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/issue16207>
_______________________________________

From report at bugs.python.org  Fri Oct 12 10:04:15 2012
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 12 Oct 2012 08:04:15 +0000
Subject: [New-bugs-announce] [issue16208] getaddrinfo returns wrong results
	if IPv6 is disabled
Message-ID: <1350029055.88.0.421531747459.issue16208@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <python-bugs at systemexit.de>:


----------
nosy: schmir
priority: normal
severity: normal
status: open
title: getaddrinfo returns wrong results if IPv6 is disabled

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

From report at bugs.python.org  Fri Oct 12 11:03:17 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 12 Oct 2012 09:03:17 +0000
Subject: [New-bugs-announce] [issue16209] add a "class str" entry to the docs
Message-ID: <1350032597.23.0.0536115574586.issue16209@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to add a str class entry to the built-in types page like we have for dict, set, memoryview, etc:

http://docs.python.org/dev/library/stdtypes.html

This will let us reference ``str`` the class separately from ``str()`` the built-in function.  It will also let us remove the "str." prefix from all of the string method descriptions.  Thirdly, it will make the str documentation match what is being done for the types previous to it in the documentation, including the range, tuple, and list classes.  Lastly, it will make referencing string-related sections in Sphinx a bit more intuitive.  Currently, :class:`str` points to the built-in function :func:`str`.

----------
assignee: docs at python
components: Documentation
messages: 172733
nosy: chris.jerdonek, docs at python, ezio.melotti
priority: normal
severity: normal
status: open
title: add a "class str" entry to the docs
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Oct 12 11:12:19 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 12 Oct 2012 09:12:19 +0000
Subject: [New-bugs-announce] [issue16210] combine the two type() definitions
	in built-in function	docs
Message-ID: <1350033139.53.0.10696980819.issue16210@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

[Found by Ezio]

The built-in function documentation has what looks like two separate definitions of the built-in function type():

http://docs.python.org/dev/library/functions.html#type

These two definitions should be combined into one with a multi-line signature like we're doing for the other built-in functions.

----------
assignee: docs at python
components: Documentation
messages: 172734
nosy: chris.jerdonek, docs at python, ezio.melotti
priority: normal
severity: normal
status: open
title: combine the two type() definitions in built-in function docs
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Oct 12 15:54:55 2012
From: report at bugs.python.org (Doug Ransom)
Date: Fri, 12 Oct 2012 13:54:55 +0000
Subject: [New-bugs-announce] [issue16211] MacInstalls break PyDev
Message-ID: <1350050095.97.0.144464091668.issue16211@psf.upfronthosting.co.za>


New submission from Doug Ransom:

A number of .py files are not installed in the mac installer.  While python programs run OK, this thwarts users from using IDEs like Aptana Studio/PyDev.  For those of us who are python dabblers, this makes it nearly impossible to write/debug python code.

urllib.py is an example.

Here is the note from PyDev which works with Aptana Studio http://pydev.org/manual_101_interpreter.html (though installing python as they discuss doesn't fix the problem, and the /lib folder thing is probably beyond most of us to figure out):

"IMPORTANT for Mac users: The Python version that usually ships with Mac doesn't seem to have the .py source files 
available, which are required for PyDev, so, using a different interpreter is recommended (i.e.: Download it from http://python.org). If you don't want to use a different interpreter, get the source files for the Python '/Lib' folder
and add those to the system installation.

After those steps, you should have a screen as presented below:..."

How about changing the install so IDEs like pydev, for all versions?  A few extra bytes of disk space probably won't harm anything.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 172743
nosy: Doug.Ransom, ronaldoussoren
priority: normal
severity: normal
status: open
title: MacInstalls break PyDev
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct 12 16:04:23 2012
From: report at bugs.python.org (Vladimir Ushakov)
Date: Fri, 12 Oct 2012 14:04:23 +0000
Subject: [New-bugs-announce] [issue16212] mmap() dumps core upon resizing
	the underlying file
Message-ID: <1350050663.98.0.0365442687476.issue16212@psf.upfronthosting.co.za>


New submission from Vladimir Ushakov:

The following code crashes the interpreter on Linux:

#!/usr/bin/python3

import mmap

with open('test', 'wb') as f:
    f.write(bytes(1))

with open('test', 'r+b') as f:
    m = mmap.mmap(f.fileno(), 0)
    f.truncate()
    a = m[:]

---

It's not specific to the zero size truncation, it's enough if the file size decreases beyond a page border.

----------
components: IO
messages: 172745
nosy: Vladimir.Ushakov
priority: normal
severity: normal
status: open
title: mmap() dumps core upon resizing the underlying file
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Fri Oct 12 17:13:35 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 12 Oct 2012 15:13:35 +0000
Subject: [New-bugs-announce] [issue16213] Expose private functions in
	marshal used by importlib
Message-ID: <1350054815.58.0.751298087125.issue16213@psf.upfronthosting.co.za>


New submission from Brett Cannon:

IOW make _w_long, _r_long, and __fix_co_filename public so as to not be some special ability that only importlib has.

----------
components: Library (Lib)
messages: 172751
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Expose private functions in marshal used by importlib
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct 12 20:44:50 2012
From: report at bugs.python.org (Chris Mayo)
Date: Fri, 12 Oct 2012 18:44:50 +0000
Subject: [New-bugs-announce] [issue16214] 2to3 does not remove exceptions
	import
Message-ID: <1350067490.94.0.738974146357.issue16214@psf.upfronthosting.co.za>


New submission from Chris Mayo:

Create file a.py:
#!/usr/bin/python
import exceptions

and run:
2to3 a.py
...
RefactoringTool: No files need to be modified.

Issue 2350 is marked as closed but this is still present for me in 2to3 of Python 2.7, 3.2 and 3.3.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 172770
nosy: cjmayo
priority: normal
severity: normal
status: open
title: 2to3 does not remove exceptions import
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Oct 13 00:33:52 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 12 Oct 2012 22:33:52 +0000
Subject: [New-bugs-announce] [issue16215] Possible double memory free in
	str.replace
Message-ID: <1350081232.49.0.0151935995631.issue16215@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In the function replace() in the file Objects/unicodeobject.c possible double free memory pointed by buf1. release1 indicates if memory was allocated and deallocation needed. However there are places where memory temporary deallocated but flag was not cleared.

----------
components: Interpreter Core
files: dbl_mem_free.patch
keywords: 3.3regression, patch
messages: 172790
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Possible double memory free in str.replace
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27547/dbl_mem_free.patch

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

From report at bugs.python.org  Sat Oct 13 00:45:08 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 12 Oct 2012 22:45:08 +0000
Subject: [New-bugs-announce] [issue16216] Arithmetic operations with NULL
Message-ID: <1350081908.35.0.947627906901.issue16216@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In the function STRINGLIB(fastsearch_memchr_1char) in the file Objects/stringlib/fastsearch.h NULL returned by memchr/memrchr casted to intptr_t, then some arithmetic operations performed on this integer, and result casted back to pointer. I think it is unsafe to do with NULL. The code is easy to rewrite in order to avoid such a questionable operations.

----------
components: Interpreter Core
files: null_align.patch
keywords: 3.3regression, patch
messages: 172791
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Arithmetic operations with NULL
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27548/null_align.patch

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

From report at bugs.python.org  Sat Oct 13 14:51:41 2012
From: report at bugs.python.org (Matthew Woodcraft)
Date: Sat, 13 Oct 2012 12:51:41 +0000
Subject: [New-bugs-announce] [issue16217] Tracebacks are unnecessarily
	verbose when using 'python	-m'
Message-ID: <1350132701.04.0.542395484982.issue16217@psf.upfronthosting.co.za>


New submission from Matthew Woodcraft:

If I run my code using 'python -m' and there is an unhandled exception, the tracebacks include lines from runpy.py (and now sometimes from importlib._bootstrap) which don't provide useful information, and tend to overwhelm the valuable part of the traceback.

I suppose this is in some sense a regression from Python 2.4.


echo fail > fail.py
python3.3 -m fail

python -m fail
Traceback (most recent call last):
  File "/usr/lib/python3.3/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python3.3/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "./fail.py", line 2, in <module>
    fail
NameError: name 'fail' is not defined

Here I think it would be better to omit the first two traceback entries.


Syntax errors are worse:
echo syntax error > fail.py
python3.3 -m fail

Traceback (most recent call last):
  File "/usr/lib/python3.3/runpy.py", line 140, in _run_module_as_main
    mod_name, loader, code, fname = _get_module_details(mod_name)
  File "/usr/lib/python3.3/runpy.py", line 114, in _get_module_details
    code = loader.get_code(mod_name)
  File "<frozen importlib._bootstrap>", line 981, in get_code
  File "<frozen importlib._bootstrap>", line 313, in _call_with_frames_removed
  File "./fail.py", line 1
    syntax error

Here there are four traceback entries which could be omitted.

----------
messages: 172806
nosy: mattheww
priority: normal
severity: normal
status: open
title: Tracebacks are unnecessarily verbose when using 'python -m'
type: enhancement

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

From report at bugs.python.org  Sat Oct 13 16:24:38 2012
From: report at bugs.python.org (Turn)
Date: Sat, 13 Oct 2012 14:24:38 +0000
Subject: [New-bugs-announce] [issue16218] Python launcher does not support
	non ascii characters
Message-ID: <1350138278.8.0.551817049969.issue16218@psf.upfronthosting.co.za>


New submission from Turn:

If there are non ASCII character in the py.exe arguments, the execution will fail. The script file name or path may contain non ASCII characters.

----------
components: Windows
messages: 172807
nosy: turncc
priority: normal
severity: normal
status: open
title: Python launcher does not support non ascii characters
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Sat Oct 13 19:22:21 2012
From: report at bugs.python.org (Scott Maxwell)
Date: Sat, 13 Oct 2012 17:22:21 +0000
Subject: [New-bugs-announce] [issue16219] segfault when using
	xml.etree.ElementTree.XMLTreeBuilder
Message-ID: <1350148941.07.0.23902695609.issue16219@psf.upfronthosting.co.za>


New submission from Scott Maxwell:

I upgraded the meld3 module (used by Supervisord) to work on Py3K and discovered this segfault. It happens every time. I have seen this on the pre-built Mac 3.3.0 and a source-built 3.3.0 on Linux. It does not occur in 3.2.2. It appears to happen in native code so I can pinpoint the exact location of the crash. But it is easy to reproduce.

It is easy to reproduce. Just grab meld3.py and test_meld3.py from my GitHub and run test_meld3. Files are here:
https://raw.github.com/scottkmaxwell/meld3/master/meld3/meld3.py
https://raw.github.com/scottkmaxwell/meld3/master/meld3/test_meld3.py

On just clone my depot.

----------
components: Library (Lib)
messages: 172815
nosy: scottmax
priority: normal
severity: normal
status: open
title: segfault when using xml.etree.ElementTree.XMLTreeBuilder
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Sat Oct 13 23:00:20 2012
From: report at bugs.python.org (Brent Tubbs)
Date: Sat, 13 Oct 2012 21:00:20 +0000
Subject: [New-bugs-announce] [issue16220] wsgiref does not call close() on
	iterable response when	client
Message-ID: <1350162020.69.0.603099084932.issue16220@psf.upfronthosting.co.za>


New submission from Brent Tubbs:

When a WSGI application returns an iterable that has a .close() method, the server is supposed to call that method once the request has finished.  The wsgiref server does not do this when a client disconnects from a streaming response.

The attached script allows testing the .close() behavior of various wsgi servers (wsgiref, cherrypy, gevent, werkzeug, and gunicorn).  wsgiref is the only one of the tested implementations that does not call .close().

----------
components: Library (Lib)
files: sleepy_app.py
messages: 172830
nosy: Brent.Tubbs
priority: normal
severity: normal
status: open
title: wsgiref does not call close() on iterable response when client
versions: Python 2.7
Added file: http://bugs.python.org/file27555/sleepy_app.py

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

From report at bugs.python.org  Sun Oct 14 07:26:56 2012
From: report at bugs.python.org (Eric Snow)
Date: Sun, 14 Oct 2012 05:26:56 +0000
Subject: [New-bugs-announce] [issue16221] tokenize.untokenize() "compat"
	mode misses the encoding	when using an iterator
Message-ID: <1350192416.31.0.110132465833.issue16221@psf.upfronthosting.co.za>


New submission from Eric Snow:

While traversing the passed iterable, untokenize() will go to "compatibility mode" one it hits a 2-tuple instead of a 5-tuple (coming from the iterable).  That token will not go through the normal steps that other tokens do.  Most critically, if that token is the ENCODING token, the source is not encoded to that encoding at the end (even though it should have been).  I'll have a patch up in a moment (for the tip of default).

There are a couple of other issues at hand that I will bring up separately.

----------
assignee: eric.snow
messages: 172848
nosy: eric.snow
priority: normal
severity: normal
stage: test needed
status: open
title: tokenize.untokenize() "compat" mode misses the encoding when using an iterator
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/issue16221>
_______________________________________

From report at bugs.python.org  Sun Oct 14 07:41:36 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 14 Oct 2012 05:41:36 +0000
Subject: [New-bugs-announce] [issue16222] "server-side clone" not found by
	devguide's search box
Message-ID: <1350193296.32.0.998873485723.issue16222@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Neither searching for "server-side" nor "clone" in the devguide "Quick Search" box pulls up the mention of server-side clones:

http://docs.python.org/devguide/committing.html#long-term-development-of-features

----------
components: Devguide
messages: 172849
nosy: chris.jerdonek, eric.araujo, ezio.melotti, ncoghlan
priority: normal
severity: normal
status: open
title: "server-side clone" not found by devguide's search box
type: enhancement

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

From report at bugs.python.org  Sun Oct 14 07:49:11 2012
From: report at bugs.python.org (Eric Snow)
Date: Sun, 14 Oct 2012 05:49:11 +0000
Subject: [New-bugs-announce] [issue16223] untokenize returns a string if no
	encoding token is	recognized
Message-ID: <1350193751.15.0.784217855065.issue16223@psf.upfronthosting.co.za>


New submission from Eric Snow:

If you pass an iterable of tokens and none of them are an ENCODING token, tokenize.untokenize() returns a string.  This is contrary to what the docs say:

   It returns bytes, encoded using the ENCODING token, which is the
   first token sequence output by tokenize().

Either the docs should be clarified or untokenize() fixed.  My vote is to fix it.  It could check that the first token is an ENCODING token and raise an exception.  Alternately it could fall back to using 'utf-8' by default.

[1] http://docs.python.org/py3k/library/tokenize.html#tokenize.untokenize

----------
messages: 172850
nosy: eric.snow
priority: normal
severity: normal
stage: test needed
status: open
title: untokenize returns a string if no encoding token is recognized
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/issue16223>
_______________________________________

From report at bugs.python.org  Sun Oct 14 08:04:53 2012
From: report at bugs.python.org (Eric Snow)
Date: Sun, 14 Oct 2012 06:04:53 +0000
Subject: [New-bugs-announce] [issue16224] tokenize.untokenize() misbehaves
	when moved to	"compatiblity mode"
Message-ID: <1350194693.62.0.576275883555.issue16224@psf.upfronthosting.co.za>


New submission from Eric Snow:

When tokenize.untokenize() encounters a 2-tuple, it moves to compatibility mode, where only the token type and string are used from that point forward.  There are two closely related problems:

* when the iterable is a sequence, the portion of the sequence prior to the 2-tuple is traversed a second time under compatibility mode.
* when the iterable is an iterator, the first 2-tuple encountered is essentially gobbled up (see issue16221).

Either an explicit "iterable = iter(iterable)" or "iterable = list(iterable)" should happen at the very beginning of Untokenizer.untokenize().  If the former, Untokenizer.compat() should be fixed to not treat that first token differently.  If the latter, self.tokens should be cleared at the beginning of Untokenizer.compat().

I'll put up a patch with the second option when I get a chance.

----------
assignee: eric.snow
components: Library (Lib)
messages: 172851
nosy: eric.snow
priority: normal
severity: normal
stage: test needed
status: open
title: tokenize.untokenize() misbehaves when moved to "compatiblity mode"
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/issue16224>
_______________________________________

From report at bugs.python.org  Sun Oct 14 09:27:28 2012
From: report at bugs.python.org (Ian Carr-de Avelon)
Date: Sun, 14 Oct 2012 07:27:28 +0000
Subject: [New-bugs-announce] [issue16225] list.remove in for loop
Message-ID: <1350199648.26.0.090631048797.issue16225@psf.upfronthosting.co.za>


New submission from Ian Carr-de Avelon:

I'm new to Python and I've hit what appears to me to be a bug, but may be a "feature", so a tutorial bug. 
I tried to loop through the items in a list, test each and remove those which fail the test.

Simplifying to illustrate:
>>> print test
[1, 2, 3, 4, 5]
>>> for item in test:
...     print item
...     test.remove(item)
... 
1
3
5
>>> print test
[2, 4]

Whereas I would expect to see all items looped through and non left in the list.
I have worked with languages where you are explicitly warned that you must not mess with the loop variable, or where the behaviour you will get is explained in detail, so you can use it. Not having anything flagged up in eg 5.6. Looping Techniques on
http://docs.python.org/tutorial/datastructures.html
I assumed that the behaviour would be safe and intuative.
Yours
Ian

----------
messages: 172855
nosy: Ian
priority: normal
severity: normal
status: open
title: list.remove in for loop
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 14 11:17:59 2012
From: report at bugs.python.org (Francisco Gracia)
Date: Sun, 14 Oct 2012 09:17:59 +0000
Subject: [New-bugs-announce] [issue16226] IDLE crashes on *File / Path
	browser*
Message-ID: <1350206279.5.0.670551753566.issue16226@psf.upfronthosting.co.za>


New submission from Francisco Gracia:

The menu option *File / Path browser* (as well in the *Shell* window as in the *Editor* one) shows a new window with a tree structure rooted at *sys.path*. The available leaf nodes show the *plus* sign that usually implies that they can be expanded by clicking on the desired one. On the performance of this action IDLE disappears immediately. If one clicks just on the legend of the node, IDLE remains undisturbed but nothing more happens.

Idle's help says:

*File Menu:
...
Path Browser -- Show sys.path directories, modules, classes and methods*

so that apparently the expansion should also work.

I suppose that this command would be mostly used at the initial phases of learning Python (at least I would have done it if I had noticed then its existence and function), but its present status does not favor such didactic purpose.

Regards

----------
components: IDLE
messages: 172863
nosy: fgracia
priority: normal
severity: normal
status: open
title: IDLE crashes on *File / Path browser*
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Sun Oct 14 11:30:04 2012
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 14 Oct 2012 09:30:04 +0000
Subject: [New-bugs-announce] [issue16227] Change unicode howtos as misleading
Message-ID: <1350207004.2.0.875772602898.issue16227@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

For http://docs.python.org/howto/unicode.html (that's Python 2.7.3) and http://docs.python.org/release/3.1.5/howto/unicode.html the first paragraph states "(This HOWTO has not yet been updated to cover the 3.x versions of Python.)".  I suggest this is changed to read something like "Release 1.12 onwards of this document covers the 3.2 Python versions onwards."

----------
assignee: docs at python
components: Documentation
messages: 172865
nosy: BreamoreBoy, docs at python
priority: normal
severity: normal
status: open
title: Change unicode howtos as misleading
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Oct 14 11:56:18 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 14 Oct 2012 09:56:18 +0000
Subject: [New-bugs-announce] [issue16228] JSON crashes during encoding
	resized lists
Message-ID: <1350208578.8.0.440875886805.issue16228@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

JSON encoding crash if the source list resized in process of encoding. This can be happen unintentionally in multithreaded code.

Simple crash code:

import json
a = [object()] * 10
def crasher(obj):
    del a[-1]

json.dumps(a, default=crasher)

----------
components: Extension Modules
messages: 172867
nosy: bob.ippolito, ezio.melotti, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: JSON crashes during encoding resized lists
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Oct 14 11:57:25 2012
From: report at bugs.python.org (Francisco Gracia)
Date: Sun, 14 Oct 2012 09:57:25 +0000
Subject: [New-bugs-announce] [issue16229] Module *redemo.py* lacking in
	recent Python distributions
Message-ID: <1350208645.0.0.150897720098.issue16229@psf.upfronthosting.co.za>


New submission from Francisco Gracia:

Since Python 3.2 the module *redemo.py* is lacking in the official Python distributions. The excellent and extremely useful *Regular expressions HOWTO* of 3.2.x and 3.3 keep however referring to it (although referring to the wrong path *Tools/demo/* instead of *Tools/Scripts/*) and the same does the *README* file.

I just copied the version of the module distributed with 3.1 and it keeps working as well with 3.2.x as with 3.3.0 without having experienced any problems.

Is there any justification for this situation or is it just a slip?

Regards

----------
components: Demos and Tools
messages: 172868
nosy: fgracia
priority: normal
severity: normal
status: open
title: Module *redemo.py* lacking in recent Python distributions
versions: Python 3.2

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

From report at bugs.python.org  Sun Oct 14 12:37:16 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 14 Oct 2012 10:37:16 +0000
Subject: [New-bugs-announce] [issue16230] select.select crashes on resized
	lists
Message-ID: <1350211036.55.0.523850963705.issue16230@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Simple crash code:

import select
a = []
class F:
    def fileno(self):
        del a[-1]
        return 1

a[:] = [F()] * 10
select.select([], a, [])

----------
components: Extension Modules
messages: 172871
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: select.select crashes on resized lists
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Oct 14 16:30:17 2012
From: report at bugs.python.org (PSchaafsma)
Date: Sun, 14 Oct 2012 14:30:17 +0000
Subject: [New-bugs-announce] [issue16231] pickle persistent_id return value
Message-ID: <1350225017.39.0.976217955919.issue16231@psf.upfronthosting.co.za>


New submission from PSchaafsma:

The documentation of persistent_id prescribes that returning None will cause default pickling behavior. This makes sense.

However, in the Pickler.save function in pickle.py, the return value of persistent_id checked as boolean, causing also return values like 0 and [] to indicate default pickling.

This becomes a problem when unpickleable objects are identified by a simple index in some other list.

----------
components: Library (Lib)
messages: 172887
nosy: pschaafsma
priority: normal
severity: normal
status: open
title: pickle persistent_id return value
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 14 16:38:05 2012
From: report at bugs.python.org (emeaudroid emeaudroid)
Date: Sun, 14 Oct 2012 14:38:05 +0000
Subject: [New-bugs-announce] [issue16232] curses.textpad.Textbox backtrace
	support
Message-ID: <1350225485.82.0.832122533952.issue16232@psf.upfronthosting.co.za>


New submission from emeaudroid emeaudroid:

python: 2.6.6
curses' revision: 61064 2008-02-25 16:29:58Z andrew.kuchling


line 93 and 102 of curses/textpad.py

could you replace the backspace's specific chars codes by using this dedicated curses' function retrieving the currently in-use char's code ?

ord( curses.erasechar( ))

this one would make specific erase char specified to term supported, unlike curses.ascii.BS, curses.KEY_BACKSPACE that are specifics to most configurations indeed.

at least adding the curses.ascii.DEL char's code seems legit na ?

----------
components: Extension Modules
messages: 172888
nosy: emeaudroid.emeaudroid
priority: normal
severity: normal
status: open
title: curses.textpad.Textbox backtrace support
type: enhancement
versions: Python 2.6

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

From report at bugs.python.org  Sun Oct 14 17:52:29 2012
From: report at bugs.python.org (Francisco Gracia)
Date: Sun, 14 Oct 2012 15:52:29 +0000
Subject: [New-bugs-announce] [issue16233] IDLE: conceptual problems with
	*Class browser*
Message-ID: <1350229949.19.0.565182759034.issue16233@psf.upfronthosting.co.za>


New submission from Francisco Gracia:

The *File* option in the menu bar of both the Python shell and the program editor have an entry called *Class Browser*.

If one selects it from the shell window, one gets always an error message with the title: "No filename" which says: "This buffer has no associated filename". This happens whatever the previous history of the current interactive session.

If one selects it from the editor window with a Python module loaded, then another window shows correctly the expected information about the classes defined in such a module, if any. The same previous error 
appears if the current contents of the editor are not recognised as a Python module (for instance by not having been yet saved), which is reasonable.

IDLE's help says:
    "Class Browser    -- Show classes and methods in current file".

This does not clarify things much (what does *current file* mean from the shell window?) and does not permit one to get a coherent idea of the purpose originally intended for the option (a module imported in 
the current interactive session could not be rightly understood as a *current file*?).

I find this situation quite confuse and would suggest that some action could be taken in order to at least clarify it, if not improve it, as for instance (in order of desirability and --very likely-- difficulty):

    - Just make the error message less puzzling and more informative when coming from the shell window (what does *buffer* mean in this context?) and let the help file explain that this operation has only sense in connection with Python scripts being edited (if that is 
the case, as it seems).
    - Disable the option in the shell window.
    - Suppress the option in the shell window and keep it only in the editor window when the document it is handling is recognised as a Python module.
    - Keep the option also in the shell window and make it display information about the classes defined in the namespace of the current interactive session, if any. I think that this is what would be a real and useful *class browser*.

Thank you in advance for your attention.

----------
components: IDLE
messages: 172891
nosy: fgracia
priority: normal
severity: normal
status: open
title: IDLE: conceptual problems with *Class browser*
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun Oct 14 22:15:55 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 14 Oct 2012 20:15:55 +0000
Subject: [New-bugs-announce] [issue16234] Implement correct block_size and
	tests for HMAC-SHA3
Message-ID: <1350245755.11.0.901944251293.issue16234@psf.upfronthosting.co.za>


New submission from Christian Heimes:

HMAC-SHA3 hasn't been specified yet. Once an official RFC or NIST document is out I can implement the correct block_size attribute and add test vectors. In the mean time I'm disabling SHA3 by returning NotImplemented from block_size.

This ticket a reminder for myself.

----------
assignee: christian.heimes
components: Extension Modules, Library (Lib)
messages: 172910
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Implement correct block_size and tests for HMAC-SHA3
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct 14 23:55:14 2012
From: report at bugs.python.org (Ray Donnelly)
Date: Sun, 14 Oct 2012 21:55:14 +0000
Subject: [New-bugs-announce] [issue16235] Add python-config.sh for use
	during cross compilation.
Message-ID: <1350251714.79.0.226527559426.issue16235@psf.upfronthosting.co.za>


New submission from Ray Donnelly:

Creates python-config.sh which aims to behave exactly the same as python-config except it doesn't depend on a Python interpreter on the build machine (only depends on a posixy shell, tested with bash, dash, MSYS-bash).

I use this for cross compiling gdb with Python pretty printer support.

----------
components: Cross-Build
files: 0000-add-python-config-sh.patch
keywords: patch
messages: 172925
nosy: Ray.Donnelly
priority: normal
severity: normal
status: open
title: Add python-config.sh for use during cross compilation.
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27572/0000-add-python-config-sh.patch

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

From report at bugs.python.org  Mon Oct 15 00:15:17 2012
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 14 Oct 2012 22:15:17 +0000
Subject: [New-bugs-announce] [issue16236] Doc/Makefile should have
	$PYTHON=python2
Message-ID: <1350252917.6.0.180225296667.issue16236@psf.upfronthosting.co.za>


New submission from Michele Orr?:

On Arch/Linux, running `make html` fails with

$ make html
mkdir -p build/html build/doctrees
python tools/sphinx-build.py -b html -d build/doctrees -D latex_paper_size=  . build/html 
Traceback (most recent call last):
  File "tools/sphinx-build.py", line 27, in <module>
    from sphinx import main
  File "/..../cpython/Doc/tools/sphinx/__init__.py", line 44
    except ImportError, err:
                      ^
SyntaxError: invalid syntax
make: *** [build] Error 1

That is because sphinx needs python version 2 to run; but `python` is symlinked to python3 on my platform. We should replace $PYTHON with python2, which AFAIS here[0], it would point to the correct version.

[0] http://hg.python.org/cpython/file/5fc6f47974db/Makefile.pre.in#l808

----------
components: Interpreter Core
messages: 172931
nosy: maker
priority: normal
severity: normal
status: open
title: Doc/Makefile should have $PYTHON=python2
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/issue16236>
_______________________________________

From report at bugs.python.org  Mon Oct 15 04:24:31 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 15 Oct 2012 02:24:31 +0000
Subject: [New-bugs-announce] [issue16237] bdist_rpm SPEC files created with
	distutils may be	distro specific
Message-ID: <1350267871.71.0.392371801371.issue16237@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

In resolving 14443 we effectively embedded the vendor macros in the SPEC file generated by bdist_rpm on older versions of RHEL (and derivatives).

While I think that's a necessary evil (in order to create Python 3 RPMs that actually work properly at all on those platforms), we should note the distro limitation somewhere in the documentation: even if the RPM would otherwise work properly on Fedora *and* RHEL (and perhaps even openSUSE), the embedded copy of the vendor post install macros may misfire.

----------
assignee: docs at python
components: Documentation
messages: 172938
nosy: dmalcolm, docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: bdist_rpm SPEC files created with distutils may be distro specific
type: enhancement
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Oct 15 13:33:54 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 15 Oct 2012 11:33:54 +0000
Subject: [New-bugs-announce] [issue16238] Automatically remove build
	directory when build options	changed
Message-ID: <1350300834.63.0.981208567885.issue16238@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

After build options in setup.py is edited, command `python setup.py install` doesn't remove build directory and uses its cached content. This behavior is non-obvious and leads to errors.

The proposal is to calculate hash from build configuration, save it in build directory, and regenerate build dir when hash doesn't match.

----------
assignee: eric.araujo
components: Distutils, Distutils2
messages: 172961
nosy: alexis, eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: Automatically remove build directory when build options changed
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Oct 15 14:55:38 2012
From: report at bugs.python.org (=?utf-8?q?Peter_W=C3=BCrtz?=)
Date: Mon, 15 Oct 2012 12:55:38 +0000
Subject: [New-bugs-announce] [issue16239] PEP8 arithmetic operator examples
Message-ID: <1350305738.94.0.323061453439.issue16239@psf.upfronthosting.co.za>


New submission from Peter W?rtz:

I think the PEP8 examples for arithmetic expressions are a bit misleading. (http://www.python.org/dev/peps/pep-0008/#id20)

The text clearly says that it should add spaces around operators of low(est) priority, which means that I'm encouraged to visually group an expression of high priority. It doesn't say (anymore?) that there should always be spaces around all arithmetic operators.

This is however not reflected in the examples. In the examples
"x = x*2 - 1" is listed as a negative example, while being perfectly compliant with the guide. Shouldn't this be in the "Yes" or an "Optionally" example block?

I believe these examples may cause some people to interpret the style guide in a very rigid way, eventually leading to PEP8 formatting tools that flatten out nicely grouped expressions.

----------
assignee: docs at python
components: Documentation
messages: 172965
nosy: docs at python, pwuertz
priority: normal
severity: normal
status: open
title: PEP8 arithmetic operator examples
type: enhancement

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

From report at bugs.python.org  Mon Oct 15 16:43:29 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 15 Oct 2012 14:43:29 +0000
Subject: [New-bugs-announce] [issue16240] Document a way to escape
	metacharacters in glob/fnmatch
Message-ID: <1350312209.74.0.651951907427.issue16240@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

fnmatch.translate's docstraing says "There is no way to quote meta-characters.", but this is wrong. One can remove the special meaning of ``'?'``, ``'*'`` and ``'['`` by wrapping them between square brackets. Thus, ``'[?]'`` matches the literal character ``'?'``.

There are a lot of related issues: issue8402, issue13929, issue9358, issue738389, issue738361, issue1580472, issue5852.

----------
assignee: docs at python
components: Documentation
files: fnmatch_doc_escape.patch
keywords: easy, patch
messages: 172976
nosy: docs at python, serhiy.storchaka
priority: high
severity: normal
status: open
title: Document a way to escape metacharacters in glob/fnmatch
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27581/fnmatch_doc_escape.patch

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

From report at bugs.python.org  Mon Oct 15 17:05:21 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 15 Oct 2012 15:05:21 +0000
Subject: [New-bugs-announce] [issue16241] "-X faulthandler" is not
	documented in -X option docs
Message-ID: <1350313521.23.0.589479174065.issue16241@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

http://docs.python.org/release/3.3.0/using/cmdline.html#cmdoption-X says "CPython currently defines none of them..." But in Python 3.3, "faulthandler" can be passed to the option.

----------
assignee: docs at python
components: Documentation
messages: 172980
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: "-X faulthandler" is not documented in -X option docs
versions: Python 3.3

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

From report at bugs.python.org  Mon Oct 15 20:11:13 2012
From: report at bugs.python.org (Joseph Fall)
Date: Mon, 15 Oct 2012 18:11:13 +0000
Subject: [New-bugs-announce] [issue16242] Pickle and __getattr__
Message-ID: <1350324673.62.0.567343854306.issue16242@psf.upfronthosting.co.za>


New submission from Joseph Fall:

This report is to re-raise an old issue from 2009:
http://bugs.python.org/issue5370
Although that issue is marked as "fixed", I disagree that it was ever "fixed", and spent an evil day tracking it down. 

Use Case:
- take two 3rd party packages: django and django-crispy-forms
- django, deep in its inner-workings, uses Pickle
- django-cripsy-forms implements the _getattr__ method in one of it's classes
- when you put the two together such that django pickles a form, the python interpreter goes into a tailspin in very sinister and hard-to-track-down ways (different behaviour in 2.5, 2.6, 2.7, as noted in issue5370, which includes a simple test case)

The "resolution" for issue5370 was to add some documentation to Pickle.  But I would argue this is insufficient - the implementer of django-crispy-forms would have no reason to ever look at the Pickle docs, and so is very likely to implement this bug (which s/he did).

Perhaps, if this issue cannot be resolved in code, as suggested by gagenellina back in 2009, at least some documentation could be added to __getattr__ (and others) warning that these methods could potentially be called before __init__ (similar to the documentation added to Pickle)?  I'd be happy to draft a small bit of documentation for this, although if someone can think of a way to simply resolve this in Pickle so it does not cause the issue in the first place, that seems to me ideal.

A test case is included with issue5370

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 172993
nosy: docs at python, powderflask
priority: normal
severity: normal
status: open
title: Pickle and __getattr__
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Oct 16 01:19:45 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 15 Oct 2012 23:19:45 +0000
Subject: [New-bugs-announce] [issue16243] Regression in inspect module
Message-ID: <1350343185.48.0.60485336671.issue16243@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

In Python 3.3.0 and 3.2.3:

>>> from inspect import *
>>> def f(a,b):pass
...
>>> formatargspec(getargspec(f))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/inspect.py", line 905, in formatargspec
    spec = formatargandannotation(arg)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/inspect.py", line 898, in formatargandannotation
    if arg in annotations:
TypeError: unhashable type: 'list'

No such error in 2.7.1:

>>> formatargspec(getargspec(f))
'((a, b), None, None, None)'

----------
components: Library (Lib)
messages: 173003
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Regression in inspect module
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Oct 16 07:05:37 2012
From: report at bugs.python.org (Richard Jones)
Date: Tue, 16 Oct 2012 05:05:37 +0000
Subject: [New-bugs-announce] [issue16244] TimedRotatingFileHandler forces
	"write" mode, should use "append"
Message-ID: <1350363937.05.0.667982982296.issue16244@psf.upfronthosting.co.za>


New submission from Richard Jones:

The RotatingFileHandler classes force the open() mode of the new log file to be "w" even though it is initially defaulted to "a" in doRollover() methods:

        self.mode = 'w'
        self.stream = self._open()

This can cause problems in systems that have multiple programs writing to the log file; they can both end up opening the new file in "w" mode and then there's loss of data.

I cannot think of a reason why "w" should be forced in this manner.

The fix is to remove the "self.mode = 'w'" line from the two doRollover() methods.

----------
components: Library (Lib)
messages: 173016
nosy: richard
priority: normal
severity: normal
status: open
title: TimedRotatingFileHandler forces "write" mode, should use "append"
type: behavior

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

From report at bugs.python.org  Tue Oct 16 11:41:51 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Oct 2012 09:41:51 +0000
Subject: [New-bugs-announce] [issue16245] Update html.entities.html5
	dictionary and	parseentities.py
Message-ID: <1350380511.49.0.860998010837.issue16245@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

A JSON file containing all the HTML5 entities is now available at http://dev.w3.org/html5/spec/entities.json.
I tested from the interpreter to see if it matches the values in html.entities.html5 and there are a dozen of entities that need to be updated:

>>> s = json.load(open('entities.json'))
>>> from html.entities import html5
>>> for (k1,i1),(k2,i2) in zip(sorted(s.items()), sorted(html5.items())):
...   if i1['characters'] != i2: (k1, k2, i1['characters'], i2, i1['codepoints'], list(map(ord, i2)))
... 
('&DotDot;', 'DotDot;', '?', '??', [8412], [9676, 8412])
('&DownBreve;', 'DownBreve;', '?', '??', [785], [9676, 785])
('&LeftAngleBracket;', 'LeftAngleBracket;', '?', '?', [10216], [9001])
('&NewLine;', 'NewLine;', '\n', '?', [10], [9226])
('&RightAngleBracket;', 'RightAngleBracket;', '?', '?', [10217], [9002])
('&Tab;', 'Tab;', '\t', '?', [9], [9225])
('&TripleDot;', 'TripleDot;', '?', '??', [8411], [9676, 8411])
('&lang;', 'lang;', '?', '?', [10216], [9001])
('&langle;', 'langle;', '?', '?', [10216], [9001])
('&rang;', 'rang;', '?', '?', [10217], [9002])
('&rangle;', 'rangle;', '?', '?', [10217], [9002])
('&tdot;', 'tdot;', '?', '??', [8411], [9676, 8411])

The Tools/scripts/parseentities.py script should also be updated (or possibly a new, separate script should be added), so it can be used to generate the html5 dict.  I'm setting this as release blocker so that the update gets done before the release (other values might change in the meanwhile).

----------
assignee: ezio.melotti
messages: 173021
nosy: ezio.melotti
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Update html.entities.html5 dictionary and parseentities.py
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Oct 16 14:16:57 2012
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 16 Oct 2012 12:16:57 +0000
Subject: [New-bugs-announce] [issue16246] Multiprocessing infinite loop on
	Windows
Message-ID: <1350389817.55.0.995425148307.issue16246@psf.upfronthosting.co.za>


New submission from Ethan Furman:

On Windows multiprocessing has a well known limitation: because there is no fork() new shells must be invoked, and if the call that ultimately starts multiprocessing is not guarded by an `if __name__ == '__main___'` check an infinite loops results and you have a very nice brick instead of a computer.

On Stackoverflow I proposed a work-around [1], which is basically to check if an environment variable exists (MP_GUARD is this case), and if it does raise an exception.

I'm going to try and merge that into multiprocessing itself.  Are there any other platforms besides Windows where this is a problem?

[1] http://stackoverflow.com/q/12852643/208880

----------
components: Windows
messages: 173033
nosy: amaury.forgeotdarc, jnoller, stoneleaf
priority: normal
severity: normal
status: open
title: Multiprocessing infinite loop on Windows
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Oct 16 14:31:20 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 16 Oct 2012 12:31:20 +0000
Subject: [New-bugs-announce] [issue16247] Report failing url in URLError?
Message-ID: <1350390680.77.0.132205585956.issue16247@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Trying to streamline the URL retrieval example in the concurrent.futures docs were severely hampered by the fact the URLError thrown by urlopen doesn't tell you *what URL* it was trying to retrieve when it failed.

This is OK in synchronous code (where you probably still have the URL around), but quite a pain in asynchronous code (such as that using concurrent.futures) where the original context may have been lost by the time the future is signalled.

----------
messages: 173035
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Report failing url in URLError?

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

From report at bugs.python.org  Tue Oct 16 17:29:21 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 16 Oct 2012 15:29:21 +0000
Subject: [New-bugs-announce] [issue16248] Security bug in tkinter allows for
	untrusted code	execution.
Message-ID: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

Because tkinter.py uses exec to execute code from a file, it has a security bug. It searches for the file in the home dir. Apparently, on my system (don't know if its the same on others), the $HOME variable is the same as the non-root one when running Python with root priveleges
Steps to reproduce:
create a file called .Tk.py in your home folder
Whatever code is in that file will be executed.

run these three lines of code in Python:

import tkinter
w = tkinter.Tk()
w.mainloop()

I will add more details in later comments.

----------
components: Tkinter
messages: 173047
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: Security bug in tkinter allows for untrusted code execution.

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

From report at bugs.python.org  Tue Oct 16 17:32:35 2012
From: report at bugs.python.org (julien tayon)
Date: Tue, 16 Oct 2012 15:32:35 +0000
Subject: [New-bugs-announce] [issue16249] unicode name accepts a punctuation
	glyph
Message-ID: <1350401555.49.0.382314434888.issue16249@psf.upfronthosting.co.za>


New submission from julien tayon:

I guess unicode variable names are restricted to letters, and that symbols and punctuation shoud be ignored (except _).

I have tested other dots (punctuation) they dont work. 

Only
http://www.fileformat.info/info/unicode/char/00b7/index.htm
oddly enough has worked so far.


$ python3.2
Python 3.2.3 (default, Sep 10 2012, 18:14:40) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> foo?bar=42
  File "<stdin>", line 1
    foo?bar=42
            ^
SyntaxError: invalid character in identifier
>>> print(ord("foo?bar"[3]))
8901
>>> foo?bar = 42
>>> print(ord("foo?bar"[3]))
183

I have sampled randomly in the same block as MIDDLE DOT and it seems to behave correctly.

----------
components: Interpreter Core
messages: 173049
nosy: julien.tayon
priority: normal
severity: normal
status: open
title: unicode name accepts a punctuation glyph
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Oct 16 18:18:13 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 16 Oct 2012 16:18:13 +0000
Subject: [New-bugs-announce] [issue16250] URLError invoked with reason as
	filename
Message-ID: <1350404293.01.0.800497532294.issue16250@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to fix invocations of URLError so that "reasons" are not passed in for the "filename" argument of the URLError constructor.

Ezio found and described this issue when commenting on issue 10836:

  http://bugs.python.org/issue10836#msg172988

In more detail: URLError accepts "reason" and "filename" arguments:

http://hg.python.org/cpython/file/74b95194ba86/Lib/urllib/error.py#l23

However, in several places in Lib/urllib, URLError is invoked with a "reason" passed in for the filename.  For example:

    raise URLError('local file error', 'not on local host')

This issue could be addressed for this example by changing the above to:

    raise URLError('local file error: not on local host')

This dovetails with issue #16247, which is to start passing the actual filename in for some calls to URLError (and perhaps to adjust URLError's __str__, etc).

----------
components: Library (Lib)
keywords: easy
messages: 173058
nosy: chris.jerdonek, ezio.melotti
priority: normal
severity: normal
status: open
title: URLError invoked with reason as filename
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 16 20:24:54 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 16 Oct 2012 18:24:54 +0000
Subject: [New-bugs-announce] [issue16251] object.__reduce__()
Message-ID: <1350411894.01.0.763638555345.issue16251@psf.upfronthosting.co.za>


New submission from Eric Snow:

In Objects/typeobject.c, reduce_2() makes _PyObject_GetAttrId() calls to pull some methods for the object in question.  This is a problem when the object's type defines __getattr__() or __getattribute__() and returns something like None when the attribute is not found:


from copy import deepcopy

class Spam(dict):
    def __getattr__(self, name):
        # defaults to None
        return self.get(name)

deepcopy(Spam(ham=5))


While we could do a check on the result of _PyObject_GetAttrId() to make sure it is callable, the better solution would be to look up the methods on the object's type rather than on the object.  Doing so falls in line with the specified pattern for special method lookup [1].  I'm guessing there are a few other related places in typeobject.c that have the same problem which could be fixed in the same way.

I'm marking this as a bug rather than a feature since it is a deviation from the specification for special methods.

[1] http://docs.python.org/dev/reference/datamodel.html#special-method-lookup

----------
components: Interpreter Core
messages: 173066
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: object.__reduce__()
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/issue16251>
_______________________________________

From report at bugs.python.org  Tue Oct 16 21:10:56 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Oct 2012 19:10:56 +0000
Subject: [New-bugs-announce] [issue16252] bytes and bytearray methods are
	undocumented
Message-ID: <1350414656.76.0.593225775655.issue16252@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Everything is in the title. I couldn't find any doc for bytes.join, etc. (while str methods are documented in library/stdtypes.html#string-methods).

----------
assignee: docs at python
components: Documentation
messages: 173074
nosy: docs at python, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: bytes and bytearray methods are undocumented
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Oct 16 21:28:04 2012
From: report at bugs.python.org (Roger Upole)
Date: Tue, 16 Oct 2012 19:28:04 +0000
Subject: [New-bugs-announce] [issue16253] Docs for
	PyArg_ParseTupleAndKeywords say it doesn't	accept nested tuples
Message-ID: <1350415684.72.0.0946925077197.issue16253@psf.upfronthosting.co.za>


New submission from Roger Upole:

The docs for this function state
"Nested tuples cannot be parsed when using keyword arguments!"
but this restriction was removed some time ago.

----------
assignee: docs at python
components: Documentation
messages: 173081
nosy: docs at python, rupole
priority: normal
severity: normal
status: open
title: Docs for PyArg_ParseTupleAndKeywords say it doesn't accept nested tuples

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

From report at bugs.python.org  Tue Oct 16 22:14:08 2012
From: report at bugs.python.org (David Beazley)
Date: Tue, 16 Oct 2012 20:14:08 +0000
Subject: [New-bugs-announce] [issue16254] PyUnicode_AsWideCharString()
	increases string size
Message-ID: <1350418448.6.0.265249549125.issue16254@psf.upfronthosting.co.za>


New submission from David Beazley:

The PyUnicode_AsWideCharString() function is described as creating a new buffer of type wchar_t allocated by PyMem_Alloc() (which must be freed by the user).   However, if you use this function, it causes the size of the original string object to permanently increase.  For example, suppose you had some extension code like this:

static PyObject *py_receive_wchar(PyObject *self, PyObject *args) {
  PyObject *obj;
  wchar_t *s;
  Py_ssize_t len;

  if (!PyArg_ParseTuple(args, "U", &obj)) {
    return NULL;
  }
  if ((s = PyUnicode_AsWideCharString(obj, &len)) == NULL) {
    return NULL;
  }
  /* Do nothing */
  PyMem_Free(s);
  Py_RETURN_NONE;
}

Now, try an experiment (assume that the above extension function is available as 'receive_wchar'). 

>>> s = "Hell"*1000
>>> len(s)
4000
>>> import sys
>>> sys.getsizeof(s)
4049
>>> receive_wchar(s)
>>> sys.getsizeof(s)
20053
>>>

It seems that PyUnicode_AsWideCharString() may be filling in the wstr field of the associated PyASCIIObject structure from PEP393 (I haven't verified).  Once filled, it never seems to be discarded.

Background:  I am trying to figure out how to convert from Unicode to (wchar_t, int *) that doesn't cause a permanent increase in the memory footprint of the original Unicode object.  Also, I'm trying to stay away from deprecated Unicode APIs.

----------
components: Extension Modules, Interpreter Core, Unicode
messages: 173089
nosy: dabeaz, ezio.melotti
priority: normal
severity: normal
status: open
title: PyUnicode_AsWideCharString() increases string size
versions: Python 3.3

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

From report at bugs.python.org  Tue Oct 16 23:00:02 2012
From: report at bugs.python.org (Ben Rousch)
Date: Tue, 16 Oct 2012 21:00:02 +0000
Subject: [New-bugs-announce] [issue16255] subrocess.Popen needs /bin/sh but
	Android only has	/system/bin/sh
Message-ID: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za>


New submission from Ben Rousch:

The subprocess.Popen function uses /bin/sh in Unix environments. Android is detected as a Unix environemnt, but has moved that executable to /system/bin/sh. This can be worked around by adding a parameter "executable='/system/bin/sh'" to the call, but it is impractical to do this for every call to Popen in every library and codebase. For subprocess.Popen to work on Android, Popen needs to be able to detect if /bin/sh is not there and try /system/bin/sh instead.

----------
components: Library (Lib)
messages: 173093
nosy: brousch
priority: normal
severity: normal
status: open
title: subrocess.Popen needs /bin/sh but Android only has /system/bin/sh
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 17 01:09:22 2012
From: report at bugs.python.org (Christopher Barker)
Date: Tue, 16 Oct 2012 23:09:22 +0000
Subject: [New-bugs-announce] [issue16256] permissions wrong on Mac doc dir
Message-ID: <1350428962.56.0.21849680877.issue16256@psf.upfronthosting.co.za>


New submission from Christopher Barker:

I just tried to "pip install ipython" and got:

error: could not create
'/Library/Frameworks/Python.framework/Versions/2.7/share/doc/ipython':
Permission denied

indeed:

$ ls -l /Library/Frameworks/Python.framework/Versions/2.7/share/
total 0
drwxr-xr-x  3 root  admin  102 Oct 11 09:14 doc
drwxrwxr-x  3 root  admin  102 Jun 11  2011 man

which looks like the doc dir should have the same perms as the man dir.

we might want to clen up that tiny nugget in future builds.

----------
assignee: ronaldoussoren
components: Installation, Macintosh
messages: 173108
nosy: Chris.Barker, ronaldoussoren
priority: normal
severity: normal
status: open
title: permissions wrong on Mac doc dir
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 17 04:18:11 2012
From: report at bugs.python.org (Trent Nelson)
Date: Wed, 17 Oct 2012 02:18:11 +0000
Subject: [New-bugs-announce] [issue16257] test_socket.test_create_connection
	tests for wrong errno	on Solaris
Message-ID: <1350440291.72.0.895496145296.issue16257@psf.upfronthosting.co.za>


New submission from Trent Nelson:

======================================================================
FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/3.x.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/test/test_socket.py", line 4112, in test_create_connection
    self.assertEqual(cm.exception.errno, errno.ECONNREFUSED)
AssertionError: 128 != 146

>>> errno.errorcode[128]
'ENETUNREACH'

Needs a Solaris-specific exception.

----------
messages: 173123
nosy: trent
priority: normal
severity: normal
status: open
title: test_socket.test_create_connection tests for wrong errno on Solaris
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Oct 17 04:19:55 2012
From: report at bugs.python.org (Trent Nelson)
Date: Wed, 17 Oct 2012 02:19:55 +0000
Subject: [New-bugs-announce] [issue16258] test_local.TestEnUSCollection
	failures on Solaris 10
Message-ID: <1350440395.6.0.0364005495024.issue16258@psf.upfronthosting.co.za>


New submission from Trent Nelson:

======================================================================
ERROR: test_strxfrm (test.test_locale.TestEnUSCollation)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/3.x.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/test/test_locale.py", line 346, in test_strxfrm
    self.assertLess(locale.strxfrm('a'), locale.strxfrm('b'))
ValueError: character U+101010e is not in range [U+0000; U+10ffff]

======================================================================
ERROR: test_strxfrm_with_diacritic (test.test_locale.TestEnUSCollation)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/3.x.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/test/test_locale.py", line 367, in test_strxfrm_with_diacritic
    self.assertLess(locale.strxfrm('?'), locale.strxfrm('b'))
ValueError: character U+101010e is not in range [U+0000; U+10ffff]

----------------------------------------------------------------------

Haven't investigated yet.

----------
messages: 173124
nosy: trent
priority: normal
severity: normal
status: open
title: test_local.TestEnUSCollection failures on Solaris 10
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Oct 17 05:26:34 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 17 Oct 2012 03:26:34 +0000
Subject: [New-bugs-announce] [issue16259] Replace exec() in test.regrtest
	with __import__
Message-ID: <1350444394.63.0.4278126209.issue16259@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In Lib/test/regrtest.py:1336 , exec is used to import an module. I think it could be replaced with an __import__ call.

----------
components: Library (Lib)
messages: 173126
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: Replace exec() in test.regrtest with __import__

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

From report at bugs.python.org  Wed Oct 17 10:02:43 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 17 Oct 2012 08:02:43 +0000
Subject: [New-bugs-announce] [issue16260] change bare except in locale.py
Message-ID: <1350460963.18.0.317835294303.issue16260@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In Lib/locale.py:1860 , a bare except is used. It should be replaced with "except Error" as the setlocale() function raises `Error` if an error occurs.

----------
components: Library (Lib)
messages: 173138
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: change bare except in locale.py

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

From report at bugs.python.org  Wed Oct 17 10:06:05 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 17 Oct 2012 08:06:05 +0000
Subject: [New-bugs-announce] [issue16261] Fix bare excepts in various places
	in std lib
Message-ID: <1350461165.29.0.129000928595.issue16261@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

Will attach patch.

----------
components: Library (Lib)
messages: 173140
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: Fix bare excepts in various places in std lib

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

From report at bugs.python.org  Wed Oct 17 11:01:26 2012
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 17 Oct 2012 09:01:26 +0000
Subject: [New-bugs-announce] [issue16262] srcdir != builddir builds fail,
	if hg is not installed
Message-ID: <1350464486.47.0.189031527493.issue16262@psf.upfronthosting.co.za>


New submission from Matthias Klose:

seen with the 3.3 branch and the trunk:

also, I think using python now unconditionally breaks the cross builds, so this should call PYTHON_FOR_BUILD, not python.

/bin/mkdir -p Include
hg: no-repository, python: found! cannot run ../Parser/asdl_c.py -h Include ../Parser/Python.asdl
/bin/mkdir -p Python
hg: no-repository, python: found! cannot run ../Parser/asdl_c.py -c Python ../Parser/Python.asdl
gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security  -fprofile-generate -g -flto -fuse-linker-plugin -IObjects -IInclude -IPython -I. -IInclude -I../Include -D_FORTIFY_SOURCE=2   -DPy_BUILD_CORE -o Python/Python-ast.o Python/Python-ast.c
gcc: error: Python/Python-ast.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.
make[3]: *** [Python/Python-ast.o] Error 4

----------
messages: 173146
nosy: doko
priority: normal
severity: normal
status: open
title: srcdir != builddir builds fail, if hg is not installed

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

From report at bugs.python.org  Wed Oct 17 12:21:45 2012
From: report at bugs.python.org (Trent Nelson)
Date: Wed, 17 Oct 2012 10:21:45 +0000
Subject: [New-bugs-announce] [issue16263] sendmsg, recvmsg,
	recvmsg_into et al not being detected on Solaris
Message-ID: <1350469305.65.0.493434149752.issue16263@psf.upfronthosting.co.za>


New submission from Trent Nelson:

Sample test_socket -v output:

testSendmsgDataGenerator (test.test_socket.SendmsgUDPTest) ... skipped "don't have sendmsg"
testSendmsgExcessCmsgReject (test.test_socket.SendmsgUDPTest) ... skipped "don't have sendmsg"
testSendmsgGather (test.test_socket.SendmsgUDPTest) ... skipped "don't have sendmsg"
testSendmsgNoDestAddr (test.test_socket.SendmsgUDPTest) ... skipped "don't have sendmsg"
testRecvmsg (test.test_socket.RecvmsgUDPTest) ... skipped "don't have recvmsg"
testRecvmsgAfterClose (test.test_socket.RecvmsgUDPTest) ... skipped "don't have recvmsg"
testRecvmsgBadArgs (test.test_socket.RecvmsgUDPTest) ... skipped "don't have recvmsg"

This is on the Solaris 10 box.  sendmsg/recvmsg etc definitely exist.

Haven't investigated yet.

----------
assignee: trent
messages: 173154
nosy: jcea, trent
priority: normal
severity: normal
status: open
title: sendmsg, recvmsg, recvmsg_into et al not being detected on Solaris
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Oct 17 13:00:46 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Oct 2012 11:00:46 +0000
Subject: [New-bugs-announce] [issue16264] test_logging failure on Windows 7
	buildbot
Message-ID: <1350471646.28.0.767525471529.issue16264@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Changeset d3c7ebdc71bb produced the following test failure on one of the stable buildbots:


======================================================================
FAIL: test_noserver (test.test_logging.SocketHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_logging.py", line 1453, in test_noserver
    self.assertTrue(self.sock_hdlr.retryTime > now)
AssertionError: False is not true

See http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x

----------
assignee: giampaolo.rodola
components: Library (Lib), Tests
messages: 173157
nosy: giampaolo.rodola, jkloth, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging failure on Windows 7 buildbot
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 17 14:48:50 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Wed, 17 Oct 2012 12:48:50 +0000
Subject: [New-bugs-announce] [issue16265] Code sample does not collapse
	correctly
Message-ID: <1350478130.47.0.20528799459.issue16265@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

http://docs.python.org/py3k/tutorial/inputoutput.html#fancier-output-formatting

In the last but second code sample in that section, the code is not correctly colored and cannot be correctly collapsed.

Expanded:

>>> table = {'Sjoerd': 4127, 'Jack': 4098, 'Dcab': 8637678}
>>> print ('Jack: {0[Jack]:d}; Sjoerd: {0[Sjoerd]:d}; '
...        'Dcab: {0[Dcab]:d}'.format(table))
Jack: 4098; Sjoerd: 4127; Dcab: 8637678

Collapsed:

table = {'Sjoerd': 4127, 'Jack': 4098, 'Dcab': 8637678}
print('Jack: {0[Jack]:d}; Sjoerd: {0[Sjoerd]:d}; '

----------
assignee: docs at python
components: Documentation
messages: 173163
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Code sample does not collapse correctly
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Oct 17 14:58:39 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Wed, 17 Oct 2012 12:58:39 +0000
Subject: [New-bugs-announce] [issue16266] Typo in tutorial
Message-ID: <1350478719.85.0.211709670607.issue16266@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

http://docs.python.org/py3k/tutorial/inputoutput.html#reading-and-writing-files

The text:

In text mode, the default is to convert platform-specific line endings (\n on Unix, \r\n on Windows) to just \n on reading and \n back to platform-specific line endings on writing. 

Is the last '\n' a typo and not needed?

----------
assignee: docs at python
components: Documentation
messages: 173165
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Typo in tutorial
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Oct 17 17:41:21 2012
From: report at bugs.python.org (Christopher the Magnificent)
Date: Wed, 17 Oct 2012 15:41:21 +0000
Subject: [New-bugs-announce] [issue16267] order of decorators
	@abstractmethod and @classmethod is	significant (is not
	documented to be in @abstractclassmethod	which advises their
	combined use)
Message-ID: <1350488481.01.0.487550684008.issue16267@psf.upfronthosting.co.za>


New submission from Christopher the Magnificent:

This may be an issue with the interpreter behavior or it may be a documentation issue.

Note: I only selected Python 3.3 as the version, but it probably affects MANY other Python versions.

Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 01:25:11) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "copyright", "credits" or "license()" for more information.
>>> import abc
>>> help(abc.abstractclassmethod)
Help on class abstractclassmethod in module abc:

class abstractclassmethod(builtins.classmethod)
 |  A decorator indicating abstract classmethods.
 |  
 |  Similar to abstractmethod.
 |  
 |  Usage:
 |  
 |      class C(metaclass=ABCMeta):
 |          @abstractclassmethod
 |          def my_abstract_classmethod(cls, ...):
 |              ...
 |  
 |  'abstractclassmethod' is deprecated. Use 'classmethod' with
 |  'abstractmethod' instead.
. (et cetra)
.
.
>>> # doesn't work
>>> class Demo(metaclass=abc.ABCMeta):
... 	@abc.abstractmethod
... 	@classmethod
... 	def test(cls):
... 		pass
... 
Traceback (most recent call last):
  File "<pyshell#26>", line 1, in <module>
    class Demo3(metaclass=abc.ABCMeta):
  File "<pyshell#26>", line 3, in Demo3
    @classmethod
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/abc.py", line 24, in abstractmethod
    funcobj.__isabstractmethod__ = True
AttributeError: attribute '__isabstractmethod__' of 'classmethod' objects is not writable
>>> # DOES work
>>> class Demo2(metaclass=abc.ABCMeta):
... 	@classmethod
... 	@abc.abstractmethod
... 	def test(cls):
... 		pass
... 	
>>> Demo2()
Traceback (most recent call last):
  File "<pyshell#33>", line 1, in <module>
    Demo4()
TypeError: Can't instantiate abstract class Demo2 with abstract methods test


Hopefully this is enough documentation to show what the issues is.  If not, just chime in.  :-)

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 173183
nosy: christopherthemagnificent, docs at python
priority: normal
severity: normal
status: open
title: order of decorators @abstractmethod and @classmethod is significant (is not documented to be in @abstractclassmethod which advises their combined use)
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Oct 17 21:05:10 2012
From: report at bugs.python.org (Christopher the Magnificent)
Date: Wed, 17 Oct 2012 19:05:10 +0000
Subject: [New-bugs-announce] [issue16268] dir(closure) claims that a closure
	has no __dir__,
	only to work later after manually invoking __dir__ from its type
Message-ID: <1350500710.5.0.876584221442.issue16268@psf.upfronthosting.co.za>


New submission from Christopher the Magnificent:

This is really short, you should spot the inconsistency in the result of the same function call fairly easily.

Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 01:25:11) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class Thing:
...     def method(self):
...             print(__class__)
... 
>>> x = Thing.method.__closure__[0]
>>> dir(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object does not provide __dir__
>>> type(x).__dir__(x)
['__gt__', '__eq__', '__setattr__', '__doc__', '__sizeof__', '__str__', '__init__', '__repr__', 'cell_contents', '__dir__', '__ge__', '__class__', '__new__', '__ne__', '__subclasshook__', '__hash__', '__lt__', '__reduce__', '__le__', '__getattribute__', '__format__', '__reduce_ex__', '__delattr__']
>>> dir(x)
['__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'cell_contents']
>>>

----------
components: Interpreter Core
messages: 173197
nosy: christopherthemagnificent
priority: normal
severity: normal
status: open
title: dir(closure) claims that a closure has no __dir__, only to work later after manually invoking __dir__ from its type
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Oct 17 23:28:38 2012
From: report at bugs.python.org (William Edwards)
Date: Wed, 17 Oct 2012 21:28:38 +0000
Subject: [New-bugs-announce] [issue16269] multiprocessing.Queue uses select()
Message-ID: <1350509318.53.0.123166895316.issue16269@psf.upfronthosting.co.za>


New submission from William Edwards:

If you have 1024 file descriptors already open, the file descriptors created internally in multiprocessing.Queue will be beyond 1024 and the select() call buried deep in the Queue will throw an exception.

In fact, all uses of select() in the Python libs should be use poll() where available instead, obviously.

----------
components: IO
messages: 173208
nosy: William.Edwards
priority: normal
severity: normal
status: open
title: multiprocessing.Queue uses select()
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Oct 17 23:38:49 2012
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Wed, 17 Oct 2012 21:38:49 +0000
Subject: [New-bugs-announce] [issue16270] ftplib hangs when closing
	connection
Message-ID: <1350509929.7.0.680667591801.issue16270@psf.upfronthosting.co.za>


New submission from Ugra D?niel:

With version 3.3 (64 bit on Arch Linux) Python now hangs when closing FTP connection on some sites:

url = "ftp://ftp.fu-berlin.de/pub/misc/movies/database/ratings.list.gz"

with urllib.request.urlopen( url ):
	pass

----------
components: Library (Lib)
messages: 173209
nosy: daniel.ugra
priority: normal
severity: normal
status: open
title: ftplib hangs when closing connection
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Oct 18 01:43:06 2012
From: report at bugs.python.org (Christopher the Magnificent)
Date: Wed, 17 Oct 2012 23:43:06 +0000
Subject: [New-bugs-announce] [issue16271] weird dual behavior with changing
	__qualname__;
	different values observed through attribute and descriptor
Message-ID: <1350517386.42.0.0716657058677.issue16271@psf.upfronthosting.co.za>


New submission from Christopher the Magnificent:

The output below is NOT typed at the Python interactive interpeter.  The ">>> " shows what is being evaluated and the line below it shows what the result it.

The output gets generated here:  (lines 418-449 of the attached file)

    def name_globalize_class(name, second=None):
        def decorator(cls):
            
            def printval(source, value=None):
                print(">>> " + source)
                if value is not None:
                    print(repr(value))
            print("in decorator: new name is:", repr(name))
            print()
            printval("cls", cls)
            printval("cls.__name__", cls.__name__)
            printval("cls.__qualname__", cls.__qualname__)
            printval('type.__dict__["__qualname__"].__get__(cls)',
                     type.__dict__["__qualname__"].__get__(cls))
            print()
            
            cls.__name__ = name
            cls.__qualname__ = name
            
            stuff = ">>> cls.__name__ = {0}\n>>> cls.__qualname__ = {0}\n"
            print(stuff.format(repr(name)))
            
            printval("cls.__name__", cls.__name__)
            printval("cls.__qualname__", cls.__qualname__)
            printval('type.__dict__["__qualname__"].__get__(cls)',
                     type.__dict__["__qualname__"].__get__(cls))
            printval("cls", cls)
            print()
            globals()[name] = cls
            pdb.set_trace()
            return cls
        return decorator
    
HERE IS THE OUTPUT:

>>> cls
<class '__main__._maketokensnodes.<locals>._TokenClass'>
>>> cls.__name__
'_TokenClass'
>>> cls.__qualname__
'_maketokensnodes.<locals>._TokenClass'
>>> type.__dict__["__qualname__"].__get__(cls)
'_maketokensnodes.<locals>._TokenClass'

>>> cls.__name__ = 'KEYWORD'
>>> cls.__qualname__ = 'KEYWORD'

>>> cls.__name__
'KEYWORD'
>>> cls.__qualname__
'KEYWORD'
>>> type.__dict__["__qualname__"].__get__(cls)
'_maketokensnodes.<locals>._TokenClass'
>>> cls
<class '__main__._maketokensnodes.<locals>._TokenClass'>

END OF OUTPUT

Note how after assigning to cls.__qualname__ it looks like the class's dictionary object has been assigned into, masking the class's C-level type attribute-level ht_qualname!

My gut feeling is that this has to be some kind of a bug.  Let me know if it is.

----------
components: Interpreter Core
files: parser_BUGGY2.py
messages: 173217
nosy: christopherthemagnificent
priority: normal
severity: normal
status: open
title: weird dual behavior with changing __qualname__; different values observed through attribute and descriptor
versions: Python 3.3
Added file: http://bugs.python.org/file27604/parser_BUGGY2.py

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

From report at bugs.python.org  Thu Oct 18 02:27:43 2012
From: report at bugs.python.org (Chris Colbert)
Date: Thu, 18 Oct 2012 00:27:43 +0000
Subject: [New-bugs-announce] [issue16272] C-API documentation clarification
	for tp_dictoffset
Message-ID: <1350520063.61.0.687481658196.issue16272@psf.upfronthosting.co.za>


New submission from Chris Colbert:

The documentation of the tp_dictoffset is a bit unclear when describing the responsibilities of a base type with a nonzero tp_dictoffset.
http://docs.python.org/c-api/typeobj.html

I feel there should some statement to the effect of:

"""

If a type defines a nonzero tp_dictoffset, that type is responsible for defining a `__dict__` slot as part of the tp_getset structures. Failure to do so will result in the dict being inaccesible from Python via `obj.__dict__` from instances of the type or subtypes.

"""

The reasoning is twofold:

1) `PyType_Ready` does not add the default getset members like `type_new` does. This prevents the instances of the type itself from retrieving `obj.__dict__`

2) `type_new` will provide the default `subtype_dict` getset member for subclasses, but this calls `get_builtin_base_with_dict` which will resolve to the most base type which is not heap allocated; in this case, the C type. Since this type has no `__dict__` getset member, the lookup fails.


Adding a bit of verbage about this "gotcha" would likely save some headaches in the future.

----------
assignee: docs at python
components: Documentation
messages: 173222
nosy: Chris.Colbert, docs at python
priority: normal
severity: normal
status: open
title: C-API documentation clarification for tp_dictoffset
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/issue16272>
_______________________________________

From report at bugs.python.org  Thu Oct 18 04:08:42 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Oct 2012 02:08:42 +0000
Subject: [New-bugs-announce] [issue16273] f.tell() returning negative number
	on Windows build
Message-ID: <1350526122.97.0.103530434711.issue16273@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

On a fresh 64-bit install of Windows 2.7.3 running on Windows 7, f.tell() is producing unexpected (and unusable) results:

>>> f = open('sample.txt')
>>> f.read(3)
>>> f.read(3)
>>> f.tell()
-5L

----------
components: Interpreter Core
messages: 173226
nosy: rhettinger
priority: normal
severity: normal
status: open
title: f.tell() returning negative number on Windows build
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 18 10:06:51 2012
From: report at bugs.python.org (Trent Nelson)
Date: Thu, 18 Oct 2012 08:06:51 +0000
Subject: [New-bugs-announce] [issue16274] test_asyncore failing on Solaris
	10 2.7 (nitrogen/s10)
Message-ID: <1350547611.85.0.565736375067.issue16274@psf.upfronthosting.co.za>


New submission from Trent Nelson:

% ./python -m test.regrtest test_asyncore
test_asyncore
Exception in thread Thread-3:
Traceback (most recent call last):
  File "/home/cpython/hg/2.7/Lib/threading.py", line 552, in __bootstrap_inner
    self.run()
  File "/home/cpython/hg/2.7/Lib/threading.py", line 505, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/home/cpython/hg/2.7/Lib/test/test_asyncore.py", line 712, in <lambda>
    t = threading.Thread(target=lambda: asyncore.loop(timeout=0.1, count=500))
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 220, in loop
    poll_fun(timeout, map)
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 156, in poll
    read(obj)
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 87, in read
    obj.handle_error()
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 83, in read
    obj.handle_read_event()
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 443, in handle_read_event
    self.handle_accept()
  File "/home/cpython/hg/2.7/Lib/test/test_asyncore.py", line 487, in handle_accept
    sock, addr = self.accept()
TypeError: 'NoneType' object is not iterable

Exception in thread Thread-4:
Traceback (most recent call last):
  File "/home/cpython/hg/2.7/Lib/threading.py", line 552, in __bootstrap_inner
    self.run()
  File "/home/cpython/hg/2.7/Lib/threading.py", line 505, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/home/cpython/hg/2.7/Lib/test/test_asyncore.py", line 712, in <lambda>
    t = threading.Thread(target=lambda: asyncore.loop(timeout=0.1, count=500))
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 220, in loop
    poll_fun(timeout, map)
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 156, in poll
    read(obj)
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 87, in read
    obj.handle_error()
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 83, in read
    obj.handle_read_event()
  File "/home/cpython/hg/2.7/Lib/asyncore.py", line 443, in handle_read_event
    self.handle_accept()
  File "/home/cpython/hg/2.7/Lib/test/test_asyncore.py", line 487, in handle_accept
    sock, addr = self.accept()
TypeError: 'NoneType' object is not iterable

1 test OK.
[43391 refs]

Sample buildbot run that failed: http://buildbot.python.org/all/builders/SPARC64%20Solaris%2010%20%5BSB%5D%202.7/builds/69/steps/test/logs/stdio

Haven't investigated yet.

----------
assignee: trent
messages: 173237
nosy: jcea, trent
priority: normal
severity: normal
status: open
title: test_asyncore failing on Solaris 10 2.7 (nitrogen/s10)
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 18 11:24:49 2012
From: report at bugs.python.org (Trent Nelson)
Date: Thu, 18 Oct 2012 09:24:49 +0000
Subject: [New-bugs-announce] [issue16275] test_ctypes fails on Solaris 10
	SPARC 2.7 (nitrogen/s10)	(Sun C compiler)
Message-ID: <1350552289.03.0.785225307416.issue16275@psf.upfronthosting.co.za>


New submission from Trent Nelson:

This should be a fun one to track down.

Relevant buildbot run: http://buildbot.python.org/all/builders/SPARC64%20Solaris%2010%20%5BSB%5D%202.7/builds/69/steps/test/logs/stdio

When recompiled with gcc 4.6.3 (/opt/csw/bin/gcc), test_ctypes passes without issue (on 2.7 and 3.2).

Going to try a local build of libffi from git with Sun C and --with-system-ffi to see if that helps.

======================================================================
FAIL: test_struct_return_2H (ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py", line 172, in test_struct_return_2H
    self.assertEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: Tuples differ: (-65, -28679) != (198, 264)

First differing element 0:
-65
198

- (-65, -28679)
+ (198, 264)

======================================================================
FAIL: test_struct_return_8H (ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py", line 189, in test_struct_return_8H
    (9*2, 8*3, 7*4, 6*5, 5*6, 4*7, 3*8, 2*9))
AssertionError: Tuples differ: (8412232, 9364168, 1, -4223016... != (18, 24, 28, 30, 30, 28, 24, 1...

First differing element 0:
8412232
18

- (8412232, 9364168, 1, -4223016, -8, -32, -4222983, 5425288)
+ (18, 24, 28, 30, 30, 28, 24, 18)

======================================================================
FAIL: test_wchar_parm (ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py", line 28, in test_wchar_parm
    self.assertEqual(result, 139)
AssertionError: 138 != 139

======================================================================
FAIL: test_struct_return_2H (ctypes.test.test_as_parameter.AsParamWrapperTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py", line 172, in test_struct_return_2H
    self.assertEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: Tuples differ: (-65, -28679) != (198, 264)

First differing element 0:
-65
198

- (-65, -28679)
+ (198, 264)

======================================================================
FAIL: test_struct_return_8H (ctypes.test.test_as_parameter.AsParamWrapperTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py", line 189, in test_struct_return_8H
    (9*2, 8*3, 7*4, 6*5, 5*6, 4*7, 3*8, 2*9))
AssertionError: Tuples differ: (8431512, 9370440, 1, -4223016... != (18, 24, 28, 30, 30, 28, 24, 1...

First differing element 0:
8431512
18

- (8431512, 9370440, 1, -4223016, -8, -32, -4222983, 5425848)
+ (18, 24, 28, 30, 30, 28, 24, 18)

======================================================================
FAIL: test_wchar_parm (ctypes.test.test_as_parameter.AsParamWrapperTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py", line 28, in test_wchar_parm
    self.assertEqual(result, 139)
AssertionError: 138 != 139

======================================================================
FAIL: test_struct_return_2H (ctypes.test.test_as_parameter.BasicWrapTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py", line 172, in test_struct_return_2H
    self.assertEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: Tuples differ: (-65, -28679) != (198, 264)

First differing element 0:
-65
198

- (-65, -28679)
+ (198, 264)

======================================================================
FAIL: test_struct_return_8H (ctypes.test.test_as_parameter.BasicWrapTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py", line 189, in test_struct_return_8H
    (9*2, 8*3, 7*4, 6*5, 5*6, 4*7, 3*8, 2*9))
AssertionError: Tuples differ: (5707864, 9374608, 1, -4223016... != (18, 24, 28, 30, 30, 28, 24, 1...

First differing element 0:
5707864
18

- (5707864, 9374608, 1, -4223016, -8, -32, -4222983, -25924296)
+ (18, 24, 28, 30, 30, 28, 24, 18)

======================================================================
FAIL: test_wchar_parm (ctypes.test.test_as_parameter.BasicWrapTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_as_parameter.py", line 28, in test_wchar_parm
    self.assertEqual(result, 139)
AssertionError: 138 != 139

======================================================================
FAIL: test_ints (ctypes.test.test_bitfields.C_Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_bitfields.py", line 40, in test_ints
    self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), name)))
AssertionError: Tuples differ: ('A', 1, -1) != ('A', 1, 0)

First differing element 2:
-1
0

- ('A', 1, -1)
?          ^^

+ ('A', 1, 0)
?          ^


======================================================================
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_bitfields.py", line 47, in test_shorts
    self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), name)))
AssertionError: Tuples differ: ('M', 1, -1) != ('M', 1, 0)

First differing element 2:
-1
0

- ('M', 1, -1)
?          ^^

+ ('M', 1, 0)
?          ^


======================================================================
FAIL: test_byte (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 36, in test_byte
    self.check_type(c_byte, 42)
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 22, in check_type
    self.assertEqual(self.got_args, (arg,))
AssertionError: Tuples differ: (0,) != (42,)

First differing element 0:
0
42

- (0,)
+ (42,)

======================================================================
FAIL: test_char (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 91, in test_char
    self.check_type(c_char, "x")
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 22, in check_type
    self.assertEqual(self.got_args, (arg,))
AssertionError: Tuples differ: ('\x00',) != ('x',)

First differing element 0:

x

- ('\x00',)
?   - --

+ ('x',)

======================================================================
FAIL: test_double (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 83, in test_double
    self.check_type(c_double, 3.14)
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 30, in check_type
    self.assertEqual(self.got_args, (-3, arg))
AssertionError: Tuples differ: (0, 3.14) != (-3, 3.14)

First differing element 0:
0
-3

- (0, 3.14)
?  ^

+ (-3, 3.14)
?  ^^


======================================================================
FAIL: test_int (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 50, in test_int
    self.check_type(c_int, 42)
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 30, in check_type
    self.assertEqual(self.got_args, (-3, arg))
AssertionError: Tuples differ: (0, 42) != (-3, 42)

First differing element 0:
0
-3

- (0, 42)
?  ^

+ (-3, 42)
?  ^^


======================================================================
FAIL: test_long (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 57, in test_long
    self.check_type(c_long, 42)
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 30, in check_type
    self.assertEqual(self.got_args, (-3, arg))
AssertionError: Tuples differ: (0, 42) != (-3, 42)

First differing element 0:
0
-3

- (0, 42)
?  ^

+ (-3, 42)
?  ^^


======================================================================
FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 87, in test_longdouble
    self.check_type(c_longdouble, 3.14)
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 30, in check_type
    self.assertEqual(self.got_args, (-3, arg))
AssertionError: Tuples differ: (0, 3.14) != (-3, 3.14)

First differing element 0:
0
-3

- (0, 3.14)
?  ^

+ (-3, 3.14)
?  ^^


======================================================================
FAIL: test_longlong (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 65, in test_longlong
    self.check_type(c_longlong, 5948291757245277467)
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 30, in check_type
    self.assertEqual(self.got_args, (-3, arg))
AssertionError: Tuples differ: (0, 5948291757245277467L) != (-3, 5948291757245277467L)

First differing element 0:
0
-3

- (0, 5948291757245277467L)
?  ^

+ (-3, 5948291757245277467L)
?  ^^


======================================================================
FAIL: test_pyobject (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 107, in test_pyobject
    self.check_type(py_object, o)
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 30, in check_type
    self.assertEqual(self.got_args, (-3, arg))
AssertionError: Tuples differ: (0, ()) != (-3, ())

First differing element 0:
0
-3

- (0, ())
?  ^

+ (-3, ())
?  ^^


======================================================================
FAIL: test_short (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 43, in test_short
    self.check_type(c_short, 42)
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 22, in check_type
    self.assertEqual(self.got_args, (arg,))
AssertionError: Tuples differ: (0,) != (42,)

First differing element 0:
0
42

- (0,)
+ (42,)

======================================================================
FAIL: test_ubyte (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 40, in test_ubyte
    self.check_type(c_ubyte, 42)
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 22, in check_type
    self.assertEqual(self.got_args, (arg,))
AssertionError: Tuples differ: (0,) != (42,)

First differing element 0:
0
42

- (0,)
+ (42,)

======================================================================
FAIL: test_uint (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 54, in test_uint
    self.check_type(c_uint, 42)
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 30, in check_type
    self.assertEqual(self.got_args, (-3, arg))
AssertionError: Tuples differ: (0, 42L) != (-3, 42)

First differing element 0:
0
-3

- (0, 42L)
?  ^    -

+ (-3, 42)
?  ^^


======================================================================
FAIL: test_ulong (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 61, in test_ulong
    self.check_type(c_ulong, 42)
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 30, in check_type
    self.assertEqual(self.got_args, (-3, arg))
AssertionError: Tuples differ: (0, 42L) != (-3, 42)

First differing element 0:
0
-3

- (0, 42L)
?  ^    -

+ (-3, 42)
?  ^^


======================================================================
FAIL: test_ulonglong (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 72, in test_ulonglong
    self.check_type(c_ulonglong, 10955412242170339782)
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 30, in check_type
    self.assertEqual(self.got_args, (-3, arg))
AssertionError: Tuples differ: (0, 10955412242170339782L) != (-3, 10955412242170339782L)

First differing element 0:
0
-3

- (0, 10955412242170339782L)
?  ^

+ (-3, 10955412242170339782L)
?  ^^


======================================================================
FAIL: test_ushort (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 47, in test_ushort
    self.check_type(c_ushort, 42)
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_callbacks.py", line 22, in check_type
    self.assertEqual(self.got_args, (arg,))
AssertionError: Tuples differ: (0,) != (42,)

First differing element 0:
0
42

- (0,)
+ (42,)

======================================================================
FAIL: test_byte (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_cfuncs.py", line 20, in test_byte
    self.assertEqual(self._dll.tf_b(-126), -42)
AssertionError: 0 != -42

======================================================================
FAIL: test_byte_plus (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_cfuncs.py", line 26, in test_byte_plus
    self.assertEqual(self._dll.tf_bb(0, -126), -42)
AssertionError: 0 != -42

======================================================================
FAIL: test_longdouble (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_cfuncs.py", line 164, in test_longdouble
    self.assertEqual(self._dll.tf_D(42.), 14.)
AssertionError: nan != 14.0

======================================================================
FAIL: test_longdouble_plus (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_cfuncs.py", line 170, in test_longdouble_plus
    self.assertEqual(self._dll.tf_bD(0, 42.), 14.)
AssertionError: nan != 14.0

======================================================================
FAIL: test_short (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_cfuncs.py", line 44, in test_short
    self.assertEqual(self._dll.tf_h(-32766), -10922)
AssertionError: 0 != -10922

======================================================================
FAIL: test_short_plus (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_cfuncs.py", line 50, in test_short_plus
    self.assertEqual(self._dll.tf_bh(0, -32766), -10922)
AssertionError: 0 != -10922

======================================================================
FAIL: test_ubyte (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_cfuncs.py", line 32, in test_ubyte
    self.assertEqual(self._dll.tf_B(255), 85)
AssertionError: 0 != 85

======================================================================
FAIL: test_ubyte_plus (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_cfuncs.py", line 38, in test_ubyte_plus
    self.assertEqual(self._dll.tf_bB(0, 255), 85)
AssertionError: 0 != 85

======================================================================
FAIL: test_ushort (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_cfuncs.py", line 56, in test_ushort
    self.assertEqual(self._dll.tf_H(65535), 21845)
AssertionError: 0 != 21845

======================================================================
FAIL: test_ushort_plus (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_cfuncs.py", line 62, in test_ushort_plus
    self.assertEqual(self._dll.tf_bH(0, 65535), 21845)
AssertionError: 0 != 21845

======================================================================
FAIL: test_dllfunctions (ctypes.test.test_funcptr.CFuncPtrTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_funcptr.py", line 100, in test_dllfunctions
    self.assertEqual(strchr("abcdefghi", "b"), "bcdefghi")
AssertionError: '' != 'bcdefghi'

======================================================================
FAIL: test_doubleresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_functions.py", line 139, in test_doubleresult
    self.assertEqual(result, 21)
AssertionError: 18.0 != 21

======================================================================
FAIL: test_floatresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_functions.py", line 127, in test_floatresult
    self.assertEqual(result, 21)
AssertionError: 18.0 != 21

======================================================================
FAIL: test_intresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_functions.py", line 101, in test_intresult
    self.assertEqual(result, 21)
AssertionError: 18 != 21

======================================================================
FAIL: test_longdoubleresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_functions.py", line 151, in test_longdoubleresult
    self.assertEqual(result, 21)
AssertionError: nan != 21

======================================================================
FAIL: test_longlongresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_functions.py", line 167, in test_longlongresult
    self.assertEqual(result, 21)
AssertionError: 18L != 21

======================================================================
FAIL: test_struct_return_2H (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_functions.py", line 349, in test_struct_return_2H
    self.assertEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: Tuples differ: (-65, -28679) != (198, 264)

First differing element 0:
-65
198

- (-65, -28679)
+ (198, 264)

======================================================================
FAIL: test_struct_return_8H (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_functions.py", line 377, in test_struct_return_8H
    (9*2, 8*3, 7*4, 6*5, 5*6, 4*7, 3*8, 2*9))
AssertionError: Tuples differ: (5707864, 9758944, 1, -4223016... != (18, 24, 28, 30, 30, 28, 24, 1...

First differing element 0:
5707864
18

- (5707864, 9758944, 1, -4223016, -8, -32, -4222983, -25924296)
+ (18, 24, 28, 30, 30, 28, 24, 18)

======================================================================
FAIL: test_wchar_parm (ctypes.test.test_functions.FunctionTestCatest test_ctypes failed -- multiple errors occurred
se)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_functions.py", line 74, in test_wchar_parm
    self.assertEqual(result, 139)
AssertionError: 138 != 139

======================================================================
FAIL: test_with_prototype (ctypes.test.test_returnfuncptrs.ReturnFuncPtrTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_returnfuncptrs.py", line 15, in test_with_prototype
    self.assertEqual(strchr("abcdef", "b"), "bcdef")
AssertionError: '' != 'bcdef'

======================================================================
FAIL: test_without_prototype (ctypes.test.test_returnfuncptrs.ReturnFuncPtrTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_returnfuncptrs.py", line 29, in test_without_prototype
    self.assertTrue(strchr("abcdef", "b"), "bcdef")
AssertionError: bcdef

======================================================================
FAIL: test_functions (ctypes.test.test_stringptr.StringPtrTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/2.7.snakebite-solaris10-u10ga2-sparc64-1/build/Lib/ctypes/test/test_stringptr.py", line 51, in test_functions
    self.assertEqual(strchr("abcdef", "c"), "cdef")
AssertionError: '' != 'cdef'

----------------------------------------------------------------------
Ran 340 tests in 2.623s

FAILED (failures=47, skipped=2)

----------
assignee: trent
messages: 173245
nosy: amaury.forgeotdarc, belopolsky, jcea, meador.inge, trent
priority: normal
severity: normal
status: open
title: test_ctypes fails on Solaris 10 SPARC 2.7 (nitrogen/s10) (Sun C compiler)
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 18 11:33:33 2012
From: report at bugs.python.org (Antoine Dechaume)
Date: Thu, 18 Oct 2012 09:33:33 +0000
Subject: [New-bugs-announce] [issue16276] OrderedDict constructor do not
	keep items order
Message-ID: <1350552813.45.0.500801824963.issue16276@psf.upfronthosting.co.za>


New submission from Antoine Dechaume:

Example:

from collections import OrderedDict
print OrderedDict(a=0,b=1,c=2)

I get
OrderedDict([('a', 0), ('c', 2), ('b', 1)])

I expected
OrderedDict([('a', 0), ('b', 1), ('c', 2)])

----------
components: Library (Lib)
messages: 173247
nosy: ADechaume
priority: normal
severity: normal
status: open
title: OrderedDict constructor do not keep items order
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 18 13:59:50 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 18 Oct 2012 11:59:50 +0000
Subject: [New-bugs-announce] [issue16277] Objects/longobject.c not compiled
	without long long
Message-ID: <1350561590.48.0.466518610474.issue16277@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Preprocessor directives emit error in PyLong_FromVoidPtr:

PyLong_FromVoidPtr: sizeof(void*) > sizeof(long), but no long long

if HAVE_LONG_LONG not defined.

Here is a patch which adds missing branch (lost somewhere in 2->3 translation).  Also removed non-needed optimization which can cause undefined behavior (C Standard not guarantee (long long)NULL == 0).

----------
components: Interpreter Core
files: long_fromvoidptr.patch
keywords: patch
messages: 173257
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Objects/longobject.c not compiled without long long
type: compile error
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27610/long_fromvoidptr.patch

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

From report at bugs.python.org  Thu Oct 18 19:36:16 2012
From: report at bugs.python.org (David Benjamin)
Date: Thu, 18 Oct 2012 17:36:16 +0000
Subject: [New-bugs-announce] [issue16278] os.rename documentation slightly
	inaccurate
Message-ID: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>


New submission from David Benjamin:

This is somewhat of a nitpick. os.rename's documentation says "If dst is a directory, OSError will be raised". On Unix, this isn't completely true. If the source is a directory and the destination is an empty directory, it'll overwrite the former with the latter. (Actually if the source is a directory the inverse is true; if dst is a file, OSError will be raised.)

In [1]: import os

In [2]: os.mkdir("aaa")

In [3]: open("aaa/blah", "w").close()

In [4]: os.mkdir("bbb")

In [5]: os.rename("aaa", "bbb")

In [6]: os.listdir("bbb")
Out[6]: ['blah']

----------
assignee: docs at python
components: Documentation
messages: 173285
nosy: David.Benjamin, docs at python
priority: normal
severity: normal
status: open
title: os.rename documentation slightly inaccurate
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Oct 18 21:59:43 2012
From: report at bugs.python.org (Julian Berman)
Date: Thu, 18 Oct 2012 19:59:43 +0000
Subject: [New-bugs-announce] [issue16279] namedtuple should compare equality
	with field names	taken into account
Message-ID: <1350590383.92.0.380750579544.issue16279@psf.upfronthosting.co.za>


New submission from Julian Berman:

I find the following to be unintuitive:

Python 3.3.0rc1 (default, Sep  6 2012, 16:02:32) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import namedtuple
>>> F = namedtuple("F", "x")
>>> G = namedtuple("G", "y")
>>> F(12) == G(12)
True

I'm OK with not taking the class name into account, that sounds reasonable, but I think field names should make those unequal.

----------
components: Library (Lib)
messages: 173292
nosy: Julian, rhettinger
priority: normal
severity: normal
status: open
title: namedtuple should compare equality with field names taken into account
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Oct 18 22:36:45 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 18 Oct 2012 20:36:45 +0000
Subject: [New-bugs-announce] [issue16280] Inconsistency with
	PyLong_FromVoidPtr() and	PyLong_AsVoidPtr()
Message-ID: <1350592605.75.0.903576562046.issue16280@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

This issue is taken out of the discussion of issue16277.

PyLong_FromVoidPtr() has special case which maps null pointer to zero integer.

On platforms where (uintptr_t)(void *)0 is 0, this code has no effect and is redundant.  But on hypothetic platforms where (uintptr_t)(void *)0 is not 0, PyLong_FromVoidPtr() maps NULL to 0 and then PyLong_AsVoidPtr() maps 0 to non-NULL. Also PyLong_FromVoidPtr() is multivalued, it maps to 0 NULL and may be some other pointer.

PyLong_FromVoidPtr() in 2.7 has special case only on platform where sizeof(void*) >?sizeof(long). It commented as "optimize null pointers". In 3.x branch such optimization non needed because PyLong_FromUnsignedLongLong() already has special case for short integers.

The solution of this issue is getting rid of a special case, or adding a special case in PyLong_FromVoidPtr(). It is desirable to make it avoiding multivaluedity.

----------
components: Interpreter Core
messages: 173295
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Inconsistency with PyLong_FromVoidPtr() and PyLong_AsVoidPtr()
type: resource usage
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Oct 19 02:51:23 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Oct 2012 00:51:23 +0000
Subject: [New-bugs-announce] [issue16281] TODO in tailmatch(): it does not
	support backward in all	cases
Message-ID: <1350607883.61.0.918476063498.issue16281@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Oh oh, it looks like the implementation of tailmatch() was not finished:

        /* If both are of the same kind, memcmp is sufficient */
        if (kind_self == kind_sub) {
            return ...;
        }
        /* otherwise we have to compare each character by first accesing it */
        else {
            /* We do not need to compare 0 and len(substring)-1 because
               the if statement above ensured already that they are equal
               when we end up here. */
            /* TODO: honor direction and do a forward or backwards search */
            for (i = 1; i < end_sub; ++i) {
                if (PyUnicode_READ(kind_self, data_self, offset + i) !=
                    PyUnicode_READ(kind_sub, data_sub, i))
                    return 0;
            }
            return 1;
        }

----------
messages: 173301
nosy: haypo, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: TODO in tailmatch(): it does not support backward in all cases
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Oct 19 10:11:13 2012
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 19 Oct 2012 08:11:13 +0000
Subject: [New-bugs-announce] [issue16282] The Python Tutorial the previous
	link needs updating
Message-ID: <1350634273.76.0.49473405577.issue16282@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

http://docs.python.org/tutorial/ the previous link goes to http://docs.python.org/whatsnew/2.0.html.  Can we have this updated please?

----------
assignee: docs at python
components: Documentation
messages: 173311
nosy: BreamoreBoy, docs at python
priority: normal
severity: normal
status: open
title: The Python Tutorial the previous link needs updating
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct 19 10:52:58 2012
From: report at bugs.python.org (Marcus von Appen)
Date: Fri, 19 Oct 2012 08:52:58 +0000
Subject: [New-bugs-announce] [issue16283] ctypes.util.find_library does not
	find all DLLs anymore
Message-ID: <1350636778.52.0.107234052838.issue16283@psf.upfronthosting.co.za>


New submission from Marcus von Appen:

ctypes.util.find_library does not seem to be able to find certain libraries in Python3.3 on Win32 platforms anymore, if the library suffix is omitted. For some reason, os.path.isfile() in ctypes.util.find_library returns False in those cases.

Please try out the attached test script. This produces the following output on a Windows 7 x64 system for me (given that a OpenAL32.dll is installed):


C:\>c:\Python27-x64\python.exe ct_test.py

Python build: 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)]
Path 'C:\Windows\system32' exists in $PATH: True
File 'C:\Windows\system32\OpenAL32.dll' exists: True
ctypes says for 'OpenAL32.dll': C:\Windows\system32\OpenAL32.dll
ctypes says for 'OpenAL32': C:\Windows\system32\OpenAL32.dll


C:\>c:\Python31-x64\python.exe ct_test.py

Python build: 3.1.4 (default, Jun 12 2011, 14:16:16) [MSC v.1500 64 bit (AMD64)]
Path 'C:\Windows\system32' exists in $PATH: True
File 'C:\Windows\system32\OpenAL32.dll' exists: True
ctypes says for 'OpenAL32.dll': C:\Windows\system32\OpenAL32.dll
ctypes says for 'OpenAL32': C:\Windows\system32\OpenAL32.dll

C:\>c:\Python32-x64\python.exe ct_test.py

Python build: 3.2.3 (default, Apr 11 2012, 07:12:16) [MSC v.1500 64 bit (AMD64)]
Path 'C:\Windows\system32' exists in $PATH: True
File 'C:\Windows\system32\OpenAL32.dll' exists: True
ctypes says for 'OpenAL32.dll': C:\Windows\system32\OpenAL32.dll
ctypes says for 'OpenAL32': C:\Windows\system32\OpenAL32.dll

C:\>c:\Python33-x64\python.exe ct_test.py

Python build: 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)]
Path 'C:\Windows\system32' exists in $PATH: True
File 'C:\Windows\system32\OpenAL32.dll' exists: True
ctypes says for 'OpenAL32.dll': C:\Windows\system32\OpenAL32.dll
ctypes says for 'OpenAL32': None

----------
components: ctypes
files: ct_test.py
messages: 173315
nosy: marcusva
priority: normal
severity: normal
status: open
title: ctypes.util.find_library does not find all DLLs anymore
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file27618/ct_test.py

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

From report at bugs.python.org  Fri Oct 19 12:15:26 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 19 Oct 2012 10:15:26 +0000
Subject: [New-bugs-announce] [issue16284] concurrent.futures
	ThreadPoolExecutor keeps unnecessary	references to worker functions.
Message-ID: <1350641726.57.0.22505418852.issue16284@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

The ThreadPoolExecutor unnecessarily keeps references to _WorkItem objects.  With the attached patch (which lacks a test), all tests still pass, and the references are removed as soon as they're no longer needed.

----------
files: kill_reference.diff
keywords: patch
messages: 173318
nosy: bquinlan, mark.dickinson
priority: normal
severity: normal
status: open
title: concurrent.futures ThreadPoolExecutor keeps unnecessary references to worker functions.
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27619/kill_reference.diff

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

From report at bugs.python.org  Fri Oct 19 12:56:08 2012
From: report at bugs.python.org (Matteo Parrucci)
Date: Fri, 19 Oct 2012 10:56:08 +0000
Subject: [New-bugs-announce] [issue16285] Erroneously encoding tilde to %7e
	in quote
Message-ID: <1350644168.93.0.364254038155.issue16285@psf.upfronthosting.co.za>


New submission from Matteo Parrucci:

RFC 3986 (http://www.ietf.org/rfc/rfc3986.txt) says:

For consistency, percent-encoded octets in the ranges of ALPHA
(%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E),
underscore (%5F), or tilde (%7E) should not be created by URI
producers and, when found in a URI, should be decoded to their
corresponding unreserved characters by URI normalizers.

>From python documentation talking about urllib.quote()

Example: quote('/~connolly/') yields '/%7econnolly/'.

I think ~ should be added to the safe characters of quote function

----------
messages: 173319
nosy: Matteo.Parrucci
priority: normal
severity: normal
status: open
title: Erroneously encoding tilde to %7e in quote

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

From report at bugs.python.org  Fri Oct 19 14:36:06 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Oct 2012 12:36:06 +0000
Subject: [New-bugs-announce] [issue16286] Optimize a==b and a!=b for bytes
	and str
Message-ID: <1350650166.87.0.27478619259.issue16286@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch optimize a==b and a!=b operators for bytes and str types of Python 3.4. For str, memcmp() is now always used, instead of a loop using PyUnicode_READ() (which is slow) for kind different than 1. For bytes, compare the first but also the last byte before calling memcmp(), instead of just comparing the first byte. Similar optimization was implemented in Py_UNICODE_MATCH():

changeset:   38242:0de9a789de39
branch:      legacy-trunk
user:        Fredrik Lundh <fredrik at pythonware.com>
date:        Tue May 23 10:10:57 2006 +0000
files:       Include/unicodeobject.h
description:
needforspeed: check first *and* last character before doing a full memcmp

Initially I only wrote the patch to check the hash values before comparing content of the strings.

--

I done some statistics tests. For a fresh Python interpreter, the hash values are only known in 7% cases (but when hashes are compared, they are quite always different, so the optimization is useful). When running "./python -m test test_os", hashes are known and different in 41.4%. After running 70 tests, hashes are known and different in 80%.

----------
files: compare_hash.patch
keywords: patch
messages: 173332
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Optimize a==b and a!=b for bytes and str
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file27623/compare_hash.patch

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

From report at bugs.python.org  Fri Oct 19 15:16:39 2012
From: report at bugs.python.org (Trent Nelson)
Date: Fri, 19 Oct 2012 13:16:39 +0000
Subject: [New-bugs-announce] [issue16287] Sporadic test_utime() failures on
	Solaris
Message-ID: <1350652599.36.0.707342371082.issue16287@psf.upfronthosting.co.za>


New submission from Trent Nelson:

This was initially observed in #15745, however, there's a separate problem here.  The current test_utime() on Solaris sporadically (usually) fails along the following lines:

>     self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime"))
>     AssertionError: 1347752941.275297 != 1347752941.275296

> That is, test_utime() always results in a st1.st_mtime that is
> "off-by-1" from st0.st_mtime.  The precision is well within the
> nanasecond resolution offered by utimensat, so it doesn't appear to be
> the same issue experienced by other platforms.

Run that test in a loop though, and it sometimes passes.  So, there's an underlying bug, somewhere.

----------
messages: 173339
nosy: trent
priority: normal
severity: normal
status: open
title: Sporadic test_utime() failures on Solaris

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

From report at bugs.python.org  Fri Oct 19 20:34:49 2012
From: report at bugs.python.org (Robert Collins)
Date: Fri, 19 Oct 2012 18:34:49 +0000
Subject: [New-bugs-announce] [issue16288] TextTestResult uses
	TestCase.__str__() which isn't	customisable (vs id() or
	shortDescription())
Message-ID: <1350671689.29.0.0409273215418.issue16288@psf.upfronthosting.co.za>


New submission from Robert Collins:

TextTestRunner calls str(TestCase) directly, which makes it hard for testscenarios to rename the test cases as it parameterises them (because __str__ is a descriptor). While testscenarios could use a decorator instead, thats undesirable as the test case object would still need to be customised so that calls to self.id() and self.shortDescription() inside it still return consistent information.

So the relevant code is this:
 def getDescription(self, test):
41 if self.descriptions:
42 return test.shortDescription() or str(test)
43 else:
44 return str(test)

What I'd like is to have this be something like:
41 if self.descriptions:
42     return test.shortDescription() or test.id()
43 else:
44     return test.id()

Which would let testscenarios adjust both shortDescriptions and id, and Just Work.

----------
messages: 173352
nosy: michael.foord, rbcollins
priority: normal
severity: normal
status: open
title: TextTestResult uses TestCase.__str__() which isn't customisable (vs id() or shortDescription())
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/issue16288>
_______________________________________

From report at bugs.python.org  Sat Oct 20 09:12:20 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 20 Oct 2012 07:12:20 +0000
Subject: [New-bugs-announce] [issue16289] Update devguide for 3.4
Message-ID: <1350717140.43.0.154723711234.issue16289@psf.upfronthosting.co.za>


New submission from Ned Deily:

The Developer's Guide needs to be updated to reflect the release of 3.3.  Primarily, this involves adding the 3.3 branch and updating the sequence of branch names and other release number references.  The attached patch does so.  It's pretty much a straightforward substitution except for noting that the 3.2 branch remains open for bug fixes until its upcoming final maintenance release when it will move to security mode (the devguide should be updated again at that point).

----------
assignee: ned.deily
components: Devguide
files: update_devguide_for_34.patch
keywords: patch
messages: 173372
nosy: benjamin.peterson, ezio.melotti, georg.brandl, larry, ned.deily
priority: normal
severity: normal
stage: patch review
status: open
title: Update devguide for 3.4
Added file: http://bugs.python.org/file27629/update_devguide_for_34.patch

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

From report at bugs.python.org  Sat Oct 20 11:39:39 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Oct 2012 09:39:39 +0000
Subject: [New-bugs-announce] [issue16290] PyComplex_AsCComplex should allow
	__complex__ to return	float.
Message-ID: <1350725979.91.0.694424373202.issue16290@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

See thread starting at http://mail.python.org/pipermail/python-dev/2012-October/122241.html

The cmath module functions don't accept custom types that define __complex__, but whose __complex__ method returns a float rather than a complex number:

Python 3.4.0a0 (default:53a7c2226a2b+, Oct 19 2012, 12:16:36) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
...     def __complex__(self): return 42.0
... 
>>> import cmath
>>> cmath.sqrt(A())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __complex__ should return a complex object

In contrast, the complex constructor is happy to accept such objects.

The root cause is that PyArg_ParseTuple's 'D' format calls PyComplex_AsCComplex (in Objects/complexobject.c), which refuses to accept a __complex__ result of type float.

----------
assignee: mark.dickinson
components: Interpreter Core
messages: 173379
nosy: mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: PyComplex_AsCComplex should allow __complex__ to return float.
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct 21 00:09:37 2012
From: report at bugs.python.org (Ray Donnelly)
Date: Sat, 20 Oct 2012 22:09:37 +0000
Subject: [New-bugs-announce] [issue16291] Fix some general cross compile
	issues and some darwin	specific ones. Tested with build=linux,
	host=darwin
Message-ID: <1350770977.75.0.64501763721.issue16291@psf.upfronthosting.co.za>


New submission from Ray Donnelly:

I've fixed up the very few missing configure bits and one issue with PYTHON_FOR_BUILD using srcdir instead of builddir. I also rolled in a simple warning fix that I ran into (the #ifdef HAVE_CHROOT added to posixmodule.c)

configured with:
$srcdir/configure --prefix=$PWD/install/darwin-x86_64/python-3.4.x --build=x86_64-linux-gnu --host=x86_64-apple-darwin11

using these compilers:
http://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Linux-120724.tar.xz

and MacOSX10.7.sdk,

I can successfully build Python for Mac OS X on Linux.

----------
components: Cross-Build
files: 0010-DARWIN-CROSS.patch
keywords: patch
messages: 173420
nosy: Ray.Donnelly, doko
priority: normal
severity: normal
status: open
title: Fix some general cross compile issues and some darwin specific ones. Tested with build=linux, host=darwin
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27641/0010-DARWIN-CROSS.patch

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

From report at bugs.python.org  Sun Oct 21 01:05:08 2012
From: report at bugs.python.org (Ray Donnelly)
Date: Sat, 20 Oct 2012 23:05:08 +0000
Subject: [New-bugs-announce] [issue16292] Cross compilation fixes (general)
Message-ID: <1350774308.18.0.656262327513.issue16292@psf.upfronthosting.co.za>


New submission from Ray Donnelly:

This patch fixes 2 cross compilation bugs and improves a comment.

----------
components: Cross-Build
files: 0005-cross-fixes.patch
keywords: patch
messages: 173423
nosy: Ray.Donnelly, doko
priority: normal
severity: normal
status: open
title: Cross compilation fixes (general)
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file27643/0005-cross-fixes.patch

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

From report at bugs.python.org  Sun Oct 21 03:25:37 2012
From: report at bugs.python.org (Julian Berman)
Date: Sun, 21 Oct 2012 01:25:37 +0000
Subject: [New-bugs-announce] [issue16293] curses.ungetch raises
	OverflowError when given -1
Message-ID: <1350782737.16.0.822622780307.issue16293@psf.upfronthosting.co.za>


New submission from Julian Berman:

The following code now raises an OverflowError on 3.3:

import curses

def test_screen(screen):
    screen.nodelay(True)
    key = screen.getch()
    screen.nodelay(False)
    curses.ungetch(key)

curses.wrapper(test_screen)

or equivalently just

def test_screen(screen):
    curses.ungetch(-1)

----------
components: Library (Lib)
messages: 173425
nosy: Julian, haypo
priority: normal
severity: normal
status: open
title: curses.ungetch raises OverflowError when given -1
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Oct 21 14:13:01 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Sun, 21 Oct 2012 12:13:01 +0000
Subject: [New-bugs-announce] [issue16294] 8 space indent in tutorial
Message-ID: <1350821581.15.0.866474949137.issue16294@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

http://docs.python.org/py3k/tutorial/stdlib2.html#weak-references

In the code example, the two class funtions' bodies have indents of 8 spaces. All other indents in the docs are 4 spaces. I suggest here we use 4 spaces also.

----------
assignee: docs at python
components: Documentation
messages: 173443
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: 8 space indent in tutorial
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Oct 21 19:21:22 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 21 Oct 2012 17:21:22 +0000
Subject: [New-bugs-announce] [issue16295] With VS2010 the select extension
	links against wsock32	instead of ws2_32
Message-ID: <1350840082.43.0.801367725826.issue16295@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

Using VS2010 _socket links against ws2_32.lib but select links against wsock32.lib.

Using VS2008 both extensions link against ws2_32.lib.  It appears that the conversion to VS2010 caused the regression.

(Compare #10295 and #11750.)

----------
messages: 173463
nosy: kristjan.jonsson, sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: With VS2010 the select extension links against wsock32 instead of ws2_32
type: resource usage
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Oct 21 19:56:15 2012
From: report at bugs.python.org (Silverback Networks)
Date: Sun, 21 Oct 2012 17:56:15 +0000
Subject: [New-bugs-announce] [issue16296] Patch to fix building on Win32/64
	under VS 2010
Message-ID: <1350842175.59.0.919553926658.issue16296@psf.upfronthosting.co.za>


New submission from Silverback Networks:

Once I got my broken environment fixed, this was the only thing that didn't work. The bug is that VS 2010 no longer creates a manifest by default, despite the documentation, and there are confirmation posts around the internet. /Manifest has to be forced starting with VS 2010. Here is a patch to fix that:


--- Lib/distutils/msvc9compiler.py    2011-08-14 11:17:42.000000000 -0700
+++ Lib/distutils/msvc9compiler.py    2012-10-21 10:38:42.257682200 -0700
@@ -411,10 +411,16 @@
                                           '/Z7', '/D_DEBUG']

         self.ldflags_shared = ['/DLL', '/nologo', '/INCREMENTAL:NO']
+        if self.__version >= 10:
+            self.ldflags_shared = ['/DLL', '/nologo', '/INCREMENTAL:NO', '/Manifest']
         if self.__version >= 7:
             self.ldflags_shared_debug = [
                 '/DLL', '/nologo', '/INCREMENTAL:no', '/DEBUG', '/pdb:None'
                 ]
+            if self.__version >= 10:
+                self.ldflags_shared = [
+                '/DLL', '/nologo', '/INCREMENTAL:NO', '/DEBUG', '/pdb:None', '/Manifest'
+                ]
         self.ldflags_static = [ '/nologo']

         self.initialized = True

----------
components: Build
messages: 173464
nosy: silverbacknet
priority: normal
severity: normal
status: open
title: Patch to fix building on Win32/64 under VS 2010
type: compile error
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Oct 22 10:27:29 2012
From: report at bugs.python.org (tb)
Date: Mon, 22 Oct 2012 08:27:29 +0000
Subject: [New-bugs-announce] [issue16297] csv.DictReader
Message-ID: <1350894449.05.0.527683107859.issue16297@psf.upfronthosting.co.za>


New submission from tb:

The csv.DictReader contains a setter method for the fieldnames (@fieldnames.setter). However, the __init__ method does not make use of the setter method as it sets _fieldnames directly. To allow users correct/functional overriding of the fieldnames.setter method I would propose changing the line 

self._fieldnames = fieldnames 

to

self.fieldnames = fieldnames

----------
components: Library (Lib)
messages: 173500
nosy: tb
priority: normal
severity: normal
status: open
title: csv.DictReader
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Oct 22 13:32:32 2012
From: report at bugs.python.org (Eran Rundstein)
Date: Mon, 22 Oct 2012 11:32:32 +0000
Subject: [New-bugs-announce] [issue16298] httplib.HTTPResponse.read could
	potentially leave the	socket opened forever
Message-ID: <1350905552.38.0.183421910215.issue16298@psf.upfronthosting.co.za>


New submission from Eran Rundstein:

When calling HTTPResponse.read() on a response that is:
a. not chunked
b. contains no content-length header
the underlying socket (referenced by self.fp) will never get closed (through self.close())

The offending code is at the bottom of the read() function:
        s = self.fp.read(amt)
        if self.length is not None:
            self.length -= len(s)
            if not self.length:
                self.close()
        return s
As seen, if self.length is None, even when the server closes the connection (causing self.fp.read to return ''), the socket will not get closed.

btw, this may be the cause of Issue15633 (http://bugs.python.org/issue15633)

----------
components: Library (Lib)
messages: 173505
nosy: eranrund
priority: normal
severity: normal
status: open
title: httplib.HTTPResponse.read could potentially leave the socket opened forever
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Oct 22 15:58:41 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 22 Oct 2012 13:58:41 +0000
Subject: [New-bugs-announce] [issue16299] __build__ as a temp build
	directory for setup.py
Message-ID: <1350914321.82.0.675095841484.issue16299@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Currently distutils builds files in a temporary directory named 'build' in current dir if not specified otherwise. It will be pythonic to name this directory to be __build__ be default to distinguish it from project specific directories and clarify that this one can be safely removed (much like __pycache__).

----------
assignee: eric.araujo
components: Distutils, Distutils2
messages: 173521
nosy: alexis, eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: __build__ as a temp build directory for setup.py
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Oct 22 16:11:46 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 22 Oct 2012 14:11:46 +0000
Subject: [New-bugs-announce] [issue16300] Windows raises ValueError for
	file:///file/not/exists	instead of URLError
Message-ID: <1350915106.57.0.374555323258.issue16300@psf.upfronthosting.co.za>


New submission from Senthil Kumaran:

>From the Buildbot failure - http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/7573/steps/test/logs/stdio

I remember that we restricted the access for file:// scheme to localhost only for Windows/Cygwin. In terms of exception raised it could either be consistent with other platforms and raise URLError or it could be for good reasons, the tests may need to be tweaked for windows.

----------
assignee: orsenthil
keywords: easy
messages: 173522
nosy: orsenthil
priority: normal
severity: normal
status: open
title: Windows raises ValueError for file:///file/not/exists instead of URLError
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Oct 22 17:29:05 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 22 Oct 2012 15:29:05 +0000
Subject: [New-bugs-announce] [issue16301] localhost() and thishost() in
	urllib/request.py
Message-ID: <1350919745.8.0.0839924289599.issue16301@psf.upfronthosting.co.za>


New submission from Senthil Kumaran:

localhost() returns a string and thishost() returns tuple. In urllib/request.py, for file:// protocol, there is a verification to check to if the host is in the localhost and check happens:

socket.gethostbyname(host) in (localhost() + thishost())):

This is clearly wrong for the above mentioned reason. It should be changed to this, wrapping localhost with tuple() or making localhost return a tuple, which will be consistent with thishost

socket.gethostbyname(host) in (tuple(localhost()) + thishost())):

----------
assignee: orsenthil
messages: 173530
nosy: orsenthil
priority: normal
severity: normal
status: open
title: localhost() and thishost() in urllib/request.py
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/issue16301>
_______________________________________

From report at bugs.python.org  Mon Oct 22 17:46:00 2012
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 22 Oct 2012 15:46:00 +0000
Subject: [New-bugs-announce] [issue16302] Fix ResourceWarning in
	Lib/test/test_urllib.py
Message-ID: <1350920760.93.0.59056683313.issue16302@psf.upfronthosting.co.za>


New submission from Berker Peksag:

See the output:

test_file_notexists (test.test_urllib.urlopen_HttpTests) ... file:///tmp/tmpmlmjhf
/home/berker/hacking/cpython/Lib/test/test_urllib.py:284: ResourceWarning: unclosed file <_io.BufferedReader name='/tmp/tmpmlmjhf'>
  self.assertTrue(urlopen(tmp_fileurl))
ok

----------
components: Tests
files: resourcewarning_urllib_test.patch
keywords: patch
messages: 173532
nosy: berker.peksag
priority: normal
severity: normal
status: open
title: Fix ResourceWarning in Lib/test/test_urllib.py
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27662/resourcewarning_urllib_test.patch

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

From report at bugs.python.org  Tue Oct 23 13:53:19 2012
From: report at bugs.python.org (Vladimir Rutsky)
Date: Tue, 23 Oct 2012 11:53:19 +0000
Subject: [New-bugs-announce] [issue16303] typo in error message in pstats.py
Message-ID: <1350993199.31.0.48592557313.issue16303@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky:

Please see attached patch for details.

----------
files: quote_typo.patch
keywords: patch
messages: 173594
nosy: vrutsky
priority: normal
severity: normal
status: open
title: typo in error message in pstats.py
versions: Python 2.7
Added file: http://bugs.python.org/file27672/quote_typo.patch

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

From report at bugs.python.org  Tue Oct 23 13:59:09 2012
From: report at bugs.python.org (Vladimir Rutsky)
Date: Tue, 23 Oct 2012 11:59:09 +0000
Subject: [New-bugs-announce] [issue16304] re: Match Objects always have a
	boolean value of True
Message-ID: <1350993549.54.0.0789320233606.issue16304@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky:

re module documentation says:

 Match Objects always have a boolean value of :const:`True`, so that you can test
   whether e.g. :func:`match` resulted in a match with a simple if statement.

which is confusing - matched objects have boolean value True, doesn't matched - False.

----------
assignee: docs at python
components: Documentation
messages: 173595
nosy: docs at python, vrutsky
priority: normal
severity: normal
status: open
title: re: Match Objects always have a boolean value of  True
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 24 00:33:28 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Oct 2012 22:33:28 +0000
Subject: [New-bugs-announce] [issue16305] possible segfault in math.factorial
Message-ID: <1351031608.7.0.419151487248.issue16305@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

>>> import math, sys
>>> math.factorial(sys.maxsize - 1)
(Hit Ctrl-C)
Segmentation fault

The cause is probably in mathmodule.c::factorial_odd_part():
  error:
    Py_DECREF(outer);
  done:
    Py_DECREF(inner);
    return outer;
In case of error, the function returns a released reference instead of NULL.

----------
messages: 173643
nosy: amaury.forgeotdarc
priority: normal
severity: normal
status: open
title: possible segfault in math.factorial
type: crash
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Oct 24 01:47:11 2012
From: report at bugs.python.org (=?utf-8?q?Thi=C3=A9baud_Weksteen?=)
Date: Tue, 23 Oct 2012 23:47:11 +0000
Subject: [New-bugs-announce] [issue16306] Multiple error line for unknown
	command line parameter
Message-ID: <1351036031.44.0.0447945169816.issue16306@psf.upfronthosting.co.za>


New submission from Thi?baud Weksteen:

Hi,

I've just came across an insignificant bug in the Python command line 
interface. When using an unknown parameter, the same error appears 
more than once:

$ python3 -a -z
Unknown option: -a
Unknown option: -z
Unknown option: -a
usage: python3 [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.
$ python -a -z
Unknown option: -a
Unknown option: -z
Unknown option: -a
usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.

----------
components: None
messages: 173649
nosy: tweksteen
priority: normal
severity: normal
status: open
title: Multiple error line for unknown command line parameter
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Oct 24 09:14:12 2012
From: report at bugs.python.org (Bbb)
Date: Wed, 24 Oct 2012 07:14:12 +0000
Subject: [New-bugs-announce] [issue16307] multiprocess.pool.map_async
	callables not working
Message-ID: <1351062852.0.0.92760767978.issue16307@psf.upfronthosting.co.za>


New submission from Bbb:

When using map_async() my callbacks don't get called back.  When using apply_async() they do get called.

CODE:
from multiprocessing import Pool,TimeoutError
from time import sleep

servers=["s1","s2","s3","s4","s5","s6"]
blah = "no callback"

def f(x):
    print("start f(" + x + ")")
    sleep(5)
    print("end   f(" + x + ")")
    return "did " + x

def mycallback(x):
    global blah
    blah = "called back"
    print("My callback " + str(x))
    


def myerrorcallback(r):
    print("My errorcallback " + str(r))


if __name__ == '__main__':
    pool = Pool(processes=7)
    results = pool.map_async(f, servers,  callback=mycallback, error_callback=myerrorcallback)
    print(results.get(timeout=11))
    pool.close()
    pool.join()
    print(blah)

OUTPUT:
D:\python>f.py
start f(s1)
start f(s2)
start f(s3)
start f(s4)
start f(s6)
start f(s5)
end   f(s1)
end   f(s2)
end   f(s3)
end   f(s4)
end   f(s5)
end   f(s6)
['did s1', 'did s2', 'did s3', 'did s4', 'did s5', 'did s6']
no callback

...whereas replacing the code with this:
   with Pool(processes=7) as pool:         # start 4 worker processes
        for server in servers:
            r = pool.apply_async(f, (server,),  callback=mycallback, error_callback=myerrorcallback)
        pool.close()
        pool.join()
        print (blah)


GIVES:
D:\python\f2.py
start f(s1)
start f(s2)
start f(s3)
start f(s4)
start f(s5)
start f(s6)
end   f(s2)
end   f(s1)
My callback did s2
My callback did s1
end   f(s4)
My callback did s4
end   f(s3)
My callback did s3
end   f(s5)
My callback did s5
end   f(s6)
My callback did s6
called back


This is v3.3 on Windows XP.

----------
components: Library (Lib)
messages: 173653
nosy: Bbb
priority: normal
severity: normal
status: open
title: multiprocess.pool.map_async callables not working
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Oct 24 11:22:33 2012
From: report at bugs.python.org (telmich)
Date: Wed, 24 Oct 2012 09:22:33 +0000
Subject: [New-bugs-announce] [issue16308] Undocumented (?) behaviour change
	in argparse from 3.2.3	to 3.3.0
Message-ID: <1351070553.1.0.217274613803.issue16308@psf.upfronthosting.co.za>


New submission from telmich:

Using argparse with subparsers, the default behaviour if no subparser was selected, was to print help:

cdist% git describe 
2.0.14-59-g5315c41
cdist% ./bin/cdist 
usage: cdist [-h] [-d] [-v] [-V] {banner,config} ...
cdist: error: too few arguments
cdist% python3 -V 
Python 3.2.3

With python 3.3.0, this changed and thus the so far uncalled code block is executed:

cdist% ./bin/cdist  
Traceback (most recent call last):
  File "./bin/cdist", line 237, in <module>
    commandline()
  File "./bin/cdist", line 104, in commandline
    args.func(args)
AttributeError: 'Namespace' object has no attribute 'func'
cdist% git describe 
2.0.14-59-g5315c41
cdist% python3 -V
Python 3.3.0


Question:

What is the correct way now to abort, if no subparser or
no option was given (i.e. restore the previous behaviour)?

I tried to fix this problem by using

parser['main'].set_defaults(func=commandline_main)

to setup a default handler for main, but this overwrites the func= parameter for all subparsers as well and thus renders this possibility useless (commits b7a8a84 and 840dbc5 in cdist).

The source code for cdist using the subparsers is available at http://git.schottelius.org/?p=cdist

----------
components: Library (Lib)
messages: 173659
nosy: telmich
priority: normal
severity: normal
status: open
title: Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0
versions: Python 3.3

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

From report at bugs.python.org  Wed Oct 24 12:37:40 2012
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 24 Oct 2012 10:37:40 +0000
Subject: [New-bugs-announce] [issue16309] "PYTHONPATH=" different from no
	PYTHONPATH at all
Message-ID: <1351075060.78.0.16981158153.issue16309@psf.upfronthosting.co.za>


New submission from Armin Rigo:

On Posix, it is documented that setting PATH to the empty string is equivalent to not setting PATH at all, which is an exception to the rule that in a string like "/bin::/usr/bin" the empty string in the middle gets interpreted as ".".

PYTHONPATH does not have this exception: an empty PYTHONPATH is interpreted as equivalent to ".".

This difference is not documented.  This is a detail, but a possible source of confusion, so I'm reporting it here.

How to reproduce:

file x/x.py: "import z"
file z.py: "print(42)"

The following two lines behave differently (Bash syntax):

PYTHONPATH= python x/x.py
unset PYTHONPATH && python x/x.py

For comparison, if "./foo" is an executable, the following two lines behave identically (neither finds "./foo"):

PATH= foo
unset PATH && foo

----------
components: Interpreter Core
keywords: easy
messages: 173665
nosy: arigo
priority: normal
severity: normal
status: open
title: "PYTHONPATH=" different from no PYTHONPATH at all
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 24 14:33:45 2012
From: report at bugs.python.org (Stefan Holek)
Date: Wed, 24 Oct 2012 12:33:45 +0000
Subject: [New-bugs-announce] [issue16310] zipfile: allow surrogates in
	filenames
Message-ID: <1351082025.34.0.287428579283.issue16310@psf.upfronthosting.co.za>


New submission from Stefan Holek:

Please allow for surrogates in the zipfile module like it was done for tarfile in #8390.

Currently zipfile breaks when encountering surrogates:

Traceback (most recent call last):
  File "/usr/local/python3.3/lib/python3.3/zipfile.py", line 392, in _encodeFilenameFlags
    return self.filename.encode('ascii'), self.flag_bits
UnicodeEncodeError: 'ascii' codec can't encode character '\udcfc' in position 21: ordinal not in range(128)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "setup.py", line 20, in <module>
    'setuptools',
  File "/usr/local/python3.3/lib/python3.3/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/local/python3.3/lib/python3.3/distutils/dist.py", line 917, in run_commands
    self.run_command(cmd)
  File "/usr/local/python3.3/lib/python3.3/distutils/dist.py", line 936, in run_command
    cmd_obj.run()
  File "/home/stefan/sandbox/setuptools-git/lib/python3.3/site-packages/distribute-0.6.30-py3.3.egg/setuptools/command/sdist.py", line 161, in run
    self.make_distribution()
  File "/usr/local/python3.3/lib/python3.3/distutils/command/sdist.py", line 447, in make_distribution
    file = self.make_archive(base_name, fmt, base_dir=base_dir)
  File "/usr/local/python3.3/lib/python3.3/distutils/cmd.py", line 370, in make_archive
    dry_run=self.dry_run)
  File "/usr/local/python3.3/lib/python3.3/distutils/archive_util.py", line 178, in make_archive
    filename = func(base_name, base_dir, **kwargs)
  File "/usr/local/python3.3/lib/python3.3/distutils/archive_util.py", line 118, in make_zipfile
    zip.write(path, path)
  File "/usr/local/python3.3/lib/python3.3/zipfile.py", line 1328, in write
    self.fp.write(zinfo.FileHeader())
  File "/usr/local/python3.3/lib/python3.3/zipfile.py", line 382, in FileHeader
    filename, flag_bits = self._encodeFilenameFlags()
  File "/usr/local/python3.3/lib/python3.3/zipfile.py", line 394, in _encodeFilenameFlags
    return self.filename.encode('utf-8'), self.flag_bits | 0x800
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcfc' in position 21: surrogates not allowed

----------
components: Library (Lib), Unicode
messages: 173676
nosy: ezio.melotti, stefanholek
priority: normal
severity: normal
status: open
title: zipfile: allow surrogates in filenames
versions: Python 3.3

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

From report at bugs.python.org  Wed Oct 24 20:38:21 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Oct 2012 18:38:21 +0000
Subject: [New-bugs-announce] [issue16311] Use _PyUnicodeWriter API in text
	decoders
Message-ID: <1351103901.39.0.0945105753188.issue16311@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch modifies text decoders to use the _PyUnicodeWriter API to factorize the code. It removes unicode_widen() and unicode_putchar() functions.

 * Don't overallocate by default  (except for "raw-unicode-escape" codec), enable overallocation on the first decode error (as done currently)
 * _PyUnicodeWriter_Prepare() only overallocates 25%, instead of 100%
for unicode_decode_call_errorhandler()
 * Use _PyUnicodeWriter_Prepare() + PyUnicode_WRITE() (two macros)
instead of unicode_putchar() (function)
 * _PyUnicodeWriter structures stores many useful fields, so we don't
have to pass multiple parameters to functions, only the writer

I wrote the patch to factorize the code, but it might be faster.

----------
files: codecs_writer.patch
keywords: patch
messages: 173695
nosy: haypo
priority: normal
severity: normal
status: open
title: Use _PyUnicodeWriter API in text decoders
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file27697/codecs_writer.patch

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

From report at bugs.python.org  Wed Oct 24 21:58:35 2012
From: report at bugs.python.org (Piotr Dobrogost)
Date: Wed, 24 Oct 2012 19:58:35 +0000
Subject: [New-bugs-announce] [issue16312] New command line option supported
	by unittest.main() for	running initialization code before tests
Message-ID: <1351108715.95.0.725545714985.issue16312@psf.upfronthosting.co.za>


New submission from Piotr Dobrogost:

When running tests bundled with a library it would be useful to be able to run some initialization code before tests are being run so that one can configure options pertaining to logging for example.

For this reason it would be useful to have a new command line option handled by unittest.main() for running custom Python module before running tests.

See http://stackoverflow.com/q/8607767/95735

----------
components: Library (Lib)
messages: 173699
nosy: piotr.dobrogost
priority: normal
severity: normal
status: open
title: New command line option supported by unittest.main() for running initialization code before tests
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Oct 24 23:32:28 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Oct 2012 21:32:28 +0000
Subject: [New-bugs-announce] [issue16313] Support xz compression in shutil
	module
Message-ID: <1351114348.5.0.919820105174.issue16313@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds xz compression support in additional to gzip and bzip2 in shutil module.

----------
components: Library (Lib)
files: shutil-lzma.patch
keywords: patch
messages: 173707
nosy: hynek, nadeem.vawda, serhiy.storchaka, tarek
priority: normal
severity: normal
status: open
title: Support xz compression in shutil module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27699/shutil-lzma.patch

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

From report at bugs.python.org  Wed Oct 24 23:32:58 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Oct 2012 21:32:58 +0000
Subject: [New-bugs-announce] [issue16314] Support xz compression in distutils
Message-ID: <1351114378.64.0.718374634123.issue16314@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds xz compression support in additional to gzip, compress and bzip2 in distutils.

----------
assignee: eric.araujo
components: Distutils
files: distutils-lzma.patch
keywords: patch
messages: 173708
nosy: eric.araujo, nadeem.vawda, serhiy.storchaka, tarek
priority: normal
severity: normal
stage: patch review
status: open
title: Support xz compression in distutils
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27700/distutils-lzma.patch

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

From report at bugs.python.org  Wed Oct 24 23:40:34 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Oct 2012 21:40:34 +0000
Subject: [New-bugs-announce] [issue16315] Support xz compression in Mac buil
	script
Message-ID: <1351114834.01.0.950919502981.issue16315@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds xz compression support in additional to gzip and bzip2 in Mac buil script.

----------
assignee: ronaldoussoren
components: Build, Macintosh
files: macbuildscript-lzma.patch
keywords: patch
messages: 173711
nosy: hynek, nadeem.vawda, ned.deily, ronaldoussoren, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Support xz compression in Mac buil script
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27701/macbuildscript-lzma.patch

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

From report at bugs.python.org  Wed Oct 24 23:40:45 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Oct 2012 21:40:45 +0000
Subject: [New-bugs-announce] [issue16316] Support xz compression in
	mimetypes module
Message-ID: <1351114845.07.0.378323444057.issue16316@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds xz compression support in additional to gzip, compress and bzip2 in mimetypes module.

----------
components: Library (Lib)
files: mimetypes-lzma.patch
keywords: patch
messages: 173712
nosy: nadeem.vawda, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Support xz compression in mimetypes module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27702/mimetypes-lzma.patch

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

From report at bugs.python.org  Wed Oct 24 23:59:12 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 24 Oct 2012 21:59:12 +0000
Subject: [New-bugs-announce] [issue16317] Mention lzma module in tutorial
Message-ID: <1351115952.07.0.995218078366.issue16317@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds link to lzma module (in additional to zlib, gzip, bz2, and zipfile) in tutorial.

----------
assignee: docs at python
components: Documentation
files: stdlib-lzma.patch
keywords: patch
messages: 173713
nosy: docs at python, nadeem.vawda, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Mention lzma module in tutorial
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27703/stdlib-lzma.patch

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

From report at bugs.python.org  Thu Oct 25 01:09:24 2012
From: report at bugs.python.org (Jeremy Brock)
Date: Wed, 24 Oct 2012 23:09:24 +0000
Subject: [New-bugs-announce] [issue16318] FTP_TLS in ftplib not supporting
	prot_p storlines in	FTP7.5
Message-ID: <1351120164.32.0.969400884781.issue16318@psf.upfronthosting.co.za>


New submission from Jeremy Brock:

Recently I have been working on a project to utilize the new FTP_TLS library from ftplib in Python 2.7.3.  What I found is that no matter what I try, when prot_p() is called prior to transferring files to 2008 Server R2 running FTP7.5, the python client connection no longer is able to transfer files to the FTP7.5 server resulting in *get* '425 Data channel timed out due to not meeting the minimum bandwidth requirement.\r\n' .

    I have reproduced this in Python 2.7.3 on HPUX and Windows.

    I am able to successfully transfer files using winscp and Filezilla to the same FTP7.5 server using FTPes with Prot_P in Active Mode.

----------
components: Library (Lib)
files: FTP7.5 Issues Documentation.zip
messages: 173719
nosy: Jeremy.Brock
priority: normal
severity: normal
status: open
title: FTP_TLS in ftplib not supporting prot_p storlines in FTP7.5
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file27706/FTP7.5 Issues Documentation.zip

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

From report at bugs.python.org  Thu Oct 25 08:24:20 2012
From: report at bugs.python.org (Inyeol Lee)
Date: Thu, 25 Oct 2012 06:24:20 +0000
Subject: [New-bugs-announce] [issue16319] optional comma inside function
	argument list triggers	syntax error
Message-ID: <1351146260.34.0.857834219193.issue16319@psf.upfronthosting.co.za>


New submission from Inyeol Lee:

Ubuntu 12.04, python 3.2.3

Optional trailing comma causes syntax error if used for keyword-only argument list:

These are OK --
def f(a, b,): pass
def f(a, b=None,): pass

These triggers syntax error --
def f(a, *, b,): pass
def f(a, *, b=None,): pass

python 3.1 and 3.2 shows this error, not tested for 3.3 yet.

----------
components: Interpreter Core
messages: 173735
nosy: Inyeol.Lee
priority: normal
severity: normal
status: open
title: optional comma inside function argument list triggers syntax error
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Oct 25 11:07:17 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 25 Oct 2012 09:07:17 +0000
Subject: [New-bugs-announce] [issue16320] Establish order in bytes/string
	dependencies
Message-ID: <1351156037.64.0.017004315605.issue16320@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch reorganizes the dependencies for bytes and strings. Now object files depended only from needed (and from all needed) headers. This will reduce the compilation time when modifying the bytes implementation.

----------
components: Build, Unicode
files: Makefile.pre.in.diff
keywords: patch
messages: 173747
nosy: ezio.melotti, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Establish order in bytes/string dependencies
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27710/Makefile.pre.in.diff

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

From report at bugs.python.org  Thu Oct 25 11:29:39 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 25 Oct 2012 09:29:39 +0000
Subject: [New-bugs-announce] [issue16321] Move eq.h out of stringlib
Message-ID: <1351157379.02.0.714048258846.issue16321@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The Objects/stringlib directory used for "templates" which instantiates for specified bytes or unicode kinds. Objects/stringlib/eq.h has no relation to this "templates" and should be moved out (as Objects/unicode_eq.h for example).

Also it should be removed from Include/Python.h. It used only in Objects/dictobject.c and Objects/setobject.c, and included there directly.

----------
components: Interpreter Core, Unicode
messages: 173749
nosy: ezio.melotti, haypo, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Move eq.h out of stringlib
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Oct 25 13:56:50 2012
From: report at bugs.python.org (Masami HIRATA)
Date: Thu, 25 Oct 2012 11:56:50 +0000
Subject: [New-bugs-announce] [issue16322] time.tzname on Python 3.3.0 for
	Windows is decoded by	wrong encoding
Message-ID: <1351166210.69.0.0993824857313.issue16322@psf.upfronthosting.co.za>


New submission from Masami HIRATA:

OS: Windows 7 Starter Edition SP1 (32-bit) Japanese version
Python: 3.3.0 for Windows x86 (python-3.3.0.msi)

time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding.

C:\Python33>python.exe
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (In
tel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.tzname[0]
'\x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)'
>>> time.tzname[0].encode('iso-8859-1').decode('mbcs')
'?? (???)'
>>>

'?? (???)' means 'Tokyo (Standard Time)' in Japanese.
time.tzname on Python 3.2.3 for Windows works correctly.

C:\Python32>python.exe
Python 3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.tzname[0]
'?? (???)'
>>>

----------
components: Windows
messages: 173755
nosy: msmhrt
priority: normal
severity: normal
status: open
title: time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Oct 25 15:57:34 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 25 Oct 2012 13:57:34 +0000
Subject: [New-bugs-announce] [issue16323] Wrong C API documentation for
	locale encoding
Message-ID: <1351173455.0.0.737976146006.issue16323@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The documentation for PyUnicode_DecodeLocale() and PyUnicode_EncodeLocale() are wrong. The second parameter described as "int surrogateescape", but actually it is "const char *errors".

----------
assignee: docs at python
components: Documentation, Unicode
messages: 173760
nosy: docs at python, ezio.melotti, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Wrong C API documentation for locale encoding
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Oct 25 17:49:32 2012
From: report at bugs.python.org (Claude Paroz)
Date: Thu, 25 Oct 2012 15:49:32 +0000
Subject: [New-bugs-announce] [issue16324] MIMEText __init__ does not support
	Charset instance
Message-ID: <1351180172.93.0.972082460953.issue16324@psf.upfronthosting.co.za>


New submission from Claude Paroz:

When initializing a MIMEText instance, it might be desirable to set the _charset parameter to a real Charset instance, not only a charset identifier (for example to pass a Charset with customized body_encoding). Unfortunately, this is failing:

  File ".../django/core/mail/message.py", line 128, in __init__
    MIMEText.__init__(self, text, subtype, charset)
  File "/usr/lib/python3.2/email/mime/text.py", line 29, in __init__
    **{'charset': _charset})
  File "/usr/lib/python3.2/email/mime/base.py", line 25, in __init__
    self.add_header('Content-Type', ctype, **_params)
  File "/usr/lib/python3.2/email/message.py", line 475, in add_header
    parts.append(_formatparam(k.replace('_', '-'), v))
  File "/usr/lib/python3.2/email/message.py", line 67, in _formatparam
    if value is not None and len(value) > 0:
TypeError: object of type 'Charset' has no len()

It is possible to later call set_charset, but the payload is already encoded (and 'Content-Transfer-Encoding' is set).
Did I miss anything?

----------
components: email
messages: 173764
nosy: barry, claudep, r.david.murray
priority: normal
severity: normal
status: open
title: MIMEText __init__ does not support Charset instance
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Oct 25 19:32:47 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 25 Oct 2012 17:32:47 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue16325=5D_PEP=C2=A08_refers_?=
	=?utf-8?q?to_reference_to_PEP_8?=
Message-ID: <1351186367.56.0.154772018317.issue16325@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

PEP?8 refers to Guido's original Python Style Guide essay (http://www.python.org/doc/essays/styleguide.html), but the essay was removed, only link to PEP?8 (and PEP 257) left.

----------
assignee: docs at python
components: Documentation
messages: 173773
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PEP?8 refers to reference to PEP 8
type: behavior

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

From report at bugs.python.org  Thu Oct 25 21:44:24 2012
From: report at bugs.python.org (Andy Salnikov)
Date: Thu, 25 Oct 2012 19:44:24 +0000
Subject: [New-bugs-announce] [issue16326] distutils build_ext fails to set
	library_dirs in 2.7.2	on Linux
Message-ID: <1351194264.28.0.869819451271.issue16326@psf.upfronthosting.co.za>


New submission from Andy Salnikov:

Hi,

when trying to build extension modules with distutils I ran into
a problem that linking fails with an errors like:

gcc -pthread -shared -L build/temp.linux-x86_64-2.7/h5py/defs.o -L/reg/g/psdm/sw/external/hdf5/1.8.4p1/x86_64-rhel6-gcc44-opt/lib -L. -Wl,-R/reg/g/psdm/sw/external/hdf5/1.8.4p1/x86_64-rhel6-gcc44-opt/lib -lhdf5 -lpython2.7 -o build/lib.linux-x86_64-2.7/h5py/defs.so
/usr/bin/ld: cannot find -lpython2.7
collect2: ld returned 1 exit status

For some reason location of the python library is not added to the 
command line with -L option.

I tracked the reason down to a particular environment that we have, 
in out environment python executable found in a $PATH is a symbolic link
to a binary installed in some non-standard location. I believe this 
piece of code in build_ext.py fails to realize this:

            if sys.executable.startswith(os.path.join(sys.exec_prefix, "bin")):
                # building third party extensions
                self.library_dirs.append(sysconfig.get_config_var('LIBDIR'))
            else:
                # building python standard extensions
                self.library_dirs.append('.')

apparently sys.executable in our case refers to a symlink path, while 
sys.exec_prefix refers to actual installation directory.

I think fix for our case should be easy (I can't say about other cases
which may be broken by this logic), one just need to apply os.path.realpath()
to sys.executable before comparing it to sys.exec_prefix.

Andy

----------
assignee: eric.araujo
components: Distutils
messages: 173796
nosy: Andy.Salnikov, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils build_ext fails to set library_dirs in 2.7.2 on Linux
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct 26 00:31:03 2012
From: report at bugs.python.org (Mark Gius)
Date: Thu, 25 Oct 2012 22:31:03 +0000
Subject: [New-bugs-announce] [issue16327] subprocess.Popen leaks file
	descriptors on os.fork()	failure
Message-ID: <1351204263.29.0.689540716038.issue16327@psf.upfronthosting.co.za>


New submission from Mark Gius:

When subprocess.Popen is called with subprocess.PIPE and os.fork() fails (due to insufficient memory for example), the pipes created by _get_handles() are not closed.

Steps to reproduce:

1) Launch a python shell, import subprocess
2) Create a situation where os.fork() will fail (I ran a program to eat up nearly all of the memory on a system)
3) subprocess.Popen('/bin/echo', stdin=subprocess.PIPE)
4) OSError(12, 'Cannot allocate memory')
5) ls /proc/$pid/fd , There are now extra pipes.

I tested on Ubuntu 11.10 python (2.7.2-5ubuntu1).  My reading of the 2.7 and 3.3 development trees suggest that this is an issue with both of those branches, but I don't have a 3.3 installation to confirm with.

I've attached a snippet that fixes it for my version of Python on Ubuntu.  No idea what ramifications it will have for other versions/OS/etc.  No automated testing included because I'm not entirely sure how to replicate this without eating up a ton of ram or doing something naughty with ulimit.

----------
components: Library (Lib)
files: fd_leak_fix.diff
keywords: patch
messages: 173804
nosy: Mark.Gius
priority: normal
severity: normal
status: open
title: subprocess.Popen leaks file descriptors on os.fork() failure
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file27719/fd_leak_fix.diff

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

From report at bugs.python.org  Fri Oct 26 14:41:22 2012
From: report at bugs.python.org (Emil Styrke)
Date: Fri, 26 Oct 2012 12:41:22 +0000
Subject: [New-bugs-announce] [issue16328] win_add2path.py sets wrong user
	path
Message-ID: <1351255282.63.0.930970476961.issue16328@psf.upfronthosting.co.za>


New submission from Emil Styrke:

OS: Windows 7 Ultimate x64
Python version: 2.7.3 x64

win_add2path.py in the scripts directory is supposed to add the Scripts directory according to its source.  However, it tries to add $PYTHONPATH/Scripts, when in fact the Scripts directory is at $PYTHONPATH/Tools/Scripts in 2.7.

However, it seems like e.g. Setuptools still installs itself in $PYTHONPATH/Scripts, so maybe the right solution is to add both directories.

Furthermore, the script sets the default user path to %PATH%, which is not correct at least on windows 7.  I have to manually delete this part of the user path to get the user path merged correctly with the system path in cmd.exe.

----------
components: Demos and Tools, Windows
messages: 173840
nosy: Emil.Styrke
priority: normal
severity: normal
status: open
title: win_add2path.py sets wrong user path
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct 26 15:34:58 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 26 Oct 2012 13:34:58 +0000
Subject: [New-bugs-announce] [issue16329] mimetypes does not support webm
	type
Message-ID: <1351258498.52.0.166970519729.issue16329@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

http://www.webmproject.org/docs/container/#naming

----------
components: Library (Lib)
files: webm.diff
keywords: patch
messages: 173843
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: mimetypes does not support webm type
versions: Python 3.4
Added file: http://bugs.python.org/file27728/webm.diff

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

From report at bugs.python.org  Fri Oct 26 17:42:56 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 26 Oct 2012 15:42:56 +0000
Subject: [New-bugs-announce] [issue16330] Use surrogate-related macros
Message-ID: <1351266176.96.0.911861478569.issue16330@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

A set of macros to work with surrogates was introduced in 3.3: Py_UNICODE_IS_SURROGATE, Py_UNICODE_IS_HIGH_SURROGATE, Py_UNICODE_IS_LOW_SURROGATE, Py_UNICODE_JOIN_SURROGATES, Py_UNICODE_HIGH_SURROGATE, and Py_UNICODE_LOW_SURROGATE.  Using this macros makes a code more readable, protect from errors, and allows use the one most effective implementation.  But not all surrogate-related code uses this macros.  I suppose this is done inadvertently, somewhere the macro and naked code used in neighboring lines.

The proposed patch replaces a naked surrogate code to macros in all places except expat (which is a foreign code).

----------
components: Interpreter Core, Unicode
files: use_surrogate_macros.patch
keywords: patch
messages: 173855
nosy: ezio.melotti, haypo, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use surrogate-related macros
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27730/use_surrogate_macros.patch

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

From report at bugs.python.org  Fri Oct 26 19:34:20 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 26 Oct 2012 17:34:20 +0000
Subject: [New-bugs-announce] [issue16331] Add a version switcher to python
	docs site
Message-ID: <1351272860.89.0.664706637925.issue16331@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

This patch adds a dropdown to python documentation top toolbar:
https://dl.dropbox.com/u/21052/python/p3_doc_dd.png

This patch version is for python 3.3 & 3.4 docs theme, but I can quickly make patches for 3.2-style and below.

JavaScript that monitors dropdown events is smart enough to:

1) Redirect users to the same documentation section, i.e. if the user is on 'atexit' module doc page for 3.3, and decides to switch to '2.7', he'll see 'atexit' module doc page for 2.7

2) Before making a redirect, is checks that the doc page exists for the selected python version, and if not, then it simply redirects to 'http://docs.python.org/{version}'

3) Users with JS disabled will see a plain-text current version (no drop down)

----------
assignee: docs at python
components: Documentation
files: py3_version_switch.patch
keywords: patch
messages: 173864
nosy: docs at python, georg.brandl, rhettinger, yselivanov
priority: normal
severity: normal
status: open
title: Add a version switcher to python docs site
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27731/py3_version_switch.patch

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

From report at bugs.python.org  Fri Oct 26 22:03:28 2012
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 26 Oct 2012 20:03:28 +0000
Subject: [New-bugs-announce] [issue16332] Use new exception handling syntax
	in Subprocess	documentation
Message-ID: <1351281808.98.0.372067988973.issue16332@psf.upfronthosting.co.za>


New submission from Berker Peksag:

See: http://docs.python.org/whatsnew/2.6.html#pep-3110-exception-handling-changes

Patch attached.

----------
assignee: docs at python
components: Documentation
files: subprocess-exception-2.7.patch
keywords: patch
messages: 173881
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Use new exception handling syntax in Subprocess documentation
versions: Python 2.7
Added file: http://bugs.python.org/file27733/subprocess-exception-2.7.patch

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

From report at bugs.python.org  Fri Oct 26 23:25:12 2012
From: report at bugs.python.org (Zach Mathew)
Date: Fri, 26 Oct 2012 21:25:12 +0000
Subject: [New-bugs-announce] [issue16333] Trailing whitespace in json dump
	when using indent
Message-ID: <1351286712.61.0.639993947204.issue16333@psf.upfronthosting.co.za>


New submission from Zach Mathew:

When using the indent option in json.JSONEncoder, extra trailing whitespace (preceding the newline) is added to list and dict items.

For example:

>>> import json
>>> json.dumps(['foo', 'bar'], indent=1)
'[\n "foo", \n "bar"\n]'

Notice the blank space between "foo", and \n

EXPECTED OUTPUT:

'[\n "foo",\n "bar"\n]'

----------
components: Library (Lib)
files: fix_json_trailing_space_and_tests.patch
keywords: patch
messages: 173891
nosy: zmathew
priority: normal
severity: normal
status: open
title: Trailing whitespace in json dump when using indent
type: behavior
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/file27735/fix_json_trailing_space_and_tests.patch

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

From report at bugs.python.org  Sat Oct 27 00:48:25 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 26 Oct 2012 22:48:25 +0000
Subject: [New-bugs-announce] [issue16334] Faster unicode-escape and
	raw-unicode-escape codecs
Message-ID: <1351291705.86.0.638624862326.issue16334@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch optimizes unicode-escape and raw-unicode-escape codecs.  Coders still slower than in 3.2, but much faster than in 3.3.  Further speedup is possible with the use of stringlib, but I think that this is enough.  The code unified and simplified (251 insertions, 345 deletions).

Benchmark results (on AMD Athlon 64 X2 4600+):

Py2.7        Py3.2        Py3.3        Py3.4+patch

193 (+11%)   325 (-34%)   66 (+224%)   214    decode  unicode-escape  'A'*10000
138 (+72%)   241 (-1%)    154 (+55%)   238    decode  unicode-escape  '\x80'*10000
193 (+10%)   323 (-34%)   72 (+194%)   212    decode  unicode-escape    '\x80'+'A'*9999
160 (+59%)   273 (-7%)    169 (+51%)   255    decode  unicode-escape  '\u0100'*10000
193 (-7%)    324 (-44%)   61 (+195%)   180    decode  unicode-escape    '\u0100'+'A'*9999
138 (+67%)   242 (-5%)    135 (+71%)   231    decode  unicode-escape    '\u0100'+'\x80'*9999
160 (+59%)   274 (-7%)    169 (+51%)   255    decode  unicode-escape  '\u8000'*10000
193 (-7%)    323 (-44%)   61 (+195%)   180    decode  unicode-escape    '\u8000'+'A'*9999
138 (+67%)   242 (-5%)    135 (+71%)   231    decode  unicode-escape    '\u8000'+'\x80'*9999
160 (+60%)   276 (-7%)    169 (+51%)   256    decode  unicode-escape    '\u8000'+'\u0100'*9999
178 (+42%)   275 (-8%)    177 (+43%)   253    decode  unicode-escape  '\U00010000'*10000
192 (+30%)   323 (-23%)   61 (+310%)   250    decode  unicode-escape    '\U00010000'+'A'*9999
139 (+35%)   243 (-23%)   119 (+57%)   187    decode  unicode-escape    '\U00010000'+'\x80'*9999
161 (+38%)   273 (-19%)   150 (+48%)   222    decode  unicode-escape    '\U00010000'+'\u0100'*9999
161 (+38%)   273 (-19%)   150 (+48%)   222    decode  unicode-escape    '\U00010000'+'\u8000'*9999

558 (-62%)   427 (-50%)   82 (+161%)   214    decode  raw-unicode-escape  'A'*10000
560 (-62%)   425 (-50%)   75 (+183%)   212    decode  raw-unicode-escape  '\x80'*10000
558 (-62%)   425 (-50%)   75 (+183%)   212    decode  raw-unicode-escape    '\x80'+'A'*9999
178 (+75%)   235 (+32%)   108 (+188%)  311    decode  raw-unicode-escape  '\u0100'*10000
555 (-62%)   424 (-50%)   61 (+248%)   212    decode  raw-unicode-escape    '\u0100'+'A'*9999
559 (-62%)   424 (-50%)   61 (+248%)   212    decode  raw-unicode-escape    '\u0100'+'\x80'*9999
179 (+74%)   235 (+32%)   108 (+188%)  311    decode  raw-unicode-escape  '\u8000'*10000
555 (-62%)   424 (-50%)   61 (+248%)   212    decode  raw-unicode-escape    '\u8000'+'A'*9999
558 (-62%)   425 (-50%)   61 (+248%)   212    decode  raw-unicode-escape    '\u8000'+'\x80'*9999
178 (+75%)   235 (+32%)   108 (+188%)  311    decode  raw-unicode-escape    '\u8000'+'\u0100'*9999
200 (+18%)   249 (-5%)    132 (+79%)   236    decode  raw-unicode-escape  '\U00010000'*10000
554 (-58%)   423 (-46%)   61 (+277%)   230    decode  raw-unicode-escape    '\U00010000'+'A'*9999
558 (-59%)   424 (-46%)   61 (+277%)   230    decode  raw-unicode-escape    '\U00010000'+'\x80'*9999
178 (+46%)   235 (+11%)   100 (+160%)  260    decode  raw-unicode-escape    '\U00010000'+'\u0100'*9999
178 (+44%)   235 (+9%)    100 (+157%)  257    decode  raw-unicode-escape    '\U00010000'+'\u8000'*9999


182 (+137%)  215 (+101%)  148 (+192%)  432    encode  unicode-escape  'A'*10000
582 (-10%)   617 (-16%)   470 (+11%)   521    encode  unicode-escape  '\x80'*10000
182 (+131%)  215 (+96%)   148 (+184%)  421    encode  unicode-escape    '\x80'+'A'*9999
624 (-7%)    967 (-40%)   558 (+4%)    579    encode  unicode-escape  '\u0100'*10000
183 (-19%)   215 (-31%)   132 (+12%)   148    encode  unicode-escape    '\u0100'+'A'*9999
584 (-23%)   617 (-27%)   464 (-3%)    451    encode  unicode-escape    '\u0100'+'\x80'*9999
627 (-8%)    968 (-40%)   557 (+4%)    579    encode  unicode-escape  '\u8000'*10000
183 (-19%)   215 (-31%)   148 (+0%)    148    encode  unicode-escape    '\u8000'+'A'*9999
584 (-23%)   617 (-27%)   490 (-8%)    451    encode  unicode-escape    '\u8000'+'\x80'*9999
629 (-8%)    969 (-40%)   555 (+4%)    578    encode  unicode-escape    '\u8000'+'\u0100'*9999
931 (-39%)   939 (-39%)   602 (-5%)    572    encode  unicode-escape  '\U00010000'*10000
183 (+7%)    215 (-9%)    180 (+9%)    196    encode  unicode-escape    '\U00010000'+'A'*9999
584 (-9%)    617 (-13%)   482 (+11%)   534    encode  unicode-escape    '\U00010000'+'\x80'*9999
630 (-14%)   962 (-43%)   565 (-4%)    544    encode  unicode-escape    '\U00010000'+'\u0100'*9999
630 (-14%)   964 (-44%)   565 (-4%)    544    encode  unicode-escape    '\U00010000'+'\u8000'*9999

332 (+1459%) 330 (+1468%) 333 (+1454%) 5175   encode  raw-unicode-escape  'A'*10000
332 (+1589%) 329 (+1604%) 333 (+1584%) 5607   encode  raw-unicode-escape  '\x80'*10000
336 (+1569%) 334 (+1579%) 333 (+1584%) 5607   encode  raw-unicode-escape    '\x80'+'A'*9999
904 (-38%)   911 (-39%)   557 (+0%)    558    encode  raw-unicode-escape  '\u0100'*10000
336 (+15%)   335 (+16%)   197 (+97%)   388    encode  raw-unicode-escape    '\u0100'+'A'*9999
335 (+16%)   335 (+16%)   197 (+97%)   388    encode  raw-unicode-escape    '\u0100'+'\x80'*9999
904 (-38%)   913 (-39%)   557 (+0%)    558    encode  raw-unicode-escape  '\u8000'*10000
335 (+16%)   335 (+16%)   197 (+96%)   387    encode  raw-unicode-escape    '\u8000'+'A'*9999
335 (+16%)   335 (+16%)   196 (+98%)   388    encode  raw-unicode-escape    '\u8000'+'\x80'*9999
912 (-39%)   909 (-39%)   554 (+1%)    558    encode  raw-unicode-escape    '\u8000'+'\u0100'*9999
966 (-40%)   997 (-42%)   584 (-0%)    583    encode  raw-unicode-escape  '\U00010000'*10000
336 (-42%)   335 (-41%)   213 (-8%)    196    encode  raw-unicode-escape    '\U00010000'+'A'*9999
336 (-42%)   335 (-41%)   213 (-8%)    196    encode  raw-unicode-escape    '\U00010000'+'\x80'*9999
911 (-43%)   911 (-43%)   570 (-8%)    522    encode  raw-unicode-escape    '\U00010000'+'\u0100'*9999
911 (-43%)   913 (-43%)   570 (-8%)    522    encode  raw-unicode-escape    '\U00010000'+'\u8000'*9999

----------
components: Interpreter Core, Unicode
files: faster_unicode_escape.patch
keywords: 3.3regression, patch
messages: 173901
nosy: benjamin.peterson, ezio.melotti, haypo, lemburg, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Faster unicode-escape and raw-unicode-escape codecs
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file27740/faster_unicode_escape.patch

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

From report at bugs.python.org  Sat Oct 27 00:55:21 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 26 Oct 2012 22:55:21 +0000
Subject: [New-bugs-announce] [issue16335] Integer overflow in unicode-escape
	decoder
Message-ID: <1351292121.99.0.943463007307.issue16335@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Size of parsed Unicode character name casted to int in unicode-escape decoder.  This can cause integer overflow.

----------
components: Interpreter Core, Unicode
files: decode_unicode_escape_overflow.patch
keywords: patch
messages: 173902
nosy: benjamin.peterson, ezio.melotti, haypo, lemburg, mark.dickinson, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Integer overflow in unicode-escape decoder
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27741/decode_unicode_escape_overflow.patch

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

From report at bugs.python.org  Sat Oct 27 12:06:10 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 27 Oct 2012 10:06:10 +0000
Subject: [New-bugs-announce] [issue16336] Check input in surrogatepass error
	handler
Message-ID: <1351332370.82.0.307074271772.issue16336@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch fixes input checking in surrogatepass error handler. Also it fixes 10% speed regression introduced by changeset 74d65c746f63.

----------
components: Interpreter Core, Unicode
files: codecs_surrogatepass_2.patch
keywords: patch
messages: 173915
nosy: ezio.melotti, pjenvey, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Check input in surrogatepass error handler
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27744/codecs_surrogatepass_2.patch

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

From report at bugs.python.org  Sat Oct 27 14:15:47 2012
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 27 Oct 2012 12:15:47 +0000
Subject: [New-bugs-announce] [issue16337] typo in documentation regarding
	"Bytearray Objects", chapter 4.8.2
Message-ID: <1351340147.76.0.113530855942.issue16337@psf.upfronthosting.co.za>


New submission from Winfried Plappert:

In the online documentation at http://docs.python.org/py3k/library/stdtypes.html?highlight=bytearray%20objects%20copying%20existing%20binary%20data%20via%20buffer%20protocol and the PDF version 3.3.0, page 46, both in chapter 4.8.2:

Bullet 4 is "bytearray(b'Hi!)" but should be "bytearray(b'Hi!')"

----------
assignee: docs at python
components: Documentation
messages: 173924
nosy: docs at python, wplappert
priority: normal
severity: normal
status: open
title: typo in documentation regarding "Bytearray Objects", chapter 4.8.2
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sat Oct 27 18:45:00 2012
From: report at bugs.python.org (Trenton Craig)
Date: Sat, 27 Oct 2012 16:45:00 +0000
Subject: [New-bugs-announce] [issue16338] pysnmp/asyncore - timeout
	ineffective?
Message-ID: <1351356300.75.0.420247508313.issue16338@psf.upfronthosting.co.za>


New submission from Trenton Craig:

I have an application that is set to use pysnmp to obtain sysDescription and system names from devices on our network.  Currently, we are using python 2.6.2, due to the limitations of the box (solaris), and it works fine.

However, our new environment uses python2.7.3, and ubuntu, and the timeout attribute appears to be failing.

Not sure if this is a bug with pysnmp or asyncore.

I apologize for the brevity of the situation, but will be happy to provide more details upon request.

----------
components: None
messages: 173940
nosy: Trenton.Craig
priority: normal
severity: normal
status: open
title: pysnmp/asyncore - timeout ineffective?
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Oct 27 19:31:07 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 27 Oct 2012 17:31:07 +0000
Subject: [New-bugs-announce] [issue16339] Document "exec(stmt, global_dict,
	local_dict)" form in Python 2?
Message-ID: <1351359067.41.0.359232821509.issue16339@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

In Python 2, the 'exec' statement supports 'exec'-ing a (statement, globals, locals) tuple:

>>> exec("print 2", {}, {})
2

This doesn't seem to be documented at http://docs.python.org/reference/simple_stmts.html#the-exec-statement.

If I understand correctly, the 'exec tuple' form was originally there for backwards compatibility with ancient versions of Python;  however, it now also conveniently provides the semblance of forwards compatibility with Python 3.  It appears to be supported by current versions of Jython (though judging by issue 403345 that wasn't always the case) and PyPy.

Is this omission intentional?  Is this form of exec an official, supported part of the Python 2 language?

----------
assignee: docs at python
components: Documentation
messages: 173947
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Document "exec(stmt, global_dict, local_dict)" form in Python 2?
versions: Python 2.7

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

From report at bugs.python.org  Sat Oct 27 20:42:48 2012
From: report at bugs.python.org (Konstantin Zemlyak)
Date: Sat, 27 Oct 2012 18:42:48 +0000
Subject: [New-bugs-announce] [issue16340] Error: 'utf-8' codec can't decode
	byte 0x9e in position	0: invalid start byte
Message-ID: <1351363368.32.0.193110558396.issue16340@psf.upfronthosting.co.za>


New submission from Konstantin Zemlyak:

When installing python 3.3 under windows and checking "Compile .py files to byte code after installation" Lib/venv/scripts/nt/pydoc.py gets precompiled as well. This causes venv module to abort with "Error: 'utf-8' codec can't decode byte 0x9e in position 0: invalid start byte" while copying scripts from Lib/venv/scripts/nt since only .exe files are copied verbatim, and rest are treated as utf-8 text: http://hg.python.org/cpython/file/b20e473157b8/Lib/venv/__init__.py#l314

The solution is to add another exception to compileargs at Tools/msi/msi.py: http://hg.python.org/cpython/file/b20e473157b8/Tools/msi/msi.py#l419

This issue doesn't affect non-windows systems, since Lib/venv/scripts/posix doesn't contain .py files.

----------
components: Installation
messages: 173955
nosy: zart
priority: normal
severity: normal
status: open
title: Error: 'utf-8' codec can't decode byte 0x9e in position 0: invalid start byte
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Oct 28 02:58:40 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 28 Oct 2012 01:58:40 +0000
Subject: [New-bugs-announce] [issue16341] In examples,
	"except:" should use new syntax
Message-ID: <1351389520.62.0.621289823852.issue16341@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

In python 2.7 documentation, doing "grep -i 'except.*,.*:' *rst" shows quite a few "old style" "except:". I think that "except X, e:" should be transformed to "except X as e:", for clarity, as done in issue #16332.

The only thing is that this syntax, used in examples, would be incompatible with old python releases.

Opinions?

----------
keywords: easy
messages: 173988
nosy: jcea
priority: normal
severity: normal
status: open
title: In examples, "except:" should use new syntax
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 28 03:32:19 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 28 Oct 2012 02:32:19 +0000
Subject: [New-bugs-announce] [issue16342] setup.py not compiling with NDEBUG
	in non-debug builds
Message-ID: <1351391539.96.0.993483572486.issue16342@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Discovered on OS X 10.8 with clang 3.1, I'm having build failures for _json, _md5, _sha1, _sha256, _sha3, and _sha512 because _PyUnicode_CheckConsistency() is only defined when defined(Py_DEBUG) && !defined(Py_LIMITED_API) even though it is only used in assert() calls (like the one below). If you read the comment in Include/Python.h where assert.h is included it explicitly says that:

/* CAUTION:  Build setups should ensure that NDEBUG is defined on the
 * compiler command line when building Python in release mode; else
 * assert() calls won't be removed.
 */

Based on the output below that is not currently happening in setup.py. Not sure if that is a failure of setup.py or distutils of not specifying the flag.



building '_json' extension
/Users/bcannon/Developer/bin/clang -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -Wno-unused-value -Wno-empty-body -Qunused-arguments -Wno-unused-value -Wno-empty-body -Qunused-arguments -I./Include -I. -I/Users/bcannon/Developer/include -I/Users/bcannon/Developer/Cellar/readline/6.2.2/include -I/Users/bcannon/Developer/repo/cpython/py3.3/Include -I/Users/bcannon/Developer/repo/cpython/py3.3 -c /Users/bcannon/Developer/repo/cpython/py3.3/Modules/_json.c -o build/temp.macosx-10.8-x86_64-3.3/Users/bcannon/Developer/repo/cpython/py3.3/Modules/_json.o
/Users/bcannon/Developer/repo/cpython/py3.3/Modules/_json.c:249:12: warning: implicit declaration of function
      '_PyUnicode_CheckConsistency' is invalid in C99 [-Wimplicit-function-declaration]
    assert(_PyUnicode_CheckConsistency(rval, 1));
           ^
/usr/include/assert.h:93:25: note: expanded from macro 'assert'
    (__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __FILE__, __LINE__, #e) : (void)0)
                        ^
1 warning generated.
/Users/bcannon/Developer/bin/clang -bundle -undefined dynamic_lookup -L /Users/bcannon/Developer/lib -L/Users/bcannon/Developer/Cellar/readline/6.2.2/lib -L /Users/bcannon/Developer/lib -L/Users/bcannon/Developer/Cellar/readline/6.2.2/lib -L /Users/bcannon/Developer/lib -L/Users/bcannon/Developer/Cellar/readline/6.2.2/lib -Wno-unused-value -Wno-empty-body -Qunused-arguments -I /Users/bcannon/Developer/include -I/Users/bcannon/Developer/Cellar/readline/6.2.2/include build/temp.macosx-10.8-x86_64-3.3/Users/bcannon/Developer/repo/cpython/py3.3/Modules/_json.o -L/Users/bcannon/Developer/lib -L/Users/bcannon/Developer/Cellar/readline/6.2.2/lib -o build/lib.macosx-10.8-x86_64-3.3/_json.so
*** WARNING: renaming "_json" since importing it failed: dlopen(build/lib.macosx-10.8-x86_64-3.3/_json.so, 2): Symbol not found: __PyUnicode_CheckConsistency
  Referenced from: build/lib.macosx-10.8-x86_64-3.3/_json.so
  Expected in: flat namespace
 in build/lib.macosx-10.8-x86_64-3.3/_json.so

----------
components: Build
keywords: 3.3regression
messages: 173992
nosy: brett.cannon, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: setup.py not compiling with NDEBUG in non-debug builds
type: compile error
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Oct 28 05:06:11 2012
From: report at bugs.python.org (Mariano Reingart)
Date: Sun, 28 Oct 2012 04:06:11 +0000
Subject: [New-bugs-announce] [issue16343] PyUnicode_FromFormatV() doesn't
	support utf-8 text
Message-ID: <1351397171.27.0.117750740634.issue16343@psf.upfronthosting.co.za>


New submission from Mariano Reingart:

Working in an internationalization proposal <http://python.org.ar/pyar/TracebackInternationalizationProposal>
I've stopped at #9769 where multi byte encodings (like utf-8) is not supported by PyUnicode_FromFormatV()

Beside my proposal, I think utf-8 should be supported for consistency with the other unicode functions, like PyUnicode_FromString() or even unicode_fromformat_arg()

Attached is a patch that:
- enhanced the iterator to detect multibyte sequences, with sanity checks about start & continuation bytes
- replaced unicode_write_cstr with PyUnicode_DecodeUTF8Stateful
- tests

Hope it helps, this is my first patch for cpython and my C skills are a bit rusty, so excuse me if there is any newbie glitch

----------
components: Interpreter Core, Unicode
files: pyunicode_fromformat_utf8.patch
keywords: patch
messages: 173996
nosy: ezio.melotti, reingart
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormatV() doesn't support utf-8 text
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27755/pyunicode_fromformat_utf8.patch

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

From report at bugs.python.org  Sun Oct 28 07:57:37 2012
From: report at bugs.python.org (Mariano Reingart)
Date: Sun, 28 Oct 2012 06:57:37 +0000
Subject: [New-bugs-announce] [issue16344] Traceback Internationalization
	Proposal
Message-ID: <1351407457.67.0.14897287706.issue16344@psf.upfronthosting.co.za>


New submission from Mariano Reingart:

I'm opening this ticket to organize patches for a proposal of a GETTEXT-based message translation for exception/tracebacks as described in:

<http://python.org.ar/pyar/TracebackInternationalizationProposal>

This requires the patch in issue #16343

Attached is a patch for a proof of concept, it includes:

- pyi18n.h: header for Py_GETTEXT macro definition
- Locale/es.po: sample Spanish language messages translation file
- test_i18n.py: basic tests
- errors.c: patched PyErr_SetString(), PyErr_Format()
- traceback.c: patched tb_displayline(), PyTraceBack_Print()
- pythonrun.c: patched _Py_InitializeEx_Private()
- site.py: patched main() and added seti18n()

----------
components: Interpreter Core, Unicode
files: traceback_internationalization_proposal.patch
keywords: patch
messages: 173998
nosy: ezio.melotti, reingart
priority: normal
severity: normal
status: open
title: Traceback Internationalization Proposal
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27756/traceback_internationalization_proposal.patch

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

From report at bugs.python.org  Sun Oct 28 09:04:26 2012
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 28 Oct 2012 08:04:26 +0000
Subject: [New-bugs-announce] [issue16345] dict.fromkeys() assumes 'self' is
	empty
Message-ID: <1351411466.77.0.264436866601.issue16345@psf.upfronthosting.co.za>


New submission from Armin Rigo:

The implementation of dict.fromkeys() assumes that the new dictionary is empty.  That's not the case if we tweak __new__.  Attached example shows 'dictresize(mp, 0)' being called with 'mp' being dictionary of 10 items.  This causes an infinite uninterruptible loop.

----------
components: Interpreter Core
files: x.py
messages: 174009
nosy: arigo
priority: normal
severity: normal
status: open
title: dict.fromkeys() assumes 'self' is empty
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27758/x.py

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

From report at bugs.python.org  Sun Oct 28 09:48:55 2012
From: report at bugs.python.org (Mathieu Dutour Sikiric)
Date: Sun, 28 Oct 2012 08:48:55 +0000
Subject: [New-bugs-announce] [issue16346] readline problem
Message-ID: <1351414135.83.0.205698336567.issue16346@psf.upfronthosting.co.za>


New submission from Mathieu Dutour Sikiric:

Dear all,

I tried to install Python 2.7.3 in a home directory for simplicity. On the Ubuntu platform that I had, the readline-dev was not installed.
So, I I tried to install the readline package either by "pip install readline" or "python setup.py install" and what I got was following behavior:
------------------------------------------------------------------
.
.
.
  File "/home/dutour/opt/Python-2.7.3/lib/python2.7/distutils/dist.py", line 1118, in write_pkg_file

    self._write_field(file, 'Metadata-Version', version)

  File "/home/dutour/opt/Python-2.7.3/lib/python2.7/distutils/dist.py", line 1145, in _write_field

    file.write('%s: %s\n' % (name, self._encode_field(value)))

  File "/home/dutour/opt/Python-2.7.3/lib/python2.7/distutils/dist.py", line 1154, in _encode_field

    if isinstance(value, unicode):

RuntimeError: maximum recursion depth exceeded while calling a Python object
----------------------------------------------------------------------
So, the install went into an infinite loop and crashed.
Instead the correct error message that should have been shown at some point is missing .h file.

I am a beginner on Python, I asked on help at python.org and Matthew Dixon Cowles indicated me that I should report the problem here.

----------
components: Build
messages: 174012
nosy: mathieu37
priority: normal
severity: normal
status: open
title: readline problem
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 28 11:52:33 2012
From: report at bugs.python.org (Antonio Cavallo)
Date: Sun, 28 Oct 2012 10:52:33 +0000
Subject: [New-bugs-announce] [issue16347] configure.ac patch
Message-ID: <1351421553.76.0.859904155942.issue16347@psf.upfronthosting.co.za>


New submission from Antonio Cavallo:

I've noticed that linux distros have a set of patch to fix a hardcoded lib in their makefiles:

eg. Makefile.pre.in:
....
INCLUDEDIR=?@includedir@
CONFINCLUDEDIR=?$(exec_prefix)/include
SCRIPTDIR=??$(prefix)/lib        <== HARDCODED


This is due to the fact on the 64 bit they split lib and lib64 directories.

I understand that removing such hardcoded values will be a very long task (multiple places where lib is hardcoded). 

To make it into incremental steps I think a good idea would be to introduce two simple modification into the configure.ac script: they are transparent (eg. won't affect in anyway the current code) but will provide the base infrastructure to build upon.

Please find patch attached (mercurial ref 3fb84c1da8c5 / 79960)

I'm using a build infrastructure for testing the whole patch set (I've applied them in full in the past) at https://build.opensuse.org/project/packages?project=home%3Acavallo71%3Aopt-python-interpreters.
This tracks 2.7 but the patches should be easily ported in 3.x as well.

I hope this helps,
Antonio

PS. Would be possible to remove "tabs" from cofigure.ac?

----------
components: Build, Cross-Build
files: autoconfigure.dif
messages: 174028
nosy: cavallo71, doko, georg.brandl, larry, skrah, trent
priority: normal
severity: normal
status: open
title: configure.ac patch
versions: Python 2.7
Added file: http://bugs.python.org/file27762/autoconfigure.dif

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

From report at bugs.python.org  Sun Oct 28 13:20:53 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Oct 2012 12:20:53 +0000
Subject: [New-bugs-announce] [issue16348] Decimal.remainder_near
	documentation incorrect.
Message-ID: <1351426853.23.0.197083736305.issue16348@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

The documentation for Decimal.remainder_near is incorrect.  It states:

"If both are equally close, the one chosen will have the same sign as self."

That's incorrect:  instead, the chosen remainder has the property that it makes the corresponding quotient even rather than odd.  E.g.,

>>> Decimal(25).remainder_near(Decimal(10))
Decimal('5')
>>> Decimal(35).remainder_near(Decimal(10))
Decimal('-5')

----------
assignee: docs at python
components: Documentation
messages: 174039
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Decimal.remainder_near documentation incorrect.
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Oct 28 13:43:42 2012
From: report at bugs.python.org (Thomas Kluyver)
Date: Sun, 28 Oct 2012 12:43:42 +0000
Subject: [New-bugs-announce] [issue16349] Document whether it's safe to use
	bytes for struct	format string
Message-ID: <1351428222.6.0.656645524198.issue16349@psf.upfronthosting.co.za>


New submission from Thomas Kluyver:

At least in CPython, format strings can be given as bytes, as an alternative to str. E.g.

>>> struct.unpack(b'>hhl', b'\x00\x01\x00\x02\x00\x00\x00\x03')
(1, 2, 3)

Looking at the source code [1], this appears to be consciously accounted for. But it doesn't seem to be mentioned in the documentation. I think the docs should either say it's a possibility, or warn that it's an implementation detail.

[1] http://hg.python.org/cpython/file/cde4b66699fe/Modules/_struct.c#l1340

----------
components: Library (Lib)
messages: 174042
nosy: takluyver
priority: normal
severity: normal
status: open
title: Document whether it's safe to use bytes for struct format string

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

From report at bugs.python.org  Sun Oct 28 17:25:19 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 28 Oct 2012 16:25:19 +0000
Subject: [New-bugs-announce] [issue16350] zlib.Decompress.decompress() after
	EOF discards existing	value of unused_data
Message-ID: <1351441519.18.0.51487757055.issue16350@psf.upfronthosting.co.za>


New submission from Nadeem Vawda:

>From issue 5210:

amaury.forgeotdarc wrote:
> Hm, I tried a modified version of your first test, and I found another
> problem with the current zlib library;
> starting with the input:
> x = x1 + x2 + HAMLET_SCENE    # both compressed and uncompressed data
>
> The following scenario is OK:
> dco.decompress(x) # returns HAMLET_SCENE
> dco.unused_data   # returns HAMLET_SCENE
>
> But this one:
> for c in x:
>     dco.decompress(x) # will return HAMLET_SCENE, in several pieces
> dco.unused_data   # only one character, the last of (c in x)!
>
> This is a bug IMO: unused_data should accumulate all the extra uncompressed 
> data.

Ideally, I would prefer to raise an EOFError if decompress() is called
after end-of-stream is reached (for consistency with BZ2Decompressor).
However, accumulating the data in unused_data is closer to being backward-
compatible, so it's probably the better approach to take.

----------
components: Library (Lib)
files: zlib_unused_data_test.py
messages: 174056
nosy: amaury.forgeotdarc, nadeem.vawda
priority: normal
severity: normal
stage: needs patch
status: open
title: zlib.Decompress.decompress() after EOF discards existing value of unused_data
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27767/zlib_unused_data_test.py

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

From report at bugs.python.org  Sun Oct 28 18:30:20 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 28 Oct 2012 17:30:20 +0000
Subject: [New-bugs-announce] [issue16351] Add a function to get GC statistics
Message-ID: <1351445420.88.0.605881847233.issue16351@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This patch adds a function named gc.get_stats() which returns a list of dictionaries containing per-generation statistics:

>>> import pprint, gc
>>> pprint.pprint(gc.get_stats())
[{'collected': 0, 'collections': 12, 'uncollectable': 0},
 {'collected': 0, 'collections': 1, 'uncollectable': 0},
 {'collected': 0, 'collections': 0, 'uncollectable': 0}]

----------
components: Library (Lib)
files: gc_get_stats.patch
keywords: patch
messages: 174060
nosy: benjamin.peterson, gregory.p.smith, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Add a function to get GC statistics
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27768/gc_get_stats.patch

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

From report at bugs.python.org  Mon Oct 29 00:18:19 2012
From: report at bugs.python.org (James Lu)
Date: Sun, 28 Oct 2012 23:18:19 +0000
Subject: [New-bugs-announce] [issue16352] Error call
Message-ID: <1351466299.78.0.336914696558.issue16352@psf.upfronthosting.co.za>


New submission from James Lu:

>>>x="y"
>>>y=x
>>>x=y
>>>print x
x
>>>print y
x
It should raise a RuntimeError

----------
components: None
messages: 174086
nosy: James.Lu
priority: normal
severity: normal
status: open
title: Error call
type: performance
versions: Python 2.6

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

From report at bugs.python.org  Mon Oct 29 02:19:20 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 29 Oct 2012 01:19:20 +0000
Subject: [New-bugs-announce] [issue16353] add function to os module for
	getting path to default	shell
Message-ID: <1351473560.4.0.147895276383.issue16353@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to add a function to the os module for getting the path to the default shell (e.g. os.getdefaultshell()).

In issue 16255, it was reported that on Android, the path to the default shell is "/system/bin/sh" rather than "/bin/sh" which it is on other Unix systems.

Such a function in the os module would implement the necessary detection logic which could then be used, for example, by the subprocess module when invoking Popen() with shell=True (e.g. for issue 16255).

----------
components: Library (Lib)
messages: 174093
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: add function to os module for getting path to default shell
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 29 11:16:07 2012
From: report at bugs.python.org (Wichert Akkerman)
Date: Mon, 29 Oct 2012 10:16:07 +0000
Subject: [New-bugs-announce] [issue16354] Remember python version choice on
	docs.python.org
Message-ID: <1351505767.0.0.302833012175.issue16354@psf.upfronthosting.co.za>


New submission from Wichert Akkerman:

docs.python.org was recently change to redirect http://docs.python.org/ to http://docs.python.org/3/ , with an option to switch to documentation for a different version using both (why two ways?) a dropdown and links in the left column. Would it be possible to remember the selection and honour that in the docs.python.org redirect? That would remove the minor annoyance of always ending up at the Python 3 documentation and having to switch back to 2.7.

----------
assignee: docs at python
components: Documentation
messages: 174106
nosy: docs at python, wichert
priority: normal
severity: normal
status: open
title: Remember python version choice on docs.python.org

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

From report at bugs.python.org  Mon Oct 29 12:58:50 2012
From: report at bugs.python.org (Marco Buttu)
Date: Mon, 29 Oct 2012 11:58:50 +0000
Subject: [New-bugs-announce] [issue16355] inspect.getcomments() does not
	work in the interactive	shell
Message-ID: <1351511930.82.0.59071323276.issue16355@psf.upfronthosting.co.za>


New submission from Marco Buttu:

The documentation for `inspect.getcomments()` says that it returns 
the "lines of comments immediately preceding an object's source code".
It works fine for the comments that immediately preceded an object 
defined in a module:

$ more foo.py 
import inspect
# A dummy comment
def foo():
    pass

print(inspect.getcomments(foo))
$ python3.3 foo.py 
# A dummy comment

But it does not work if we define an object interactively:

$ python3.3
Python 3.3.0 (default, Oct  9 2012, 18:20:32) 
[GCC 4.5.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import inspect
>>> # A dummy comment
... def foo():
...     pass
... 
>>> inspect.getcomments(foo)
>>> # A dummy comment
... 
>>> def foo():
...     pass
... 
>>> inspect.getcomments(foo)
>>>

----------
components: Library (Lib)
messages: 174108
nosy: marco.buttu
priority: normal
severity: normal
status: open
title: inspect.getcomments() does not work in the interactive shell
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Oct 29 15:21:13 2012
From: report at bugs.python.org (Richard Delorenzi)
Date: Mon, 29 Oct 2012 14:21:13 +0000
Subject: [New-bugs-announce] [issue16356] cjson dose not decode \/ properly
Message-ID: <1351520473.63.0.0215534885564.issue16356@psf.upfronthosting.co.za>


New submission from Richard Delorenzi:

This code produces the wrong result

import cjson
cjson.decode(cjson.encode('/'))

It produces '\\/', it should produce '/'

using
/usr/lib/pymodules/python2.7/cjson.so
cjson version 1.0.5-4build1

----------
components: None
messages: 174114
nosy: Richard.Delorenzi
priority: normal
severity: normal
status: open
title: cjson dose not decode \/ properly
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Oct 29 16:53:59 2012
From: report at bugs.python.org (Jeff McNeil)
Date: Mon, 29 Oct 2012 15:53:59 +0000
Subject: [New-bugs-announce] [issue16357] SSLSocket created from
	SSLContext.wrap_socket doesn't	include cert/keyfile
Message-ID: <1351526039.51.0.105215109749.issue16357@psf.upfronthosting.co.za>


New submission from Jeff McNeil:

mcjeff at martian:~/cpython$ ./python -V
Python 3.4.0a0

When an SSLSocket is created via SSLContext.wrap_socket, it is passed a _context parameter directly.  SSLSocket.__init__ sets self.context at this point, but it does not set self.keyfile or self.certfile.

However, in SSLSocket.accept, both keyfile & certfile are passed when creating a new, wrapped SSLSocket, from socket.accept's newsock.

The result is an attribute error.
>>> import ssl
>>> c = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
>>> c.load_cert_chain('Lib/test/keycert.pem')        
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
>>> s.bind(('127.0.0.1', 5050))
>>> s.listen(5)
>>> s.accept()  # nc localhost 5050 in another term.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/google/home/mcjeff/cpython/Lib/ssl.py", line 557, in accept
    keyfile=self.keyfile, certfile=self.certfile,
AttributeError: 'SSLSocket' object has no attribute 'keyfile'
>>> 

Attached one-liner addresses it by passing in the context rather than the keyfile & certfile.

>>> s.accept()
(<socket.socket object, fd=4, family=2, type=1, proto=0>, ('127.0.0.1', 37306))
>>>

----------
components: Library (Lib)
files: ssl_context.patch
keywords: patch
messages: 174121
nosy: mcjeff
priority: normal
severity: normal
status: open
title: SSLSocket created from SSLContext.wrap_socket doesn't include cert/keyfile
versions: Python 3.4
Added file: http://bugs.python.org/file27776/ssl_context.patch

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

From report at bugs.python.org  Mon Oct 29 17:20:11 2012
From: report at bugs.python.org (Elwyn Davies)
Date: Mon, 29 Oct 2012 16:20:11 +0000
Subject: [New-bugs-announce] [issue16358] Enhancement for mmap_read:
	Consistency with standard	file read
Message-ID: <1351527611.16.0.402353331604.issue16358@psf.upfronthosting.co.za>


New submission from Elwyn Davies:

Enhancement requested for module mmap:
Alter the interface of mmap.read from
mmap.read(num)
to
mmap.read([num])
reading the whole file if no argument provided.

The read function in the mmap module (Modules/mmapmodule.c) *requires* an argument whereas for the standard file read function the argument is optional and the function reads the remainder of the file if absent.

The mmap module knows how big the file is, so it should be no problem to internally use the remaining length if no argument is supplied.  

This would avoid having to write (for example)
f = mmap.mmap(file_desc, file_size)
b = f.read(file_size)
j = json.loads(b)

instead of
f = mmap.mmap(file_desc, file_size)
j = json.load(f)

----------
components: Library (Lib)
messages: 174123
nosy: elwynd
priority: normal
severity: normal
status: open
title: Enhancement for mmap_read: Consistency with standard file read
type: enhancement
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/issue16358>
_______________________________________

From report at bugs.python.org  Mon Oct 29 17:28:41 2012
From: report at bugs.python.org (jose gregorio fernandez trincado)
Date: Mon, 29 Oct 2012 16:28:41 +0000
Subject: [New-bugs-announce] [issue16359] can't print figures 08 and 09
Message-ID: <1351528121.94.0.0812523965219.issue16359@psf.upfronthosting.co.za>


New submission from jose gregorio fernandez trincado:

In [2]: 09
  File "<ipython-input-2-7010843e6b42>", line 1
    09
     ^
SyntaxError: invalid token

Using str() produce SyntaxError too. The same for 08. Figures like 01 and 02 produce the appropriate output.

Hardware: Lenovo 3000 N200, 80Gb of HD, 4Gb of RAM, Core-Duo 2.6GHz
OS: Ubuntu 12.04, 64bits.

----------
components: None
messages: 174126
nosy: jose.gregorio.fernandez.trincado
priority: normal
severity: normal
status: open
title: can't print figures 08 and 09
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Oct 29 17:49:08 2012
From: report at bugs.python.org (Ben Gamari)
Date: Mon, 29 Oct 2012 16:49:08 +0000
Subject: [New-bugs-announce] [issue16360] argparse: comma in metavar causes
	assertion failure when	formatting long usage message
Message-ID: <1351529348.85.0.0475227022594.issue16360@psf.upfronthosting.co.za>


New submission from Ben Gamari:

argparse suffers from a failing assertion when formatting a long usage message with an option whose metavar contains a comma. This can be seen in the attached testcase, which fails with,

Traceback (most recent call last):
  File "/home/ben/hi.py", line 24, in <module>
    args = parser.parse_args()
  File "/usr/lib/python2.7/argparse.py", line 1688, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib/python2.7/argparse.py", line 1720, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib/python2.7/argparse.py", line 1937, in _parse_known_args
    self.error(_('too few arguments'))
  File "/usr/lib/python2.7/argparse.py", line 2360, in error
    self.print_usage(_sys.stderr)
  File "/usr/lib/python2.7/argparse.py", line 2322, in print_usage
    self._print_message(self.format_usage(), file)
  File "/usr/lib/python2.7/argparse.py", line 2278, in format_usage
    return formatter.format_help()
  File "/usr/lib/python2.7/argparse.py", line 279, in format_help
    help = self._root_section.format_help()
  File "/usr/lib/python2.7/argparse.py", line 209, in format_help
    func(*args)
  File "/usr/lib/python2.7/argparse.py", line 330, in _format_usage
    assert ' '.join(opt_parts) == opt_usage
AssertionError

This failure is apparently due to a regular expression used to wrap  the usage message. The solution to this is unclear, but it seems to me using a regular expression here is a hack at best.

----------
components: Library (Lib)
files: hi.py
messages: 174130
nosy: bgamari
priority: normal
severity: normal
status: open
title: argparse: comma in metavar causes assertion failure when formatting long usage message
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file27778/hi.py

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

From report at bugs.python.org  Mon Oct 29 23:52:02 2012
From: report at bugs.python.org (Phil)
Date: Mon, 29 Oct 2012 22:52:02 +0000
Subject: [New-bugs-announce] [issue16361] HTTPS/TLS Problem in Python 3.3
Message-ID: <1351551122.11.0.0678496091034.issue16361@psf.upfronthosting.co.za>


New submission from Phil:

I had converted some code for a scraper from 2.7.3 to 3.3.0 on Windows 7 and suddenly the code stopped working.  Now the https fetch results in:
Traceback (most recent call last):
  File "D:\Users\Phil\Desktop\demo.py", line 67, in <module>
    page=getWebData()
  File "D:\Users\Phil\Desktop\demo.py", line 59, in getWebData
    response=urllib.request.urlopen(req, cadefault=False)
  File "D:\Program Files\Python33\lib\urllib\request.py", line 160, in urlopen
    return opener.open(url, data, timeout)
  File "D:\Program Files\Python33\lib\urllib\request.py", line 473, in open
    response = self._open(req, data)
  File "D:\Program Files\Python33\lib\urllib\request.py", line 491, in _open
    '_open', req)
  File "D:\Program Files\Python33\lib\urllib\request.py", line 451, in _call_chain
    result = func(*args)
  File "D:\Program Files\Python33\lib\urllib\request.py", line 1287, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "D:\Program Files\Python33\lib\urllib\request.py", line 1255, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [WinError 10054] An existing connection was forcibly closed by the remote host>
 
I have run Wireshark using Python 2.7.3 and Python 3.3.0 (see attached files)

----------
components: Library (Lib)
files: demo.py
messages: 174158
nosy: pventura
priority: normal
severity: normal
status: open
title: HTTPS/TLS Problem in Python 3.3
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file27785/demo.py

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

From report at bugs.python.org  Tue Oct 30 08:07:29 2012
From: report at bugs.python.org (Simon Blanchard)
Date: Tue, 30 Oct 2012 07:07:29 +0000
Subject: [New-bugs-announce] [issue16362] _LegalCharsPatt in cookies.py
	includes illegal characters
Message-ID: <1351580849.36.0.343039143633.issue16362@psf.upfronthosting.co.za>


New submission from Simon Blanchard:

_LegalCharsPatt  = r"[\w\d!#%&'~_`><@,:/\$\*\+\-\.\^\|\)\(\?\}\{\=]"

The above regex in cookies.py includes the the comma character but RFC 6265 https://tools.ietf.org/html/rfc6265 section 4.1.1 says:

 cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                       ; US-ASCII characters excluding CTLs,
                       ; whitespace DQUOTE, comma, semicolon,
                       ; and backslash

That is, no comma.

----------
components: Library (Lib)
messages: 174183
nosy: Simon.Blanchard
priority: normal
severity: normal
status: open
title: _LegalCharsPatt in cookies.py includes illegal characters
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Oct 30 09:07:59 2012
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Tue, 30 Oct 2012 08:07:59 +0000
Subject: [New-bugs-announce] [issue16363] super cannot invoke descriptors
Message-ID: <1351584479.14.0.539937815992.issue16363@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt:

this means its much harder to have a mixin to change the behaviour of a property

instead of super(Mixin, self).prop = foo

the code is super(Mixin, type(self)).prop.__set__(self, foo)
which is way harder to understand

the attached file demonstrates the problem and has a proof of concept for an extended super allowing descriptor invocations

----------
components: Interpreter Core
files: test_super.py
messages: 174184
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: super cannot invoke descriptors
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file27792/test_super.py

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

From report at bugs.python.org  Tue Oct 30 13:10:57 2012
From: report at bugs.python.org (jamesf)
Date: Tue, 30 Oct 2012 12:10:57 +0000
Subject: [New-bugs-announce] [issue16364] datetime.strftime and
	locale.getdefaultlocale conflict	on Windows ?
Message-ID: <1351599057.52.0.790355581015.issue16364@psf.upfronthosting.co.za>


New submission from jamesf:

on windows(windows 7), python 2.7.3 compiled with VS 2008 and code page "cp936".

locale.getdefaultlocale call Win32 API GetACP and return "cp936",
but a small test program return "C" from 'getlocale' CRT function.
I am not sure if this behaviour is expected or bug?

It seems that datetime.strftime call the CRT function strftime to
do the real work, since the CRT locale is C, it use that to format
locale dependent directive like "%B" and "%x"; 
But since locale.getdefaultlocale return "cp936", so i expect
datetime.strftime to return locale formatted string.

----------
components: Library (Lib)
messages: 174203
nosy: jwfang
priority: normal
severity: normal
status: open
title: datetime.strftime and locale.getdefaultlocale conflict on Windows ?
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct 30 20:21:39 2012
From: report at bugs.python.org (Abhijeet Joshi)
Date: Tue, 30 Oct 2012 19:21:39 +0000
Subject: [New-bugs-announce] [issue16365] IDLE for Windows 8
Message-ID: <1351624899.92.0.657222579655.issue16365@psf.upfronthosting.co.za>


New submission from Abhijeet Joshi:

Hello,

I have installed Idle for python 3.3 on windows 8 and trying to open the GUI but unable to open anything.
The screen doesn't show up on monitor.

Please help me here.

Thanks
Abhijeet

----------
components: IDLE
messages: 174217
nosy: jabhijeet
priority: normal
severity: normal
status: open
title: IDLE for Windows 8
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Oct 30 21:00:29 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Oct 2012 20:00:29 +0000
Subject: [New-bugs-announce] [issue16366] _handleError not very informative
Message-ID: <1351627229.78.0.21301171659.issue16366@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

logging's _handleError will tell you in which code line the error happened, but it's not very useful when application code has its own logging wrappers. You need more of the stack to get useful information. The attached script showcases this, along with a possible solution.

----------
components: Library (Lib)
files: log.py
messages: 174222
nosy: pitrou, vinay.sajip
priority: normal
severity: normal
status: open
title: _handleError not very informative
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27799/log.py

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

From report at bugs.python.org  Wed Oct 31 00:43:07 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Oct 2012 23:43:07 +0000
Subject: [New-bugs-announce] [issue16367] io.FileIO.readall() is not 64-bit
	safe on Windows
Message-ID: <1351640587.41.0.234658150745.issue16367@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The changeset 374dc910db33 fixed FileIO.readinto(), FileIO.write() and os.write() on Windows for issues #9015, #9611, but FileIO.readall() was not fixed and it has a similar bug.

It uses "int n;" to store the result of read(), so FileIO.readall() may also fail to read a file longer than 2 GB on other platforms.

Attached patch should fix both issues.

----------
components: Library (Lib)
files: fileio_readall.patch
keywords: patch
messages: 174244
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: io.FileIO.readall() is not 64-bit safe on Windows
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27802/fileio_readall.patch

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

From report at bugs.python.org  Wed Oct 31 01:09:13 2012
From: report at bugs.python.org (Tom Kuiper)
Date: Wed, 31 Oct 2012 00:09:13 +0000
Subject: [New-bugs-announce] [issue16368] error when logging message
Message-ID: <1351642153.65.0.00343224829929.issue16368@psf.upfronthosting.co.za>


New submission from Tom Kuiper:

This error comes from the logging module when a message is logged, but only when I also import another module which does use logging at all:

Traceback (most recent call last):
  File "/usr/lib/python2.6/logging/__init__.py", line 776, in emit
    msg = self.format(record)
  File "/usr/lib/python2.6/logging/__init__.py", line 654, in format
    return fmt.format(record)
  File "/usr/lib/python2.6/logging/__init__.py", line 437, in format
    if string.find(self._fmt,"%(asctime)") >= 0:
  File "/usr/lib/python2.6/string.py", line 361, in find
    return s.find(*args)
AttributeError: 'int' object has no attribute 'find'

The module source is attached.  Some of it's submodules were built with f2py.

----------
components: Library (Lib)
files: __init__.py
messages: 174247
nosy: kuiper
priority: normal
severity: normal
status: open
title: error when logging message
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file27803/__init__.py

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

From report at bugs.python.org  Wed Oct 31 02:49:25 2012
From: report at bugs.python.org (Bradley Froehle)
Date: Wed, 31 Oct 2012 01:49:25 +0000
Subject: [New-bugs-announce] [issue16369] Global PyTypeObjects not
	initialized with	PyType_Ready(...)
Message-ID: <1351648165.77.0.167977661694.issue16369@psf.upfronthosting.co.za>


New submission from Bradley Froehle:

In Python 3.3.0, several global `PyTypeObject`s are not initialized using PyType_Ready(...).

The list of uninitialized type objects::

  PyCapsule_Type
  PyLongRangeIter_Type
  PyFieldNameIter_Type
  PyFormatterIter_Type
  PySTEntry_Type
  PyCell_Type
  PyInstanceMethod_Type
  PyClassMethodDescr_Type
  PyMethodDescr_Type
  PyCallIter_Type
  PySeqIter_Type
  PyDictDummy_Type

Each of these can be verified using gdb::

  $ gdb -quiet python3.3
  Reading symbols from /opt/python/3.3.0/bin/python3.3...done.
  (gdb) break Py_Finalize
  Breakpoint 1 at 0x4a40a0: file Python/pythonrun.c, line 478.
  (gdb) run -c "pass"
  Starting program: /opt/python/3.3.0/bin/python3.3 -c "pass"
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

  Breakpoint 1, Py_Finalize () at Python/pythonrun.c:478
  478	    if (!initialized)
  (gdb) print PyCell_Type->tp_mro
  $1 = (PyObject *) 0x0

(The list of uninitialized types was built by searching "info variables" in gdb to produce a list of PyTypeObjects. Those with <name>->tp_mro != NULL were treated as properly initialized. The remainder were further inspected by hand to throw out additional false positives, like those from modules which had been statically compiled into the Python binary).

I'm not sure if any of these actually need fixing, but for PyCell_Type this issue already resulted in one obscure bug: #16268.

----------
components: Interpreter Core
messages: 174255
nosy: bfroehle
priority: normal
severity: normal
status: open
title: Global PyTypeObjects not initialized with PyType_Ready(...)
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Oct 31 11:50:51 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 31 Oct 2012 10:50:51 +0000
Subject: [New-bugs-announce] [issue16370] Regarding embedding Python in
	Another Application
Message-ID: <1351680651.66.0.846831134298.issue16370@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

On Fri, Oct 26, 2012 at 12:02 AM, Tom Epperly <epperly2 at llnl.gov> wrote:
Regarding this section, http://docs.python.org/extending/embedding.html#very-high-level-embedding, according to http://docs.python.org/c-api/init.html Py_SetProgramName() should be called before Py_Initialize() (see the comment for Py_SetProgramName()). This matters for the particular case of Mac OS X (see http://mail.python.org/pipermail/pythonmac-sig/2012-October/023746.html).

I recommend adding a Py_SetProgramName() to the example.

Regards,

Tom Epperly

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 174269
nosy: asvetlov, docs at python
priority: normal
severity: normal
status: open
title: Regarding embedding Python in Another Application
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Oct 31 15:02:16 2012
From: report at bugs.python.org (George Yoshida)
Date: Wed, 31 Oct 2012 14:02:16 +0000
Subject: [New-bugs-announce] [issue16371] typo in ctypes
Message-ID: <1351692136.49.6.31679171602e-05.issue16371@psf.upfronthosting.co.za>


New submission from George Yoshida:

In the following sentence:

http://docs.python.org/3.3/library/ctypes.html
> 16.17.1.19. Surprises
> There are some edges in ctypes where you may be expect something else than what actually happens.

"you may be expect" should read "you may expect"

----------
assignee: docs at python
components: Documentation
messages: 174276
nosy: docs at python, quiver
priority: low
severity: normal
status: open
title: typo in ctypes

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

From report at bugs.python.org  Wed Oct 31 15:18:19 2012
From: report at bugs.python.org (Wojciech Danilo)
Date: Wed, 31 Oct 2012 14:18:19 +0000
Subject: [New-bugs-announce] [issue16372] Initialization strange behavior
Message-ID: <1351693099.3.0.330906676323.issue16372@psf.upfronthosting.co.za>


New submission from Wojciech Danilo:

Hi!
I'm using Python for several years and now I'm writing in Python 3 for the first time. I think I found a strange bug in it. Lets concider the code in the attachement.
In the 33 line there is construction of new instance of class Result:
print('!!!',Result().value)
what is strange, the class is defined as:
class Result:
    def __init__(self, value=[], start=0, end=0):
        self.value = value
        ...

and what I get as a result is:
"!!! ['a', 'b']"

Where the array was somehow magically stored from previous initialization (take a look at the code for full listing).

----------
components: Interpreter Core
files: test.py
messages: 174280
nosy: wdanilo
priority: normal
severity: normal
status: open
title: Initialization strange behavior
versions: Python 3.3
Added file: http://bugs.python.org/file27809/test.py

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

From report at bugs.python.org  Wed Oct 31 15:33:20 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 31 Oct 2012 14:33:20 +0000
Subject: [New-bugs-announce] [issue16373] Recursion error comparing set()
	and MutableMapping.keys()
Message-ID: <1351694000.44.0.179883669733.issue16373@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Try these in 3.3 (or Python 3.2 for the latter):

    set() < collections.ChainMap().keys()
    set() < collections.UserDict().keys()

Both fail with max recursion depth exceeded.

Given that both exhibit this behaviour, the core of the problem is quite possibly in MutableMapping.

(Uncovered while attempting to find a tidier ChainMap-based way to implement __subclasshook__ checks for ducktyping based on multiple methods)

----------
messages: 174286
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Recursion error comparing set() and MutableMapping.keys()
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Oct 31 16:01:50 2012
From: report at bugs.python.org (Daniel Gordon)
Date: Wed, 31 Oct 2012 15:01:50 +0000
Subject: [New-bugs-announce] [issue16374] ConfigParser: Passing a semicolon
	as a value
Message-ID: <1351695710.99.0.421343064251.issue16374@psf.upfronthosting.co.za>


New submission from Daniel Gordon:

I have a configuration file containing a key and value:
delimiter=;

Using ConfigParser,
the resulting value of the key delimiter is empty.
Expected behavior should be a semicolon as the value.

This behavior occurred on Linux (Ubuntu 12.04) but not on Windows 7.

----------
components: Library (Lib)
messages: 174288
nosy: Daniel.Gordon
priority: normal
severity: normal
status: open
title: ConfigParser: Passing a semicolon as a value
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 31 16:25:42 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 31 Oct 2012 15:25:42 +0000
Subject: [New-bugs-announce] [issue16375] Warning in Parser/grammar1.c
Message-ID: <1351697142.55.0.339745885879.issue16375@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The changeset 7e0e15d9957f causes annoying GCC warning in Parser/grammar1.c.

Possible solutions:

1. Revert this changes back.
2. Prohibit this type of warnings by the compiler flags.
3. Explicitly cast _PyParser_TokenNames to "char *" in PyGrammar_LabelRepr().
4. Make PyGrammar_LabelRepr() returns "const char *".

----------
components: Interpreter Core
messages: 174292
nosy: benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Warning in Parser/grammar1.c
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 31 18:02:55 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 31 Oct 2012 17:02:55 +0000
Subject: [New-bugs-announce] [issue16376] wrong type for wintypes.BYTE
Message-ID: <1351702975.6.0.783969996516.issue16376@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Windows BYTE type is unsigned char, but ctypes defines it as signed.

{{{
BYTE	
A byte (8 bits).
This type is declared in WinDef.h as follows:
typedef unsigned char BYTE;
typedef unsigned char BYTE;
}}}
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx

http://hg.python.org/cpython/file/e5f39546989f/Lib/ctypes/wintypes.py#l4

----------
components: ctypes
messages: 174331
nosy: techtonik
priority: normal
severity: normal
status: open
title: wrong type for wintypes.BYTE
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Oct 31 21:31:30 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 31 Oct 2012 20:31:30 +0000
Subject: [New-bugs-announce] [issue16377] Fix bisect unittest
Message-ID: <1351715490.4.0.45923656466.issue16377@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

TestInsort.test_vsBuiltinSort is a bit broken, as it doesn't test insorting `list` objects.

Patch attached.

----------
files: test_bisect.patch
keywords: patch
messages: 174365
nosy: christian.heimes, georg.brandl, rhettinger, yselivanov
priority: normal
severity: normal
status: open
title: Fix bisect unittest
versions: Python 3.3
Added file: http://bugs.python.org/file27816/test_bisect.patch

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