From report at bugs.python.org  Sun Dec  1 10:57:54 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 01 Dec 2013 09:57:54 +0000
Subject: [New-bugs-announce] [issue19848] Misleading error on creating
	already existed symlink
Message-ID: <1385891874.14.0.756593701822.issue19848@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Steps to reproduce the bug:
1. Download cute cat picture from internet. Name it CuteCat.jpg.

>>> import os
>>> os.listdir('.')
['CuteCat.jpg']

2. Create symbolic link.

>>> os.symlink('CuteCat.jpg', 'Aaawww.lnk')
>>> os.listdir('.')
['Aaawww.lnk', 'CuteCat.jpg']

3. Do it again.

>>> os.symlink('CuteCat.jpg', 'Aaawww.lnk')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FileExistsError: [Errno 17] File exists: 'CuteCat.jpg'

Amusingly, it only happens on 3.4 (both Windows and Linux). 3.3 gives correct error message (in Linux, I did not test it on Windows). 2.7 omits the file information (in Linux, I did not test it on Windows). I'll check again the behaviour on Windows for 2.7 and 3.3.

Do we need unit test for this? Will we change the error message again in the future? For now, I omit it. Let me know if we need unit test.

----------
components: Extension Modules, Windows
files: fix_error_message_on_creating_already_existed_symbolic_link.patch
keywords: patch
messages: 204899
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Misleading error on creating already existed symlink
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32920/fix_error_message_on_creating_already_existed_symbolic_link.patch

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

From report at bugs.python.org  Sun Dec  1 12:37:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 11:37:42 +0000
Subject: [New-bugs-announce] [issue19849] selectors behaviour on EINTR
	undocumented
Message-ID: <1385897862.95.0.970282300769.issue19849@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Selector.Select() may return an empty list when interrupted, but the doc doesn't say so. The reader will probably trust the statement that """If timeout is None, the call will block until a monitored file object becomes ready""".

----------
assignee: docs at python
components: Documentation
messages: 204914
nosy: docs at python, neologix, pitrou
priority: normal
severity: normal
status: open
title: selectors behaviour on EINTR undocumented
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec  1 13:09:15 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 12:09:15 +0000
Subject: [New-bugs-announce] [issue19850] asyncio: limit EINTR occurrences
	with SA_RESTART
Message-ID: <1385899755.41.0.415738852454.issue19850@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

asyncio makes heavy use of SIGCHLD for subprocesses.
A consequence of this if that a lot of syscalls can fail with EINTR (see e.g. issue #18885).

The attached patch uses SA_RESTART (through signal.siginterrupt()) to limit EINTR occurrences, e.g. :
"""
$ ./python -c "import os; from signal import *; signal(SIGALRM, lambda *args: None); alarm(1); os.read(0, 1)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
InterruptedError: [Errno 4] Interrupted system call
"""

With siginterrupt(False):
"""
$ ./python -c "import os; from signal import *; signal(SIGALRM, lambda *args: None); siginterrupt(SIGALRM, False); alarm(1); os.read(0, 1)"
[manual interruption]
^CTraceback (most recent call last):
  File "<string>", line 1, in <module>
KeyboardInterrupt
"""

It doesn't come with test because it's hard to come up with a syscall that's guaranteed to be restarted on al OS (and also because I'm having a hard time with all those mock-based asyncio tests ;-), but at least it doesn't break the test suite :-)

See https://groups.google.com/d/topic/python-tulip/9T2_tGWe0Sc/discussion for more background.

----------
components: Library (Lib)
files: asyncio_sa_restart.diff
keywords: patch
messages: 204915
nosy: gvanrossum, neologix
priority: normal
severity: normal
stage: patch review
status: open
title: asyncio: limit EINTR occurrences with SA_RESTART
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32923/asyncio_sa_restart.diff

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

From report at bugs.python.org  Sun Dec  1 15:11:34 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 01 Dec 2013 14:11:34 +0000
Subject: [New-bugs-announce] [issue19851] imp.reload problem with submodule
Message-ID: <1385907094.98.0.564664253092.issue19851@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

To reproduce:

* create a package with the following structure:

    pkg/
      __init__.py
      _sub.py

* __init__.py contains:

   from pkg._sub import *

* the contents of _sub.py is not important

* in a python shell do:

>>> import pkg._sub as s
>>> import imp
>>> imp.reload(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/imp.py", line 297, in reload
    return importlib.reload(module)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/importlib/__init__.py", line 123, in reload
    raise ImportError(_bootstrap._ERR_MSG.format(name), name=name)
ImportError: No module named 'pkg._sub'
>>> 

In earlier python versions this reloaded the pkg._sub module.  Importing _sub from __init__ doesn't seem to be important.

----------
components: Library (Lib)
keywords: 3.3regression
messages: 204920
nosy: brett.cannon, eric.snow, ncoghlan, ronaldoussoren
priority: normal
severity: normal
stage: test needed
status: open
title: imp.reload problem with submodule
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec  1 15:36:59 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 01 Dec 2013 14:36:59 +0000
Subject: [New-bugs-announce] [issue19852] Misplaced private API method in
	pathlib.py
Message-ID: <1385908619.09.0.979627399509.issue19852@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In class Path, line 942, you have this comment:

# Public API

but down there, in line 1048, you have this private method:

    def _raw_open(self, flags, mode=0o777):
        """
        Open the file pointed by this path and return a file descriptor,
        as os.open() does.
        """
        if self._closed:
            self._raise_closed()
        return self._accessor.open(self, flags, mode)

Here is the patch to move this private method to where it belongs.

----------
components: Library (Lib)
files: move_private_method_to_its_place.patch
keywords: patch
messages: 204926
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: Misplaced private API method in pathlib.py
versions: Python 3.4
Added file: http://bugs.python.org/file32928/move_private_method_to_its_place.patch

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

From report at bugs.python.org  Sun Dec  1 16:03:28 2013
From: report at bugs.python.org (Martin Natano)
Date: Sun, 01 Dec 2013 15:03:28 +0000
Subject: [New-bugs-announce] [issue19853] Add support for Bitrig
Message-ID: <1385910208.9.0.73177918579.issue19853@psf.upfronthosting.co.za>


New submission from Martin Natano:

This patch adds support for Bitrig to 2.7.

----------
components: Build
files: cpython2.7-bitrig.patch
keywords: patch
messages: 204930
nosy: Martin.Natano
priority: normal
severity: normal
status: open
title: Add support for Bitrig
versions: Python 2.7
Added file: http://bugs.python.org/file32929/cpython2.7-bitrig.patch

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

From report at bugs.python.org  Sun Dec  1 16:04:03 2013
From: report at bugs.python.org (Martin Natano)
Date: Sun, 01 Dec 2013 15:04:03 +0000
Subject: [New-bugs-announce] [issue19854] Add support for Bitrig to 3.4
Message-ID: <1385910243.77.0.484783750857.issue19854@psf.upfronthosting.co.za>


New submission from Martin Natano:

This patch adds support for Bitrig to 3.4.

----------
components: Build
files: cpython3.4-bitrig.patch
keywords: patch
messages: 204931
nosy: Martin.Natano
priority: normal
severity: normal
status: open
title: Add support for Bitrig to 3.4
versions: Python 3.4
Added file: http://bugs.python.org/file32930/cpython3.4-bitrig.patch

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

From report at bugs.python.org  Sun Dec  1 16:12:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 15:12:48 +0000
Subject: [New-bugs-announce] [issue19855] uuid._find_mac fails if an
	executable not in /sbin or	/usr/sbin
Message-ID: <1385910768.71.0.356029979861.issue19855@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The uuid._find_mac() function tests that executable file exist before run it. First it tries to run unmodified executable name (i.e. from $PATH) and then from the /sbin or /usr/sbin directories. However test for unmodified executable name is wrong, actually it tests that executable name exists in current directory rather than in $PATH.

As a result uuid._find_mac() always fails on platforms where ifconfig located in $PATH but not in /sbin or /usr/sbin (i.e. Gentoo). If unixdll_getnode() fails too, uuid.getnode() fallbacks to use of _random_getnode(). This is security issue.

test_uuid fails on such platforms too.

Here is a patch for 3.3+. Other Python versions requires different solution. For example this check can be just removed.

----------
components: Library (Lib)
files: uuid_find_mac_which.patch
keywords: patch
messages: 204932
nosy: Arfrever, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: uuid._find_mac fails if an executable not in /sbin or /usr/sbin
type: security
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32931/uuid_find_mac_which.patch

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

From report at bugs.python.org  Sun Dec  1 20:01:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 19:01:14 +0000
Subject: [New-bugs-announce] [issue19856] Possible bug in shutil.move() on
	Windows
Message-ID: <1385924474.74.0.566817188038.issue19856@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Perhaps following code fails on Windows (while successes on Linux): 

import os, shutil
os.makedirs('foo')
os.makedirs('bar/boo')
shutil.move('foo/', 'bar/')

However shutil.move('foo', 'bar/') and shutil.move('foo\\', 'bar/') should work.

----------
components: Library (Lib), Windows
messages: 204948
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Possible bug in shutil.move() on Windows
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Dec  1 22:32:48 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 21:32:48 +0000
Subject: [New-bugs-announce] [issue19857] test_imaplib doesn't always reap
	SocketServer thread
Message-ID: <1385933568.04.0.453956644253.issue19857@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

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

"""
[134/387/1] test_signal
Timeout (1:00:00)!
Thread 0x0000000801e24800 (most recent call first):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/socketserver.py", line 155 in _eintr_retry
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/socketserver.py", line 237 in serve_forever
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 869 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 921 in _bootstrap_inner
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 889 in _bootstrap

Thread 0x0000000801407400 (most recent call first):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_signal.py", line 529 in test_itimer_real
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/case.py", line 571 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/case.py", line 610 in __call__
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 117 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 79 in __call__
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 117 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 79 in __call__
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/runner.py", line 168 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/support/__init__.py", line 1685 in _run_suite
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/support/__init__.py", line 1719 in run_unittest
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_signal.py", line 934 in test_main
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/regrtest.py", line 1278 in runtest_inner
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/regrtest.py", line 967 in runtest
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/regrtest.py", line 763 in main
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/regrtest.py", line 1562 in main_in_temp_cwd
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/__main__.py", line 3 in <module>
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/runpy.py", line 73 in _run_code
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/runpy.py", line 160 in _run_module_as_main
*** Error code 1
"""

test_signal hangs, but that's because there's a dangling socketserver thread running from a failed test_imaplib test earlier in the test run:
"""
======================================================================
ERROR: test_login_cram_md5 (test.test_imaplib.ThreadedNetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 940, in _command
    self.send(CRLF)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 276, in send
    self.sock.sendall(data)
BrokenPipeError: [Errno 32] Broken pipe

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_imaplib.py", line 216, in reaped_pair
    yield server, client
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_imaplib.py", line 319, in test_login_cram_md5
    ret, data = client.login_cram_md5("tim", "tanstaaftanstaaf")
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 549, in login_cram_md5
    return self.authenticate('CRAM-MD5', self._CRAM_MD5_AUTH)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 380, in authenticate
    typ, dat = self._simple_command('AUTHENTICATE', mech)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 1127, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 942, in _command
    raise self.abort('socket error: %s' % val)
imaplib.abort: socket error: [Errno 32] Broken pipe

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/support/__init__.py", line 1831, in decorator
    return func(*args)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_imaplib.py", line 320, in test_login_cram_md5
    self.assertEqual(ret, "OK")
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/contextlib.py", line 77, in __exit__
    self.gen.throw(type, value, traceback)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_imaplib.py", line 218, in reaped_pair
    client.logout()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 570, in logout
    self.shutdown()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 283, in shutdown
    self.sock.shutdown(socket.SHUT_RDWR)
ConnectionResetError: [Errno 54] Connection reset by peer
"""

Here's the code in charge of stopping the client and server:
"""
    def reaped_pair(self, hdlr):
        server, thread = self.make_server((support.HOST, 0), hdlr)
        client = self.imap_class(*server.server_address)
        try:
            yield server, client
        finally:
            client.logout()
            self.reap_server(server, thread)
"""

But if client.logout() raises and exception - as is the case above - reap_server() is never called.

----------
components: Tests
messages: 204967
nosy: neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: test_imaplib doesn't always reap SocketServer thread
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec  2 02:00:14 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 02 Dec 2013 01:00:14 +0000
Subject: [New-bugs-announce] [issue19858] Make pickletools.optimize aware of
	the MEMOIZE opcode.
Message-ID: <1385946014.54.0.601831543599.issue19858@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

PEP 3154 introduced the MEMOIZE opcode which lowered the overhead of memoization compared to the PUT opcodes which were previously used.

We should update pickletools.optimize to remove superfluous uses of this new opcode.

----------
components: Library (Lib)
messages: 204985
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: needs patch
status: open
title: Make pickletools.optimize aware of the MEMOIZE opcode.
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Dec  2 11:27:47 2013
From: report at bugs.python.org (Radomir Dopieralski)
Date: Mon, 02 Dec 2013 10:27:47 +0000
Subject: [New-bugs-announce] [issue19859] functools.lru_cache keeps objects
	alive forever
Message-ID: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>


New submission from Radomir Dopieralski:

As most na?ve "memoized" decorator implementations, lru_cache keeps references to all the values of arguments of the decorated function in the cache. That means, that if we call such a decorated function with an object as a parameter, that object will be kept alive in memory forever -- that is, until the program ends. This is an obvious waste, since when we no longer have any other reference to that object, we are unable to call that function with the same parameter ever again, so it just wastes the cache space.

This is a very common case when we decorate a method -- the first parameter is "self". One solution for this particular case is to use a dedicated "memoized_method" decorator, that stores the cache on the "self" object itself, so that it can be released together with the object.

A more general solution uses weakrefs where possible in the cache key, maybe even with an additional callback that removes the cache entry when any of its parameters is dead. Obviously it adds some overhead and makes the caching decorator even slower, but it can let us save a lot of memory, especially in long-running applications.

To better illustrate what I mean, here is an example of such an improved @memoized decorator that I wrote: https://review.openstack.org/#/c/54117/5/horizon/utils/memoized.py

It would be great to have an option to do something similar with lru_cache, and if there is an interest, I would like to work on that.

----------
components: Library (Lib)
messages: 204995
nosy: thesheep
priority: normal
severity: normal
status: open
title: functools.lru_cache keeps objects alive forever
type: resource usage
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/issue19859>
_______________________________________

From report at bugs.python.org  Mon Dec  2 12:45:59 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 11:45:59 +0000
Subject: [New-bugs-announce] [issue19860] asyncio: Add context manager to
	BaseEventLoop?
Message-ID: <1385984759.42.0.47454056153.issue19860@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The BaseSelectorEventLoop class (inherited by UnixSelectorEventLoop) creates a socketpair in its constructor. So if you don't call close(), the socketpair may stay alive.

It would be convinient to support the context manager to be able to write:

with asyncio.get_event_loop() as loop
   # ... prepare loop ...
   loop.run_forever()
# KeyboardInterrupt or SystemExit: loop.close() is called

Hello World examples don't call close(), so the sockets are not closed when the example is stopped using CTRL+c.

Attached patch adds __enter__/__exit__ methods to BaseEventLoop and use it in the two Hello World examples.

----------
files: eventloop_context_manager.patch
keywords: patch
messages: 205004
nosy: gvanrossum, haypo, pitrou
priority: normal
severity: normal
status: open
title: asyncio: Add context manager to BaseEventLoop?
versions: Python 3.4
Added file: http://bugs.python.org/file32936/eventloop_context_manager.patch

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

From report at bugs.python.org  Mon Dec  2 13:23:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 12:23:02 +0000
Subject: [New-bugs-announce] [issue19861] Update What's New for Python 3.4
Message-ID: <1385986982.03.0.371652275474.issue19861@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Many features and changes were not mentioned in What's New (especially added early). Here is main features which possible worth to mention:

abc:  The ABC class, the get_cache_token function.

aifc:  Any bytes-like objects are now accepted.

audioop:  Any bytes-like objects are now accepted.  Strings no more supported.

base64:  ascii85/base85 codecs.

bz2:  The 'x' mode.

codecs:  The cp1125 encoding.

collections:  New optional parameter in ChainMap.new_child().

dbm:  Support for the context management protocol.

dis:  Added the file parameter to many functions. Added the stack_effect() 
function.

email:  The policy keyword argument was added in email.message.Message 
constructor. The replace keyword argument was added in the set_param() 
method. 
The EmailPolicy.content_manager attribute was added 

filecmp:  Added the clear_cache() function and the dircmp.DEFAULT_IGNORES 
attribute.

functools:  total_ordering now supports the NotImplemented value.

gc:  Added the get_stats() function.

glob:  Added the escape() function.

gzip: The 'x' mode.

http:  HTTP 0.9-style "Simple Responses" are not supported. Added the explain 
argument in BaseHTTPRequestHandler.send_error(). Added the --bind option in 
the http.server module CLI.

ipaddress:  Added the IPv4Address.is_global attribute.

json:  Used ``(',', ': ')`` as default in dump() and dumps() if indent is not 
None. I.e. trailing spaces no more produced by default.

logging:  An instance of a subclass of RawConfigParser is now accepted as a 
value for fname in the fileConfig() function. The verify argument was added in 
the listen() function. The atTime parameter was added in 
TimedRotatingFileHandler constructor.  Added support of Unix domain sockets 
in SocketHandler and DatagramHandler.

lzma:  The 'x' mode.

multiprocessing:  Added following functions: get_all_start_methods(), 
get_context(), get_start_method(), and set_start_method(). set_executable() 
is now supported on Unix when the 'spawn' start method is used. Added the 
context parameter in Pool constructor.

operator:  Added the length_hint() function.

os.path:  samestat() now is supported on Windows.

os:  Add O_TMPFILE constant on Linux.

plistlib:  Added support for binary format. Added load(), loads(), dump(), and 
dumps() functions. Deprecated readPlist(), writePlist() readPlistFromBytes(), 
and writePlistToBytes() functions, the Data class.

select:  epoll() now supports the context management protocol. Added the 
close() and fileno() methods and the closed attribute in the devpoll class.

shelve:  Added context manager support.

shutil:  Added the SameFileError exception.

smtpd:  The map argument was added in SMTPServer constructor.

socket:  The CAN_BCM protocol was added. The AF_LINK family was added.

sqlite3:  Added support for URI.

subprocess: The input parameter was added in the check_output() function.

sunau:  Added support for 24-bit samples. Any bytes-like objects are now 
accepted.

sys:  Added the getallocatedblocks() function. Added the __interactivehook__ 
hook.

tarfile:  Added command-line interface.

textwrap:  Added support for truncating.

threading:  Added the main_thread() function.

unittest:  Added the TestCase.assertLogs() method. The TestSuite no more held 
references to each TestCase after TestSuite.run(). Modules that raise SkipTest 
on import are recorded as skips, not errors. Paths are sorted before being 
imported to ensure execution order for a given test suite is the same.

urllib:  Added the HTTPError.headers attribute. Added the Request.full_url 
attribute and the Request.remove_header() and Request.get_full_url() methods. 
Default Request.method may be indicated at the class level.

venv:  Added the ``with_pip`` parameter in EnvBuilder.

wave:  Any bytes-like objects are now accepted. Added support for unseekable 
files.

xml.etree.elementtree:  Added support to output empty elements in short form.

zipfile:  ZIP64 extensions are enabled by default.


Other enhancements:le.

memoryview is now registered automatically with collections.abc.Sequence.

Deprecations:

The 'U' mode in open() for file objects, in the fileinput and zipfile modules. A couple of plistlib functions. The html argument of XMLParser() and the parser argument of iterparse() in the xml.etree.elementtree module.

----------
assignee: docs at python
components: Documentation
messages: 205005
nosy: docs at python, larry, serhiy.storchaka
priority: release blocker
severity: normal
status: open
title: Update What's New for Python 3.4
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec  2 16:18:46 2013
From: report at bugs.python.org (=?utf-8?b?0JLQsNC70LXRgNC40Lk=?=)
Date: Mon, 02 Dec 2013 15:18:46 +0000
Subject: [New-bugs-announce] [issue19862] Unclear xpath caching for custom
	namespaces
Message-ID: <1385997526.09.0.197144583843.issue19862@psf.upfronthosting.co.za>


New submission from ???????:

Consider repeated executions of a code like this:
>tree = xml.etree.ElementTree.parse( full_name ) # many different files
>report_type = tree.getroot().attrib['Name'] # something changing
>tree.getroot().find( ".//t:Detail", {'t' : report_type} )

There is a _cache variable in \Lib\xml\etree\ElementPath.py:
>def iterfind(elem, path, namespaces=None):
>    // ...
>    try:
>        selector = _cache[path]
>    except KeyError:
>    // ...

In my code I use the same path (".//t:Detail"), so no KeyError exception is raised and cached (the same) value is used, but full path should be different ('.//{url_one}Detail', './/{url_two}Detail', etc) depending on namespaces dictionary.

----------
components: XML
messages: 205015
nosy: valeriy.nov
priority: normal
severity: normal
status: open
title: Unclear xpath caching for custom  namespaces
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Dec  2 19:57:53 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 02 Dec 2013 18:57:53 +0000
Subject: [New-bugs-announce] [issue19863] Missing function attributes in 2.7
	docs.
Message-ID: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

The attached patch fills in some missing function attributes from the Python 2.7 datamodel docs.

----------
assignee: docs at python
components: Documentation
files: missing_function_attributes.patch
keywords: patch
messages: 205038
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: Missing function attributes in 2.7 docs.
versions: Python 2.7
Added file: http://bugs.python.org/file32938/missing_function_attributes.patch

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

From report at bugs.python.org  Mon Dec  2 20:00:54 2013
From: report at bugs.python.org (Max Polk)
Date: Mon, 02 Dec 2013 19:00:54 +0000
Subject: [New-bugs-announce] [issue19864] multiprocessing Proxy docs need
	locking semantics	explained
Message-ID: <1386010854.42.0.669130689835.issue19864@psf.upfronthosting.co.za>


New submission from Max Polk:

In the docs (both Python 2 and 3) for the multiprocessing module, the Proxy section needs to be explicit about the fact that is does NOT create locks around access to shared objects.

Why?  Because on the same page, we read about multiprocessing.managers.SyncManager's Queue method to create a shared queue.Queue object and return a proxy for it, next to other methods like SyncManager.list to create a "process safe" list.

But later, a willful violation of these semantics exists in the "Using a remote manager" section where a Proxy is implicitly created (via the register method of multiprocessing.managers.BaseManager) surrounding a Queue.Queue object.

Note that it did not create a proxy around a SyncManager.Queue, it created it around a Queue.Queue.  A user who copies this code and replaces Queue.Queue with a plain Python list gets the sense that all the needed locks will be created to protect the shared list.

However, due to lack of documentation in the Proxy section, the user will not know it's an unsafe list, and Proxy isn't helping them.  I'm guessing that Queue.Queue has its own locks to protect it in a process-shared setting, and we "lucked out" in this example, but an unwary reader's luck runs out if they replace it with a plain Python list.

Therefore, may I suggest two changes: (1) replace Queue.Queue with SyncManager.Queue in the "Using a remote manager" section to avoid misleading readers; and (2) be explicit in Proxy class docs that "no locks are created" to protect against concurrent access, and maybe add that the user must go to the multiprocessing.managers.SyncManager methods (Queue, list, etc) to get "process safe" objects to place behind the Proxy.

----------
assignee: docs at python
components: Documentation
messages: 205039
nosy: docs at python, maxpolk
priority: normal
severity: normal
status: open
title: multiprocessing Proxy docs need locking semantics explained

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

From report at bugs.python.org  Mon Dec  2 20:36:46 2013
From: report at bugs.python.org (=?utf-8?q?Gergely_Erd=C3=A9lyi?=)
Date: Mon, 02 Dec 2013 19:36:46 +0000
Subject: [New-bugs-announce] [issue19865] create_unicode_buffer() fails on
	non-BMP strings on	Windows
Message-ID: <1386013006.0.0.412572088185.issue19865@psf.upfronthosting.co.za>


New submission from Gergely Erd?lyi:

create_unicode_buffer() fails on Windows if the initializer string contains unicode code points outside of the Basic Multilingual Plane and an explicit length is not specified.

The problem appears to be rooted in the fact that, since PEP 393, len() returns the number of code points, which does not always correspond to the number of 16-bit wchar words needed for the encoding on Windows. Because of that, the preallocated c_wchar buffer will be too short for the UTF-16 string.

The following small snippet demonstrates the problem:

from ctypes import create_unicode_buffer
b = create_unicode_buffer("\U00028318\U00028319")
print(b)

  File "c:\Python33\lib\ctypes\__init__.py", line 294, in create_unicode_buffer
    buf.value = init
ValueError: string too long

----------
components: ctypes
messages: 205045
nosy: gergely.erdelyi
priority: normal
severity: normal
status: open
title: create_unicode_buffer() fails on non-BMP strings on Windows
type: crash
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec  2 23:23:28 2013
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 02 Dec 2013 22:23:28 +0000
Subject: [New-bugs-announce] [issue19866] tests aifc,
	sunau and wave failures on a fresh Win64 installation
Message-ID: <1386023008.24.0.870175921634.issue19866@psf.upfronthosting.co.za>


New submission from Francisco Mart?n Brugu?:

I've just installed Cpython 2.7.6 32bit on Windows64, run the tests [1]
and some of them failed. Some of them seems related to audiodata not beeing installed.

.\python.exe Lib\test\regrtest.py -v
== CPython 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] 
== Windows-7-6.1.7601-SP1 little-endian 
== c:\users\brugue\appdata\local\temp\test_python_1388 
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0,
division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0,
no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0,
unicode=0, bytes_warning=0, hash_randomization=0) 
... 
test_aifc
...
======================================================================
ERROR: test_close (test.test_aifc.AifcPCM8Test)
----------------------------------------------------------------------
Traceback (most recent call last):
? File "D:\programs\Python27\lib\test\audiotests.py", line 148, in test_close
? ? with open(self.sndfilepath, 'rb') as testfile:
IOError: [Errno 2] No such file or directory: 'audiodata\\pluck-pcm8.aiff'
...
and more...
FAILED (errors=30)
...
test_sunau
======================================================================
ERROR: test_close (test.test_sunau.SunauPCM8Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\programs\Python27\lib\test\audiotests.py", line 148, in test_close
    with open(self.sndfilepath, 'rb') as testfile:
IOError: [Errno 2] No such file or directory: 'audiodata\\pluck-pcm8.au'
...
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A4F3738>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A4F3738>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A4F3AA8>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A4F3C60>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A4F3F58>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A481B98>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A481B98>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A596CB0>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A596FD0>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A596918>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A47F508>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A596918>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A47FFA8>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A47F508>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A47F288>> ignored
test test_sunau failed -- multiple errors occurred
...
and more ...
...
FAILED (errors=25)
...
test_wave
...
======================================================================
ERROR: test_close (test.test_wave.WavePCM8Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\programs\Python27\lib\test\audiotests.py", line 148, in test_close
    with open(self.sndfilepath, 'rb') as testfile:
IOError: [Errno 2] No such file or directory: 'audiodata\\pluck-pcm8.wav'
...
FAILED (errors=20)
...
See attached files

----------
components: Windows
files: failed_test_aifc.txt
messages: 205059
nosy: francismb
priority: normal
severity: normal
status: open
title: tests aifc, sunau and wave failures on a fresh Win64 installation
versions: Python 2.7
Added file: http://bugs.python.org/file32941/failed_test_aifc.txt

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

From report at bugs.python.org  Mon Dec  2 23:43:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Dec 2013 22:43:57 +0000
Subject: [New-bugs-announce] [issue19867] pickletools.OpcodeInfo.code is a
	string
Message-ID: <1386024237.29.0.240373861832.issue19867@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It should probably be a bytes object instead:

>>> op
<pickletools.OpcodeInfo object at 0x7f1e119db448>
>>> op.code
'\x95'
>>> op.name
'FRAME'
>>> pickle.FRAME
b'\x95'

----------
components: Library (Lib)
messages: 205061
nosy: alexandre.vassalotti, pitrou
priority: normal
severity: normal
status: open
title: pickletools.OpcodeInfo.code is a string
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec  3 06:13:05 2013
From: report at bugs.python.org (Drew)
Date: Tue, 03 Dec 2013 05:13:05 +0000
Subject: [New-bugs-announce] [issue19868] Importing humanhash and uuid
	causes a segmentation fault	crash
Message-ID: <1386047585.47.0.784915369979.issue19868@psf.upfronthosting.co.za>


New submission from Drew:

$ pip-3.3 install humanhash
$ python3
Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import uuid
>>> import humanhash
Segmentation fault: 11

----------
assignee: ronaldoussoren
components: Macintosh
files: Python_2013-12-02-231131_shadowfax.crash
messages: 205075
nosy: compaqdrew, ronaldoussoren
priority: normal
severity: normal
status: open
title: Importing humanhash and uuid causes a segmentation fault crash
versions: Python 3.3
Added file: http://bugs.python.org/file32946/Python_2013-12-02-231131_shadowfax.crash

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

From report at bugs.python.org  Tue Dec  3 08:23:01 2013
From: report at bugs.python.org (Florian Pilz)
Date: Tue, 03 Dec 2013 07:23:01 +0000
Subject: [New-bugs-announce] [issue19869] BaseCookie does not complain if a
	non RFC compliant	cookie header was given
Message-ID: <1386055381.8.0.960410220021.issue19869@psf.upfronthosting.co.za>


New submission from Florian Pilz:

BaseCookie should give an informative error, if a non RFC compliant header was given. The problem was, that we thought several cookies are allowed in one header in a cookie *response* header. However, this is only allowed in cookie *request* headers.

In those cases the output of BaseCookie looks broken, which caused a lot of confusion, since a standard library should not have so many flaws.

Example with parsing a response header with several cookies separated by comma (not allowed by RFC):

http.cookies.BaseCookie('foo=bar, oof=rab; httponly, bar=baz').output()
'Set-Cookie: bar=baz\r\nSet-Cookie: foo=bar,\r\nSet-Cookie: oof=rab'

Flaws:

* comma after 'foo=bar' in output
* the httponly flag was omitted (it would show up with a semi-colon after it, i.e. 'oof=rab; httponly;')
* input and output style are different, i.e. several cookies in one line were transformed to several cookies in several lines

I think the best solution is to fail early and hard, if there are several cookies in one header. Maybe some problems should be fixed anyway (trailing comma, different output style).

----------
components: Library (Lib)
messages: 205077
nosy: florianpilz
priority: normal
severity: normal
status: open
title: BaseCookie does not complain if a non RFC compliant cookie header was given
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Dec  3 08:27:08 2013
From: report at bugs.python.org (Florian Pilz)
Date: Tue, 03 Dec 2013 07:27:08 +0000
Subject: [New-bugs-announce] [issue19870] Backport Cookie fix to 2.7
	(httponly / secure flag)
Message-ID: <1386055628.27.0.222770059818.issue19870@psf.upfronthosting.co.za>


New submission from Florian Pilz:

Until Python 3.3.3 the Cookie library did not support the httponly and secure flag (see Issue 16611). Therefore the library is not RFC conform until then, so I think there should be a backport into 2.7 and maybe 3.2 as well.

----------
components: Library (Lib)
messages: 205078
nosy: florianpilz
priority: normal
severity: normal
status: open
title: Backport Cookie fix to 2.7 (httponly / secure flag)
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Dec  3 09:21:13 2013
From: report at bugs.python.org (picomancer)
Date: Tue, 03 Dec 2013 08:21:13 +0000
Subject: [New-bugs-announce] [issue19871] json module won't parse a float
	that starts with a	decimal point
Message-ID: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>


New submission from picomancer:

Try the following in your favorite Python version:

    import json
    json.loads(".5")

On my Python (2.7.4 and 3.3.1 on Ubuntu Saucy Salamander), I get an exception.  However, x = .5 is a valid Python number.

With respect to the parsing of floats by the json module, the docs state:

    By default, this is equivalent to ``float(num_str)``.

This statement does not match the behavior I have observed in every version of Python I have tried, and is still in the bleeding-edge (as of this writing) at http://hg.python.org/cpython/file/9283a9c5d0ce/Doc/library/json.rst

I think it's clear that the following changes should definitely be implemented:

(1) The docs and behavior should match
(2) Whatever the desired behavior is, there is a unit test specifically for this corner case

Of course, to implement (1), there are two routes:

(1a) Leading decimal floats should be accepted by the json module; the behavior should be changed to match the docs.  Supported by Postel's Law -- "be liberal in what [your program] accept[s]"), see http://en.wikipedia.org/wiki/Postel%27s_law and the slightly relaxed attitude toward standards compliance detailed in the json module documentation.

(1b) Leading decimal floats should be rejected by the json module; the docs should be changed to match the behavior.  This fits with a strict standards compliance worldview.

I think (1a) is better.  In my particular use case, I was manually writing a json file with several numerical parameters.  The backtrace given by json.load(open("whatever.json", "r")) is uninformative and merely says "No JSON object could be decoded"; finding the token the parser considered to be malformed was fairly easy since there were only six or seven keys.  It could have been much worse if I was making manual changes to a larger JSON file.

----------
components: Library (Lib)
messages: 205080
nosy: picomancer
priority: normal
severity: normal
status: open
title: json module won't parse a float that starts with a decimal point
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Dec  3 09:22:26 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 03 Dec 2013 08:22:26 +0000
Subject: [New-bugs-announce] [issue19872] Remove unused imports in pathlib
Message-ID: <1386058946.1.0.228185932917.issue19872@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Attached the patch to remove unused imports in pathlib.

----------
components: Library (Lib)
files: remove_unused_import_in_pathlib.patch
keywords: patch
messages: 205081
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: Remove unused imports in pathlib
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file32948/remove_unused_import_in_pathlib.patch

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

From report at bugs.python.org  Tue Dec  3 09:30:49 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 03 Dec 2013 08:30:49 +0000
Subject: [New-bugs-announce] [issue19873] There is a duplicate function in
	Lib/test/test_pathlib.py
Message-ID: <1386059449.85.0.979457911898.issue19873@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Here it is (Lib/test/test_pathlib.py, line 1240):

    def _check_resolve_relative(self, p, expected):
        q = p.resolve()
        self.assertEqual(q, expected)

    def _check_resolve_absolute(self, p, expected):
        q = p.resolve()
        self.assertEqual(q, expected)

----------
components: Tests
messages: 205082
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: There is a duplicate function in Lib/test/test_pathlib.py
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec  3 11:04:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Dec 2013 10:04:56 +0000
Subject: [New-bugs-announce] [issue19874] test_logging failures on Snow
	Leopard
Message-ID: <1386065096.95.0.643671353968.issue19874@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

"test_race" in test_logging fails intermittently on the Snow Leopard buildbot:

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/741

======================================================================
ERROR: test_race (test.test_logging.HandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_logging.py", line 613, in test_race
    h.handle(r)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/logging/__init__.py", line 835, in handle
    self.emit(record)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/logging/handlers.py", line 468, in emit
    self.stream = self._open()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/logging/__init__.py", line 1005, in _open
    return open(self.baseFilename, self.mode, encoding=self.encoding)
PermissionError: [Errno 1] Operation not permitted: '/tmp/test_logging-3-0my8mx_f.log'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_logging.py", line 616, in test_race
    h.close()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/logging/__init__.py", line 990, in close
    self.flush()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/logging/__init__.py", line 937, in flush
    self.stream.flush()
ValueError: I/O operation on closed file.

----------
components: Library (Lib), Tests
messages: 205098
nosy: pitrou, r.david.murray, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging failures on Snow Leopard
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec  3 11:17:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Dec 2013 10:17:39 +0000
Subject: [New-bugs-announce] [issue19875] test_getsockaddrarg occasional
	failure
Message-ID: <1386065859.81.0.4295023541.issue19875@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It's on the FreeBSD 10.0 buildbot:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/1169

======================================================================
ERROR: test_getsockaddrarg (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/test_socket.py", line 1159, in test_getsockaddrarg
    sock.bind((host, port))
OSError: [Errno 48] Address already in use

----------
components: Library (Lib), Tests
messages: 205099
nosy: koobs, neologix, pitrou
priority: normal
severity: normal
status: open
title: test_getsockaddrarg occasional failure
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec  3 15:11:19 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 14:11:19 +0000
Subject: [New-bugs-announce] [issue19876] selectors (and asyncio?): document
	behaviour on closed	files/sockets
Message-ID: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I remember a discussion about EBADF, but I don't remember the conclusion. The documentation of the asyncio doesn't explain the behaviour of selectors when a file/socket is closed, without unregistering it from the selector.

I should be explicitly documented. I would accept an "undefined behaviour" if it's documented :-)

----------
assignee: docs at python
components: Documentation
messages: 205118
nosy: docs at python, gvanrossum, haypo, neologix
priority: normal
severity: normal
status: open
title: selectors (and asyncio?): document behaviour on closed files/sockets
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec  3 17:06:57 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 03 Dec 2013 16:06:57 +0000
Subject: [New-bugs-announce] [issue19877] test_resolve_dot of
	test_pathlib.py fails on Windows	Vista
Message-ID: <1386086817.69.0.41545302565.issue19877@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

You must run this test as administrator.

C:\Users\vajrasky\Code\cpython>PCbuild\python.exe Lib\test\test_pathlib.py
..........s..s..s..s.........s.....E............ssssssssssssssssssssssssssssssss
ssssssssssssssssssssssssssssssssssssssssssssssss................................
................................................................................
...............................................s..s..s..s.........s.....E.......
..
======================================================================
ERROR: test_resolve_dot (__main__.PathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 1281, in test_resolve_dot
    self.assertEqual(q.resolve(), p)
  File "C:\Users\vajrasky\Code\cpython\lib\pathlib.py", line 1017, in resolve
    s = self._flavour.resolve(self)
  File "C:\Users\vajrasky\Code\cpython\lib\pathlib.py", line 179, in resolve
    return self._ext_to_normal(_getfinalpathname(s))
OSError: [WinError 123] The filename, directory name, or volume label syntax is
incorrect: 'C:\\Users\\vajrasky\\Code\\cpython\\@test_5860_tmp\\2'

======================================================================
ERROR: test_resolve_dot (__main__.WindowsPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 1281, in test_resolve_dot
    self.assertEqual(q.resolve(), p)
  File "C:\Users\vajrasky\Code\cpython\lib\pathlib.py", line 1017, in resolve
    s = self._flavour.resolve(self)
  File "C:\Users\vajrasky\Code\cpython\lib\pathlib.py", line 179, in resolve
    return self._ext_to_normal(_getfinalpathname(s))
OSError: [WinError 123] The filename, directory name, or volume label syntax is
incorrect: 'C:\\Users\\vajrasky\\Code\\cpython\\@test_5860_tmp\\2'

----------------------------------------------------------------------

Windows does not like "/" in its name for the file.

Attached the patch to fix the test.

----------
components: Tests
files: fix_test_resolve_dot_on_windows.patch
keywords: patch
messages: 205126
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: test_resolve_dot of test_pathlib.py fails on Windows Vista
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32949/fix_test_resolve_dot_on_windows.patch

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

From report at bugs.python.org  Tue Dec  3 19:51:08 2013
From: report at bugs.python.org (Matthew Bergin)
Date: Tue, 03 Dec 2013 18:51:08 +0000
Subject: [New-bugs-announce] [issue19878] PyFile_DecUseCount() SIGSEGV
Message-ID: <1386096668.93.0.258103858078.issue19878@psf.upfronthosting.co.za>


New submission from Matthew Bergin:

[level@<removed> fuzz]# cat pyfile.py
import bz2
obj = bz2.BZ2File('/tmp/fileName')
obj.__init__("fileName")
obj.__reduce__
[level@<removed> fuzz]# gdb --args python pyfile.py
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install python-2.6.6-37.el6_4.i686 python-2.6.6-37.el6_4.x86_64
(gdb) r
Starting program: /usr/bin/python pyfile.py
[Thread debugging using libthread_db enabled]
Traceback (most recent call last):
  File "pyfile.py", line 3, in <module>
    obj.__init__("fileName")
IOError: [Errno 2] No such file or directory: 'fileName'

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7a98170 in PyFile_DecUseCount () from /usr/lib64/libpython2.6.so.1.0
(gdb)

----------
components: Interpreter Core
messages: 205137
nosy: Level
priority: normal
severity: normal
status: open
title: PyFile_DecUseCount() SIGSEGV
versions: Python 2.6

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

From report at bugs.python.org  Tue Dec  3 19:54:52 2013
From: report at bugs.python.org (Matthew Bergin)
Date: Tue, 03 Dec 2013 18:54:52 +0000
Subject: [New-bugs-announce] [issue19879] PyCFunction_NewEx() SIGABRT
Message-ID: <1386096892.95.0.429953399252.issue19879@psf.upfronthosting.co.za>


New submission from Matthew Bergin:

[level@<removed> fuzz]# cat PyCFunction.py
#
# PyCFunction_NewEx crach poc (sigabrt)
#
import imageop
imageop.rgb82rgb(u"%J8CBej >uFBi-",True,8.36)
imageop.grey2grey(None,5,u"CRi")
[level@<removed> fuzz]# gdb --args python PyCFunction.py
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install python-2.6.6-37.el6_4.i686 python-2.6.6-37.el6_4.x86_64
(gdb) r
Starting program: /usr/bin/python PyCFunction.py
[Thread debugging using libthread_db enabled]
PyCFunction.py:5: DeprecationWarning: integer argument expected, got float
  imageop.rgb82rgb(u"%J8CBej >uFBi-",True,8.36)
Fatal Python error: GC object already tracked

Program received signal SIGABRT, Aborted.
0x00007ffff6e2e8e5 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff6e2e8e5 in raise () from /lib64/libc.so.6
#1  0x00007ffff6e300c5 in abort () from /lib64/libc.so.6
#2  0x00007ffff7b2823e in Py_FatalError () from /usr/lib64/libpython2.6.so.1.0
#3  0x00007ffff7ab3175 in PyCFunction_NewEx () from /usr/lib64/libpython2.6.so.1.0
#4  0x00007ffff7b24b18 in Py_InitModule4_64 () from /usr/lib64/libpython2.6.so.1.0
#5  0x00007ffff0b66abe in initsyslog () from /usr/lib64/python2.6/lib-dynload/syslog.so
#6  0x00007ffff7b21865 in _PyImport_LoadDynamicModule () from /usr/lib64/libpython2.6.so.1.0
#7  0x00007ffff7b1f8a5 in ?? () from /usr/lib64/libpython2.6.so.1.0
#8  0x00007ffff7b1fb24 in ?? () from /usr/lib64/libpython2.6.so.1.0
#9  0x00007ffff7b2017d in ?? () from /usr/lib64/libpython2.6.so.1.0
#10 0x00007ffff7b20ee4 in PyImport_ImportModuleLevel () from /usr/lib64/libpython2.6.so.1.0
#11 0x00007ffff7b0671f in ?? () from /usr/lib64/libpython2.6.so.1.0
#12 0x00007ffff7a7ac63 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0
#13 0x00007ffff7b06c93 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.6.so.1.0
#14 0x00007ffff7b0a33f in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#15 0x00007ffff7b0db8f in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#16 0x00007ffff7b0e657 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0
#17 0x00007ffff7aa1cb0 in ?? () from /usr/lib64/libpython2.6.so.1.0
#18 0x00007ffff7a7ac63 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0
#19 0x00007ffff7b06c93 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.6.so.1.0
#20 0x00007ffff7b29cc2 in PyErr_PrintEx () from /usr/lib64/libpython2.6.so.1.0
#21 0x00007ffff7b2a287 in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.6.so.1.0
#22 0x00007ffff7b368a2 in Py_Main () from /usr/lib64/libpython2.6.so.1.0
#23 0x00007ffff6e1acdd in __libc_start_main () from /lib64/libc.so.6
#24 0x0000000000400649 in _start ()
(gdb) q

----------
components: Interpreter Core
messages: 205138
nosy: Level
priority: normal
severity: normal
status: open
title: PyCFunction_NewEx() SIGABRT
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Dec  3 23:46:40 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 22:46:40 +0000
Subject: [New-bugs-announce] [issue19880] unittest: on failure,
	TestCase.run() keeps a reference to the exception
Message-ID: <1386110800.98.0.113346130856.issue19880@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Test attached unittest_leak.py script: you will see MyException.ninstance counter increased up to 10, whereas I expect that MyException is destroyed at TestCase.run() exit.

It looks like a tricky reference cycle between:

- frames
- exc_info local variable of _Outcome.testPartExecutor() context manager
- _Outcome.errors list
- _Outclass instance

Attached unittest_workaround.patch patch works around the issue.

----------
files: unittest_leak.py
messages: 205167
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: unittest: on failure, TestCase.run() keeps a reference to the exception
versions: Python 3.4
Added file: http://bugs.python.org/file32951/unittest_leak.py

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

From report at bugs.python.org  Wed Dec  4 07:38:54 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 04 Dec 2013 06:38:54 +0000
Subject: [New-bugs-announce] [issue19881] Fix bigmem pickle tests
Message-ID: <1386139134.4.0.507714096088.issue19881@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

The bigmem tests for pickle are currently failing for protocol 4. The tests are broken because of an assumption rendered invalid by the frame header. Fixing the tests caught a legitimate bug in the save_bytes function of cpickle.

----------
assignee: alexandre.vassalotti
components: Library (Lib)
files: fix_bigmem_pickle.patch
keywords: patch
messages: 205196
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix bigmem pickle tests
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32966/fix_bigmem_pickle.patch

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

From report at bugs.python.org  Wed Dec  4 08:21:06 2013
From: report at bugs.python.org (Martin Panter)
Date: Wed, 04 Dec 2013 07:21:06 +0000
Subject: [New-bugs-announce] [issue19882] Closing a socket when makefile()
	is used
Message-ID: <1386141666.2.0.800726480915.issue19882@psf.upfronthosting.co.za>


New submission from Martin Panter:

I think the documentation is rather vague about closing the underlying OS socket. Can someone verify if the following is true (*asterisked* bits are my additions), and maybe update the documentation?

socket.close(): Close the socket *object*. *The underlying file descriptor is also closed, unless there are file objects from makefile() still open.*

socket.makefile(): Closing the file object won?t close the *file descriptor* unless *the original socket object and any other file objects have already been closed*.

----------
assignee: docs at python
components: Documentation
messages: 205200
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: Closing a socket when makefile() is used
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Dec  4 10:34:05 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 04 Dec 2013 09:34:05 +0000
Subject: [New-bugs-announce] [issue19883] overflow in zipexport.c
Message-ID: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>


New submission from Christian Heimes:

MSVC complains about "conversion from 'Py_ssize_t' to 'long', possible loss of data" in zipimport.c. header_offset is a Py_ssize_t but fseek() only takes a long. On 64bit Windows Py_ssize_t is a 64bit data type but long is still a 32bit data type.

It's safe to assume that the header will be smaller than 2 GB for the next couple of years. :)

----------
assignee: brett.cannon
files: zipimport_header_offset.patch
keywords: patch
messages: 205209
nosy: brett.cannon, christian.heimes
priority: low
severity: normal
stage: patch review
status: open
title: overflow in zipexport.c
type: compile error
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32970/zipimport_header_offset.patch

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

From report at bugs.python.org  Wed Dec  4 13:06:16 2013
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Wed, 04 Dec 2013 12:06:16 +0000
Subject: [New-bugs-announce] [issue19884] Importing readline produces
	erroneous output
Message-ID: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

A simple reproducer:

python -c 'import readline' | xxd
0000000: 1b5b 3f31 3033 3468                      .[?1034h

This was reported at [1] and originally at [2]. The readline maintainer suggests [3] using:

rl_variable_bind ("enable-meta-key", "off");

which was introduced in readline 6.1. Do you think it'd be safe to add the above line?

Thanks.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=880393
[2] https://bugzilla.redhat.com/show_bug.cgi?id=593799
[3] http://lists.gnu.org/archive/html/bug-readline/2011-04/msg00009.html

----------
components: Extension Modules
messages: 205217
nosy: bkabrda
priority: normal
severity: normal
status: open
title: Importing readline produces erroneous output
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Dec  4 17:33:46 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 04 Dec 2013 16:33:46 +0000
Subject: [New-bugs-announce] [issue19885] lzma.LZMAFile.__init__() segfault
	when __init__ with	non-existent file after executing the constructor
Message-ID: <1386174826.17.0.707477231335.issue19885@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

[sky at localhost cutecat]$ cat /tmp/lzma_segfault.py 
import lzma
file = lzma.LZMAFile("/tmp/file.lzma", "w")
file.write(b"xxxx")
file.close()
with lzma.LZMAFile("/tmp/file.lzma", "w") as f:
    f.__init__("non-existent")
[sky at localhost cutecat]$ python /tmp/lzma_segfault.py 
Segmentation fault (core dumped)

See also issue19878.

I'll provide the patch tomorrow.

----------
components: Extension Modules
messages: 205229
nosy: nadeem.vawda, vajrasky
priority: normal
severity: normal
status: open
title: lzma.LZMAFile.__init__() segfault when __init__ with non-existent file after executing the constructor
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec  4 20:30:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2013 19:30:13 +0000
Subject: [New-bugs-announce] [issue19886] Better estimated memory
	requirements for bigmem tests
Message-ID: <1386185413.56.0.459107954756.issue19886@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Some bigmem tests actually consume much more memory than declare. This can cause swapping and too long time of test run. Here is a patch which improves estimates.

----------
components: Tests
files: bigmem_tests.patch
keywords: patch
messages: 205236
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Better estimated memory requirements for bigmem tests
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32973/bigmem_tests.patch

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

From report at bugs.python.org  Wed Dec  4 21:46:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2013 20:46:45 +0000
Subject: [New-bugs-announce] [issue19887] Path.resolve() fails on deep
	symlinks
Message-ID: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a script which success with os.path.realpath(), but fails with pathlib.Path.resolve(). The `readlink -f` also success with these examples.

----------
components: Library (Lib)
files: pathlib_resolve_test.py
messages: 205245
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Path.resolve() fails on deep symlinks
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32974/pathlib_resolve_test.py

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

From report at bugs.python.org  Wed Dec  4 23:06:07 2013
From: report at bugs.python.org (Zygmunt Krynicki)
Date: Wed, 04 Dec 2013 22:06:07 +0000
Subject: [New-bugs-announce] [issue19888] possible memory corruption caused
	by for-loop iteration	over namespace.items() in a metaclass
	defining __new__
Message-ID: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>


New submission from Zygmunt Krynicki:

It seems that a particular code sequence causes memory corruption (but not a crash so far) in the interpreter. I've attached a test case that fails assertion on python3.2 (tested on current amd64 12.04 builds) and works on python3.3 (tested on current amd64 14.04 builds and i386 fedora 19 builds).

The attached test program shows how the bug is actually triggered by using a for loop to iterate over key, value in namespace.items() inside a metaclass __new__() method that does nothing else apart from that.

----------
components: Interpreter Core
files: bug.py
messages: 205250
nosy: zkrynicki
priority: normal
severity: normal
status: open
title: possible memory corruption caused by for-loop iteration over namespace.items() in a metaclass defining __new__
type: security
versions: Python 3.2
Added file: http://bugs.python.org/file32975/bug.py

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

From report at bugs.python.org  Wed Dec  4 23:24:04 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 04 Dec 2013 22:24:04 +0000
Subject: [New-bugs-announce] [issue19889] Revision information missing in
	Python 2.6.9
Message-ID: <1386195844.48.0.422896325461.issue19889@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

Not sure whether this can be considered a bug, but Python 2.6.7 for example showed the build revision in the sys.version:

>>> sys.version
'2.6.7 (r267:88850, Feb  9 2012, 18:56:05) \n[GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292]]'

whereas Python 2.6.9 does not:

>>> sys.version
'2.6.9 (unknown, Dec  4 2013, 18:39:21) \n[GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292]]'

----------
components: Build
messages: 205256
nosy: lemburg
priority: normal
severity: normal
status: open
title: Revision information missing in Python 2.6.9
versions: Python 2.6

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

From report at bugs.python.org  Thu Dec  5 00:04:12 2013
From: report at bugs.python.org (Antony Lee)
Date: Wed, 04 Dec 2013 23:04:12 +0000
Subject: [New-bugs-announce] [issue19890] Typo in multiprocessing docs
Message-ID: <1386198252.12.0.881873603907.issue19890@psf.upfronthosting.co.za>


New submission from Antony Lee:

The docs for multiprocessing refer to BaseProxy._callMethod() while it should be _callmethod.

----------
assignee: docs at python
components: Documentation
messages: 205261
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Typo in multiprocessing docs
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Dec  5 05:22:10 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 05 Dec 2013 04:22:10 +0000
Subject: [New-bugs-announce] [issue19891] Exiting Python REPL prompt with
	user without home	directory throws error in atexit._run_exitfuncs
Message-ID: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

$ sudo adduser --no-create-home cutecat
Adding user `cutecat' ...
Adding new group `cutecat' (1007) ...
Adding new user `cutecat' (1005) with group `cutecat' ...
Not creating home directory `/home/cutecat'.
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
Changing the user information for cutecat
Enter the new value, or press ENTER for the default
	Full Name []: 
	Room Number []: 
	Work Phone []: 
	Home Phone []: 
	Other []: 
Is the information correct? [Y/n] Y

$ su cutecat
Password: 

$ ./python
Python 3.4.0b1 (default:1f1498fe50e5, Dec  5 2013, 09:48:25) 
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
Error in atexit._run_exitfuncs:
FileNotFoundError: [Errno 2] No such file or directory
$

Python 2.7 and 3.3 do not throw error.

$ ./python
Python 3.3.3+ (3.3:07425df887b5+, Dec  2 2013, 12:27:06) 
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
[60778 refs]
[41580 refs]
$

$ ./python
Python 2.7.6+ (2.7:181ced5bf0be, Dec  4 2013, 11:23:42) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
$

----------
components: Extension Modules
messages: 205273
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Exiting Python REPL prompt with user without home directory throws error in atexit._run_exitfuncs
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Dec  5 06:39:22 2013
From: report at bugs.python.org (Jean Jordaan)
Date: Thu, 05 Dec 2013 05:39:22 +0000
Subject: [New-bugs-announce] [issue19892] register.send_metadata fails with
	EOFError: EOF when	reading a line
Message-ID: <1386221962.86.0.663845329774.issue19892@psf.upfronthosting.co.za>


New submission from Jean Jordaan:

On Ubuntu 12.04, using https://pypi.python.org/pypi/zest.releaser

./bin/release
[...]
INFO: Running: /.../bin/python setup.py register sdist --formats=zip upload
Showing first few lines...
running register
running egg_info
writing requirements to Products.CMFPlomino.egg-info/requires.txt
writing Products.CMFPlomino.egg-info/PKG-INFO
writing namespace_packages to Products.CMFPlomino.egg-info/namespace_packages.txt
...
Showing last few lines...
    self.send_metadata()
  File "/home/jean/zope/plomino/Python-2.7/lib/python2.7/distutils/command/register.py", line 149, in send_metadata
    choice = raw_input()
EOFError: EOF when reading a line

----------
components: Distutils
messages: 205275
nosy: neaj
priority: normal
severity: normal
status: open
title: register.send_metadata fails with EOFError: EOF when reading a line
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec  5 09:50:23 2013
From: report at bugs.python.org (Roman)
Date: Thu, 05 Dec 2013 08:50:23 +0000
Subject: [New-bugs-announce] [issue19893] Python cApi memory problem.
	Py_Initialize memory leak
Message-ID: <1386233423.48.0.18644500123.issue19893@psf.upfronthosting.co.za>


New submission from Roman:

I wrote small test program using Python cApi, and found some memory issues while working on it. I checked it with valgrind. (test code and valgrind output appended)
Maybe I'm doing something wrong, but most of the problem occurs durring Py_Initialize. I've checked python3.2.5 and 3.3.3 version. The latest version is much less confusing, but I can still see there something nasty. 
I would be grateful if you could look at this, and tell me If I'm doing something wrong, or if I can do something to prevent this memory issues.

----------
files: pytest.tgz
messages: 205283
nosy: rstarostecki
priority: normal
severity: normal
status: open
title: Python cApi memory problem. Py_Initialize memory leak
type: resource usage
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file32983/pytest.tgz

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

From report at bugs.python.org  Thu Dec  5 10:26:49 2013
From: report at bugs.python.org (Richard Milne)
Date: Thu, 05 Dec 2013 09:26:49 +0000
Subject: [New-bugs-announce] [issue19894] zipfile ignores deflate level
	settings in zipinfo object
Message-ID: <1386235609.47.0.431866049959.issue19894@psf.upfronthosting.co.za>


New submission from Richard Milne:

Reading the pkzip APPNOTE and the documentation for the zipfile module, I was under the impression that I could set the DEFLATE compression level, on a per-file basis, for each file added to an archive, by setting the appropriate bits in zipinfo.flag_bits.

You can't. Hence the attached patch, which updates the docs, tests and module source to enables this ability and makes the user aware of it.

----------
assignee: docs at python
components: Documentation, Library (Lib), Tests
files: zipfileinfo.diff
keywords: patch
messages: 205284
nosy: docs at python, rmilne
priority: normal
severity: normal
status: open
title: zipfile ignores deflate level settings in zipinfo object
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file32984/zipfileinfo.diff

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

From report at bugs.python.org  Thu Dec  5 11:35:46 2013
From: report at bugs.python.org (Antony Lee)
Date: Thu, 05 Dec 2013 10:35:46 +0000
Subject: [New-bugs-announce] [issue19895] Cryptic error when subclassing
	multiprocessing classes
Message-ID: <1386239746.14.0.69431016666.issue19895@psf.upfronthosting.co.za>


New submission from Antony Lee:

Classes defined in the multiprocessing module are in fact functions that call the internally defined class constructor with the "ctx" argument properly set; because of that, trying to subclass them yields a (very?) cryptic error message:

>>> import multiprocessing as m, multiprocessing.queues as q
>>> class Q(m.Queue): pass # normal attempt fails
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: function() argument 1 must be code, not str
>>> class Q(q.Queue): pass # that one works fine
... 

I guess the error message here could be improved, and the limitation and the workaround should be mentioned in the docs.  Even better would be to  have real classes directly in the multiprocessing module rather than wrappers, although I believe that would require sorting out some circular import issues.

----------
components: Library (Lib)
messages: 205286
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Cryptic error when subclassing multiprocessing classes
versions: Python 3.4

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

From report at bugs.python.org  Thu Dec  5 12:13:04 2013
From: report at bugs.python.org (Antony Lee)
Date: Thu, 05 Dec 2013 11:13:04 +0000
Subject: [New-bugs-announce] [issue19896] Exposing "q" and "Q" to
	multiprocessing.sharedctypes
Message-ID: <1386241984.18.0.408310965726.issue19896@psf.upfronthosting.co.za>


New submission from Antony Lee:

multiprocessing.sharedctypes was not updated after the "q" (c_longlong) and "Q" (c_ulonglong) typecodes were added to the array module (the docs claim that the typecode can be "one character typecode of the kind used by the array module").  The attached patch (just adding an entry to the typecode-to-type dict, as well as some more tests) fixes the issue.

----------
components: Library (Lib)
files: multiprocessing-longlong.patch
keywords: patch
messages: 205287
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Exposing "q" and "Q" to multiprocessing.sharedctypes
versions: Python 3.4
Added file: http://bugs.python.org/file32985/multiprocessing-longlong.patch

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

From report at bugs.python.org  Thu Dec  5 14:20:04 2013
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 05 Dec 2013 13:20:04 +0000
Subject: [New-bugs-announce] [issue19897] Use python as executable instead
	of python3 in Python 2	docs
Message-ID: <1386249604.0.0.838114607356.issue19897@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: fix-example-site.diff
keywords: patch
nosy: berker.peksag, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Use python as executable instead of python3 in Python 2 docs
versions: Python 2.7
Added file: http://bugs.python.org/file32988/fix-example-site.diff

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

From report at bugs.python.org  Thu Dec  5 16:16:53 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 05 Dec 2013 15:16:53 +0000
Subject: [New-bugs-announce] [issue19898] No tests for dequereviter_new
Message-ID: <1386256613.14.0.807664608281.issue19898@psf.upfronthosting.co.za>


New submission from Christian Heimes:

According to LCOV the dequereviter_new is never called by any test.

http://tiran.bitbucket.org/python-lcov/Modules/_collectionsmodule.c.gcov.html#1408

----------
components: Library (Lib), Tests
messages: 205305
nosy: christian.heimes, rhettinger
priority: low
severity: normal
stage: needs patch
status: open
title: No tests for dequereviter_new
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Dec  5 16:20:32 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 05 Dec 2013 15:20:32 +0000
Subject: [New-bugs-announce] [issue19899] No test for thread.interrupt_main()
Message-ID: <1386256832.82.0.17906161504.issue19899@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Accoring to LCOV thread_PyThread_interrupt_main() is never called by any test. It's only referenced by some idle code.

http://tiran.bitbucket.org/python-lcov/Modules/_threadmodule.c.gcov.html#1110

----------
messages: 205306
nosy: christian.heimes
priority: low
severity: normal
stage: needs patch
status: open
title: No test for thread.interrupt_main()
type: behavior

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

From report at bugs.python.org  Thu Dec  5 19:06:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 18:06:48 +0000
Subject: [New-bugs-announce] [issue19900] improve pickle intro
Message-ID: <1386266808.09.0.595733431093.issue19900@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This patch improved the generalities at the top of the pickle module docs.

----------
assignee: docs at python
components: Documentation
files: pickintro.patch
keywords: patch
messages: 205316
nosy: alexandre.vassalotti, docs at python, ncoghlan, pitrou, tim.peters
priority: normal
severity: normal
stage: patch review
status: open
title: improve pickle intro
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32995/pickintro.patch

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

From report at bugs.python.org  Thu Dec  5 21:59:45 2013
From: report at bugs.python.org (Reuben Garrett)
Date: Thu, 05 Dec 2013 20:59:45 +0000
Subject: [New-bugs-announce] [issue19901] tests fail due to unsupported
	SO_REUSEPORT when building	Python 3.3.2-r2
Message-ID: <1386277185.98.0.181450665143.issue19901@psf.upfronthosting.co.za>


New submission from Reuben Garrett:

When building Python 3.3.2-r2 from Gentoo's Portage tree [1], I encountered two failed tests which probably should not have been attempted on my OS (Gentoo 3.7.10): test_bind_port and test_find_unused_port both use the SO_REUSEPORT socket option which, to the best of my knowledge is only available since kernel version 3.9. I was able to build by skipping the tests ? but I believe the tests are there for a reason, and it would be best if a test that is known to fail should be skipped (or replaced with a fallback that is likely to succeed). Issue # 16594 [3] may be related (not sure).

Is it possible to detect the kernel version and skip (or modify) these tests if SO_REUSEPORT is not available? Better yet (since even a 3.9 kernel could have it disabled) ? try the test with SO_REUSEPORT, but trap the exception for lack of OS support, print a warning, and try again without SO_REUSEPORT. 

+=== excerpt of portage build log:
======================================================================
ERROR: test_bind_port (test.test_support.TestSupport)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/test_support.py", line 87, in test_bind_port
    support.bind_port(s)
  File "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/support.py", line 548, in bind_port
    if sock.getsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT) == 1:
OSError: [Errno 92] Protocol not available

======================================================================
ERROR: test_find_unused_port (test.test_support.TestSupport)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/test_support.py", line 80, in test_find_unused_port
    port = support.find_unused_port()
  File "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/support.py", line 522, in find_unused_port
    port = bind_port(tempsock)
  File "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/support.py", line 548, in bind_port
    if sock.getsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT) == 1:
OSError: [Errno 92] Protocol not available
===+

[1]: https://packages.gentoo.org/package/dev-lang/python
[2]: https://lwn.net/Articles/542629/
[3]: http://bugs.python.org/issue16594

----------
components: Build
messages: 205320
nosy: RubyTuesdayDONO
priority: normal
severity: normal
status: open
title: tests fail due to unsupported SO_REUSEPORT when building Python 3.3.2-r2
versions: Python 3.3

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

From report at bugs.python.org  Fri Dec  6 00:16:31 2013
From: report at bugs.python.org (follower)
Date: Thu, 05 Dec 2013 23:16:31 +0000
Subject: [New-bugs-announce] [issue19902] logging docs don't document
	integer constants
Message-ID: <1386285391.99.0.345532984259.issue19902@psf.upfronthosting.co.za>


New submission from follower:

The logging module documentation <http://docs.python.org/3.4/library/logging.html> makes reference to the levels DEBUG, INFO etc (e.g. in <http://docs.python.org/3.4/library/logging.html#logging.Logger.setLevel>) but AFAICT these constants are not documented in the module itself.

e.g I would expect a section like this

Level Constants
logging.DEBUG 10
logging.INFO  20
etc etc

(Although the actual values may not be listed depending on what your policy is for documenting "magic numbers".)

----------
assignee: docs at python
components: Documentation
messages: 205334
nosy: docs at python, follower
priority: normal
severity: normal
status: open
title: logging docs don't document integer constants
type: enhancement
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri Dec  6 01:21:46 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Dec 2013 00:21:46 +0000
Subject: [New-bugs-announce] [issue19903] Idle: Use inspect.signature for
	calltips
Message-ID: <1386289306.22.0.0855188637089.issue19903@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Change idlelib.CallTips.get_argspec to use inspect.signature, new in 3.3, instead of inspect.getfullargspec and inspect.formatargspec. One thing it handles better is a namedtuple class, which has a C-coded __init__ inherited from object a Python-coded __new__ written by namedtuple. Signature() will also handle C-coded functions if and when Argument Clinic (new in 3.4) adds signature information.

from collections import namedtuple
from inspect import signature

Point = namedtuple('Point', 'x y')
print(signature(Point.__new__))
# '(_cls, x, y)'
print(signature(Point))
# '(x, y)'

Note that str (called by print) is needed to get the desired string form.

There are tests in CallTips.py, but they should be converted to unittest, moved to idle_test/test_calltips.py, changed to match new output detail, and expanded to include new examples.

----------
assignee: terry.reedy
components: IDLE
messages: 205339
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle: Use inspect.signature for calltips
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec  6 03:04:23 2013
From: report at bugs.python.org (Fil Mackay)
Date: Fri, 06 Dec 2013 02:04:23 +0000
Subject: [New-bugs-announce] [issue19904] Add 128-bit integer support to
	struct
Message-ID: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>


New submission from Fil Mackay:

I've been looking at adding 128-bit support to the struct module. Currently only named integer types are supported, which vary in implementation. These include:

short
int
long
long long

Depending on the platform, none may translate to 128-bit integer (the case with all platforms today?).

One approach would be to make a new type that relates specifically to 128-bit integer, side-stepping the naming approaches to integer in C.

The other, would be to make new types for all integer sizes that relate to specific sizes, instead of relying on C namings. Much bigger implications?

I propose creating new types:

"o": __int128_t
"O": __uint128_t
"t": __int256_t (why not?)
"T": __uint256_t
"v": __int512_t (what, too far?)
"V": __int512_t

What implications are there here in killing the connection between a C named type and a specific size?

----------
components: ctypes
messages: 205344
nosy: fil
priority: normal
severity: normal
status: open
title: Add 128-bit integer support to struct
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Dec  6 03:07:34 2013
From: report at bugs.python.org (Fil Mackay)
Date: Fri, 06 Dec 2013 02:07:34 +0000
Subject: [New-bugs-announce] [issue19905] Add 128-bit integer support to
	ctypes
Message-ID: <1386295654.39.0.271762839295.issue19905@psf.upfronthosting.co.za>


New submission from Fil Mackay:

This depends on struct issue #19904, and involves adding the following types:

c_int128
c_uint128
c_int256 (maybe?)
c_uint256
c_int512 (too much?)
c_uint512

After resolution of the struct issue, this implementation will become clearer.

----------
components: ctypes
messages: 205345
nosy: fil
priority: normal
severity: normal
status: open
title: Add 128-bit integer support to ctypes
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Dec  6 11:46:04 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 06 Dec 2013 10:46:04 +0000
Subject: [New-bugs-announce] [issue19906] Typo in urllib documentation
Message-ID: <1386326764.33.0.520291465102.issue19906@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

In the first note from urllib.rst, there is a reference to urllib being replaced by urllib2 in Python 3, which is False.

----------
assignee: docs at python
components: Documentation
files: urllib2.patch
keywords: patch
messages: 205359
nosy: Claudiu.Popa, docs at python
priority: normal
severity: normal
status: open
title: Typo in urllib documentation
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file33002/urllib2.patch

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

From report at bugs.python.org  Fri Dec  6 12:20:33 2013
From: report at bugs.python.org (=?utf-8?q?Michael_M=C3=BCller?=)
Date: Fri, 06 Dec 2013 11:20:33 +0000
Subject: [New-bugs-announce] [issue19907] gettext - Non ascii chars in header
Message-ID: <1386328833.52.0.797354581277.issue19907@psf.upfronthosting.co.za>


New submission from Michael M?ller:

When having non ascii chars in the header of an translation file (xxx.po) the following error will be raised:

  File "D:\Python33\lib\gettext.py", line 410, in translation
    t = _translations.setdefault(key, class_(fp))
  File "D:\Python33\lib\gettext.py", line 160, in __init__
    self._parse(fp)
  File "D:\Python33\lib\gettext.py", line 265, in _parse
    item = b_item.decode().strip()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 51: invalid continuation byte

translation file head:

"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2013-12-06 11:47\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE+Mitteleurop?ische Zeit\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <LL at li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: utf-8\n"
"Generated-By: pygettext.py 1.5\n"

The problem here exists with the PO-Revision-Date which is followed by the timezone offset in current language (here "Mitteleurop?ische Zeit") which is automatically added by pygettext.py.
When removing it the file will work without any problems.

Current pygettext.py code part:
[Line 444] ...
    def write(self, fp):
        options = self.__options
        timestamp = time.strftime('%Y-%m-%d %H:%M+%Z')
        # The time stamp in the header doesn't have the same format as that
        # generated by xgettext...
        print(pot_header % {'time': timestamp, 'version': __version__}, file=fp)
...

To avoid this it would be better to use gmtime and not to append the timezone:

...
    def write(self, fp):
        options = self.__options
        timestamp = time.strftime('%Y-%m-%d %H:%M', time.gmtime())
...

----------
components: Library (Lib)
messages: 205361
nosy: Michael.M?ller
priority: normal
severity: normal
status: open
title: gettext - Non ascii chars in header
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Dec  6 12:50:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 11:50:09 +0000
Subject: [New-bugs-announce] [issue19908] pathlib.PureWindowsPath doesn't
	join relative paths	correctly when a drive is present
Message-ID: <1386330609.63.0.822642752717.issue19908@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> pathlib.PureWindowsPath('C:/a/b').joinpath('D:x/y')
PureWindowsPath('D:/a/b/D:/x/y')

See also issue19456.

----------
components: Library (Lib)
messages: 205364
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: pathlib.PureWindowsPath doesn't join relative paths correctly when a drive is present
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Dec  6 14:13:48 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 06 Dec 2013 13:13:48 +0000
Subject: [New-bugs-announce] [issue19909] Best practice docs for new SSL
	features
Message-ID: <1386335628.48.0.996074662164.issue19909@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The new ssl-module features #19509 (check_hostname) and  #19689 (create_default_context) need more documentation, a whatsnew entry and a best-practice paragraph in the ssl documentation.

----------
assignee: christian.heimes
components: Documentation
messages: 205367
nosy: christian.heimes
priority: high
severity: normal
stage: needs patch
status: open
title: Best practice docs for new SSL features
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Dec  6 17:12:46 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 16:12:46 +0000
Subject: [New-bugs-announce] [issue19910] Document that compile() source may
	be bytes
Message-ID: <1386346366.06.0.667657442144.issue19910@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

compile() takes a string, bytes or AST as the "source" argument.  The bytes option are not documented except in the error message you get when you pass something else.  The AST option is in the library docs but not in the function docstring.

----------
assignee: docs at python
components: Documentation
messages: 205383
nosy: docs at python, gvanrossum
priority: normal
severity: normal
status: open
title: Document that compile() source may be bytes
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec  6 19:18:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 18:18:26 +0000
Subject: [New-bugs-announce] [issue19911] ntpath.splitdrive() fails when UNC
	part contains \u0130
Message-ID: <1386353906.42.0.949556557512.issue19911@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

ntpath.splitdrive() returns wrong result when UNC part contains LATIN CAPITAL LETTER I WITH DOT ABOVE ('?', '\u0130').

>>> ntpath.splitdrive('//host/I/abc')
('//host/I', '/abc')
>>> ntpath.splitdrive('//host/?/abc')
('//host/?/', 'abc')
>>> ntpath.splitdrive('//host/??/abc')
('//host/??/a', 'bc')
>>> ntpath.splitdrive('//host/???/abc')
('//host/???/ab', 'c')

This is because ntpath.splitdrive() find an index for a split in normcased path and len('\u0130'.lower()) != 1.

----------
components: Library (Lib)
messages: 205392
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: ntpath.splitdrive() fails when UNC part contains \u0130
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec  6 20:02:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 19:02:51 +0000
Subject: [New-bugs-announce] [issue19912] ntpath.splitunc() is broken and
	not tested
Message-ID: <1386356571.53.0.00350504550121.issue19912@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

ntpath.splitunc() returns illegal results when path contains redundant slashes.

>>> import ntpath
>>> ntpath.splitunc("\\\\\\conky\\mountpoint\\foo\\bar")
('\\\\\\conky', '\\mountpoint\\foo\\bar')
>>> ntpath.splitunc("///conky/mountpoint/foo/bar")
('///conky', '/mountpoint/foo/bar')
>>> ntpath.splitunc("\\\\conky\\\\mountpoint\\foo\\bar")
('\\\\conky\\', '\\mountpoint\\foo\\bar')

It also affected by a bug from issue19911.

It also emits warnings in wrong place (from stdlib, not from places where it is used).

It has no tests.

Proposed patch fixes these issues.

----------
assignee: serhiy.storchaka
components: Library (Lib), Tests
files: ntpath_splitunc.patch
keywords: patch
messages: 205394
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: ntpath.splitunc() is broken and not tested
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33010/ntpath_splitunc.patch

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

From report at bugs.python.org  Fri Dec  6 22:13:58 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 06 Dec 2013 21:13:58 +0000
Subject: [New-bugs-announce] [issue19913] TR/Crypt.XPACK.Gen-4 in
	easy_install.exe
Message-ID: <1386364438.99.0.869672605432.issue19913@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Since today test_venv fails because Avira Antivir claims that easy_install.exe contains the trojan horse TR/Crypt.XPACK.Gen-4. I haven't seen the issue before. I'm running CPython default on Windows 7 64bit with Avira 13.

----------
files: easyinstall.png
messages: 205402
nosy: christian.heimes, dstufft, larry, ncoghlan
priority: release blocker
severity: normal
status: open
title: TR/Crypt.XPACK.Gen-4 in easy_install.exe
type: security
versions: Python 3.4
Added file: http://bugs.python.org/file33012/easyinstall.png

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

From report at bugs.python.org  Sat Dec  7 00:27:27 2013
From: report at bugs.python.org (HCT)
Date: Fri, 06 Dec 2013 23:27:27 +0000
Subject: [New-bugs-announce] [issue19914] help([object]) returns "Not enough
	memory." on standard	Python types, object and object functions
Message-ID: <1386372447.57.0.257737240226.issue19914@psf.upfronthosting.co.za>


New submission from HCT:

not sure if this ever worked. first time using help([object]), but these should work according to the documentation. OS is Win7 SP1 32-bit.

Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> help(list)
Not enough memory.

>>> help(list())
Not enough memory.

>>> help([])
Not enough memory.

>>> help(tuple())
Not enough memory.

>>> help(())
Not enough memory.

>>> help(str.format)
Not enough memory.

>>> help(str)
Not enough memory.

>>> help(b'1234')
Not enough memory.

>>> help(str.strip)
Not enough memory.

>>> help(str.count)
Not enough memory.

>>>

----------
components: Interpreter Core
messages: 205413
nosy: hct
priority: normal
severity: normal
status: open
title: help([object]) returns "Not enough memory." on standard Python types, object and object functions
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Dec  7 01:27:06 2013
From: report at bugs.python.org (anon)
Date: Sat, 07 Dec 2013 00:27:06 +0000
Subject: [New-bugs-announce] [issue19915] int.bit_at(n) - Accessing a single
	bit in O(1)
Message-ID: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>


New submission from anon:

For many numeric algorithms it's useful to be able to read individual bits at a location in an integer. Currently there is no efficient way to do this. The following function is the closest to this:

def bit_at(i, n): return (i>>n)&1

However in computing the intermediate result i>>n we must spend O(b-n) time at least (where b is n.bit_length()). It should be possible to read bits in O(1) time. Adding int.bit_at(n) would complement int.bit_length().

I would suggest making the semantics of i.bit_at(n) the same as (i>>n)&1. Although the exact meaning when i is negative should be considered.

Real world uses of bit_at include binary exponentiation and bit counting algorithms.

----------
messages: 205421
nosy: anon
priority: normal
severity: normal
status: open
title: int.bit_at(n) - Accessing a single bit in O(1)
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Dec  7 07:25:24 2013
From: report at bugs.python.org (soumen ganguly)
Date: Sat, 07 Dec 2013 06:25:24 +0000
Subject: [New-bugs-announce] [issue19916] urllib2 fails on https, SSL broken.
Message-ID: <1386397524.1.0.0289783025044.issue19916@psf.upfronthosting.co.za>


New submission from soumen ganguly:

>>import urllib2
>>urllib2.urlopen('https://example.com')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/urllib2.py", line 127, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 404, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 427, in _open
    'unknown_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1249, in unknown_open
    raise URLError('unknown url type: %s' % type)
urllib2.URLError: <urlopen error unknown url type: https>
------------------------------------------------------------------------
>>import ssl
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/ssl.py", line 60, in <module>
    import _ssl             # if we can't import it, let the error propagate
ImportError: /usr/lib/python2.7/lib-dynload/_ssl.so: symbol SSLeay_version, version OPENSSL_1.0.1 not defined in file libcrypto.so.10 with link time reference

----------
components: Build
messages: 205439
nosy: sganguly
priority: normal
severity: normal
status: open
title: urllib2 fails on https,SSL broken.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Dec  7 11:44:40 2013
From: report at bugs.python.org (Matej Cepl)
Date: Sat, 07 Dec 2013 10:44:40 +0000
Subject: [New-bugs-announce] [issue19917] [httplib] logging information for
	request is not pretty	printed
Message-ID: <1386413080.92.0.351429113589.issue19917@psf.upfronthosting.co.za>


New submission from Matej Cepl:

looking at
http://hg.python.org/cpython/file/543c76769c14/Lib/http/client.py#l847
(logging in HTTPConnection.send method; but this code has been same since like forever) I see that the HTTP request is NOT pretty printed:

     if self.debuglevel > 0:
         print("send:", repr(data))

whereas response in effect (because every header is printed separately) is. Wouldn't it be better to pretty print the request as well?

Otherwise I get quite unreadable debugging logs like the following (notice how much response is more readable than request).

It seems to me that proper solution could be just to replace repr() here with something more readable. Wouldn't just str() help? Barring that we can go all the way to pprint.pformat().

----------
components: Library (Lib)
files: urllib2-kerberos-log.txt
messages: 205446
nosy: mcepl
priority: normal
severity: normal
status: open
title: [httplib] logging information for request is not pretty printed
Added file: http://bugs.python.org/file33021/urllib2-kerberos-log.txt

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

From report at bugs.python.org  Sat Dec  7 12:02:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 11:02:31 +0000
Subject: [New-bugs-announce] [issue19918] PureWindowsPath.relative_to() is
	not case insensitive
Message-ID: <1386414151.7.0.591578690469.issue19918@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import pathlib
>>> pathlib.PureWindowsPath('C:/Foo/Bar').relative_to('C:/Foo')
PureWindowsPath('Bar')
>>> pathlib.PureWindowsPath('C:/Foo/Bar').relative_to('C:/foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/pathlib.py", line 797, in relative_to
    .format(str(self), str(formatted)))
ValueError: 'C:\\Foo\\Bar' does not start with 'C:\\foo'
>>> pathlib.PureWindowsPath('C:/Foo/Bar').relative_to('c:/Foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/pathlib.py", line 797, in relative_to
    .format(str(self), str(formatted)))
ValueError: 'C:\\Foo\\Bar' does not start with 'c:\\Foo'

It also returns strange result when an argument is naked drive:

>>> pathlib.PureWindowsPath('C:/Foo/Bar').relative_to('C:')
PureWindowsPath('//Foo/Bar')

----------
components: Library (Lib)
messages: 205448
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: PureWindowsPath.relative_to() is not case insensitive
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Dec  7 17:48:37 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 07 Dec 2013 16:48:37 +0000
Subject: [New-bugs-announce] [issue19919] SSL: test_connect_ex_error fails
	with EWOULDBLOCK
Message-ID: <1386434917.9.0.425282577519.issue19919@psf.upfronthosting.co.za>


New submission from Christian Heimes:

On Windows the test_connect_ex_error sometimes fails with EWOULDBLOCK instead of ECONNREFUSED. Valhallasw sometimes gets the same error with an Ubuntu VM on Windows. This might be a Windows socket issue. 

======================================================================
FAIL: test_connect_ex_error (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_ssl.py", line 1205, in test_connect_ex_error
    s.connect_ex(("svn.python.org", 444)))
AssertionError: 10061 != 10035

>>> for k, v in errno.__dict__.items():
...     if v == 10035: print(k)
...
EWOULDBLOCK
WSAEWOULDBLOCK
>>> for k, v in errno.__dict__.items():
...     if v == 10061: print(k)
...
WSAECONNREFUSED
ECONNREFUSED

----------
components: Tests
messages: 205467
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: SSL: test_connect_ex_error fails with EWOULDBLOCK
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Dec  7 18:37:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 17:37:40 +0000
Subject: [New-bugs-announce] [issue19920] TarFile.list() fails on some files
Message-ID: <1386437860.38.0.0478693655005.issue19920@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

TarFile.list() fails on some files. In particular on Lib/test/testtar.tar.

>>> import tarfile
>>> tarfile.open('Lib/test/testtar.tar').list()
?rw-r--r-- tarfile/tarfile       7011 2003-01-06 01:19:43 ustar/conttype 
?rw-r--r-- tarfile/tarfile       7011 2003-01-06 01:19:43 ustar/regtype 
?rwxr-xr-x tarfile/tarfile          0 2003-01-06 01:19:43 ustar/dirtype/ 
?rwxr-xr-x tarfile/tarfile        255 2003-01-06 01:19:43 ustar/dirtype-with-size/ 
?rw-r--r-- tarfile/tarfile          0 2003-01-06 01:19:43 ustar/lnktype link to ustar/regtype 
?rwxrwxrwx tarfile/tarfile          0 2003-01-06 01:19:43 ustar/symtype -> regtype 
?rw-rw---- tarfile/tarfile        3,0 2003-01-06 01:19:43 ustar/blktype 
?rw-rw-rw- tarfile/tarfile        1,3 2003-01-06 01:19:43 ustar/chrtype 
?rw-r--r-- tarfile/tarfile          0 2003-01-06 01:19:43 ustar/fifotype 
?rw-r--r-- tarfile/tarfile      86016 2003-01-06 01:19:43 ustar/sparse 
?rw-r--r-- tarfile/tarfile       7011 2003-01-06 01:19:43 Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1846, in list
    print(tarinfo.name + ("/" if tarinfo.isdir() else ""), end=' ')
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcc4' in position 14: surrogates not allowed

Command-line interface of the tarfile module also fails:

$ ./python -m tarfile -v -l Lib/test/testtar.tar
?rw-r--r-- tarfile/tarfile       7011 2003-01-06 01:19:43 ustar/conttype 
?rw-r--r-- tarfile/tarfile       7011 2003-01-06 01:19:43 ustar/regtype 
?rwxr-xr-x tarfile/tarfile          0 2003-01-06 01:19:43 ustar/dirtype/ 
?rwxr-xr-x tarfile/tarfile        255 2003-01-06 01:19:43 ustar/dirtype-with-size/ 
?rw-r--r-- tarfile/tarfile          0 2003-01-06 01:19:43 ustar/lnktype link to ustar/regtype 
?rwxrwxrwx tarfile/tarfile          0 2003-01-06 01:19:43 ustar/symtype -> regtype 
?rw-rw---- tarfile/tarfile        3,0 2003-01-06 01:19:43 ustar/blktype 
?rw-rw-rw- tarfile/tarfile        1,3 2003-01-06 01:19:43 ustar/chrtype 
?rw-r--r-- tarfile/tarfile          0 2003-01-06 01:19:43 ustar/fifotype 
?rw-r--r-- tarfile/tarfile      86016 2003-01-06 01:19:43 ustar/sparse 
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 2500, in <module>
    main()
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 2444, in main
    tf.list(verbose=args.verbose)
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1846, in list
    print(tarinfo.name + ("/" if tarinfo.isdir() else ""), end=' ')
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcc4' in position 14: surrogates not allowed
?rw-r--r-- tarfile/tarfile       7011 2003-01-06 01:19:43 serhiy at raxxla:~/py/cpython$

----------
components: IO, Library (Lib), Unicode
messages: 205475
nosy: benjamin.peterson, ezio.melotti, haypo, lars.gustaebel, lemburg, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: TarFile.list() fails on some files
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Dec  7 19:35:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 18:35:58 +0000
Subject: [New-bugs-announce] [issue19921] Path.mkdir(0, True) always fails
Message-ID: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Path.mkdir() can't create a directory with cleared write or list permission bits for owner when parent directories aren't created. This is because for parent directories same mode is used as for final directory.

To support this use case we should implicitly set write and list permission bits for owner when creating parent directories.

I don't know if this work on Windows.

----------
components: Library (Lib)
files: pathlib_mkdir_mode.patch
keywords: patch
messages: 205477
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Path.mkdir(0, True) always fails
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33027/pathlib_mkdir_mode.patch

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

From report at bugs.python.org  Sat Dec  7 21:59:38 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 07 Dec 2013 20:59:38 +0000
Subject: [New-bugs-announce] [issue19922] mbstate_t requires
	_INCLUDE__STDC_A1_SOURCE
Message-ID: <1386449978.34.0.25024018047.issue19922@psf.upfronthosting.co.za>


New submission from Christian Heimes:

On HP-UX mbstate_t for mbrtowc() is only available when _INCLUDE__STDC_A1_SOURCE is defined:

http://buildbot.python.org/all/builders/PA-RISC%20HP-UX%2011iv2%20%5BSB%5D%203.x/builds/2543/steps/compile/logs/stdio

	cc -Ae -c  -O  -O   -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c
cc: "Objects/unicodeobject.c", line 3493: error 1000: Unexpected symbol: "mbs".
cc: "Objects/unicodeobject.c", line 3493: error 1588: "mbstate_t" undefined.
cc: "Objects/unicodeobject.c", line 3497: error 1588: "mbs" undefined.
cc: "Objects/unicodeobject.c", line 3497: warning 563: Argument #1 is not the correct type.
cc: "Objects/unicodeobject.c", line 3497: error 1594: The sizeof operator cannot be applied to types with unknown size.

----------
messages: 205486
nosy: christian.heimes, trent
priority: low
severity: normal
stage: needs patch
status: open
title: mbstate_t requires _INCLUDE__STDC_A1_SOURCE
type: compile error
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Dec  7 22:23:20 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 21:23:20 +0000
Subject: [New-bugs-announce] [issue19923] OSError: [Errno 512] Unknown error
	512 in	test_multiprocessing
Message-ID: <1386451400.97.0.885839707191.issue19923@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This rather weird error occurred on a buildbot:
http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/9297

[346/387] test_multiprocessing_forkserver
Process Process-497:
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 616, in wait
    self._wait(timeout)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 651, in _wait
    if not self._cond.wait_for(lambda : self._state != 0, timeout):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/synchronize.py", line 326, in wait_for
    self.wait(waittime)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/synchronize.py", line 270, in wait
    self._lock.acquire()
OSError: [Errno 512] Unknown error 512

----------
components: Library (Lib)
keywords: buildbot
messages: 205488
nosy: neologix, pitrou, sbt
priority: normal
severity: normal
status: open
title: OSError: [Errno 512] Unknown error 512 in test_multiprocessing
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec  8 01:24:58 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 08 Dec 2013 00:24:58 +0000
Subject: [New-bugs-announce] [issue19924] test_venv fails with
	--without-threads
Message-ID: <1386462298.14.0.707345567423.issue19924@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The test fails when Python is compiled --without-threads. Two 3rd party modules import threading unconditionally:

pip/_vendor/distlib/util.py
  import threading

pip/_vendor/requests/packages/urllib3/_collections.py
  from threading import RLock

----------
messages: 205503
nosy: christian.heimes, dstufft, ncoghlan, vinay.sajip
priority: high
severity: normal
stage: needs patch
status: open
title: test_venv fails with --without-threads
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec  8 05:20:32 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 08 Dec 2013 04:20:32 +0000
Subject: [New-bugs-announce] [issue19925] Add unit test for spwd module
Message-ID: <1386476432.59.0.431887490027.issue19925@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

So we may have buildbot with root account after all. https://mail.python.org/pipermail/python-dev/2013-December/130708.html

So here is the unit test for spwd module that requires root account.

----------
components: Tests
files: unittest_for_spwd.patch
keywords: patch
messages: 205513
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Add unit test for spwd module
versions: Python 3.4
Added file: http://bugs.python.org/file33034/unittest_for_spwd.patch

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

From report at bugs.python.org  Sun Dec  8 05:47:50 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 08 Dec 2013 04:47:50 +0000
Subject: [New-bugs-announce] [issue19926] Refactor unit test in abstract
	numbers test
Message-ID: <1386478070.8.0.430049074258.issue19926@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

There are superfluous lines and unused import in Lib/test/test_abstract_numbers.py.

Attached the patch to remove superfluous lines and unused import.

----------
components: Tests
files: refactor_test_abstract_number.patch
keywords: patch
messages: 205514
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Refactor unit test in abstract numbers test
versions: Python 3.4
Added file: http://bugs.python.org/file33036/refactor_test_abstract_number.patch

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

From report at bugs.python.org  Sun Dec  8 06:08:13 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 08 Dec 2013 05:08:13 +0000
Subject: [New-bugs-announce] [issue19927] Path-based loaders lack a
	meaningful __eq__()	implementation.ModuleSpec.__eq__() is
	highly sensitive to	loader.__eq__()
Message-ID: <1386479293.44.0.514721108706.issue19927@psf.upfronthosting.co.za>


New submission from Eric Snow:

ModuleSpec.__eq__() does a comparision of its various attributes, one of them being the loader.  However, the __eq__() of the path-based loaders is just the stock one that compares object identity.  So most

----------
messages: 205515
nosy: brett.cannon, eric.snow, ncoghlan
priority: high
severity: normal
stage: test needed
status: open
title: Path-based loaders lack a meaningful __eq__() implementation.ModuleSpec.__eq__() is highly sensitive to loader.__eq__()
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec  8 09:48:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 08:48:40 +0000
Subject: [New-bugs-announce] [issue19928] Implement cell repr test
Message-ID: <1386492520.71.0.633651431528.issue19928@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Repr test for cell is empty. Proposed patch implements it.

----------
components: Tests
files: test_cell_repr.patch
keywords: patch
messages: 205528
nosy: serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Implement cell repr test
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33039/test_cell_repr.patch

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

From report at bugs.python.org  Sun Dec  8 10:38:10 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Dec 2013 09:38:10 +0000
Subject: [New-bugs-announce] [issue19929] subprocess: increase read buffer
	size
Message-ID: <1386495490.95.0.0341161010002.issue19929@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

This is a spinoff of issue #19506: currently, subprocess.communicate() uses a 4K buffer when reading data from pipes.
This was probably optimal a couple years ago, but nowadays most operating systems have larger pipes (e.g. Linux has 64K), so we might be able to gain some performance by increasing this buffer size.

For example, here's a benchmark reading from a subprocess spawning "dd if=/dev/zero bs=1M count=100":

# before, 4K buffer
$ ./python ~/test_sub_read.py 
2.72450800300021

# after, 64K buffer
$ ./python ~/test_sub_read.py 
1.2509000449999803

The difference is impressive.

I'm attaching the benchmark script so that others can experiment a bit (on multi-core machines and also different OSes).

----------
components: Library (Lib)
files: test_sub_read.py
messages: 205534
nosy: gregory.p.smith, haypo, neologix, pitrou, sbt, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: subprocess: increase read buffer size
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file33041/test_sub_read.py

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

From report at bugs.python.org  Sun Dec  8 12:09:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 11:09:05 +0000
Subject: [New-bugs-announce] [issue19930] os.makedirs('dir1/dir2',
	0) always fails
Message-ID: <1386500945.84.0.693179822476.issue19930@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

os.makedirs() can't create a directory with cleared write or list permission bits for owner when parent directories aren't created. This is because for parent directories same mode is used as for final directory.

Note that the mkdir utility creates parent directories with default mode (0o777 & ~umask).

$ mkdir -p -m 0 t1/t2/t3
$ ls -l -d t1 t1/t2 t1/t2/t3
drwxrwxr-x 3 serhiy serhiy 4096 Dec  7 22:30 t1/
drwxrwxr-x 3 serhiy serhiy 4096 Dec  7 22:30 t1/t2/
d--------- 2 serhiy serhiy 4096 Dec  7 22:30 t1/t2/t3/

The proposed patch emulates the mkdir utility.

See also issue19921.

----------
components: Library (Lib)
messages: 205543
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: os.makedirs('dir1/dir2', 0) always fails
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Dec  8 17:46:54 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 08 Dec 2013 16:46:54 +0000
Subject: [New-bugs-announce] [issue19931] namedtuple docstrings are verbose
	for no added benefit
Message-ID: <1386521214.76.0.425352875537.issue19931@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

When I make a namedtuple, I get automatic docstrings that use a lot of words to say very little.  Sphinx autodoc produces this:

```
class Key

    Key(scope, user_id, block_scope_id, field_name)

    __getnewargs__()

        Return self as a plain tuple. Used by copy and pickle.

    __repr__()

        Return a nicely formatted representation string

    block_scope_id None

        Alias for field number 2

    field_name None

        Alias for field number 3

    scope None

        Alias for field number 0

    user_id None

        Alias for field number 1
```
The individual property docstrings offer no new information over the summary at the top.   I'd like namedtuple to be not so verbose where it has no useful information to offer.  The one-line summary is all the information namedtuple has, so that is all it should include in the docstring:

```
class Key

    Key(scope, user_id, block_scope_id, field_name)
```

----------
components: Library (Lib)
messages: 205584
nosy: nedbat
priority: normal
severity: normal
status: open
title: namedtuple docstrings are verbose for no added benefit
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Dec  8 21:57:11 2013
From: report at bugs.python.org (Ziyuan Lin)
Date: Sun, 08 Dec 2013 20:57:11 +0000
Subject: [New-bugs-announce] [issue19932] Missing spaces in import.h?
Message-ID: <1386536231.5.0.310444534169.issue19932@psf.upfronthosting.co.za>


New submission from Ziyuan Lin:

In Include\import.h, line 89-97:

PyAPI_FUNC(PyObject *)_PyImport_FindBuiltin(
    const char *name            /* UTF-8 encoded string */
    );
PyAPI_FUNC(PyObject *)_PyImport_FindExtensionObject(PyObject *, PyObject *);
PyAPI_FUNC(int)_PyImport_FixupBuiltin(
    PyObject *mod,
    char *name                  /* UTF-8 encoded string */
    );
PyAPI_FUNC(int)_PyImport_FixupExtensionObject(PyObject*, PyObject *, PyObject *);


Shouldn't they be the following:

PyAPI_FUNC(PyObject *) _PyImport_FindBuiltin(
    const char *name            /* UTF-8 encoded string */
    );
PyAPI_FUNC(PyObject *) _PyImport_FindExtensionObject(PyObject *, PyObject *);
PyAPI_FUNC(int)_PyImport_FixupBuiltin(
    PyObject *mod,
    char *name                  /* UTF-8 encoded string */
    );
PyAPI_FUNC(int) _PyImport_FixupExtensionObject(PyObject*, PyObject *, PyObject *);

----------
messages: 205605
nosy: Ziyuan.Lin
priority: normal
severity: normal
status: open
title: Missing spaces in import.h?
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Mon Dec  9 05:24:20 2013
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Mon, 09 Dec 2013 04:24:20 +0000
Subject: [New-bugs-announce] [issue19933] Round default argument for
	"ndigits"
Message-ID: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo:

>From the docs for built-in function "round":
   "If ndigits is omitted, it defaults to zero"
   (http://docs.python.org/3/library/functions.html#round)

But, the only way to get an integer from `round` is by not having the second argument (ndigits):

    >>> round(3.5)
    4
    >>> round(3.5, 1)
    3.5
    >>> round(3.5, 0)
    4.0
    >>> round(3.5, -1)
    0.0
    >>> round(3.5, None)
    Traceback (most recent call last):
      File "<pyshell#6>", line 1, in <module>
        round(3.5, None)
    TypeError: 'NoneType' object cannot be interpreted as an integer


Either the docs are wrong or the behavior is wrong. I think it's easier to fix the former...

But also there should be a way to make round return an integer (e.g. passing `None` as 2nd argument)

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 205647
nosy: JBernardo, docs at python
priority: normal
severity: normal
status: open
title: Round default argument for "ndigits"
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec  9 05:54:38 2013
From: report at bugs.python.org (Matthew Gilson)
Date: Mon, 09 Dec 2013 04:54:38 +0000
Subject: [New-bugs-announce] [issue19934] collections.Counter.most_common
	does not document `None`	as acceptable input.
Message-ID: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za>


New submission from Matthew Gilson:

Reading the source for collections.Counter.most_common, the docstring mentions that `n` can be `None` or omitted, but the online documentation does not mention that `n` can be `None`.

----------
assignee: docs at python
components: Documentation
messages: 205648
nosy: docs at python, mgilson
priority: normal
severity: normal
status: open
title: collections.Counter.most_common does not document `None` as acceptable input.

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

From report at bugs.python.org  Mon Dec  9 10:58:25 2013
From: report at bugs.python.org (Yu Yang)
Date: Mon, 09 Dec 2013 09:58:25 +0000
Subject: [New-bugs-announce] [issue19935] IPv6 urlparse error on python 2.6
Message-ID: <1386583105.68.0.458235905987.issue19935@psf.upfronthosting.co.za>


New submission from Yu Yang:

Actually, there is a bug which has been fixed this issue on python 2.7 and python 3.3. http://bugs.python.org/issue2987. Open this issue aims for back port this fix to python 2.6.

----------
components: Library (Lib)
messages: 205657
nosy: yuyangbj
priority: normal
severity: normal
status: open
title: IPv6 urlparse error on python 2.6
type: enhancement
versions: Python 2.6

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

From report at bugs.python.org  Mon Dec  9 12:23:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 11:23:21 +0000
Subject: [New-bugs-announce] [issue19936] Executable permissions of Python
	source files
Message-ID: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Following files have executable permission bit but have no shebang ("#!"):

Lib/test/ssltests.py
Lib/test/test_pathlib.py
Lib/token.py
Tools/scripts/analyze_dxp.py
Tools/scripts/run_tests.py
Tools/scripts/win_add2path.py
Tools/stringbench/stringbench.py

I think executable bit should be cleared on them, because they can't be ran 
without correct shebang.

Following files have shebang but have no executable permission bit:

Doc/includes/email-alternative.py
Doc/includes/email-dir.py
Doc/includes/email-unpack.py
Lib/difflib.py
Lib/http/cookies.py
Lib/idlelib/PyShell.py
Lib/lib2to3/tests/data/different_encoding.py
Lib/lib2to3/tests/data/false_encoding.py
Lib/mailbox.py
Lib/operator.py
Lib/smtplib.py
Lib/tarfile.py
Lib/test/_test_multiprocessing.py
Lib/test/crashers/recursive_call.py
Lib/test/curses_tests.py
Lib/test/multibytecodec_support.py
Lib/test/test___future__.py
Lib/test/test_bz2.py
Lib/test/test_cmd.py
Lib/test/test_codecencodings_cn.py
Lib/test/test_codecencodings_hk.py
Lib/test/test_codecencodings_iso2022.py
Lib/test/test_codecencodings_jp.py
Lib/test/test_codecencodings_kr.py
Lib/test/test_codecencodings_tw.py
Lib/test/test_codecmaps_cn.py
Lib/test/test_codecmaps_hk.py
Lib/test/test_codecmaps_jp.py
Lib/test/test_codecmaps_kr.py
Lib/test/test_codecmaps_tw.py
Lib/test/test_dbm.py
Lib/test/test_dbm_dumb.py
Lib/test/test_eof.py
Lib/test/test_gzip.py
Lib/test/test_keywordonlyarg.py
Lib/test/test_logging.py
Lib/test/test_marshal.py
Lib/test/test_multibytecodec.py
Lib/test/test_popen.py
Lib/test/test_random.py
Lib/test/test_sched.py
Lib/test/test_smtpnet.py
Lib/test/test_socket.py
Lib/test/test_support.py
Lib/test/test_tcl.py
Lib/test/test_urllib2_localnet.py
Lib/test/test_urllib2net.py
Lib/test/test_urllibnet.py
Lib/test/test_with.py
Lib/test/test_xmlrpc_net.py
Lib/timeit.py
Lib/trace.py
Lib/turtledemo/bytedesign.py
Lib/turtledemo/clock.py
Lib/turtledemo/forest.py
Lib/turtledemo/fractalcurves.py
Lib/turtledemo/lindenmayer.py
Lib/turtledemo/minimal_hanoi.py
Lib/turtledemo/paint.py
Lib/turtledemo/peace.py
Lib/turtledemo/penrose.py
Lib/turtledemo/planet_and_moon.py
Lib/turtledemo/tree.py
Lib/turtledemo/two_canvases.py
Lib/turtledemo/yinyang.py
Lib/webbrowser.py
Mac/Tools/bundlebuilder.py
Mac/Tools/plistlib_generate_testdata.py
Modules/_ctypes/libffi/generate-ios-source-and-headers.py
Modules/_ctypes/libffi/generate-osx-source-and-headers.py
Modules/_decimal/tests/bench.py
Modules/_decimal/tests/deccheck.py
Modules/_decimal/tests/randdec.py
Objects/typeslots.py
Tools/clinic/clinic_test.py
Tools/gdb/libpython.py
Tools/i18n/makelocalealias.py
Tools/pybench/Setup.py
Tools/pybench/clockres.py
Tools/pybench/systimes.py
Tools/scripts/checkpip.py
Tools/ssl/make_ssl_data.py
Tools/test2to3/maintest.py
Tools/unicode/comparecodecs.py
Tools/unittestgui/unittestgui.py

I think most of them should got executable bit.

Exceptions are:

Doc/includes/*.py  -- they are just examples, it can be dangerous set 
executable bit on files which can be exposed via http server.

Lib/test/test_*.py -- they don't purposed to ran with with default system 
Python. Shebangs should be removed.

Lib/test/_test_multiprocessing.py, Lib/test/multibytecodec_support.py -- they 
are just auxiliary modules for other tests. Shebangs should be removed.

Lib/http/cookies.py, Lib/mailbox.py, Lib/operator.py, Modules/_decimal/tests/randdec.py -- they don't do anything. Shebangs should be removed.

Tools/test2to3/maintest.py -- this is Python2 script with Python3 shebang.

Lib/difflib.py -- this just runs doctests. Shebang should be removed.

Following files have shebang but have no executable permission bit. Both should be removed.

Lib/test/test_array.py
Lib/test/test_binhex.py
Lib/test/test_errno.py
Lib/test/test_urlparse.py
Lib/test/test_userstring.py

In Tools/unittestgui/unittestgui.py "python" should be changed to "python3" in the shebang.

Any thoughts?

----------
assignee: serhiy.storchaka
components: Demos and Tools, Library (Lib)
files: executable_scripts.patch
keywords: patch
messages: 205677
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Executable permissions of Python source files
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33056/executable_scripts.patch

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

From report at bugs.python.org  Mon Dec  9 14:33:40 2013
From: report at bugs.python.org (Ryan Z)
Date: Mon, 09 Dec 2013 13:33:40 +0000
Subject: [New-bugs-announce] [issue19937] IDLE can't be launch
Message-ID: <1386596020.76.0.208874282893.issue19937@psf.upfronthosting.co.za>


New submission from Ryan Z:

After I installed a wrong version pygame on OSX 10.9, and may updated something OSX, Then, I can't launch the IDLE, 
It appears on the dock, then quit at the same moment.


bogon:~ RyanZ$ /usr/local/bin/python3.3 -m idlelib
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/idlelib/__main__.py", line 9, in <module>
    idlelib.PyShell.main()
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/idlelib/PyShell.py", line 1572, in main
    shell.interp.runcommand(''.join(("print('", tkversionwarning, "')")))
AttributeError: 'NoneType' object has no attribute 'interp'

----------
assignee: ronaldoussoren
components: Macintosh
messages: 205692
nosy: Ryan.Z, ronaldoussoren
priority: normal
severity: normal
status: open
title: IDLE can't be launch
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Tue Dec 10 00:06:36 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 09 Dec 2013 23:06:36 +0000
Subject: [New-bugs-announce] [issue19938] Re-enable test_bug_1333982 on 3.x
Message-ID: <1386630396.24.0.124840868686.issue19938@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's a pair of patches which re-enable test_bug_1333982 in test_dis on 3.3 and 3.4; the major changes in 3.4 necessitate separate patches.  The patches also replace test_main with unittest.main which made trying to get the test to work much less annoying.

----------
components: Tests
files: test_dis_1333982-3.3.diff
keywords: patch
messages: 205750
nosy: ncoghlan, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Re-enable test_bug_1333982 on 3.x
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33069/test_dis_1333982-3.3.diff

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

From report at bugs.python.org  Tue Dec 10 06:54:41 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 10 Dec 2013 05:54:41 +0000
Subject: [New-bugs-announce] [issue19939] Deprecate portions or all of
	pkgutil module.
Message-ID: <1386654881.95.0.820542970377.issue19939@psf.upfronthosting.co.za>


New submission from Eric Snow:

In the last Python releases, particularly 3.3 and 3.4, we've made improvements to the import machinery that render (at least) portions of pkgutil obsolete.  Here's a breakdown of the public API of pkgutil:

get_importer() - duplicate of PathFinder._path_importer_cache()
iter_importers() - yields the path entry finder for each path entry
find_loader() - a parent-importing wrapper around (deprecated) importlib.find_loader()
get_loader() - looks at module.__loader__ or calls find_loader()
walk_packages() - loader-focused
iter_modules() - loader-focused
get_data() - a wrapper around the InspectLoader.get_data() API
read_code() - duplicates importlib functionality
extend_path() - no longer needed (namespace packages)
ImpImporter - already deprecated in favor of importlib
ImpLoader - already deprecated in favor of importlib

I would expect that nearly all of the module could be deprecated and any gaps in functionality ported to importlib.util.

Is it worth it to go to the effort?  To me the biggest thing would be identifying what functionality (e.g. locating all packages within a directory) in pkgutil is still relevant and should be distilled into public APIs in importlib.  The job of actually deprecating and porting code would mostly be mechanical and not even a large amount of work.

----------
components: Library (Lib)
messages: 205771
nosy: brett.cannon, eric.snow, ncoghlan, pje
priority: normal
severity: normal
stage: needs patch
status: open
title: Deprecate portions or all of pkgutil module.
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Dec 10 08:29:12 2013
From: report at bugs.python.org (akira)
Date: Tue, 10 Dec 2013 07:29:12 +0000
Subject: [New-bugs-announce] [issue19940] ssl.cert_time_to_seconds() returns
	wrong results if	local timezone is not UTC
Message-ID: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>


New submission from akira:

cert_time_to_seconds() uses `time.mktime()` [1] to convert utc time tuple to seconds since epoch. `mktime()` works with local time. It should use `calendar.timegm()` analog instead.

Example from the docs [2] is seven hours off (it shows utc offset of the local timezone of the person who created it):

    >>> import ssl
    >>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT")
    1178694000.0

It should be `1178668800`:

    >>> from datetime import datetime
    >>> datetime.utcfromtimestamp(1178668800)
    datetime.datetime(2007, 5, 9, 0, 0)
    >>> import time
    >>> time.gmtime(1178668800)
    time.struct_time(tm_year=2007, tm_mon=5, tm_mday=9, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=2, tm_yday=129, tm_isdst=0)


And `calendar.timegm` returns correct result:

    >>> calendar.timegm(time.strptime("May 9 00:00:00 2007 GMT", "%b %d %H:%M:%S %Y GMT"))
    1178668800

[1]: http://hg.python.org/cpython/file/96a68e369d13/Lib/ssl.py#l849
[2]: http://hg.python.org/cpython/file/96a68e369d13/Doc/library/ssl.rst#l359

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 205774
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Dec 10 12:04:57 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 10 Dec 2013 11:04:57 +0000
Subject: [New-bugs-announce] [issue19941] python -m imports non-ASCII .py
	file without encoding	declaration
Message-ID: <1386673497.85.0.313178291575.issue19941@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

If you have a non-ASCII .py file without encoding declaration, then you can't normally import it:

$ python --version
Python 2.7.6

$ python -c 'import test'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "test.py", line 1
SyntaxError: Non-ASCII character '\xc2' in file test.py on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details


However, "python -m" happily imports such files:

$ python -m test
?Hello world!

----------
files: test.py
messages: 205787
nosy: jwilk
priority: normal
severity: normal
status: open
title: python -m imports non-ASCII .py file without encoding declaration
versions: Python 2.7
Added file: http://bugs.python.org/file33076/test.py

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

From report at bugs.python.org  Tue Dec 10 12:48:59 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 10 Dec 2013 11:48:59 +0000
Subject: [New-bugs-announce] [issue19942] UTF-8 encoding not enforced
Message-ID: <1386676139.88.0.227932494666.issue19942@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

I created a Python file which contained a non-UTF-8 string literal (but no Unicode literals), and added "UTF-8" encoding declaration to it. I expected that Python will raise SyntaxError when importing such module, but it doesn't:

$ python --version
Python 2.7.6

$ python -c 'import test1' && echo ok
ok


Curiously enough, if I change the declaration to "UTF8", then the exception is raised as expected:

$ sed -e 's/UTF-8/UTF8/' < test1.py > test2.py
$ python -c 'import test2'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "test2.py", line 2
SyntaxError: 'utf8' codec can't decode byte 0xa1 in position 5: invalid start byte

----------
messages: 205795
nosy: jwilk
priority: normal
severity: normal
status: open
title: UTF-8 encoding not enforced
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec 10 12:58:32 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 10 Dec 2013 11:58:32 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue19943=5D_typo=3A_unkown_?=
	=?utf-8?b?4oaSIHVua25vd24=?=
Message-ID: <1386676712.53.0.751027369098.issue19943@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

There's a typo in Lib/lib2to3/fixes/fix_import.py:
unkown ? unknown

----------
components: Library (Lib)
messages: 205799
nosy: jwilk
priority: normal
severity: normal
status: open
title: typo: unkown ? unknown

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

From report at bugs.python.org  Tue Dec 10 13:29:01 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Dec 2013 12:29:01 +0000
Subject: [New-bugs-announce] [issue19944] Make importlib.find_spec load
	packages as needed
Message-ID: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

In implementing the runpy module updates for PEP 451 I ran into the fact that importlib.find_spec had copied the find_loader behaviour where it doesn't handle dotted names automatically - you have to explicitly pass in the __path__ from the parent module for it to work.

For find_loader, runpy used pkgutil.get_loader instead. The patch on issue 19700 currently includes a runpy._fixed_find_spec function that handles walking the module name components, loading packages as necessary.

I believe it would be better to move the current thin wrapper around importlib._bootstrap._find_spec to importlib.find_spec_on_path (which will only search for the specified module name directly on the given path without breaking it up into components), with find_spec itself changed to *not* take a "path" argument, and instead always doing the full lookup (as implemented in the issue 19700 patch _fixed_find_spec function)

----------
components: Library (Lib)
messages: 205804
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Make importlib.find_spec load packages as needed
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec 10 13:50:42 2013
From: report at bugs.python.org (Toilal)
Date: Tue, 10 Dec 2013 12:50:42 +0000
Subject: [New-bugs-announce] [issue19945] os.path.split starting with two
	slashes
Message-ID: <1386679842.42.0.284091102945.issue19945@psf.upfronthosting.co.za>


New submission from Toilal:

Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from os.path import split
>>> split('//computer/share')
('//computer', 'share')


Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from os.path import split
>>> split('//computer/share')
('//computer/share', '')

Result from 2.7.6 and 3.3.3 is different. Is it a bugfix from 2.7.6 to 3.3.3, or a regression in 3.3.3 ?

Same issue occurs with backslashes.

----------
components: Library (Lib)
messages: 205808
nosy: Toilal
priority: normal
severity: normal
status: open
title: os.path.split starting with two slashes
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Dec 10 14:08:59 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Tue, 10 Dec 2013 13:08:59 +0000
Subject: [New-bugs-announce] [issue19946] multiprocessing crash with
	forkserver or spawn when run	from a non ".py" ending script
Message-ID: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>


New submission from Olivier Grisel:

Here is a simple python program that uses the new forkserver feature introduced in 3.4b1:


name: checkforkserver.py
"""
import multiprocessing
import os


def do(i):
    print(i, os.getpid())


def test_forkserver():
    mp = multiprocessing.get_context('forkserver')
    mp.Pool(2).map(do, range(3))


if __name__ == "__main__":
    test_forkserver()
"""

When running this using the "python check_forkserver.py" command everything works as expected.

When running this using the nosetests launcher ("nosetests -s check_forkserver.py"), I get:

"""
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/Python-HEAD/lib/python3.4/multiprocessing/forkserver.py", line 141, in main
    spawn.import_main_path(main_path)
  File "/opt/Python-HEAD/lib/python3.4/multiprocessing/spawn.py", line 252, in import_main_path
    methods.init_module_attrs(main_module)
  File "<frozen importlib._bootstrap>", line 1051, in init_module_attrs
AttributeError: 'NoneType' object has no attribute 'loader'
"""

Indeed, the spec variable in multiprocessing/spawn.py's import_main_path
function is None as the nosetests script is not a regular python module: in particular is does not have a ".py" extension.

If I copy or symlink or renamed the "nosetests" script as "nosetests.py" in the same folder, this works as expected. I am not familiar enough with the importlib machinery to suggest a fix for this bug.

Also there is a typo in the comment: "causing a psuedo fork bomb" => "causing a pseudo fork bomb".

Note: I am running CPython head updated today.

----------
components: Library (Lib)
messages: 205810
nosy: Olivier.Grisel
priority: normal
severity: normal
status: open
title: multiprocessing crash with forkserver  or spawn  when run from a non ".py" ending script
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec 10 15:49:44 2013
From: report at bugs.python.org (Jimmy Merrild Krag)
Date: Tue, 10 Dec 2013 14:49:44 +0000
Subject: [New-bugs-announce] [issue19947] Inspect module broken
Message-ID: <1386686984.53.0.934353446234.issue19947@psf.upfronthosting.co.za>


New submission from Jimmy Merrild Krag:

I have been having issues like the below all day:

C:\JMK\CurrentWork\CPH-3516>python airport_code_downloader.py
Traceback (most recent call last):
  File "airport_code_downloader.py", line 4, in <module>
    import inspect
  File "C:\Python33\lib\inspect.py", line 53, in <module>
    from dis import COMPILER_FLAG_NAMES as _flag_names
  File "C:\Python33\lib\dis.py", line 13, in <module>
    _have_code = (types.MethodType, types.FunctionType, types.CodeType, type)
AttributeError: 'module' object has no attribute 'MethodType'

C:\JMK\CurrentWork\CPH-3516>

It seems to be a problem with the types module. All the types seem non-existing.

----------
messages: 205818
nosy: beruic
priority: normal
severity: normal
status: open
title: Inspect module broken
versions: Python 3.3

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

From report at bugs.python.org  Tue Dec 10 15:55:25 2013
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Glondu?=)
Date: Tue, 10 Dec 2013 14:55:25 +0000
Subject: [New-bugs-announce] [issue19948] POSIX semantics of PATH search in
	execvpe is not	respected
Message-ID: <1386687325.82.0.275504904763.issue19948@psf.upfronthosting.co.za>


New submission from St?phane Glondu:

Hello,

According to [1],

"In the cases where the other members of the exec family of functions would fail and set errno to [ENOEXEC], the execlp() and execvp() functions shall execute a command interpreter and the environment of the executed command shall be as if the process invoked the sh utility using execl() as follows:

execl(<shell path>, arg0, file, arg1, ..., (char *)0);"

This is not the case with os.execvp which keeps looking in PATH for other executables. To reproduce:

 1. pick some executable that exists in /usr/bin (let's say "curl")
 2. prepend to PATH a directory where you put an executable file with name "curl" and some random shell commands, without the #! line
 3. run os.execvp("curl", ["curl"])

Instead of running the #!-less shell script, /usr/bin/curl is executed. With GNU libc's execvp(), the shell script is executed. According to my interpretation of POSIX, the shell script should be executed.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01

Cheers,

-- 
St?phane

----------
components: Library (Lib)
messages: 205819
nosy: glondu
priority: normal
severity: normal
status: open
title: POSIX semantics of PATH search in execvpe is not respected
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec 10 18:32:05 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 10 Dec 2013 17:32:05 +0000
Subject: [New-bugs-announce] [issue19949] Explicitly skip or mask
	skipped/disabled tests in	test_xpickle
Message-ID: <1386696725.08.0.917922388786.issue19949@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The attached patch moves test_xpickle away from using alternately defined empty TestCases to skip the backward compatibility tests to using a skip decorator.  Also, several disabled tests are moved from defining empty tests to setting the test name to None.  Also, the have_python_version function's test has its quotes swapped between ' and "; this made it possible to test the changes on Windows.

----------
components: Tests
files: test_xpickle_cleanup.diff
keywords: patch
messages: 205837
nosy: zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Explicitly skip or mask skipped/disabled tests in test_xpickle
versions: Python 2.7
Added file: http://bugs.python.org/file33081/test_xpickle_cleanup.diff

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

From report at bugs.python.org  Tue Dec 10 23:34:18 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 10 Dec 2013 22:34:18 +0000
Subject: [New-bugs-announce] [issue19950] Document that
	unittest.TestCase.__init__ is called once	per test
Message-ID: <1386714858.72.0.878231586551.issue19950@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

I was surprised that in the following __init__ is actually called once per test function, although nothing in documentation implied so.

a.py
------

import unittest

class A(unittest.TestCase):
   def __init__(self, *args, **kwargs):
       print('called only once!')
       super().__init__(*args, **kwargs)

   def test(self):
       self.assertEqual(1, 1)
 
   def test2(self):
       self.assertEqual(2, 2)

if __name__ == '__main__':
   unittest.main()

$ python a.py
called only once!
called only once!
..
----------------------------------------------------------------------
Ran 2 tests in 0.001s

OK



The attached patch adds a note regarding this behaviour for the TestCase class.

----------
assignee: docs at python
components: Documentation
files: unittest_init.patch
keywords: patch
messages: 205864
nosy: Claudiu.Popa, docs at python, michael.foord
priority: normal
severity: normal
status: open
title: Document that unittest.TestCase.__init__ is called once per test
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33086/unittest_init.patch

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

From report at bugs.python.org  Wed Dec 11 19:11:45 2013
From: report at bugs.python.org (David Pizzuto)
Date: Wed, 11 Dec 2013 18:11:45 +0000
Subject: [New-bugs-announce] [issue19951] parse_qsl fails on empty query
	argument without =
Message-ID: <1386785505.13.0.692994563437.issue19951@psf.upfronthosting.co.za>


New submission from David Pizzuto:

Using an empty query argument with no = fails in urlparse.parse_qsl. Chrome and Firefox accept it without the =, so a navigation to google.com/search?q=foo&bar appears in the address bar as google.com/search?q=foo&bar=. Neither RFC 1738 nor RFC 3986 define the format of query strings. Wikipedia is similarly silent.

I can reproduce in 2.7.3 and 3.2.3, as shown below. I'm told this is also true of 3.3 but don't have easy access to a 3.3 interpreter to confirm.

The obvious workaround is to simply set strict_parsing=False, but I don't know what other checks that's disabling. Would it be reasonable to change parse_qsl to add the = if it's not present?

$ python
Python 2.7.3 (default, Sep 26 2013, 20:03:06) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urlparse
>>> query = 'foo&bar=baz'
>>> urlparse.parse_qs(query, strict_parsing=True, keep_blank_values=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/urlparse.py", line 353, in parse_qs
    for name, value in parse_qsl(qs, keep_blank_values, strict_parsing):
  File "/usr/lib/python2.7/urlparse.py", line 387, in parse_qsl
    raise ValueError, "bad query field: %r" % (name_value,)
ValueError: bad query field: 'foo'

$ python3
Python 3.2.3 (default, Sep 25 2013, 18:22:43) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib.parse
>>> query = 'foo&bar=baz'
>>> urllib.parse.parse_qs(query, strict_parsing=True, keep_blank_values=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/urllib/parse.py", line 556, in parse_qs
    encoding=encoding, errors=errors)
  File "/usr/lib/python3.2/urllib/parse.py", line 596, in parse_qsl
    raise ValueError("bad query field: %r" % (name_value,))
ValueError: bad query field: 'foo'

----------
messages: 205911
nosy: David.Pizzuto
priority: normal
severity: normal
status: open
title: parse_qsl fails on empty query argument without =
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Dec 11 20:55:13 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 11 Dec 2013 19:55:13 +0000
Subject: [New-bugs-announce] [issue19952] asyncio: test_wait_for_handle
	failure
Message-ID: <1386791713.28.0.425891775188.issue19952@psf.upfronthosting.co.za>


New submission from Stefan Krah:

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/3601/steps/test/logs/stdio


======================================================================
FAIL: test_wait_for_handle (test.test_asyncio.test_windows_events.ProactorTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_asyncio\test_windows_events.py", line 123, in test_wait_for_handle
    self.assertTrue(0 <= elapsed < 0.02, elapsed)
AssertionError: False is not true : 0.09299999999348074

----------
components: Tests
messages: 205918
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: asyncio: test_wait_for_handle failure
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Dec 11 21:13:08 2013
From: report at bugs.python.org (ferno)
Date: Wed, 11 Dec 2013 20:13:08 +0000
Subject: [New-bugs-announce] [issue19953] __iadd__() doc not strictly correct
Message-ID: <1386792788.94.0.272007303341.issue19953@psf.upfronthosting.co.za>


New submission from ferno:

Document in question is:

    http://docs.python.org/3.3/reference/datamodel.html#object.__iadd__

The documentation states,

    to execute the statement x += y, where x is an instance of a class that has an __iadd__() method, x.__iadd__(y) is called.

However, this doesn't appear to be strictly true. According to this, the following well-known example:

    >>> a = (1, [2, 3])
    >>> a[1] += [4, 5]
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: 'tuple' object does not support item assignment
    >>> a
    (1, [2, 3, 4, 5])

should give the same behaviour as:

    >>> a = (1, [2, 3])
    >>> a[1].__iadd__([4, 5])
    [2, 3, 4, 5]
    >>> a
    (1, [2, 3, 4, 5])

However, this snippet DOES give the identical behaviour:

    >>> a = (1, [2, 3])
    >>> a[1] = a[1].__iadd__([4, 5])
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: 'tuple' object does not support item assignment
    >>> a
    (1, [2, 3, 4, 5])

which leads me to suggest that this line of the documentation should be adjusted to read:

    to execute the statement x += y, where x is an instance of a class that has an __iadd__() method, x = x.__iadd__(y) is called.

This fix would incidentally harmonise with the documentation for operator.iadd() et al., (http://docs.python.org/3.3/library/operator.html#operator.iadd), which had a similar problem but was corrected following issue 7259 (http://bugs.python.org/issue7259), now reading:

    a = iadd(a, b) is equivalent to a += b.

----------
assignee: docs at python
components: Documentation
messages: 205920
nosy: docs at python, ferno
priority: normal
severity: normal
status: open
title: __iadd__() doc not strictly correct
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/issue19953>
_______________________________________

From report at bugs.python.org  Wed Dec 11 22:26:19 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Dec 2013 21:26:19 +0000
Subject: [New-bugs-announce] [issue19954] test_tk floating point exception
	on my gentoo box	running tk 8.6.1
Message-ID: <1386797179.8.0.0943570301002.issue19954@psf.upfronthosting.co.za>


New submission from R. David Murray:

A while ago I started getting a floating point exception from test_tk in the tip in all active versions, but I'm only now getting around to reporting it.  I've tracked this down to the tests introduced in issue 19085, which it looks like revealed some other tk issues.

Gentoo has some patches against stock 8.6.1; I don't know if they are the source of the failure or not.  I haven't updated the gentoo buildbots for a while, and since they are passing the tests it could well be that it was my upgrade from tk 8.6.0 to 8.6.1 on my dev box that triggered the failures.  The timing of that upgrade is somewhat after the patch was committed, but I hadn't been running the test suite regularly during that interval so I can't pinpoint it to one or the other.

There are also other test failures, by the way, but I'm not seeing the tracebacks because python crashes.

Here is the faulthandler traceback from 3.3:

test_indicatoron (tkinter.test.test_tkinter.test_widgets.MenubuttonTest) ... Fatal Python error: Floating point exception

Current thread 0xb75416c0:
  File "/home/rdmurray/python/p33/Lib/tkinter/__init__.py", line 1257 in _configure
  File "/home/rdmurray/python/p33/Lib/tkinter/__init__.py", line 1266 in configure
  File "/home/rdmurray/python/p33/Lib/tkinter/__init__.py", line 1273 in __setitem__
  File "/home/rdmurray/python/p33/Lib/tkinter/test/widget_tests.py", line 47 in checkParam
  File "/home/rdmurray/python/p33/Lib/tkinter/test/widget_tests.py", line 116 in checkBooleanParam
  File "/home/rdmurray/python/p33/Lib/tkinter/test/widget_tests.py", line 422 in test_indicatoron
  File "/home/rdmurray/python/p33/Lib/unittest/case.py", line 384 in _executeTestPart
  File "/home/rdmurray/python/p33/Lib/unittest/case.py", line 439 in run
  File "/home/rdmurray/python/p33/Lib/unittest/case.py", line 491 in __call__
  File "/home/rdmurray/python/p33/Lib/unittest/suite.py", line 105 in run
  File "/home/rdmurray/python/p33/Lib/unittest/suite.py", line 67 in __call__
  File "/home/rdmurray/python/p33/Lib/unittest/suite.py", line 105 in run
  File "/home/rdmurray/python/p33/Lib/unittest/suite.py", line 67 in __call__
  File "/home/rdmurray/python/p33/Lib/test/support/__init__.py", line 1560 in run
  File "/home/rdmurray/python/p33/Lib/test/support/__init__.py", line 1661 in _run_suite
  File "/home/rdmurray/python/p33/Lib/test/support/__init__.py", line 1695 in run_unittest
  File "/home/rdmurray/python/p33/Lib/test/test_tk.py", line 22 in test_main
  File "/home/rdmurray/python/p33/Lib/test/regrtest.py", line 1222 in runtest_inner
  File "/home/rdmurray/python/p33/Lib/test/regrtest.py", line 944 in runtest
  File "/home/rdmurray/python/p33/Lib/test/regrtest.py", line 717 in main
  File "/home/rdmurray/python/p33/Lib/test/__main__.py", line 13 in <module>
  File "/home/rdmurray/python/p33/Lib/runpy.py", line 73 in _run_code
  File "/home/rdmurray/python/p33/Lib/runpy.py", line 160 in _run_module_as_main
zsh: floating point exception  ./python -m test -uall test_tk

----------
components: Tests, Tkinter
messages: 205925
nosy: Arfrever, r.david.murray, serhiy.storchaka
priority: high
severity: normal
stage: needs patch
status: open
title: test_tk floating point exception on my gentoo box running tk 8.6.1
type: crash
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Dec 12 00:07:27 2013
From: report at bugs.python.org (nickhil rokkam)
Date: Wed, 11 Dec 2013 23:07:27 +0000
Subject: [New-bugs-announce] [issue19955] When adding .PY and .PYW to
	PATHEXT, it replaced string instead of appending
Message-ID: <1386803247.34.0.411424382912.issue19955@psf.upfronthosting.co.za>


New submission from nickhil rokkam:

Following installer overwrote the PATHEXT string after selecting the "add to path" installation option.
http://www.python.org/ftp/python/3.3.3/python-3.3.3.amd64.msi

----------
components: Installation
files: python-3.3.3.amd64.msi
messages: 205941
nosy: nickhil.rokkam
priority: normal
severity: normal
status: open
title: When adding .PY and .PYW to PATHEXT, it replaced string instead of appending
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file33097/python-3.3.3.amd64.msi

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

From report at bugs.python.org  Thu Dec 12 00:27:20 2013
From: report at bugs.python.org (Muhammad Tauqir Ahmad)
Date: Wed, 11 Dec 2013 23:27:20 +0000
Subject: [New-bugs-announce] [issue19956] inspect.getsource(obj.foo) fails
	when foo is an injected	method constructed from another method
Message-ID: <1386804440.21.0.0153040236788.issue19956@psf.upfronthosting.co.za>


New submission from Muhammad Tauqir Ahmad:

If a method `foo` of object instance `obj` is injected into it using a method from a different object instance, `inspect.getsource(obj.foo)` fails with the error message:

TypeError: <bound method Foo.say of <__main__.Foo object at 0x7fd348662cd0>> is not a module, class, method, function, traceback, frame, or code object

in inspect.py:getfile()

What basically is happening is that if you have `obj1`, `obj2` and `obj2` has method `foo`, setting `obj1.foo = types.MethodType(obj2.foo, obj1)` succeeds but is "double-bound-method" if that's a term. So during `getsource()`, it fails because `obj1.foo.__func__` is a method not a function as is expected.

Possible solutions:
1. Error message should be more clear if this is the intended behavior - right now it claims it's not a method,function etc. when it is indeed a method.
2. MethodType() should fail if the first argument is not a function.
3. inspect.getsource() should recursively keep "unpacking" till it finds an object that it can get the source for. 

Reproducer attached.

----------
components: Library (Lib)
files: reproducer.py
messages: 205942
nosy: mtahmed
priority: normal
severity: normal
status: open
title: inspect.getsource(obj.foo) fails when foo is an injected method constructed from another method
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file33098/reproducer.py

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

From report at bugs.python.org  Thu Dec 12 07:21:19 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 12 Dec 2013 06:21:19 +0000
Subject: [New-bugs-announce] [issue19957] Minor refactor of
	Lib/email/encoders.py
Message-ID: <1386829279.51.0.373470600297.issue19957@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In Lib/email/encoders.py:

def encode_7or8bit(msg):
    """Set the Content-Transfer-Encoding header to 7bit or 8bit."""
    orig = msg.get_payload(decode=True)
    if orig is None:
        # There's no payload.  For backwards compatibility we use 7bit
        msg['Content-Transfer-Encoding'] = '7bit'
        return
    # We play a trick to make this go fast.  If encoding/decode to ASCII
    # succeeds, we know the data must be 7bit, otherwise treat it as 8bit.
    try:
        if isinstance(orig, str):
            orig.encode('ascii')
        else:
            orig.decode('ascii')
    except UnicodeError:
        charset = msg.get_charset()


msg.get_payload(decode=True) always return bytes so there is no point of these lines:

        if isinstance(orig, str):
            orig.encode('ascii')
        else:
            orig.decode('ascii')

Attached the patch to refactor this function.

----------
components: email
files: minor_refactor_encoders_in_email_lib.patch
keywords: patch
messages: 205944
nosy: barry, r.david.murray, vajrasky
priority: normal
severity: normal
status: open
title: Minor refactor of Lib/email/encoders.py
versions: Python 3.4
Added file: http://bugs.python.org/file33099/minor_refactor_encoders_in_email_lib.patch

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

From report at bugs.python.org  Thu Dec 12 09:37:00 2013
From: report at bugs.python.org (Dmitrii Dimandt)
Date: Thu, 12 Dec 2013 08:37:00 +0000
Subject: [New-bugs-announce] [issue19958] Assignment success despite
	TypeError exception
Message-ID: <1386837420.1.0.0855964875306.issue19958@psf.upfronthosting.co.za>


New submission from Dmitrii Dimandt:

Observed behaviour:

Python 2.7.5 (default, Aug 25 2013, 00:04:04)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
>>> a = (1, [2,3])
>>> a[1] += [4,5]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment
>>> a
(1, [2, 3, 4, 5])


Expected behaviour: tuple remains unchanged

----------
components: Interpreter Core
messages: 205945
nosy: Dmitrii.Dimandt
priority: normal
severity: normal
status: open
title: Assignment success despite TypeError exception
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec 12 11:31:03 2013
From: report at bugs.python.org (Garth Bushell)
Date: Thu, 12 Dec 2013 10:31:03 +0000
Subject: [New-bugs-announce] [issue19959] argparse.FileType does not expand
	tilde "~"
Message-ID: <1386844263.55.0.374493919931.issue19959@psf.upfronthosting.co.za>


New submission from Garth Bushell:

argparse.FileType does not expand tilde "~". 

This would be useful to take file parameters beginning with "~" and use os.path.expanduser to expand this.

----------
components: Library (Lib)
messages: 205949
nosy: garthy
priority: normal
severity: normal
status: open
title: argparse.FileType does not expand tilde "~"
versions: Python 3.5

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

From report at bugs.python.org  Thu Dec 12 13:07:05 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 12 Dec 2013 12:07:05 +0000
Subject: [New-bugs-announce] [issue19960] MacOSX: Building 2.7 without the
	xcode command line	tools installed
Message-ID: <1386850025.77.0.292014271005.issue19960@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

When you build python 2.7 on an OSX 10.9 machine with Xcode but without the command-line tools installed that build mostly succeeds, but doesn't detect a number of dependencies (in particular zlib).

The attached patch teaches "add_dir_to_list" about the SDK sysroot on OSX and with that the build succeeds.

Aside: I also noticed problems with build tinter, with 2.7 but also with 3.3 and 3.4. I'll file a separate issue about that.

----------
assignee: ronaldoussoren
components: Build
files: python2.7-alternative-sdk.txt
keywords: needs review, patch
messages: 205952
nosy: hynek, ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: patch review
status: open
title: MacOSX: Building 2.7 without the xcode command line  tools installed
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file33101/python2.7-alternative-sdk.txt

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

From report at bugs.python.org  Thu Dec 12 13:11:26 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 12 Dec 2013 12:11:26 +0000
Subject: [New-bugs-announce] [issue19961] MacOSX: Tkinter build failure when
	building without	command-line tools
Message-ID: <1386850286.1.0.287048995559.issue19961@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

When you build python on an OSX 10.9 machine with Xcode but without the command-line tools installed that build mostly succeeds, but Tkinter fails to build.

The following error message is from a 2.7 build, but the same problem occurs when building 3.3 and 3.4:

clang -fno-strict-aliasing -fno-common -dynamic -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -fexceptions -g -O0 -Wall -Wstrict-prototypes -DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/include -I/Users/ronald/Projects/python/rw/2.7/Mac/Include -I. -IInclude -I../Include -I/Users/ronald/Projects/python/rw/2.7/Include -I/Users/ronald/Projects/python/rw/2.7/build -c /Users/ronald/Projects/python/rw/2.7/Modules/_tkinter.c -o build/temp.macosx-10.8-intel-2.7-pydebug/Users/ronald/Projects/python/rw/2.7/Modules/_tkinter.o -framework Tk -arch x86_64 -arch i386
clang: warning: -framework Tk: 'linker' input unused
In file included from /Users/ronald/Projects/python/rw/2.7/Modules/_tkinter.c:71:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/tk.h:78:11: fatal error: 
      'X11/Xlib.h' file not found
#       include <X11/Xlib.h>
                ^
1 error generated.


NOTE: I haven't tried building with the command-line tools for xcode installed, I have a freshly installed system and want to try to live without these tools because that makes it easier to upgrade xcode.

----------
components: Build
messages: 205953
nosy: hynek, ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: MacOSX: Tkinter build failure when building without command-line tools
type: compile error
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Dec 12 16:33:49 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 12 Dec 2013 15:33:49 +0000
Subject: [New-bugs-announce] [issue19962] Create a 'python.bat' script to
	invoke interpreter from	source root
Message-ID: <1386862429.77.0.358851450829.issue19962@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The attached patch adds a CustomBuildStep to python.vcxproj which creates a 'python.bat' script in the root of the source tree for quicker and easier invocation for testing purposes, and to make the Windows Python developer experience a little closer to the UNIX experience.  Sample output:

"""
C:\path\to\cpython>type python.bat
@rem This script invokes the most recently built Python with all arguments
@rem passed through to the interpreter.  This file is generated by the
@rem build process and any changes *will* be thrown away by the next
@rem rebuild.
@rem This is only meant as a convenience for developing CPython
@rem and using it outside of that context is ill-advised.
@echo Running Debug^|Win32 interpreter...
@"C:\path\to\cpython\PCbuild\python_d.exe" %*

C:\path\to\cpython>python -c "import sys;print(sys.version)"
Running Debug|Win32 interpreter...
3.4.0b1 (default:6864abd8e83a+, Dec 12 2013, 08:35:32) [MSC v.1600 32 bit (Intel
)]
"""

As the commentary (which can likely be improved) states, the script is re-created by every rebuild, so it always points to the most recently built interpreter.  Also, being a CustomBuildStep, it is cleaned up automatically by the Clean build target.

I'm not sure whether echoing the interpreter configuration is the best idea, but I personally prefer that over echoing the full command which has the potential to be very long.  I think that the Configuration/Platform should be displayed somehow to reduce confusion since there could be up to 8 different interpreters living together in PCbuild (not to mention PC/VS10.0, when it exists someday) and python.bat will only point to one of them.

Note that the x64 changes are done by hand and untested; I don't have the ability to do so just yet.

----------
assignee: zach.ware
components: Build, Windows
files: python.bat.diff
keywords: patch
messages: 205957
nosy: brian.curtin, loewis, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Create a 'python.bat' script to invoke interpreter from source root
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33103/python.bat.diff

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

From report at bugs.python.org  Thu Dec 12 16:51:28 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 12 Dec 2013 15:51:28 +0000
Subject: [New-bugs-announce] [issue19963] Update docs for
	importlib.import_module()
Message-ID: <1386863488.66.0.95075387915.issue19963@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The docs for importlib.import_module() say that you need to import parent packages first, but this is actually no longer the case (thankfully):

Python 3.4.0b1 (default:a3bdbe220f8a, Dec 10 2013, 11:07:04) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> 'test' in sys.modules
False
>>> import importlib
>>> importlib.import_module('test.test_importlib.source')
<module 'test.test_importlib.source' from '/usr/local/google/home/bcannon/Repos/cpython/default/Lib/test/test_importlib/source/__init__.py'>


Also need to check if this is false in Python 3.3 (or wherever the change occurred) to update the docs there and to add a versionchanged flag.

----------
assignee: brett.cannon
components: Documentation
messages: 205958
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Update docs for importlib.import_module()
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Dec 12 18:07:47 2013
From: report at bugs.python.org (Sworddragon)
Date: Thu, 12 Dec 2013 17:07:47 +0000
Subject: [New-bugs-announce] [issue19964] '?' is always non-greedy
Message-ID: <1386868067.16.0.771792818941.issue19964@psf.upfronthosting.co.za>


New submission from Sworddragon:

>From the documentation: "The '*', '+', and '?' qualifiers are all greedy;"

But this is not the case for '?'. In the attachments is an example which shows this: re.search(r'1?', '01') should find '1' but it doesn't find anything.

----------
components: Library (Lib)
files: test.py
messages: 205962
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: '?' is always non-greedy
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file33104/test.py

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

From report at bugs.python.org  Thu Dec 12 18:20:10 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 12 Dec 2013 17:20:10 +0000
Subject: [New-bugs-announce] [issue19965] Non-atomic generation of
	Include/Python-ast.h and	Python/Python-ast.c
Message-ID: <1386868810.74.0.691786710751.issue19965@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

A user reported this error with `make -j${high_value}`:

========================
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/_warnings.o Python/_warnings.c
/bin/mkdir -p Include
python3.3 ./Parser/asdl_c.py -h Include ./Parser/Python.asdl
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/asdl.o Python/asdl.c
make Parser/pgen
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/bltinmodule.o Python/bltinmodule.c
make[1]: Entering directory '/var/tmp/portage/dev-lang/python-3.3.3-r1000/work/Python-3.3.3'
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/dynamic_annotations.o Python/dynamic_annotations.c
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/mysnprintf.o Python/mysnprintf.c
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/ceval.o Python/ceval.c
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/pyctype.o Python/pyctype.c
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Parser/tokenizer_pgen.o Parser/tokenizer_pgen.c
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/codecs.o Python/codecs.c
Python/bltinmodule.c:4:24: warning: Include/Python-ast.h is shorter than expected [enabled by default]
 #include "Python-ast.h"
                        ^
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/errors.o Python/errors.c
In file included from Python/bltinmodule.c:10:0:
Include/ast.h:7:1: warning: parameter names (without types) in function declaration [enabled by default]
 PyAPI_FUNC(int) PyAST_Validate(mod_ty);
 ^
In file included from Include/Python.h:50:0,
                 from Python/bltinmodule.c:3:
Include/ast.h:8:12: error: unknown type name ?mod_ty?
 PyAPI_FUNC(mod_ty) PyAST_FromNode(
            ^
Include/pyport.h:777:34: note: in definition of macro ?PyAPI_FUNC?
 #       define PyAPI_FUNC(RTYPE) RTYPE
                                  ^
Python/bltinmodule.c: In function ?builtin_compile?:
Python/bltinmodule.c:641:13: error: unknown type name ?mod_ty?
             mod_ty mod;
             ^
Python/bltinmodule.c:647:21: warning: comparison between pointer and integer [enabled by default]
             if (mod == NULL) {
                     ^
Python/bltinmodule.c:656:49: warning: passing argument 1 of ?PyAST_CompileEx? makes pointer from integer without a cast [enabled by default]
                                                 &cf, optimize, arena);
                                                 ^
In file included from Include/Python.h:122:0,
                 from Python/bltinmodule.c:3:
Include/compile.h:33:28: note: expected ?struct _mod *? but argument is of type ?int?
 PyAPI_FUNC(PyCodeObject *) PyAST_CompileEx(
                            ^
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/frozenmain.o Python/frozenmain.c
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Parser/printgrammar.o Parser/printgrammar.c
Makefile:1362: recipe for target 'Python/bltinmodule.o' failed
make: *** [Python/bltinmodule.o] Error 1
make: *** Waiting for unfinished jobs....
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Parser/parsetok_pgen.o Parser/parsetok_pgen.c
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Parser/pgenmain.o Parser/pgenmain.c
x86_64-pc-linux-gnu-gcc -pthread -DNDEBUG  -Wl,-O1 -Wl,--sort-common -Wl,--as-needed  Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/dynamic_annotations.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/parsetok_pgen.o Parser/pgenmain.o -lpthread -ldl  -lutil -o Parser/pgen
make[1]: Leaving directory '/tmp/Python-3.3.3'
Parser/pgen ./Grammar/Grammar Include/graminit.h Python/graminit.c
========================

I attach a patch (for default branch). This bug should be also fixed in 2.7 and 3.3 branches.

----------
components: Build
files: asdl_c.py.patch
keywords: easy, patch
messages: 205964
nosy: Arfrever
priority: normal
severity: normal
status: open
title: Non-atomic generation of Include/Python-ast.h and Python/Python-ast.c
type: compile error
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33105/asdl_c.py.patch

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

From report at bugs.python.org  Thu Dec 12 18:37:02 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 12 Dec 2013 17:37:02 +0000
Subject: [New-bugs-announce] [issue19966] Wrong mtimes of files in 3.3.3
	tarballs
Message-ID: <1386869822.97.0.610221510269.issue19966@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

This bug is present in 3.3.3 tarballs (Python-3.3.3.tar.bz2, Python-3.3.3.tar.xz, Python-3.3.3.tgz). This bug is absent in 3.3.2 tarballs.

In unpacked 3.3.2:

$ ./configure
...
$ make Include/Python-ast.h
make: 'Include/Python-ast.h' is up to date.
$ make Python/Python-ast.c
make: 'Python/Python-ast.c' is up to date.


In unpacked 3.3.3:

$ ./configure
...
$ make Include/Python-ast.h
/bin/mkdir -p Include
python3.3 ./Parser/asdl_c.py -h Include ./Parser/Python.asdl
$ make Python/Python-ast.c
/bin/mkdir -p Python
python3.3 ./Parser/asdl_c.py -c Python ./Parser/Python.asdl


At least please fix the script used to generate tarballs, to ensure that this bug will not occur with future tarballs.

----------
components: Build
messages: 205967
nosy: Arfrever, georg.brandl
priority: normal
severity: normal
status: open
title: Wrong mtimes of files in 3.3.3 tarballs
versions: Python 3.3

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

From report at bugs.python.org  Fri Dec 13 00:02:49 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Dec 2013 23:02:49 +0000
Subject: [New-bugs-announce] [issue19967] asyncio: remove _TracebackLogger
Message-ID: <1386889369.33.0.285516490097.issue19967@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Thanks to the PEP 442 (Safe object finalization), _TracebackLogger helper of asyncio.Futures becomes useless.

Attached patch removes it.

--

If you agree to diverge code with Tulip project, the Python 3.3 code of WriteTransport.writelines can also be removed:

        if not PY34:
            # In Python 3.3, bytes.join() doesn't handle memoryview.
            list_of_data = (
                bytes(data) if isinstance(data, memoryview) else data
                for data in list_of_data)

----------
files: asyncio_log_traceback.patch
keywords: patch
messages: 205988
nosy: gvanrossum, haypo, pitrou
priority: normal
severity: normal
status: open
title: asyncio: remove _TracebackLogger
versions: Python 3.4
Added file: http://bugs.python.org/file33106/asyncio_log_traceback.patch

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

From report at bugs.python.org  Fri Dec 13 01:15:44 2013
From: report at bugs.python.org (Quanah Gibson-Mount)
Date: Fri, 13 Dec 2013 00:15:44 +0000
Subject: [New-bugs-announce] [issue19968] Using DESTDIR breaks sys.path
Message-ID: <1386893744.29.0.246592837254.issue19968@psf.upfronthosting.co.za>


New submission from Quanah Gibson-Mount:

I found that when trying to use Python with the "stow" utility, that it incorrectly hard codes the full DESTDIR path into python, instead of the relative portion of the DESTDIR path.  As a result, DESTDIR usage is fundamentally broken in relation to all other software packages I've ever built.  For example:

make install DESTDIR=/usr/local/stow/python-3.3.2

results in a sys.path that includes /usr/local/stow/python-3.3.2, when instead what is desired is just "/usr/local", so you can properly stow the package:

[quanah at git Python-3.3.2]$ python3
Python 3.3.2 (default, Dec 12 2013, 17:18:31)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print(sys.path)
['', '/usr/local/stow/python-3.3.2/lib/python33.zip', '/usr/local/stow/python-3.3.2/lib/python3.3', '/usr/local/stow/python-3.3.2/lib/python3.3/plat-linux', '/usr/local/stow/python-3.3.2/lib/python3.3/lib-dynload', '/usr/local/stow/python-3.3.2/lib/python3.3/site-packages']

Python itself was correctly built with --prefix=/usr/local, as that is the desired prefix.

----------
components: Build
messages: 205993
nosy: mishikal
priority: normal
severity: normal
status: open
title: Using DESTDIR breaks sys.path
versions: Python 3.3

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

From report at bugs.python.org  Fri Dec 13 01:29:48 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 00:29:48 +0000
Subject: [New-bugs-announce] [issue19969] PyBytes_FromFormatV("%c") and
	PyString_FromFormatV("%c")	don't check for character min/max value
Message-ID: <1386894588.54.0.168996140683.issue19969@psf.upfronthosting.co.za>


New submission from STINNER Victor:

PyBytes_FromFormatV("%c") and PyString_FromFormatV("%c") overflow if the parameter is not in range [0; 255].

If nobody complained before, it's maybe not worth to fix the bug in Python 2.7 or 3.3.

----------
components: Interpreter Core
messages: 205996
nosy: haypo
priority: normal
severity: normal
status: open
title: PyBytes_FromFormatV("%c") and PyString_FromFormatV("%c") don't check for character min/max value

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

From report at bugs.python.org  Fri Dec 13 10:28:46 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 13 Dec 2013 09:28:46 +0000
Subject: [New-bugs-announce] [issue19970] Typo of `immediatly` and `agin`
	words
Message-ID: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

ethan at amiau:~/Documents/code/python/cpython3.4$ grep -R immediatly *
Doc/library/asyncio-protocol.rst::meth:`Transport.close` can be called immediatly after
Lib/test/test_signal.py:            # unblock the pending signal calls immediatly the signal handler
Modules/faulthandler.c:    /* call the previous signal handler: it is called immediatly if we use
ethan at amiau:~/Documents/code/python/cpython3.4$ grep -R " agin " *
Modules/posixmodule.c:           the symlink path agin and not the actual final path. */
Modules/posixmodule.c:           the symlink path agin and not the actual final path. */

----------
assignee: docs at python
components: Documentation, Extension Modules, Library (Lib)
files: fix_typo_agin_and_immediatly_python34.patch
keywords: patch
messages: 206031
nosy: docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Typo of `immediatly` and `agin` words
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33114/fix_typo_agin_and_immediatly_python34.patch

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

From report at bugs.python.org  Fri Dec 13 10:54:50 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 13 Dec 2013 09:54:50 +0000
Subject: [New-bugs-announce] [issue19971] Remove Tulip words from asyncio
	documentation/code
Message-ID: <1386928490.02.0.72947185095.issue19971@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

I was reading the documentation about asyncio. Here is the introduction paragraph:

Doc/library/asyncio.rst
=======================

This module provides infrastructure for writing single-threaded concurrent
code using coroutines, multiplexing I/O access over sockets and other
resources, running network clients and servers, and other related primitives.
Here is a more detailed list of the package contents:

Then I read it like a novel. Then somewhere out of the blue, the Tulip word shows up.

Doc/library/asyncio-sync.rst
============================

Unlike the standard library :mod:`queue`, you can reliably know this Queue's
   size with :meth:`qsize`, since your single-threaded Tulip application won't
   be interrupted between calling :meth:`qsize` and doing an operation on the
   Queue.

The Tulip word breaks the flow of the story because we never introduce the Tulip word previously. There are two ways to handle this situation:
1. Introduce the Tulip word in the introduction and other parts consistently,
2. Remove the references to Tulip.

I suggest we take option 2 (users of Python 3.4 asyncio stdlib have no reason to know the word Tulip). Here is the patch.

----------
assignee: docs at python
components: Documentation
files: remove_Tulip.patch
keywords: patch
messages: 206036
nosy: docs at python, gvanrossum, vajrasky
priority: normal
severity: normal
status: open
title: Remove Tulip words from asyncio documentation/code
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33117/remove_Tulip.patch

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

From report at bugs.python.org  Fri Dec 13 11:14:34 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 Dec 2013 10:14:34 +0000
Subject: [New-bugs-announce] [issue19972] Leak in pickle (?)
Message-ID: <1386929674.63.0.934928142629.issue19972@psf.upfronthosting.co.za>


New submission from Stefan Krah:

Hi Alexandre, the following leaks appear after 64c6d52793be. I'm
not sure yet if they're caused or just exposed by the changeset.


Code:
==============
import sys
import pickle
sys.exit(0)
==============


==8118== 864 (192 direct, 672 indirect) bytes in 3 blocks are definitely lost in loss record 2,198 of 2,365
==8118==    at 0x4C28B8C: malloc (vg_replace_malloc.c:270)
==8118==    by 0x41D12A: _PyMem_RawMalloc (obmalloc.c:60)
==8118==    by 0x41D5E9: PyObject_Malloc (obmalloc.c:351)
==8118==    by 0x533FC9: _PyObject_GC_Malloc (gcmodule.c:1726)
==8118==    by 0x534092: _PyObject_GC_New (gcmodule.c:1749)
==8118==    by 0x450CDF: new_dict (dictobject.c:391)
==8118==    by 0x4527BB: _PyDict_NewPresized (dictobject.c:1043)
==8118==    by 0x4DCAFD: PyEval_EvalFrameEx (ceval.c:2366)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4D3A59: PyEval_EvalCode (ceval.c:770)
==8118==    by 0x4CD6BE: builtin_exec (bltinmodule.c:876)
==8118==    by 0x5B11B3: PyCFunction_Call (methodobject.c:93)
==8118==    by 0x4E6946: ext_do_call (ceval.c:4546)
==8118==    by 0x4DFC60: PyEval_EvalFrameEx (ceval.c:2866)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4E5BF7: fast_function (ceval.c:4332)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x5B05F2: function_call (funcobject.c:632)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x42619E: _PyObject_CallMethodIdObjArgs (abstract.c:2359)
==8118==    by 0x502FBE: PyImport_ImportModuleLevelObject (import.c:1473)
==8118==    by 0x4CC3EC: builtin___import__ (bltinmodule.c:210)
==8118==    by 0x5B11D5: PyCFunction_Call (methodobject.c:99)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x4E4E01: PyEval_CallObjectWithKeywords (ceval.c:4101)
==8118==    by 0x4DD718: PyEval_EvalFrameEx (ceval.c:2466)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4D3A59: PyEval_EvalCode (ceval.c:770)
==8118==    by 0x4CD6BE: builtin_exec (bltinmodule.c:876)
==8118==    by 0x5B11B3: PyCFunction_Call (methodobject.c:93)
==8118==    by 0x4E6946: ext_do_call (ceval.c:4546)
==8118==    by 0x4DFC60: PyEval_EvalFrameEx (ceval.c:2866)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4E5BF7: fast_function (ceval.c:4332)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)


==8118== 2,112 (128 direct, 1,984 indirect) bytes in 2 blocks are definitely lost in loss record 2,301 of 2,365
==8118==    at 0x4C28B8C: malloc (vg_replace_malloc.c:270)
==8118==    by 0x41D12A: _PyMem_RawMalloc (obmalloc.c:60)
==8118==    by 0x41D5E9: PyObject_Malloc (obmalloc.c:351)
==8118==    by 0x533FC9: _PyObject_GC_Malloc (gcmodule.c:1726)
==8118==    by 0x4734D9: PyType_GenericAlloc (typeobject.c:784)
==8118==    by 0x456438: dict_new (dictobject.c:2604)
==8118==    by 0x473355: type_call (typeobject.c:751)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x4E6313: do_call (ceval.c:4454)
==8118==    by 0x4E57B5: call_function (ceval.c:4252)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4D3A59: PyEval_EvalCode (ceval.c:770)
==8118==    by 0x4CD6BE: builtin_exec (bltinmodule.c:876)
==8118==    by 0x5B11B3: PyCFunction_Call (methodobject.c:93)
==8118==    by 0x4E6946: ext_do_call (ceval.c:4546)
==8118==    by 0x4DFC60: PyEval_EvalFrameEx (ceval.c:2866)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4E5BF7: fast_function (ceval.c:4332)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x5B05F2: function_call (funcobject.c:632)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x42619E: _PyObject_CallMethodIdObjArgs (abstract.c:2359)
==8118==    by 0x502FBE: PyImport_ImportModuleLevelObject (import.c:1473)
==8118==    by 0x4CC3EC: builtin___import__ (bltinmodule.c:210)
==8118==    by 0x5B11D5: PyCFunction_Call (methodobject.c:99)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x4E4E01: PyEval_CallObjectWithKeywords (ceval.c:4101)
==8118==    by 0x4DD718: PyEval_EvalFrameEx (ceval.c:2466)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4D3A59: PyEval_EvalCode (ceval.c:770)
==8118==    by 0x4CD6BE: builtin_exec (bltinmodule.c:876)
==8118==    by 0x5B11B3: PyCFunction_Call (methodobject.c:93)
==8118==    by 0x4E6946: ext_do_call (ceval.c:4546)
==8118==    by 0x4DFC60: PyEval_EvalFrameEx (ceval.c:2866)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118== 


==8118== 2,402 (64 direct, 2,338 indirect) bytes in 1 blocks are definitely lost in loss record 2,304 of 2,365
==8118==    at 0x4C28B8C: malloc (vg_replace_malloc.c:270)
==8118==    by 0x41D12A: _PyMem_RawMalloc (obmalloc.c:60)
==8118==    by 0x41D5E9: PyObject_Malloc (obmalloc.c:351)
==8118==    by 0x533FC9: _PyObject_GC_Malloc (gcmodule.c:1726)
==8118==    by 0x534092: _PyObject_GC_New (gcmodule.c:1749)
==8118==    by 0x450CDF: new_dict (dictobject.c:391)
==8118==    by 0x450E4C: PyDict_New (dictobject.c:429)
==8118==    by 0x45F97D: module_init (moduleobject.c:372)
==8118==    by 0x47342B: type_call (typeobject.c:766)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x4E6313: do_call (ceval.c:4454)
==8118==    by 0x4E57B5: call_function (ceval.c:4252)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x5B05F2: function_call (funcobject.c:632)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x42619E: _PyObject_CallMethodIdObjArgs (abstract.c:2359)
==8118==    by 0x502FBE: PyImport_ImportModuleLevelObject (import.c:1473)
==8118==    by 0x4CC3EC: builtin___import__ (bltinmodule.c:210)
==8118==    by 0x5B11D5: PyCFunction_Call (methodobject.c:99)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x4E4E01: PyEval_CallObjectWithKeywords (ceval.c:4101)
==8118==    by 0x4DD718: PyEval_EvalFrameEx (ceval.c:2466)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4D3A59: PyEval_EvalCode (ceval.c:770)
==8118==    by 0x4CD6BE: builtin_exec (bltinmodule.c:876)
==8118==    by 0x5B11B3: PyCFunction_Call (methodobject.c:93)
==8118==    by 0x4E6946: ext_do_call (ceval.c:4546)
==8118==    by 0x4DFC60: PyEval_EvalFrameEx (ceval.c:2866)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4E5BF7: fast_function (ceval.c:4332)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118== 

==8118== 4,919 (64 direct, 4,855 indirect) bytes in 1 blocks are definitely lost in loss record 2,347 of 2,365
==8118==    at 0x4C28B8C: malloc (vg_replace_malloc.c:270)
==8118==    by 0x41D12A: _PyMem_RawMalloc (obmalloc.c:60)
==8118==    by 0x41D5E9: PyObject_Malloc (obmalloc.c:351)
==8118==    by 0x533FC9: _PyObject_GC_Malloc (gcmodule.c:1726)
==8118==    by 0x534092: _PyObject_GC_New (gcmodule.c:1749)
==8118==    by 0x450CDF: new_dict (dictobject.c:391)
==8118==    by 0x450E15: new_dict_with_shared_keys (dictobject.c:420)
==8118==    by 0x458477: _PyObjectDict_SetItem (dictobject.c:3746)
==8118==    by 0x46215A: _PyObject_GenericSetAttrWithDict (object.c:1143)
==8118==    by 0x462394: PyObject_GenericSetAttr (object.c:1185)
==8118==    by 0x4618E4: PyObject_SetAttr (object.c:914)
==8118==    by 0x4DABEB: PyEval_EvalFrameEx (ceval.c:2111)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x5B05F2: function_call (funcobject.c:632)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x5A1348: method_call (classobject.c:347)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x482B2A: slot_tp_init (typeobject.c:5895)
==8118==    by 0x47342B: type_call (typeobject.c:766)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x4E6313: do_call (ceval.c:4454)
==8118==    by 0x4E57B5: call_function (ceval.c:4252)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4E5BF7: fast_function (ceval.c:4332)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x5B05F2: function_call (funcobject.c:632)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x5A1348: method_call (classobject.c:347)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x42632D: PyObject_CallFunctionObjArgs (abstract.c:2381)
==8118==    by 0x4DF288: PyEval_EvalFrameEx (ceval.c:2711)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x5B05F2: function_call (funcobject.c:632)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x42619E: _PyObject_CallMethodIdObjArgs (abstract.c:2359)
==8118==    by 0x502FBE: PyImport_ImportModuleLevelObject (import.c:1473)
==8118==    by 0x4CC3EC: builtin___import__ (bltinmodule.c:210)
==8118==    by 0x5B11D5: PyCFunction_Call (methodobject.c:99)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x4E4E01: PyEval_CallObjectWithKeywords (ceval.c:4101)
==8118==    by 0x4DD718: PyEval_EvalFrameEx (ceval.c:2466)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4D3A59: PyEval_EvalCode (ceval.c:770)
==8118==    by 0x4CD6BE: builtin_exec (bltinmodule.c:876)
==8118==    by 0x5B11B3: PyCFunction_Call (methodobject.c:93)
==8118==    by 0x4E6946: ext_do_call (ceval.c:4546)
==8118==    by 0x4DFC60: PyEval_EvalFrameEx (ceval.c:2866)
==8118==

----------
components: Extension Modules
messages: 206044
nosy: alexandre.vassalotti, skrah
priority: normal
severity: normal
status: open
title: Leak in pickle (?)
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Dec 13 12:41:24 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 13 Dec 2013 11:41:24 +0000
Subject: [New-bugs-announce] [issue19973] Deprecate pyio
Message-ID: <1386934884.58.0.337950563019.issue19973@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Does it make sense to finally deprecate pyio, so we can eventually delete it?

----------
messages: 206060
nosy: larry
priority: normal
severity: normal
status: open
title: Deprecate pyio
versions: Python 3.5

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

From report at bugs.python.org  Fri Dec 13 12:59:08 2013
From: report at bugs.python.org (Antony Mayi)
Date: Fri, 13 Dec 2013 11:59:08 +0000
Subject: [New-bugs-announce] [issue19974] tarfile doesn't overwrite symlink
	by directory
Message-ID: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>


New submission from Antony Mayi:

tarfile.py compared to GNU tar doesn't overwrite existing symlink with directory of same name if such directory exists in the extracted tarball.

----------
components: Library (Lib)
messages: 206066
nosy: antonymayi
priority: normal
severity: normal
status: open
title: tarfile doesn't overwrite symlink by directory
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Dec 13 15:28:20 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 13 Dec 2013 14:28:20 +0000
Subject: [New-bugs-announce] [issue19975] Remove unused imports from
	webbrowser
Message-ID: <1386944900.75.0.705131055274.issue19975@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

The attached patch removes three unused imports in webbrowser module.

----------
components: Library (Lib)
files: webbrowser_unused_imports.patch
keywords: patch
messages: 206091
nosy: Claudiu.Popa, georg.brandl
priority: normal
severity: normal
status: open
title: Remove unused imports from webbrowser
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33121/webbrowser_unused_imports.patch

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

From report at bugs.python.org  Fri Dec 13 15:43:06 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 Dec 2013 14:43:06 +0000
Subject: [New-bugs-announce] [issue19976] Argument Clinic: generate second
	arg for METH_NOARGS
Message-ID: <1386945786.12.0.418187279765.issue19976@psf.upfronthosting.co.za>


New submission from Stefan Krah:

I was just reading the _pickle sources and it appears that AC does not
generate a second arg for METH_NOARGS functions:

#define _PICKLE_PICKLERMEMOPROXY_CLEAR_METHODDEF    \
    {"clear", (PyCFunction)_pickle_PicklerMemoProxy_clear, METH_NOARGS, _pickle_PicklerMemoProxy_clear__doc__},

static PyObject *
_pickle_PicklerMemoProxy_clear(PicklerMemoProxyObject *self)


While this is a common occurrence in the source tree, the consensus
in #15402 was that the unused second arg should be present, e.g.:

msg166250
msg166405

----------
components: Demos and Tools
messages: 206093
nosy: larry, skrah
priority: normal
severity: normal
status: open
title: Argument Clinic: generate second arg for METH_NOARGS
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Dec 13 17:40:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 16:40:20 +0000
Subject: [New-bugs-announce] [issue19977] Use "surrogateescape" error
	handler for sys.stdout on	UNIX for the C locale
Message-ID: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za>


New submission from STINNER Victor:

When LANG=C is used to get the english language (which is a mistake, LC_CTYPE=C should be used instead) or when Python is started with an empty environment (no environment variable), Python gets the POSIX locale (aka "C locale") for the LC_CTYPE (encoding) locale.

Standard streams use the locale encoding, which is usually ASCII with POSIX locale on most platforms (except on AIX: ISO 8859-1). In this case, data read from the OS (environment variables, command line arguments, filenames, etc.) may contain surrogate characters because of the internal usage of the surrogateescape error handler (see the PEP 383 for the rationale).

The problem is that standard output uses the strict error handler, and so print() fails to display OS data like filenames.

Example, "ls" command in Python:
---
import os
for name in sorted(os.listdir()): print(name)
---

Try it with "LANG=C python ls.py" in a directory containing non-ASCII characters and you will get unicode errors.

Issues #19846 and #19847 are examples of this annoyance.

I propose to use also the surrogateescape error handler for sys.stdout if the POSIX locale is used for LC_CTYPE at startup. Attached patch implements this idea.

With the patch, "LANG=C python ls.py" almost works as filenames and stdout are byte streams, even if the Unicode type is used.

----------
components: Unicode
files: c_locale_surrogateescape.patch
keywords: patch
messages: 206111
nosy: Sworddragon, a.badger, ezio.melotti, haypo, loewis, ncoghlan
priority: normal
severity: normal
status: open
title: Use "surrogateescape" error handler for sys.stdout on UNIX for the C locale
versions: Python 3.4
Added file: http://bugs.python.org/file33122/c_locale_surrogateescape.patch

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

From report at bugs.python.org  Fri Dec 13 17:44:41 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 16:44:41 +0000
Subject: [New-bugs-announce] [issue19978] Update multiprocessing.spawn to
	use runpy.run_path
Message-ID: <1386953081.33.0.610270366508.issue19978@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Once the 'target' parameter for runpy.run_path lands then multiprocessing.spawn should be updated to use it.

----------
components: Library (Lib)
messages: 206117
nosy: brett.cannon, jnoller, ncoghlan, sbt
priority: normal
severity: normal
stage: test needed
status: open
title: Update multiprocessing.spawn to use runpy.run_path
versions: Python 3.5

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

From report at bugs.python.org  Fri Dec 13 22:31:17 2013
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 13 Dec 2013 21:31:17 +0000
Subject: [New-bugs-announce] [issue19979] Missing nested scope vars in class
	scope (bis)
Message-ID: <1386970277.4.0.799872209267.issue19979@psf.upfronthosting.co.za>


New submission from Armin Rigo:

This is a repeat of the old issue 532860: "NameError assigning to class in a func".  It is about class statements' variable lookups, which has different behavior at module level or in a nested scope:

def f(n):
    class A:
        n = n     # doesn't work, tries to look up 'n' as a global

The point of repeating this very old issue is the much more recent issue 17853: "Conflict between lexical scoping and name injection in __prepare__".  This was a slightly different problem, but resolved by adding the exact opcode that would be needed to fix the old issue too: LOAD_CLASSDEREF.  It's an opcode which looks in the locals dict for a name, and if not found, falls back to freevars instead of to globals.

The present bug report is here to argue that this new opcode should be used a bit more systematically by the compiler.  Contrary to the conclusions reached in the very old bug report, I argue that nowadays it would seem reasonable to expect that the previous example should work.  By no means is it an essential issue in my opinion, but this would probably be a slight simplification and prevent corner-case surprizes.  Moreover it probably leads to a simplification in the compiler: no need to track which variables are local or not in class bodies --- instead just compile the loading of 'n' above as a LOAD_CLASSDEREF without worrying about the fact that the same 'n' is also assigned to in the same scope.

----------
components: Interpreter Core
messages: 206149
nosy: arigo
priority: normal
severity: normal
status: open
title: Missing nested scope vars in class scope (bis)

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

From report at bugs.python.org  Sat Dec 14 02:34:52 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Dec 2013 01:34:52 +0000
Subject: [New-bugs-announce] [issue19980] Improve help('non-topic') response
Message-ID: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

>>> help(1)
# help on int
>>> help(b'a')
# help on bytes
>>> help('a')
no Python documentation found for 'a'

The reason for this unhelpful response is that strings are treated differently from all other non-class objects. (msg205861 thought this a bug.) The strings value is matched against strings that would be recognized at the help> prompt given after help().

>>> help('topics')
# list of TOPICS
>>> help('LISTS')
# information about mutable sequences

Suggestion: add something more about what to do. Example enhanced response:

No Python documentation found for 'a'. Try help('help') for information on recognized strings or help(str) for help on the str class.

I believe this could be backported since help() is intented for interactive use only.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 206157
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve help('non-topic') response
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Dec 14 10:47:14 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sat, 14 Dec 2013 09:47:14 +0000
Subject: [New-bugs-announce] [issue19981] Typo in mailbox documentation
Message-ID: <1387014434.61.0.267929363323.issue19981@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

In the last example, there is a misspelled imported module.

----------
assignee: docs at python
components: Documentation
files: mailbox_typo.patch
keywords: patch
messages: 206174
nosy: Claudiu.Popa, docs at python
priority: normal
severity: normal
status: open
title: Typo in mailbox documentation
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33130/mailbox_typo.patch

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

From report at bugs.python.org  Sat Dec 14 14:22:03 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Dec 2013 13:22:03 +0000
Subject: [New-bugs-announce] [issue19982] Add a "target" parameter to
	runpy.run_path and	runpy.run_module
Message-ID: <1387027323.14.0.795736210788.issue19982@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

One idea from PEP 451 was to add a "target" parameter to runpy.run_path and runpy.run_module to allow them to support execution in an existing module namespace (like __main__).

This missed the feature freeze deadline for 3.4, but can be added in 3.5.

----------
messages: 206181
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a "target" parameter to runpy.run_path and runpy.run_module
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Dec 15 03:28:58 2013
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Sun, 15 Dec 2013 02:28:58 +0000
Subject: [New-bugs-announce] [issue19983] Ctrl-C causes startup crashes on
	Windows
Message-ID: <1387074538.57.0.560740834981.issue19983@psf.upfronthosting.co.za>


New submission from Jurko Gospodneti?:

If you press Ctrl-C during Python startup on Windows you may get interpreter crashes with different Python tracebacks displayed on the standard system error output stream.

Reproduced using:
  - Windows 7 SP1 x64
  - Python 3.3.3 (64-bit) as downloaded from 'http://www.python.org/download/releases/3.3.3' (but seen with different earlier Python versions as well).
  - either a non-trivial Python script, one containing only a '#! python3' shabang line, or a completely empty one
  - default site.py

To reproduce simply run the Python interpreter with a prepared Python script as input and press Ctrl-C immediately afterwards.

Possible results:
  * Script finishes before your Ctrl-C kicks in.
  * You get a clean KeyboardInterrupt traceback and the script exits.
  * You get a KeyboardInterrupt traceback and the interpreter process crashes.

I'm attaching more detailed information on specific crash instances.

For some more information & background see the devel mailing list thread started at: 'https://mail.python.org/pipermail/python-dev/2013-December/130750.html'.

----------
components: Interpreter Core, Windows
files: crash-info-10.txt
messages: 206212
nosy: Jurko.Gospodneti?
priority: normal
severity: normal
status: open
title: Ctrl-C causes startup crashes on Windows
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file33137/crash-info-10.txt

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

From report at bugs.python.org  Sun Dec 15 06:23:22 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 15 Dec 2013 05:23:22 +0000
Subject: [New-bugs-announce] [issue19984] Add new format of fix length
	string for PyErr_Format
Message-ID: <1387085002.5.0.729792789255.issue19984@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

This ticket sprung from this discussion:
https://mail.python.org/pipermail/python-dev/2013-December/130756.html

Basically I am always confused when writing error message in C-API.

Is it:

PyErr_Format(PyExc_TypeError,"can't intern %.400s", s->ob_type->tp_name);

or

PyErr_Format(PyExc_TypeError,"can't intern %.80s", s->ob_type->tp_name);

or

PyErr_Format(PyExc_TypeError,"can't intern %s", s->ob_type->tp_name);

In conclusion, is it %s or %.80s or %.400s?

This patch will add one true way of writing fixed length string of the wrong type. This is just preliminary patch. I'll write the documentation later (and maybe test?).

----------
components: Interpreter Core
files: add_T_format_for_PyErr_Format.patch
keywords: patch
messages: 206216
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Add new format of fix length string for PyErr_Format
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file33141/add_T_format_for_PyErr_Format.patch

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

From report at bugs.python.org  Sun Dec 15 10:28:50 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 15 Dec 2013 09:28:50 +0000
Subject: [New-bugs-announce] [issue19985] Not so correct error message when
	initializing Struct	with ill argument
Message-ID: <1387099730.06.0.788825958744.issue19985@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Python 3.4 (3.3 is also afflicted:

>>> import struct
>>> struct.Struct(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Struct() argument 1 must be a bytes object, not int
>>> struct.Struct('b')
<Struct object at 0x7fec04763180>

Python 2.7:

>>> import struct
>>> struct.Struct(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Struct() argument 1 must be string, not int
>>> struct.Struct(u'b')
<Struct object at 0x17993e8>

Here is the patch to better error message for Python 3.4 and 3.3.

----------
components: Extension Modules
files: better_error_message_struct_python_34_and_33.patch
keywords: patch
messages: 206218
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Not so correct error message when initializing Struct with ill argument
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33143/better_error_message_struct_python_34_and_33.patch

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

From report at bugs.python.org  Sun Dec 15 16:13:58 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 15 Dec 2013 15:13:58 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlMTk5ODZdIOKAmG1wZF9kZWw=?=
 =?utf-8?q?=E2=80=99_discards_qualifiers_from_pointer_target_type?=
Message-ID: <1387120438.0.0.567792231798.issue19986@psf.upfronthosting.co.za>


New submission from Christian Heimes:

One buildbot is emitting a warning:

Modules/_decimal/libmpdec/mpdecimal.c:4438: warning: passing argument 1 of ?mpd_del? discards qualifiers from pointer target type

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/9351/steps/compile/logs/warnings%20%281%29

----------
components: Extension Modules
messages: 206236
nosy: christian.heimes
priority: low
severity: normal
stage: needs patch
status: open
title: ?mpd_del? discards qualifiers from pointer target type
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec 15 17:05:31 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 15 Dec 2013 16:05:31 +0000
Subject: [New-bugs-announce] [issue19987] Winsound: test_alias_fallback
	fails on WS 2008
Message-ID: <1387123531.4.0.00419061279512.issue19987@psf.upfronthosting.co.za>


New submission from Christian Heimes:

======================================================================
FAIL: test_alias_fallback (test.test_winsound.PlaySoundTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\test\test_winsound.py", line 167, in test_alias_fallback
    '!"$%&/(#+*', winsound.SND_ALIAS
AssertionError: RuntimeError not raised by PlaySound


http://buildbot.python.org/all/builders/x86%20Windows%20Server%202008%20%5BSB%5D%203.x/builds/1948/steps/test/logs/stdio

----------
components: Tests
keywords: buildbot
messages: 206237
nosy: christian.heimes, serhiy.storchaka
priority: low
severity: normal
stage: test needed
status: open
title: Winsound: test_alias_fallback fails on WS 2008
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec 15 17:27:52 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 15 Dec 2013 16:27:52 +0000
Subject: [New-bugs-announce] [issue19988] hex() and oct() use __index__
	instead of __int__
Message-ID: <1387124872.75.0.863849760572.issue19988@psf.upfronthosting.co.za>


New submission from Ethan Furman:

In Py3k __hex__ and __oct__ were removed, and hex() and oct() switched to use __index__.

hex() and oct() should be using __int__ instead.

Having read through PEP 357 [1] I see that __index__ is /primarily/ concerned with allowing arbitrary objects to be used in slices, but will also allow Python to convert an object to an int "whenever it needs one".

The problem is that my dbf [2] module has a couple custom types (Logical and Quantum) that allow for ternary logic (False/True/Unknown).  As much as possible Logical is intended to be a drop in replacement for the bool type, but of course there are some differences:

  - internally 'unknown' is represented as None

  - attempts to get an int, float, complex, etc., numeric value
    on Unknown raises an Exception

  - attempts to get the numeric string value via __hex__ and
    __oct__ on Unknown raises an Exception

  - when Unknown is used as an index (via __index__), 2 is returned

The problem, of course, is that in Python 3 calling hex() and oct() on Unknown now succeeds when it should be raising an exception, and would be if __int__ were used instead of __index__.

In summary, if Python just switches to using __index__, there would be little point in having separate __int__ and __index__ methods.


[1] http://www.python.org/dev/peps/pep-0357
[2] https://pypi.python.org/pypi/dbf

----------
messages: 206238
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: hex() and oct() use __index__ instead of __int__
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec 15 17:39:00 2013
From: report at bugs.python.org (Filip Malczak)
Date: Sun, 15 Dec 2013 16:39:00 +0000
Subject: [New-bugs-announce] [issue19989] Error while sending function code
	over queue	(multiprocessing)
Message-ID: <1387125540.4.0.544926984003.issue19989@psf.upfronthosting.co.za>


New submission from Filip Malczak:

Ive been using YAPSY to load plugins in one process. In this process I tried to put them in queue, and in another process I read them from queue.

There was a problem with non-existing type of plugin in consumer process, so I tried to serialize plugin instance by hand and deserialize by hand in consumer.

Both processes were created and started from main process, which passed them both the same queue.

Law forbids me from showing the whole code, but I'm attaching file with code pieces that generate error below:

Process ConsumerProcess-2:
Traceback (most recent call last):
  File "/usr/lib/python3.3/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/usr/lib/python3.3/multiprocessing/process.py", line 95, in run
    self._target(*self._args, **self._kwargs)
  File "/<private_path>/consumer_stub.py", line 27, in _consumer
    result = foo()
  File "/<private_path>/loader_process.py", line 90, in x
    val = (kind, plugin, meta)
SystemError: ../Objects/cellobject.c:24: bad argument to internal function

----------
components: Build
files: pythonbug.txt
messages: 206239
nosy: Filip.Malczak
priority: normal
severity: normal
status: open
title: Error while sending function code over queue (multiprocessing)
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file33149/pythonbug.txt

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

From report at bugs.python.org  Sun Dec 15 23:27:50 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 15 Dec 2013 22:27:50 +0000
Subject: [New-bugs-announce] [issue19990] Add unittests for imghdr module
Message-ID: <1387146470.57.0.419345603545.issue19990@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hello! The following patch adds unit tests for the previously untested `imghdr` module.

----------
components: Tests
files: test_imghdr.patch
keywords: patch
messages: 206262
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Add unittests for imghdr module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33155/test_imghdr.patch

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

From report at bugs.python.org  Mon Dec 16 01:13:55 2013
From: report at bugs.python.org (Andrei Kucharavy)
Date: Mon, 16 Dec 2013 00:13:55 +0000
Subject: [New-bugs-announce] [issue19991] configparser instances cannot be
	pretty printed
Message-ID: <1387152835.44.0.30925026143.issue19991@psf.upfronthosting.co.za>


New submission from Andrei Kucharavy:

ConfigParser seems to share a lot of behavior with a dict, but cannot be pretty printed.

----------
messages: 206267
nosy: Andrei.Kucharavy
priority: normal
severity: normal
status: open
title: configparser instances cannot be pretty printed
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Dec 16 02:52:40 2013
From: report at bugs.python.org (Thayne McCombs)
Date: Mon, 16 Dec 2013 01:52:40 +0000
Subject: [New-bugs-announce] [issue19992] subprocess documentation not
	explicit about fileno()
Message-ID: <1387158760.79.0.499761911724.issue19992@psf.upfronthosting.co.za>


New submission from Thayne McCombs:

The subprocess documentation for stdout/stderr/stdin states: 
"Valid values are PIPE, an existing file descriptor (a positive integer), an existing file object, and None. PIPE indicates that a new pipe to the child should be created."

However, file-like objects such as StringIO are not valid if they do not implement fileno(). The documentation should be more explicit that the file object should be backed by an actual file descriptor (and therefore has a fileno() function).

----------
assignee: docs at python
components: Documentation
messages: 206272
nosy: Thayne.McCombs, docs at python
priority: normal
severity: normal
status: open
title: subprocess documentation not explicit about fileno()

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

From report at bugs.python.org  Mon Dec 16 09:31:16 2013
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Mon, 16 Dec 2013 08:31:16 +0000
Subject: [New-bugs-announce] [issue19993] Pool.imap doesn't work as
	advertised
Message-ID: <1387182676.04.0.471976296284.issue19993@psf.upfronthosting.co.za>


New submission from Jurjen N.E. Bos:

The pool.imap and pool.imap_unordered functions are documented as "a lazy version of Pool.map".
In fact, they aren't: they consume the iterator argument as a whole. This is almost certainly not what the user wants: it uses unnecessary memory and will be slower than expected if the output iterator isn't consumed in full. In fact, there isn't much use at all of imap over map at the moment.
I tried to fixed the code myself, but due to the two-level queueing of the input arguments this is not trivial.
Stackoverflow's Blckknght wrote a simplified solution that gives the idea how it should work.
Since that wasn't posted here, I thought it would be useful to put it here, even if only for documentation purposes.

----------
components: Library (Lib)
files: mypool.py
messages: 206279
nosy: jneb
priority: normal
severity: normal
status: open
title: Pool.imap doesn't work as advertised
type: behavior
Added file: http://bugs.python.org/file33158/mypool.py

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

From report at bugs.python.org  Mon Dec 16 10:16:04 2013
From: report at bugs.python.org (Taesu Pyo)
Date: Mon, 16 Dec 2013 09:16:04 +0000
Subject: [New-bugs-announce] [issue19994] re.match does not return or takes
	long time
Message-ID: <1387185364.15.0.621254841933.issue19994@psf.upfronthosting.co.za>


New submission from Taesu Pyo:

// code sampe:

import re

r = (r'(/.*)*X')
s = '////////////////////////////'

print re.match(r, s)
print list(re.finditer(r, s))
print re.findall(r, s)

// it does not return or takes long time depends on length of 's'

----------
components: Regular Expressions
messages: 206283
nosy: Taesu.Pyo, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.match does not return or takes long time
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Dec 16 11:29:04 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Dec 2013 10:29:04 +0000
Subject: [New-bugs-announce] [issue19995] hex() and %x,
	oct() and %o do not behave the same
Message-ID: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Using Enum to illustrate:

    --> class Grade(enum.Enum):
    ...   A = 4
    ...   B = 3
    ...   C = 2
    ...   D = 1
    ...   F = 0
    ...   def __index__(self):
    ...     return self._value_

    --> ['miserable'][Grade.F]
    'miserable'

    --> '%x' % Grade.F
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: %x format: a number is required, not Grade

    --> hex(Grade.F)
    '0x0'

I suggest that hex() and oct() have the same check that %x and %o do so that non-numbers are not representable as hex and octal.  

While we're at it, we should do the same for bin().  Are there any others?

I'll create a patch once we have a decision on which way to solve this issue.

----------
assignee: ethan.furman
messages: 206290
nosy: ethan.furman, gvanrossum, mark.dickinson, pitrou, rhettinger, serhiy.storchaka, skrah
priority: normal
severity: normal
status: open
title: hex() and %x, oct() and %o do not behave the same
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec 16 12:42:30 2013
From: report at bugs.python.org (Cory Benfield)
Date: Mon, 16 Dec 2013 11:42:30 +0000
Subject: [New-bugs-announce] [issue19996] httplib infinite read on invalid
	header
Message-ID: <1387194150.79.0.311354392317.issue19996@psf.upfronthosting.co.za>


Changes by Cory Benfield <cory at lukasa.co.uk>:


----------
components: Library (Lib)
nosy: Lukasa
priority: normal
severity: normal
status: open
title: httplib infinite read on invalid header
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Dec 16 13:48:13 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Mon, 16 Dec 2013 12:48:13 +0000
Subject: [New-bugs-announce] [issue19997] imghdr.what doesn't accept bytes
	paths
Message-ID: <1387198093.92.0.388328564702.issue19997@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

imghdr.what check explicitly for string path, while `open` happily accepts bytes paths, as seen below:

>>> x
b'\xc2\xba'
>>> imghdr.what(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tank/libs/cpython/Lib/imghdr.py", line 15, in what
    location = file.tell()
AttributeError: 'bytes' object has no attribute 'tell'
>>> open(x)
<_io.TextIOWrapper name=b'\xc2\xba' mode='r' encoding='UTF-8'>

A reason why this should be supported can be found in this message: http://bugs.python.org/msg191691.
The following patch fixes this. Also, it depends on issue19990 (where test_imghdr.py was added).

----------
components: Library (Lib)
files: imghdr_bytes.patch
keywords: patch
messages: 206299
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: imghdr.what doesn't accept bytes paths
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file33164/imghdr_bytes.patch

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

From report at bugs.python.org  Mon Dec 16 14:34:41 2013
From: report at bugs.python.org (Jim Carroll)
Date: Mon, 16 Dec 2013 13:34:41 +0000
Subject: [New-bugs-announce] [issue19998] Python 2.7.6 fails to build
	_ctypes on GCC 2.x toolchain
Message-ID: <1387200881.03.0.963168965941.issue19998@psf.upfronthosting.co.za>


New submission from Jim Carroll:

When building Python 2.7.6 on older GCC 2.x, the _ctypes module fails to build. The failure is caused due to a header file reference to __builtin_expect (the author expected this to be available when the module was built with gcc, but did not take into account that this was not available in all versions of gcc).

The solution is a simple modification to the test in ffi_common.h

--- Modules/_ctypes/libffi/include/ffi_common.h Sun Nov 10 02:36:41 2013
+++ Modules/_ctypes/libffi/include/ffi_common.h.fix     Mon Dec 16 08:23:56 2013
@@ -115,7 +115,7 @@

 typedef float FLOAT32;

-#ifndef __GNUC__
+#if !defined(__GNUC__) || __GNUC__==2
 #define __builtin_expect(x, expected_value) (x)
 #endif
 #define LIKELY(x)    __builtin_expect(!!(x),1)

----------
components: Build
files: ffi_common.h.patch
keywords: patch
messages: 206307
nosy: jamercee
priority: normal
severity: normal
status: open
title: Python 2.7.6 fails to build _ctypes on GCC 2.x toolchain
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file33165/ffi_common.h.patch

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

From report at bugs.python.org  Mon Dec 16 19:46:58 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 16 Dec 2013 18:46:58 +0000
Subject: [New-bugs-announce] [issue19999] test_monotonic fails on x86
	OpenIndiana
Message-ID: <1387219618.02.0.0675755074748.issue19999@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I have seen this failure multiple times.

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

======================================================================
FAIL: test_monotonic (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_time.py", line 387, in test_monotonic
    self.assertAlmostEqual(dt, 0.5, delta=0.2)
AssertionError: 0.8012567944824696 != 0.5 within 0.2 delta

----------------------------------------------------------------------

----------
assignee: haypo
components: Tests
keywords: buildbot
messages: 206344
nosy: christian.heimes, haypo
priority: low
severity: normal
stage: test needed
status: open
title: test_monotonic fails on x86 OpenIndiana
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec 16 19:53:50 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 16 Dec 2013 18:53:50 +0000
Subject: [New-bugs-announce] [issue20000] SSLContext.get_ca_certs() and
	self-signed certs
Message-ID: <1387220030.99.0.0276464783547.issue20000@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The new method SSLContext.get_ca_certs() returns all certificates in the context's trusted X509_STORE. I recently found out that it is possible to put a self-signed certificate into the store and use it successfully with verify_mode CERT_REQUIRED. get_ca_certs() doesn't return the cert although it is used to successfully validate a remote cert.

I propose to modify and rename the function and to add a "check_ca" to the dict that is returned by getpeercert().

----------
components: Extension Modules
messages: 206347
nosy: christian.heimes
priority: normal
severity: normal
stage: test needed
status: open
title: SSLContext.get_ca_certs() and self-signed certs
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec 16 20:18:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 19:18:58 +0000
Subject: [New-bugs-announce] [issue20001] pathlib inheritance diagram too
	large
Message-ID: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The inheritance diagram at http://docs.python.org/dev/library/pathlib.html is too large, it can easily take up half the vertical space (or perhaps all of it on a smaller screen).

The font size looks fine, it's just that there's a lot of spacing around.
(of course, the style could perhaps also be changed or improved)

----------
assignee: docs at python
components: Documentation
messages: 206354
nosy: docs at python, eli.bendersky, georg.brandl, pitrou
priority: low
severity: normal
status: open
title: pathlib inheritance diagram too large
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec 16 20:49:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Dec 2013 19:49:49 +0000
Subject: [New-bugs-announce] [issue20002] Cleanup and microoptimize pathlib
Message-ID: <1387223389.48.0.793135130447.issue20002@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which contains many small cleanups and optimizations for the pathlib module. Not all of them can be backported to 2.7 version.

----------
assignee: pitrou
components: Library (Lib)
files: pathlib_cleanup.patch
keywords: patch
messages: 206357
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Cleanup and microoptimize pathlib
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33167/pathlib_cleanup.patch

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

From report at bugs.python.org  Tue Dec 17 04:47:52 2013
From: report at bugs.python.org (rurpy)
Date: Tue, 17 Dec 2013 03:47:52 +0000
Subject: [New-bugs-announce] [issue20003] Language Ref "raise" doc misssing
	"from None"
Message-ID: <1387252072.89.0.572943909834.issue20003@psf.upfronthosting.co.za>


New submission from rurpy:

In the current (3.3.3 and 3.4dev) Language Reference Manual, the section on the Raise statement fails to mention that the second expression can be None (per PEP-409/415) or the special behavior (suppressing a chained exception) that ensues.  Rather it explicitly states it can not be None:
 "...the second expression must be another exception class  or instance..."

It appears that although the Exceptions section of the Library Reference was updated when PEP-409/415 was implemented, the Language Reference was not.

----------
assignee: docs at python
components: Documentation
messages: 206400
nosy: docs at python, rurpy2
priority: normal
severity: normal
status: open
title: Language Ref "raise" doc misssing "from None"
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec 17 12:09:53 2013
From: report at bugs.python.org (Peter Otten)
Date: Tue, 17 Dec 2013 11:09:53 +0000
Subject: [New-bugs-announce] [issue20004] csv.DictReader classic class has a
	property with setter
Message-ID: <1387278593.92.0.0717442259637.issue20004@psf.upfronthosting.co.za>


New submission from Peter Otten:

I ran into this when trying to trigger rereading the column names with

$ cat tmp.csv
alpha,beta
1,2
gamma,delta,epsilon
3,4,5
$ python
Python 2.7.2+ (default, Jul 20 2012, 22:15:08) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> with open("tmp.csv") as f:
...     reader = csv.DictReader(f)
...     for i in range(2):
...             print next(reader)
...             reader.fieldnames = None
... 
{'alpha': '1', 'beta': '2'}
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  File "/usr/lib/python2.7/csv.py", line 112, in next
    d = dict(zip(self.fieldnames, row))
TypeError: zip argument #1 must support iteration

reader = csv.DictReader(...)
...
reader.fieldnames = None

I think the easiest fix would be to have it inherit from object:

>>> class DictReader(csv.DictReader, object): pass
... 
>>> with open("tmp.csv") as f:
...     reader = DictReader(f)
...     for i in range(2):
...             print next(reader)
...             reader.fieldnames = None
... 
{'alpha': '1', 'beta': '2'}
{'3': 'gamma', '5': 'epsilon', '4': 'delta'}

----------
messages: 206418
nosy: peter.otten
priority: normal
severity: normal
status: open
title: csv.DictReader classic class has a property with setter
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec 17 13:26:35 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 17 Dec 2013 12:26:35 +0000
Subject: [New-bugs-announce] [issue20005] Minor typo in operator
	documentation
Message-ID: <1387283195.64.0.628097556961.issue20005@psf.upfronthosting.co.za>


Changes by Claudiu.Popa <pcmanticore at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: typo_operator.patch
keywords: patch
nosy: Claudiu.Popa, docs at python
priority: normal
severity: normal
status: open
title: Minor typo in operator documentation
versions: Python 3.4
Added file: http://bugs.python.org/file33176/typo_operator.patch

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

From report at bugs.python.org  Tue Dec 17 14:55:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 13:55:47 +0000
Subject: [New-bugs-announce] [issue20006] Sporadic failures of test_weakset
Message-ID: <1387288547.32.0.139263201617.issue20006@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

test_weakset often fails on FreeBSD. Fo example see http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%202.7/builds/285/steps/test/logs/stdio.

test test_weakset failed -- Traceback (most recent call last):
  File "/usr/home/buildbot/koobs-freebsd10/2.7.koobs-freebsd10/build/Lib/test/test_weakset.py", line 491, in test_weak_destroy_and_mutate_while_iterating
    self.assertTrue(u in s)
AssertionError: False is not true

Second run of this test is successful.

----------
messages: 206435
nosy: fdrake, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Sporadic failures of test_weakset
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec 17 15:29:41 2013
From: report at bugs.python.org (Simon Sapin)
Date: Tue, 17 Dec 2013 14:29:41 +0000
Subject: [New-bugs-announce] [issue20007] .read(0) on
	http.client.HTTPResponse drops the rest of	the content
Message-ID: <1387290581.03.0.808557642929.issue20007@psf.upfronthosting.co.za>


New submission from Simon Sapin:

When given a file-like object, html5lib calls .read(0) in order to check if the result is bytes or Unicode:

https://github.com/html5lib/html5lib-python/blob/e269a2fd0aafcd83af7cf1e65bba65c0e5a2c18b/html5lib/inputstream.py#L434

When given the result of urllib.client.urlopen(), it parses an empty document because of this bug.

Test case:

>>> from urllib.request import urlopen
>>> response = urlopen('http://python.org')
>>> response.read(0)
b''
>>> len(response.read())
0

For comparison:

>>> response = urlopen('http://python.org')
>>> len(response.read())
20317

The bug is here:

http://hg.python.org/cpython/file/d489394a73de/Lib/http/client.py#l541

'if not n:' assumes that "zero bytes have been read" indicates EOF, which is not the case when we ask for zero bytes.

----------
messages: 206446
nosy: ssapin
priority: normal
severity: normal
status: open
title: .read(0) on http.client.HTTPResponse drops the rest of the content
type: behavior

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

From report at bugs.python.org  Tue Dec 17 22:24:32 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 17 Dec 2013 21:24:32 +0000
Subject: [New-bugs-announce] [issue20008] Clean up/refactor/make
	discoverable test_decimal
Message-ID: <1387315472.11.0.523562380055.issue20008@psf.upfronthosting.co.za>


New submission from Zachary Ware:

This patch makes extensive changes to test_decimal, with the ultimate goal of making `python -m unittest discover Lib/test/ "test_*.py"` not choke on test_decimal (see issue16748).  Trying to do so uncovered a few other issues, such as some tests not properly cleaning up the context.

Here's a (non-exhaustive) list of what the patch will do:

- Clean up imports, including a repeated import of warnings
- Create a new hierarchy of TestCase subclasses
    - BaseTestCase is an empty subclass of unittest.TestCase to serve
      as a base class for all tests that are meant to test both
      implementations.  This makes it easy to find such tests and
      create the implementation-specific test cases programmatically.
    - DecimalTest defines some methods for all tests:
        - setUp and tearDown, which ensure that the context is set up
          properly and cleaned up properly.  A test that changes the
          context is marked as a failure in tearDown.  These take the
          place of the toplevel init(module) function.
        - assertSignals, formerly toplevel assert_signals.  It has
          also been enhanced to provide the current context if no
          context is given, and to accept strings as signals (which
          are then looked up on the current decimal module to get the
          real exception)
        - assertAndClearFlags, which is a shortcut for
          assertSignals('flags' ...) and clears the flags when done.
          Several tests made no changes to the context except for
          flags, and this was a quick, easy, and convenient way to
          confirm behavior and clean up.
    - CDecimalTest and PyDecimalTest, subclasses of DecimalTest which
      can be inherited from directly by tests that are meant for a
      single implementation (such as C/PyWhitebox, C/PyFunctionality),
      and are inherited by the generated subclasses of the base classes
      (IBMTestCases, FormatTest, etc.)
- Do away with the 'skip_expected' global, use a decorator to skip
  IBMTestCases if the test data can't be found.
- Clean up other toplevel setup code a bit.
- Make vertical spacing more consistent throughout the module.
- Move a couple of tests into `with localcontext()` blocks to avoid
  context pollution.
- Decorate all of CFunctionality with @requires_extra_functionality
  instead of each individual test
- Remove the explicit listing of test classes.
- Remove test_main().
- Add a Doctests base class which runs the doctests via 
  doctest.testmod() and expects a certain number of tests to have been
  run.  Attempts to use doctest.DocTestSuite were stymied by the
  two-headed nature of decimal and _decimal, and would have required a 
  load_tests function to load them anyway.
- Add tearDownModule, which restores the original contexts and checks
  to make sure sys.modules['decimal'] is as expected.
- Convert `if __name__ == '__main__'` argument handling from optparse 
  to argparse.
    - Allow arguments to be passed through to unittest.main().
    - The old method of specifying IBM test case names now requires a
      '--test' or '-t' switch before each set of names (more than one
      -t switch can be present, but each must have at least one name
      following).
    - Add an '--extended'/'-e' switch for switching
      'EXTENDEDERRORTEST', which formerly required editing the file.
- Use unittest.main() for running the script directly.

With the patch test_decimal can be run successfully: directly, by regrtest, or by unittest discovery in Lib/test/; with any acceptable combination of arguments when run directly; with or without _decimal; with or without -OO.  I have not yet been able to test -DEXTRA_FUNCTIONALITY, --without-docstrings, or on any platform but Windows, but I don't expect any issues (of course :).

The patch is against default; 3.3 requires the removal of a usage of subTest and a tweaking of the Doctest expected results.

Any review will be very much appreciated!

Thanks,

Zach

----------
components: Tests
files: test_decimal_cleanup.diff
keywords: needs review, patch
messages: 206482
nosy: ezio.melotti, facundobatista, mark.dickinson, rhettinger, skrah, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Clean up/refactor/make discoverable test_decimal
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33182/test_decimal_cleanup.diff

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

From report at bugs.python.org  Tue Dec 17 22:49:55 2013
From: report at bugs.python.org (steven Michalske)
Date: Tue, 17 Dec 2013 21:49:55 +0000
Subject: [New-bugs-announce] [issue20009] Property should expose wrapped
	function.
Message-ID: <1387316995.02.0.931185950843.issue20009@psf.upfronthosting.co.za>


New submission from steven Michalske:

When using the @property decorator the wrapped functions are not exposed for source introspection. (At least I can't see how they are.)

The issue is then that Ipython "%psource" will show the source for the @property as opposed to the function that it wraps.

By implementing the __wrapped__ attribute you can set the wrapped function to fget and then the source for that function can me identified for source introspection.

I perform this hack in code to overcome this issue.

class qproperty(property):
    # Fix for ipython ? and ?? (%pdef, %psource)
    # Omitting the class doc string prevents ipython from showing the
    # doctoring for the property builtin class; I suspect this is a
    # bug.
    def __init__(self, fget=None, fset=None, fdel=None, doc=None):
        super(qproperty, self).__init__(fget, fset, fdel, doc)
        self.__wrapped__ = fget

# Overwrite property with qproperty so that in the future this hack might
# be easily removed.
property = qproperty

This is related to issue #5982.

----------
messages: 206483
nosy: hardkrash
priority: normal
severity: normal
status: open
title: Property should expose wrapped function.
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Dec 17 23:38:51 2013
From: report at bugs.python.org (Civa Lin)
Date: Tue, 17 Dec 2013 22:38:51 +0000
Subject: [New-bugs-announce] [issue20010] time.strftime('%z') didn't make
	+HHMM return in windows	xp
Message-ID: <1387319931.23.0.412917689607.issue20010@psf.upfronthosting.co.za>


New submission from Civa Lin:

On windows xp (Taiwanese) platform...

    c:\> py -c "import time; print(time.strftime('%z', time.localtime()))"

It will raise a UnicodeEncodeError in my system.

I think it's not a +HHMM format and has different behavior with document:
    http://docs.python.org/3/library/time.html#time.strftime

----------
components: Library (Lib), Unicode, Windows
messages: 206484
nosy: civalin, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: time.strftime('%z') didn't make +HHMM return in windows xp
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Dec 18 01:04:43 2013
From: report at bugs.python.org (Antony Lee)
Date: Wed, 18 Dec 2013 00:04:43 +0000
Subject: [New-bugs-announce] [issue20011] Changing the signature for
	Parameter's constructor
Message-ID: <1387325083.19.0.919186460465.issue20011@psf.upfronthosting.co.za>


New submission from Antony Lee:

As suggested on python-ideas, this small patch changes the constructor of inspect.Parameter so that "kind" defaults to "POSITIONAL_OR_KEYWORD", which should make code that needs to construct Parameter objects slightly less verbose (as I believe POSITIONAL_OR_KEYWORD is likely the most common kind).

----------
components: Library (Lib)
files: parameter-constructor.patch
keywords: patch
messages: 206490
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Changing the signature for Parameter's constructor
versions: Python 3.5
Added file: http://bugs.python.org/file33183/parameter-constructor.patch

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

From report at bugs.python.org  Wed Dec 18 07:10:11 2013
From: report at bugs.python.org (Alexander Boyd)
Date: Wed, 18 Dec 2013 06:10:11 +0000
Subject: [New-bugs-announce] [issue20012] Allow Path.relative_to() to accept
	non-ancestor paths
Message-ID: <1387347011.06.0.0464883312921.issue20012@psf.upfronthosting.co.za>


New submission from Alexander Boyd:

pathlib.Path.relative_to() blows up when given a path that's not an ancestor of the path on which relative_to is being called:

>>> pathlib.Path("/usr/bin").relative_to("/etc")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "pathlib.py", line 822, in relative_to
    .format(str(self), str(formatted)))
ValueError: '/usr/bin' does not start with '/etc'

The equivalent with posixpath.relpath (or ntpath.relpath) works just fine:

>>> posixpath.relpath("/usr/bin", "/etc")
'../usr/bin'

It'd be nice if Path.relative_to supported this type of usage.

----------
components: Library (Lib)
messages: 206497
nosy: javawizard, pitrou
priority: normal
severity: normal
status: open
title: Allow Path.relative_to() to accept non-ancestor paths
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Dec 18 09:34:20 2013
From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=)
Date: Wed, 18 Dec 2013 08:34:20 +0000
Subject: [New-bugs-announce] [issue20013] imaplib behaviour when deleting
	selected folder
Message-ID: <1387355660.84.0.595349398689.issue20013@psf.upfronthosting.co.za>


New submission from Dani?l van Eeden:

When executing DELETE against a SELECTED imap folder the server responds:
---------------------------
a8 SELECT SentMail
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
* 0 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1386063387] UIDs valid
* OK [UIDNEXT 1] Predicted next UID
* OK [NOMODSEQ] No permanent modsequences
a8 OK [READ-WRITE] Select completed (0.001 secs).
a9 delete SentMail
a9 OK Delete completed.
* BYE Selected mailbox was deleted, have to disconnect.
Connection closed by foreign host.
---------------------------

If the same is done with imaplib the exception does not clearly
indicate what happened.

  File "/usr/lib/python2.7/imaplib.py", line 649, in select
    typ, dat = self._simple_command(name, mailbox)
  File "/usr/lib/python2.7/imaplib.py", line 1070, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/lib/python2.7/imaplib.py", line 899, in _command_complete
    raise self.abort('command: %s => %s' % (name, val))
imaplib.abort: command: SELECT => socket error: EOF

----------
components: Library (Lib)
messages: 206501
nosy: dveeden
priority: normal
severity: normal
status: open
title: imaplib behaviour when deleting selected folder
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec 18 10:49:55 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 18 Dec 2013 09:49:55 +0000
Subject: [New-bugs-announce] [issue20014] Makes array.array constructor
	accepts ascii-unicode	typecode
Message-ID: <1387360195.98.0.786950742842.issue20014@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

>>> import array
>>> array.array(u'i', [1,2,3])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be char, not unicode

In this ticket #13566, Alexandre Vassalotti said:
"We should still fix array in 2.7 to accept unicode object for the typecode though."

So here is the patch to add support for ascii-unicode typecode for array.array constructor.

----------
components: Extension Modules
files: makes_array_accepts_ascii_unicode_typecode.patch
keywords: patch
messages: 206503
nosy: alexandre.vassalotti, vajrasky
priority: normal
severity: normal
status: open
title: Makes array.array constructor accepts ascii-unicode typecode
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file33184/makes_array_accepts_ascii_unicode_typecode.patch

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

From report at bugs.python.org  Wed Dec 18 16:59:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 15:59:26 +0000
Subject: [New-bugs-announce] [issue20015] Allow 1-character ASCII unicode
	where 1-character str is	required
Message-ID: <1387382366.37.0.964927896158.issue20015@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In most cases when str object required, unicode object is allowed too. "s" and "z" codes (with modifiers) in PyArg_Parse*() accept both str and unicode instances. But "c" code accepts only 1-character str, not unicode. This makes harder writing version-agnostic code with imported unicode_literals (2.7 functions require bytes literals, 3.x functions require unicode literals) and breaks pickle compatibility (see issue13566).

This change will affect:

* str.ljust(), str.rjust() and str.center();
* '%c' % char;
* mmap.write_byte();
* array constructor and item setter for 'c' type;
* datetime.isoformat();
* bsddb.set_re_delim() and bsddb.set_re_pad();
* msvcrt.putch() and msvcrt.ungetch();
* swi.block.padstring().

----------
components: Interpreter Core
files: getargs_c_unicode.patch
keywords: patch
messages: 206529
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Allow 1-character ASCII unicode where 1-character str is required
versions: Python 2.7
Added file: http://bugs.python.org/file33193/getargs_c_unicode.patch

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

From report at bugs.python.org  Wed Dec 18 17:10:15 2013
From: report at bugs.python.org (Derek Wilson)
Date: Wed, 18 Dec 2013 16:10:15 +0000
Subject: [New-bugs-announce] [issue20016] make site.py Quitter call itself
	on repr
Message-ID: <1387383015.85.0.019158387414.issue20016@psf.upfronthosting.co.za>


New submission from Derek Wilson:

calling exit() or quit() is actually very cumbersome especially as most other commandline tools that have a command interface allow you to exit or quit by typing exit or quit and not by calling a function.

if quitter's builtins are only available in the interactive interpreter this seems like it would be perfectly safe. now that we are looking at 3.x going forward, perhaps we can reopen this: http://bugs.python.org/issue8220

----------
components: Extension Modules
files: quit_from_repr.patch
keywords: patch
messages: 206537
nosy: underrun
priority: normal
severity: normal
status: open
title: make site.py Quitter call itself on repr
versions: Python 3.5
Added file: http://bugs.python.org/file33194/quit_from_repr.patch

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

From report at bugs.python.org  Wed Dec 18 17:33:28 2013
From: report at bugs.python.org (Hugo.Lol)
Date: Wed, 18 Dec 2013 16:33:28 +0000
Subject: [New-bugs-announce] [issue20017] SimpleHTTPServer:
	UnicodeDecodeError on Windows 8	(64-bit)
Message-ID: <1387384408.95.0.919714643908.issue20017@psf.upfronthosting.co.za>


New submission from Hugo.Lol:

Running Windows 8 (64-bit) and Python 2.7.6 (64-bit).

> python -m SimpleHTTPServer
Traceback (most recent call last):
  File "C:\Python27\lib\runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "C:\Python27\lib\runpy.py", line 72, in _run_code
    exec code in run_globals
  File "C:\Python27\lib\SimpleHTTPServer.py", line 27, in <module>
    class SimpleHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler):
  File "C:\Python27\lib\SimpleHTTPServer.py", line 208, in SimpleHTTPRequestHand
ler
    mimetypes.init() # try to read system mime.types
  File "C:\Python27\lib\mimetypes.py", line 358, in init
    db.read_windows_registry()
  File "C:\Python27\lib\mimetypes.py", line 258, in read_windows_registry
    for subkeyname in enum_types(hkcr):
  File "C:\Python27\lib\mimetypes.py", line 249, in enum_types
    ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd7 in position 2: ordinal
not in range(128)

----------
components: Unicode, Windows
messages: 206538
nosy: Hugo.Lol, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: SimpleHTTPServer: UnicodeDecodeError on Windows 8 (64-bit)
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec 18 19:52:35 2013
From: report at bugs.python.org (Jeroen Van Goey)
Date: Wed, 18 Dec 2013 18:52:35 +0000
Subject: [New-bugs-announce] [issue20018] Replace dead URL with link to
	mirror
Message-ID: <1387392755.61.0.550067417471.issue20018@psf.upfronthosting.co.za>


New submission from Jeroen Van Goey:

The header of a cookie file generated by _MozillaCookieJar.py contains a link to the spec: http://www.netscape.com/newsref/std/cookie_spec.html

This URL no longer exists (redirects to the AOL homepage). Attached patch replaces the link with a mirror where the original text is hosted.

----------
assignee: docs at python
components: Documentation
files: _MozillaCookieJar.diff
keywords: patch
messages: 206549
nosy: docs at python, jeroen-vangoey, loewis
priority: normal
severity: normal
status: open
title: Replace dead URL with link to mirror
type: enhancement
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file33196/_MozillaCookieJar.diff

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

From report at bugs.python.org  Thu Dec 19 00:08:47 2013
From: report at bugs.python.org (Wes)
Date: Wed, 18 Dec 2013 23:08:47 +0000
Subject: [New-bugs-announce] [issue20019] platform.py line _sys_version
	function
Message-ID: <1387408127.09.0.79406077892.issue20019@psf.upfronthosting.co.za>


New submission from Wes:

Marc-Andre,
I'm on a Macbook pro OSX Mountain Lion

I've been automating virtual environment builds locally and remotely, but it seems that when my "pip install -r requirements.txt" tries to run and download.py in pip/ runs it invokes "platform.py".  I'm getting a user-agent issue from the _sys_version function.  Here is the error:



  File "/Users/me/anaconda/lib/python2.7/platform.py", line 1500, in python_implementation
    return _sys_version()[0]

  File "/Users/me/anaconda/lib/python2.7/platform.py", line 1464, in _sys_version
    repr(sys_version))
ValueError: failed to parse CPython sys.version: '2.7.5 (default, Sep 12 2013, 21:33:34) \n[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)]'


I've found the following stack that also references this error:

http://stackoverflow.com/questions/19105255/praw-failed-to-parse-cpython-sys-version-when-creating-reddit-object

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 206560
nosy: lemburg, wesmadrigal
priority: normal
severity: normal
status: open
title: platform.py line _sys_version function
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec 19 05:05:25 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 04:05:25 +0000
Subject: [New-bugs-announce] [issue20020] "modernize" the modulefinder module
Message-ID: <1387425925.56.0.593354940747.issue20020@psf.upfronthosting.co.za>


New submission from Eric Snow:

The modulefinder module (Lib/modulefinder.py) provides a ModuleFinder class (plus 2 helpers) you can use to see what modules a script imports (directly or indirectly).  The module's implementation is centered on the old imp.find_/load_module() API (which has been deprecated).  The implementation should be refactored to reflect/make use of the newer import-related APIs.

The documented API for ModuleFinder is very small.  However, it has quite a few methods that are "public" in the sense that their names do not start with an underscore.  This will make any kind of refactoring trickier.

----------
components: Library (Lib)
messages: 206576
nosy: eric.snow
priority: low
severity: normal
status: open
title: "modernize" the modulefinder module
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Dec 19 05:11:25 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 04:11:25 +0000
Subject: [New-bugs-announce] [issue20021] "modernize" makeopcodetargets.py
Message-ID: <1387426285.76.0.769422966502.issue20021@psf.upfronthosting.co.za>


New submission from Eric Snow:

Python/makeopcodetargets.py uses deprecated imp APIs.  It should be refactored to use newer import-related APIs.

----------
components: Library (Lib)
messages: 206577
nosy: eric.snow
priority: low
severity: normal
status: open
title: "modernize" makeopcodetargets.py
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Dec 19 05:13:34 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 04:13:34 +0000
Subject: [New-bugs-announce] [issue20022] "modernize" the Mac
	bundlebuilder.py script
Message-ID: <1387426414.21.0.655267134142.issue20022@psf.upfronthosting.co.za>


New submission from Eric Snow:

Mac/Tools/bundlebuilder.py uses deprecated imp APIs.  It should be refactored to use the current import-related APIs.

----------
messages: 206578
nosy: eric.snow
priority: low
severity: normal
status: open
title: "modernize" the Mac bundlebuilder.py script
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Dec 19 11:05:52 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 10:05:52 +0000
Subject: [New-bugs-announce] [issue20023] _csv.Dialect() does not check type
	for delimiter, escapechar and quotechar fields
Message-ID: <1387447552.86.0.0617469678586.issue20023@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Example:

$ ./python -c "import _csv; _csv.Dialect(escapechar=b'x')"
python: Python/ceval.c:4262: call_function: Assertion `(x != ((void *)0) && !PyErr_Occurred()) || (x == ((void *)0) && PyErr_Occurred())' failed.
Abandon (core dumped)

Attached patch should fix this issue and adds a unit test.

Note: I found this issue using Fusil the fuzzer.

----------
files: csv.patch
keywords: patch
messages: 206593
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: _csv.Dialect() does not check type for delimiter, escapechar and quotechar fields
versions: Python 3.4
Added file: http://bugs.python.org/file33203/csv.patch

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

From report at bugs.python.org  Thu Dec 19 12:13:31 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 11:13:31 +0000
Subject: [New-bugs-announce] [issue20024] Py_BuildValue() can call Python
	code with an exception	set
Message-ID: <1387451611.0.0.792673049242.issue20024@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In Python 3.4, an assertion now checks that no exception is set when arbitrary Python code is called. Python code may suppress the exception.

When Py_BuildValue() is used to build a tuple and an error when the creation of an item failed, the function may execute indirectly Python code with an exception set.

Attached patch works around the issue by storing the current exception in a variable and then restore it. It changes the behaviour if more than one exception is raised: at the end, its the first exception which is passed to the caller. I prefer to get the first exception instead of the following exceptions, because following exceptions may be caused by the first exception. See for example the parser bug below for an example of a second exception caused by the first exception.

--

Example with the parser module:

            PyObject *err = Py_BuildValue("os", elem,
                                          "Illegal node construct.");
            PyErr_SetObject(parser_error, err);

The "o" is not a valid format and so a SystemError is raised, but then the UTF-8 decoder tries to raise a second exception, an UnicodeDecodeError, because the decoders is called with an invalid bytes string (elem variable, instead of the "Illegal node construct." string, because "o" format didn't increment the argument pointer). The bug is obvious in the parser module, but the problem is more general than that.

Gdb traceback of the parser bug:

python: Objects/typeobject.c:741: type_call: Assertion `!PyErr_Occurred()' failed.

Program received signal SIGABRT, Aborted.
0x000000301c0359e9 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-19.fc19.x86_64
(gdb) where
#0  0x000000301c0359e9 in raise () from /lib64/libc.so.6
#1  0x000000301c0370f8 in abort () from /lib64/libc.so.6
#2  0x000000301c02e956 in __assert_fail_base () from /lib64/libc.so.6
#3  0x000000301c02ea02 in __assert_fail () from /lib64/libc.so.6
#4  0x00000000004dae18 in type_call (type=0x906780 <_PyExc_UnicodeDecodeError>, args=('utf-8', b'\xc8\x87\xe0\xf7\xff\x7f', 2, 3, 'invalid continuation byte'), kwds=0x0)
    at Objects/typeobject.c:741
#5  0x000000000045fb75 in PyObject_Call (func=<type at remote 0x906780>, arg=('utf-8', b'\xc8\x87\xe0\xf7\xff\x7f', 2, 3, 'invalid continuation byte'), kw=0x0)
    at Objects/abstract.c:2067
#6  0x000000000045fd0f in call_function_tail (callable=<type at remote 0x906780>, args=('utf-8', b'\xc8\x87\xe0\xf7\xff\x7f', 2, 3, 'invalid continuation byte'))
    at Objects/abstract.c:2104
#7  0x000000000045ff94 in _PyObject_CallFunction_SizeT (callable=<type at remote 0x906780>, format=0x669e19 "sy#nns") at Objects/abstract.c:2150
#8  0x000000000048643d in PyUnicodeDecodeError_Create (encoding=0x67e312 "utf-8", object=0x7ffff6ddcf40 "\310\207\340\367\377\177", length=6, start=2, end=3, 
    reason=0x67f1c1 "invalid continuation byte") at Objects/exceptions.c:1960
#9  0x000000000050fe7c in make_decode_exception (exceptionObject=0x7fffffff9090, encoding=0x67e312 "utf-8", input=0x7ffff6ddcf40 "\310\207\340\367\377\177", length=6, 
    startpos=2, endpos=3, reason=0x67f1c1 "invalid continuation byte") at Objects/unicodeobject.c:4009
#10 0x0000000000510015 in unicode_decode_call_errorhandler_writer (errors=0x0, errorHandler=0x7fffffff9098, encoding=0x67e312 "utf-8", 
    reason=0x67f1c1 "invalid continuation byte", input=0x7fffffff90b8, inend=0x7fffffff90b0, startinpos=0x7fffffff90a8, endinpos=0x7fffffff90a0, 
    exceptionObject=0x7fffffff9090, inptr=0x7fffffff9088, writer=0x7fffffff90c0) at Objects/unicodeobject.c:4157
#11 0x00000000005163a8 in PyUnicode_DecodeUTF8Stateful (s=0x7ffff6ddcf42 "\340\367\377\177", size=6, errors=0x0, consumed=0x0) at Objects/unicodeobject.c:4798
#12 0x0000000000506198 in PyUnicode_FromStringAndSize (u=0x7ffff6ddcf40 "\310\207\340\367\377\177", size=6) at Objects/unicodeobject.c:1840
#13 0x00000000005da9d2 in do_mkvalue (p_format=0x7fffffff92e0, p_va=0x7fffffff92c8, flags=0) at Python/modsupport.c:319
#14 0x00000000005d9e50 in do_mktuple (p_format=0x7fffffff92e0, p_va=0x7fffffff92c8, endchar=0, n=2, flags=0) at Python/modsupport.c:164
#15 0x00000000005db067 in va_build_value (format=0x7ffff750f34b "os", va=0x7fffffff9310, flags=0) at Python/modsupport.c:455
#16 0x00000000005dae8c in Py_BuildValue (format=0x7ffff750f34b "os") at Python/modsupport.c:410
#17 0x00007ffff750641c in build_node_children (tuple=(1467, -415088696226, 183475025091, 3, -85006798, 915338703290779849), root=0x7ffff7f7f6b8, line_num=0x7fffffff95cc)
    at /home/haypo/prog/python/default/Modules/parsermodule.c:788

----------
files: py_buildvalue_failed.patch
keywords: patch
messages: 206602
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Py_BuildValue() can call Python code with an exception set
versions: Python 3.4
Added file: http://bugs.python.org/file33208/py_buildvalue_failed.patch

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

From report at bugs.python.org  Thu Dec 19 12:28:30 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 11:28:30 +0000
Subject: [New-bugs-announce] [issue20025] ssl.RAND_bytes() and
	ssl.RAND_pseudo_bytes() don't check	if num is negative
Message-ID: <1387452510.42.0.848389239504.issue20025@psf.upfronthosting.co.za>


New submission from STINNER Victor:

ssl.RAND_bytes() and ssl.RAND_pseudo_bytes() should raise a ValueError, not a SystemError, if num is negative.

Attached patch fixes that.

----------
files: ssl_rand.patch
keywords: patch
messages: 206604
nosy: christian.heimes, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: ssl.RAND_bytes() and ssl.RAND_pseudo_bytes() don't check if num is negative
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33210/ssl_rand.patch

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

From report at bugs.python.org  Thu Dec 19 13:58:50 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 12:58:50 +0000
Subject: [New-bugs-announce] [issue20026] sqlite: handle correctly invalid
	isolation_level
Message-ID: <1387457930.38.0.260350520356.issue20026@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The C function pysqlite_connection_init() doesn't check if pysqlite_connection_set_isolation_level() failed or not.

Attached patch fixes that.

----------
files: sqlite.patch
keywords: patch
messages: 206610
nosy: haypo
priority: normal
severity: normal
status: open
title: sqlite: handle correctly invalid isolation_level
versions: Python 3.4
Added file: http://bugs.python.org/file33212/sqlite.patch

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

From report at bugs.python.org  Thu Dec 19 20:42:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 19:42:08 +0000
Subject: [New-bugs-announce] [issue20027] Fixed support for Indian locales
Message-ID: <1387482128.81.0.923367011564.issue20027@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The locales alias table contains invalid entries for devanagari modifiers (see issue5815):

    'ks_in at devanagari':                     'ks_IN at devanagari.UTF-8',
    'sd':                                   'sd_IN at devanagari.UTF-8',

Here is a patch which fixes aliases for these locales.

----------
components: Library (Lib)
files: locale_aliases.patch
keywords: patch
messages: 206636
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fixed support for Indian locales
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33218/locale_aliases.patch

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

From report at bugs.python.org  Fri Dec 20 05:38:14 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 20 Dec 2013 04:38:14 +0000
Subject: [New-bugs-announce] [issue20028] Confusing error message when
	giving invalid quotechar in	initializing csv dialect
Message-ID: <1387514294.66.0.0650917642902.issue20028@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Python 3.4.0b1 (default:13a505260f17, Dec 20 2013, 12:02:44) 
[GCC 4.7.2] on linux
>>> import _csv
>>> import csv
>>> _csv.Dialect(quotechar=b'+')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: "quotechar" must be string, not bytes

Hey, that's not true. Quotechar can be None.

>>> _csv.Dialect(quotechar=None)
<_csv.Dialect object at 0x7f64a8534790>

>>> _csv.Dialect(quotechar="cutecat")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: "quotechar" must be an 1-character string

That's not strictly true. Quotechar can be 0-character string in certain situation.

>>> _csv.Dialect(quotechar="", quoting=csv.QUOTE_NONE)
<_csv.Dialect object at 0x7f64a85345f0>

Python 2.7 suffers the same issue.

----------
components: Library (Lib)
messages: 206663
nosy: r.david.murray, serhiy.storchaka, vajrasky
priority: normal
severity: normal
status: open
title: Confusing error message when giving invalid quotechar in initializing csv dialect
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec 20 07:37:34 2013
From: report at bugs.python.org (akira)
Date: Fri, 20 Dec 2013 06:37:34 +0000
Subject: [New-bugs-announce] [issue20029] asyncio.SubprocessProtocol is
	missing
Message-ID: <1387521454.41.0.193901809521.issue20029@psf.upfronthosting.co.za>


New submission from akira:

`SubprocessProtocol` is documented  to be accessible as `asyncio.SubprocessProtocol` [1] but it is not included in `asyncio.protocols.__all__` [2] that leads to `AttributeError`:

    python3.4 -c "import asyncio; asyncio.SubprocessProtocol"
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    AttributeError: 'module' object has no attribute 'SubprocessProtocol'

The following works as expected:

    python3.4 -c "import asyncio; asyncio.protocols.SubprocessProtocol"

No error.

[1]: http://docs.python.org/3.4/library/asyncio-protocol.html#asyncio.SubprocessProtocol

[2]: http://hg.python.org/cpython/file/13a505260f17/Lib/asyncio/protocols.py#l3

----------
components: Library (Lib)
messages: 206665
nosy: akira
priority: normal
severity: normal
status: open
title: asyncio.SubprocessProtocol is missing
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Dec 20 10:02:25 2013
From: report at bugs.python.org (Arnaut Billings)
Date: Fri, 20 Dec 2013 09:02:25 +0000
Subject: [New-bugs-announce] [issue20030] unittest.TestLoader.discover
	return value incorrectly	documented.
Message-ID: <1387530145.58.0.951879545916.issue20030@psf.upfronthosting.co.za>


New submission from Arnaut Billings:

Here: http://docs.python.org/3/library/unittest.html#unittest.TestLoader.discover

it states that "Find and return all test modules ..."

This implies that in order to get a test suite, one has to iterate over the return value of unittest.TestLoader.discover and call loadTestsFromModule for each module.

But, the type of the result of unittest.TestLoader.discover returns: <class 'unittest.suite.TestSuite'>

----------
assignee: docs at python
components: Documentation
messages: 206670
nosy: arnaut-billings, docs at python
priority: normal
severity: normal
status: open
title: unittest.TestLoader.discover return value incorrectly documented.
versions: Python 3.3

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

From report at bugs.python.org  Fri Dec 20 10:08:19 2013
From: report at bugs.python.org (Arnaut Billings)
Date: Fri, 20 Dec 2013 09:08:19 +0000
Subject: [New-bugs-announce] [issue20031] unittest.TextTestRunner missing
	run() documentation.
Message-ID: <1387530499.44.0.66291527317.issue20031@psf.upfronthosting.co.za>


New submission from Arnaut Billings:

Here: http://docs.python.org/3/library/unittest.html

1) unittest.TextTestRunner is missing documentation for its public run method.

2) There are references to the TestRunner class sprinkled through out the above page, yet no link or documentation as to what that class actually is and does.

----------
assignee: docs at python
components: Documentation
messages: 206671
nosy: arnaut-billings, docs at python
priority: normal
severity: normal
status: open
title: unittest.TextTestRunner missing run() documentation.
versions: Python 3.3

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

From report at bugs.python.org  Fri Dec 20 10:55:03 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Dec 2013 09:55:03 +0000
Subject: [New-bugs-announce] [issue20032] asyncio.Future.set_exception()
	creates a reference cycle
Message-ID: <1387533303.95.0.0629214738994.issue20032@psf.upfronthosting.co.za>


New submission from STINNER Victor:

asyncio.Future.set_exception(exc) sets the exception attribute to exc, but exc.__traceback__ refers to frames and the current frame probably referes to the future instance.

Tell me if I'm wrong, but it looks like a reference cycle:
fut -- fut.exception --> exception --exception.__traceback__ -> traceback --traceback.tb_frame --> frame --frame.fb_locals --> fut

The frame class got a new clear() method in Python 3.4:
http://docs.python.org/dev/reference/datamodel.html#frame.clear

Maybe because of the PEP 442, the reference cycle is no more an issue. In fact, the following example calls fut destructor immediatly, at "fut = None" line.
---
import asyncio

fut = asyncio.Future()
try:
    raise ValueError()
except Exception as err:
    fut.set_exception(err)
fut = None
---

Attached patch breaks explicitly the reference cycle by scheduling a call to traceback.clear_frames() using call_soon(). The patch depends on asyncio_defer_format_tb.patch which is attached to the issue #19967.

----------
files: asyncio_break_ref_cycle.patch
keywords: patch
messages: 206672
nosy: gvanrossum, haypo, pitrou
priority: normal
severity: normal
status: open
title: asyncio.Future.set_exception() creates a reference cycle
versions: Python 3.4
Added file: http://bugs.python.org/file33228/asyncio_break_ref_cycle.patch

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

From report at bugs.python.org  Fri Dec 20 12:05:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Dec 2013 11:05:01 +0000
Subject: [New-bugs-announce] [issue20033] Fix makelocalealias.py for Python 3
Message-ID: <1387537501.53.0.333984460427.issue20033@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When Tools/i18n/makelocalealias.py was ported to Python 3 some things were not fixed.

1. locale.alias is opened as binary file in Python 2, but as text file (with locale encoding) in Python 3. This can cause fail when the script runs in UTF-8 locale because locale.alias contains non-ASCII locales ('bokm?l' and 'fran?ais', encoded in Latin1).

2. In Python 2 %r formatting always produce ASCII output. In Python 3 %a should be used to produce the same output.

Proposed patch fixes these minor bugs.

----------
components: Demos and Tools
files: locale_py3k.patch
keywords: patch
messages: 206675
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix makelocalealias.py for Python 3
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33230/locale_py3k.patch

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

From report at bugs.python.org  Fri Dec 20 12:36:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Dec 2013 11:36:45 +0000
Subject: [New-bugs-announce] [issue20034] Update locale alias table
Message-ID: <1387539405.64.0.71303309039.issue20034@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch updates locale alias table to most recent locale.alias file (from X.org 7.7 distribution).

----------
components: Library (Lib)
files: locale_aliases_77.patch
keywords: patch
messages: 206676
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Update locale alias table
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33232/locale_aliases_77.patch

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

From report at bugs.python.org  Fri Dec 20 17:30:50 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 20 Dec 2013 16:30:50 +0000
Subject: [New-bugs-announce] [issue20035] Suppress 'os.environ was modified'
	warning on Tcl/Tk	tests
Message-ID: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The attached patch refactors tkinter._fix's main logic into a function called 'fix_environ' which is called unconditionally on import, and adds a function 'unfix_environ' to undo the effects of fix_environ.  fix/unfix_environ are then used in all test files that import tkinter (test___all__, test_tcl, test_tk, test_ttk_guionly, test_ttk_textonly, test_idle) to ensure that the environment is properly set to allow Tcl to load and to suppress regrtest's warning that os.environ has been modified.

Since tkinter._fix is an implementation detail, I assume this change isn't against the 'no new features' policy of all currently open branches, but if this needs to wait until 3.5, that's ok with me.

----------
components: Tests, Tkinter
files: suppress_environ_warning.diff
keywords: patch
messages: 206692
nosy: zach.ware
priority: low
severity: normal
stage: patch review
status: open
title: Suppress 'os.environ was modified' warning on Tcl/Tk tests
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33233/suppress_environ_warning.diff

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

From report at bugs.python.org  Fri Dec 20 19:11:01 2013
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Fri, 20 Dec 2013 18:11:01 +0000
Subject: [New-bugs-announce] [issue20036] Running same doctests not possible
	on both py3 and py2
Message-ID: <1387563061.69.0.696193662364.issue20036@psf.upfronthosting.co.za>


New submission from Maries Ionel Cristian:

One of these doesn't work depending on how you write the exception name.


 python3 -mdoctest src/tete.rst  
 python -mdoctest src/tete.rst   

One cannot put an ellipsis in the exception name so you see how this is a problem.

----------
components: Demos and Tools, Library (Lib)
files: tete.py
messages: 206698
nosy: ionel.mc
priority: normal
severity: normal
status: open
title: Running same doctests not possible on both py3 and py2
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file33236/tete.py

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

From report at bugs.python.org  Fri Dec 20 23:19:07 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Dec 2013 22:19:07 +0000
Subject: [New-bugs-announce] [issue20037] Calling
	traceback.format_exception() during Pyhon	shutdown does crash Python
Message-ID: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached crash.py script does crash Python.

Python traceback on the crash:

(gdb) py-bt
Traceback (most recent call first):
  File "/home/haypo/prog/python/default/Lib/tokenize.py", line 431, in open
    text = TextIOWrapper(buffer, encoding, line_buffering=True)
  File "/home/haypo/prog/python/default/Lib/linecache.py", line 126, in updatecache
    with tokenize.open(fullname) as fp:
  File "/home/haypo/prog/python/default/Lib/linecache.py", line 41, in getlines
    return updatecache(filename, module_globals)
  File "/home/haypo/prog/python/default/Lib/linecache.py", line 15, in getline
    lines = getlines(filename, module_globals)
  File "/home/haypo/prog/python/default/Lib/traceback.py", line 65, in _extract_tb_or_stack_iter
    line = linecache.getline(filename, lineno, f.f_globals)
  File "/home/haypo/prog/python/default/Lib/traceback.py", line 18, in _format_list_iter
    for filename, lineno, name, line in extracted_list:
  File "/home/haypo/prog/python/default/Lib/traceback.py", line 153, in _format_exception_iter
    yield from _format_list_iter(_extract_tb_iter(tb, limit=limit))
  File "/home/haypo/prog/python/default/Lib/traceback.py", line 181, in format_exception
    return list(_format_exception_iter(etype, value, tb, limit, chain))
  File "/home/haypo/prog/python/default/Lib/asyncio/futures.py", line 178, in __del__
    exc.__traceback__)
  Garbage-collecting

End of the C traceback:

#46 0x00000000005aa742 in PyEval_CallObjectWithKeywords (func=<method at remote 0x7ffff19e79f8>, arg=(), kw=0x0) at Python/ceval.c:4107
#47 0x00000000004ee268 in slot_tp_finalize (
    self=<Future(_state='FINISHED', _exception=ValueError(), _loop=<_UnixSelectorEventLoop(_selector=<EpollSelector(_epoll=<select.epoll at remote 0x7ffff0dd3a18>, _fd_to_key={9: <SelectorKey at remote 0x7fffeefaa0e0>}, _map=<_SelectorMapping(_selector=<...>) at remote 0x7ffff18eae90>) at remote 0x7ffff18ea1f8>, _running=False, _signal_handlers={}, _default_executor=None, _ssock=<socket at remote 0x7fffef7e6e68>, _internal_fds=1, _scheduled=[], _ready=<collecti---Type <return> to continue, or q <return> to quit---
ons.deque at remote 0x7ffff18c56e0>, _csock=<socket at remote 0x7fffeefb5958>) at remote 0x7ffff18ea190>, _log_traceback=True, _callbacks=[]) at remote 0x7ffff18ea0c0>) at Objects/typeobject.c:5954
#48 0x000000000043b530 in finalize_garbage (collectable=0x7fffffffdc90, old=0x8eea20 <generations+64>) at Modules/gcmodule.c:793
#49 0x000000000043bce5 in collect (generation=2, n_collected=0x0, n_uncollectable=0x0, nofail=1) at Modules/gcmodule.c:1009
#50 0x000000000043cff4 in _PyGC_CollectNoFail () at Modules/gcmodule.c:1625
#51 0x00000000005cd873 in PyImport_Cleanup () at Python/import.c:383
#52 0x000000000041e898 in Py_Finalize () at Python/pythonrun.c:622
#53 0x000000000043a65c in Py_Main (argc=2, argv=0x970020) at Modules/main.c:800
#54 0x000000000041aad9 in main (argc=2, argv=0x7fffffffe0b8) at ./Modules/python.c:69

----------
files: crash.py
messages: 206707
nosy: haypo
priority: normal
severity: normal
status: open
title: Calling traceback.format_exception() during Pyhon shutdown does crash Python
versions: Python 3.4
Added file: http://bugs.python.org/file33239/crash.py

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

From report at bugs.python.org  Sat Dec 21 02:35:32 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 21 Dec 2013 01:35:32 +0000
Subject: [New-bugs-announce] [issue20038] Crash due to I/O in __del__
Message-ID: <1387589732.66.0.870061019982.issue20038@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

I was writing a new Tulip example (a cache client and server, not yet public) and I noticed that when I interrupted the client with ^C I got a traceback (expected) followed by a segfault (unexpected).  This is on OSX 10.8 but I don't think it is platform dependent.

A little experiment showed that this only happened with Python 3.4 and only with the latest Tulip, where Future has a __del__ method.  

According to gdb, the segfault happens on the first line of PyModule_GetState(), because the argument 'm' is NULL.

Putting a NULL check in this function averts the segfault but give the following disturbing extra traceback:

--- Logging error ---
Traceback (most recent call last):
Exception ignored in: <bound method Task.__del__ of Task(<testing>)<exception=KeyboardInterrupt()>>
Traceback (most recent call last):
  File "/Users/guido/tulip/asyncio/futures.py", line 177, in __del__
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 1278, in error
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 1384, in _log
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 1394, in handle
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 1456, in callHandlers
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 835, in handle
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 959, in emit
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 888, in handleError
  File "/Users/guido/cpython/Lib/traceback.py", line 169, in print_exception
  File "/Users/guido/cpython/Lib/traceback.py", line 153, in _format_exception_iter
  File "/Users/guido/cpython/Lib/traceback.py", line 18, in _format_list_iter
  File "/Users/guido/cpython/Lib/traceback.py", line 65, in _extract_tb_or_stack_iter
  File "/Users/guido/cpython/Lib/linecache.py", line 15, in getline
  File "/Users/guido/cpython/Lib/linecache.py", line 41, in getlines
  File "/Users/guido/cpython/Lib/linecache.py", line 126, in updatecache
  File "/Users/guido/cpython/Lib/tokenize.py", line 431, in open
TypeError: bad argument type for built-in operation

This suggests the problem is triggered by some I/O due to the exception logging in the __del__ method.

The gdb traceback (too big to post here) tells me that this PyModule_GetState() call is in the IO_STATE macro in textiowrapper_init().  The whole thing seems to be in a GC run called from Py_Finalize().  Check out the attached @bt.txt.

Any ideas?  (The TypeError is simply what PyModule_GetState() returns for a non-module argument -- I made it take the same exit path for NULL.)

----------
files: @bt.txt
messages: 206721
nosy: gvanrossum, haypo, pitrou
priority: normal
severity: normal
status: open
title: Crash due to I/O in __del__
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file33241/@bt.txt

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

From report at bugs.python.org  Sat Dec 21 11:40:25 2013
From: report at bugs.python.org (Arnaut Billings)
Date: Sat, 21 Dec 2013 10:40:25 +0000
Subject: [New-bugs-announce] [issue20039] Missing documentation for
	argparse.ArgumentTypeError
Message-ID: <1387622425.21.0.562750433804.issue20039@psf.upfronthosting.co.za>


New submission from Arnaut Billings:

There is no documentation for argparse.ArgumentTypeError:

http://docs.python.org/3/library/unittest.html

Though it does appear in an example and its usage is simple enough to decipher what it means, it would none the less look more professional if there was formal documentation for it. Not only on what it is, but when it should actually be used, etc...

----------
assignee: docs at python
components: Documentation
messages: 206723
nosy: arnaut-billings, docs at python
priority: normal
severity: normal
status: open
title: Missing documentation for argparse.ArgumentTypeError
versions: Python 3.3

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

From report at bugs.python.org  Sat Dec 21 14:55:53 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 Dec 2013 13:55:53 +0000
Subject: [New-bugs-announce] [issue20040] Tracing not disabled in generator
	when the system trace	function returns None.
Message-ID: <1387634153.88.0.744375474198.issue20040@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The sys.settrace documentation states:
  The trace function is invoked (with event set to 'call') whenever a new local scope is entered;
  it should return a reference to a local trace function to be used that scope, or None if the scope shouldn?t be traced.

But when tracing a generator, 'line' events may be traced even though tracing has been disabled by
returning None at the 'call' event. Run the attached tracer.py with 0 as argument and see that
tracing does not stop as it should when count is 1:
$ python tracer.py 0
call gen with count 0
line
line
return
call gen with count 1
returning None: the scope shouldn?t be traced
line
return

However, when tracer.py is run with 1 as argument, tracing is (correctly) disabled when count is 1
and 2. This problem is closely related to issue 11992.
The dispatch_call() method of Bdb in the bdb module is broken when the frame is a generator and the
previous command is next, until or return (and when this problem is fixed).

----------
components: Interpreter Core
files: tracer.py
messages: 206734
nosy: xdegaye
priority: normal
severity: normal
status: open
title: Tracing not disabled in generator when the system trace function returns None.
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33244/tracer.py

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

From report at bugs.python.org  Sat Dec 21 15:01:27 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 Dec 2013 14:01:27 +0000
Subject: [New-bugs-announce] [issue20041] TypeError when f_trace is None and
	tracing.
Message-ID: <1387634487.03.0.628100767515.issue20041@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Section 3.2 of 'The Python Language Reference' states:
  f_trace, if not None, is a function called at the start of each source code line

Run the attached tracer.py and see that although f_trace is None in both cases when 'cmd' is either
'delete' or 'set', the second case raises a TypeError exception:
$ python tracer.py
f_trace: None
delete start
delete done
f_trace: None
set start
Traceback (most recent call last):
  File "tracer.py", line 19, in <module>
    foo('set')
  File "tracer.py", line 15, in foo
    print(cmd, 'done')
  File "tracer.py", line 15, in foo
    print(cmd, 'done')
TypeError: 'NoneType' object is not callable

Also, the frame.f_lineno may be wrong in a traceback when f_trace is set to None because
PyFrame_GetLineNumber() does not handle this case.

The attached patch fixes this issue.
The patch also fixes issue 11992 and issue 20040.
The patch also fixes the dispatch_call() method of Bdb in the bdb module when the frame is a
generator and the previous command is next, until or return.
The patch also provides a backward compatible solution to the performance enhancement described in
issue 16672.

----------
components: Interpreter Core
files: tracer.py
messages: 206735
nosy: xdegaye
priority: normal
severity: normal
status: open
title: TypeError when f_trace is None and tracing.
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33245/tracer.py

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

From report at bugs.python.org  Sat Dec 21 15:10:03 2013
From: report at bugs.python.org (Konstantin Zemlyak)
Date: Sat, 21 Dec 2013 14:10:03 +0000
Subject: [New-bugs-announce] [issue20042] Python Launcher for Windows fails
	to invoke scripts with	non-latin names
Message-ID: <1387635003.7.0.211054481065.issue20042@psf.upfronthosting.co.za>


New submission from Konstantin Zemlyak:

Running `py.exe ??????.py` in cmd window fails:

E:\>set PYLAUNCH_DEBUG=1

E:\>py ??????.py
launcher build: 32bit
launcher executable: Console
File 'C:\Users\Zart\AppData\Local\py.ini' non-existent
Using global configuration file 'C:\Windows\py.ini'
Called with command line: .pymaybe_handle_shebang: read 211 bytes
maybe_handle_shebang: BOM not found, using UTF-8
parse_shebang: found command: python3
locating Pythons in 64bit registry
locate_pythons_for_key: unable to open PythonCore key in HKCU
locate_pythons_for_key: "C:\Program Files\Python27\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python2\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python2\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python32\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python33\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locating Pythons in native registry
locate_pythons_for_key: unable to open PythonCore key in HKCU
locate_pythons_for_key: "C:\Program Files (x86)\Python27\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python2\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python2\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python32\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python33\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
found configured value 'python3=3.2-32' in environment
search for Python version '3.2-32' found '"C:\Program Files (x86)\Python32\python.exe"'
run_child: about to run '"C:\Program Files (x86)\Python32\python.exe" .py'
C:\Program Files (x86)\Python32\python.exe: can't open file '.py': [Errno 2] No such file or directory
child process exit code: 2


Note "Called with command line: .py" in output shows that filename was mangled very early on. Invoking `??????.py` (which is associated with py.exe) directly works fine though.

The problem lies in Windows handling of command-line arguments and fix to this is simple but non-obvious. Patch attached.

----------
components: Unicode, Windows
files: pylauncher-fix-launcing-unicode-filenames.patch
keywords: patch
messages: 206741
nosy: ezio.melotti, haypo, zart
priority: normal
severity: normal
status: open
title: Python Launcher for Windows fails to invoke scripts with non-latin names
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file33247/pylauncher-fix-launcing-unicode-filenames.patch

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

From report at bugs.python.org  Sat Dec 21 15:28:45 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 21 Dec 2013 14:28:45 +0000
Subject: [New-bugs-announce] [issue20043] test_multiprocessing_main_handling
	fails	--without-threads
Message-ID: <1387636125.31.0.836708895935.issue20043@psf.upfronthosting.co.za>


New submission from Stefan Krah:

http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/5874/steps/test/logs/stdio


test test_multiprocessing_main_handling crashed -- Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/regrtest.py", line 1271, in runtest_inner
    the_module = importlib.import_module(abstest)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/importlib/__init__.py", line 129, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 2172, in _gcd_import
  File "<frozen importlib._bootstrap>", line 2155, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2144, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1209, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1133, in _exec
  File "<frozen importlib._bootstrap>", line 1436, in exec_module
  File "<frozen importlib._bootstrap>", line 321, in _call_with_frames_removed
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/test_multiprocessing_main_handling.py", line 19, in <module>
    import multiprocessing
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/multiprocessing/__init__.py", line 16, in <module>
    from . import context
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/multiprocessing/context.py", line 3, in <module>
    import threading
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/threading.py", line 4, in <module>
    import _thread
ImportError: No module named '_thread'

----------
components: 2to3 (2.x to 3.x conversion tool)
keywords: buildbot
messages: 206747
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_multiprocessing_main_handling fails --without-threads
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Dec 21 17:15:20 2013
From: report at bugs.python.org (Francis Moreau)
Date: Sat, 21 Dec 2013 16:15:20 +0000
Subject: [New-bugs-announce] [issue20044] gettext.install() ignores previous
	call to	locale.setlocale()
Message-ID: <1387642520.63.0.386289472626.issue20044@psf.upfronthosting.co.za>


New submission from Francis Moreau:

It seems that gettext.install() uses environment variables such as LANGUAGE, to find out which language it should use to find the translation file.

This means that any local settings done by setlocale() previoulsy are ignored.

I don't think it's the case with the C implementation.

----------
components: Library (Lib)
messages: 206762
nosy: fmoreau
priority: normal
severity: normal
status: open
title: gettext.install() ignores previous call to locale.setlocale()
versions: Python 2.7

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

From report at bugs.python.org  Sat Dec 21 17:42:30 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 21 Dec 2013 16:42:30 +0000
Subject: [New-bugs-announce] [issue20045] setup.py register
	--list-classifiers is broken
Message-ID: <1387644150.38.0.435206294981.issue20045@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

$ ./python -V
Python 3.4.0b1
$ ./python setup.py register --list-classifiers
running register
running check
Traceback (most recent call last):
  File "setup.py", line 2219, in <module>
    main()
  File "setup.py", line 2214, in main
    "Tools/scripts/2to3", "Tools/scripts/pyvenv"]
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/command/register.py", line 54, in run
    self.classifiers()
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/command/register.py", line 90, in classifiers
    log.info(response.read())
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/log.py", line 44, in info
    self._log(INFO, msg, args)
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/log.py", line 33, in _log
    msg = msg.encode(encoding, "backslashreplace").decode(encoding)
AttributeError: 'bytes' object has no attribute 'encode'

----------
components: Distutils
messages: 206764
nosy: eric.araujo, giampaolo.rodola, tarek
priority: normal
severity: normal
status: open
title: setup.py register --list-classifiers is broken
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Dec 21 20:20:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 19:20:57 +0000
Subject: [New-bugs-announce] [issue20046] Optimize locale aliases table
Message-ID: <1387653657.74.0.379588693101.issue20046@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch removes over 400 entities from locale alias tables. They are redundant because they can be calculated on fly.

Also it enables utf8 aliases. Now this adds not hundreds of redundant aliases, but only 8 new locales:

+    'be_bg.utf8':                           'bg_BG.UTF-8',
+    'c.utf8':                               'en_US.UTF-8',
+    'en_dl.utf8':                           'en_DL.UTF-8',
+    'en_zw.utf8':                           'en_ZS.UTF-8',
+    'pa_pk.utf8':                           'pa_PK.UTF-8',
+    'sr_yu.utf8':                           'sr_RS.UTF-8',
+    'te_in.utf8':                           'te_IN.UTF-8',
+    'zh_sg.utf8':                           'zh_SG.UTF-8',

----------
components: Library (Lib)
files: locale_optimize_aliases.patch
keywords: patch
messages: 206769
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Optimize locale aliases table
type: enhancement
Added file: http://bugs.python.org/file33249/locale_optimize_aliases.patch

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

From report at bugs.python.org  Sat Dec 21 20:52:41 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Dec 2013 19:52:41 +0000
Subject: [New-bugs-announce] [issue20047] bytearray partition bug
Message-ID: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

If partition is called with a single byte it works correctly but if called with the equivalent integer it returns the same bytearray with two empty arrays as follows.

py> ba = bytearray(range(8))
py> ba
bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07')
py> 3 in ba
True
py> ba.find(3) == ba.index(3) == ba.find(b'\x03')
True
py> ba.partition(b'\x03')
(bytearray(b'\x00\x01\x02'), bytearray(b'\x03'), bytearray(b'\x04\x05\x06
\x07'))
py> ba.partition(3)
(bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07'), bytearray(b''), bytearray
(b''))

More background on the thread starting here https://mail.python.org/pipermail/python-list/2013-December/663111.html which refers to Issue 12170.

----------
components: Interpreter Core
messages: 206773
nosy: BreamoreBoy
priority: normal
severity: normal
status: open
title: bytearray partition bug
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Dec 21 21:58:59 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 21 Dec 2013 20:58:59 +0000
Subject: [New-bugs-announce] [issue20048] zipfile's readline() drops data in
	universal newline mode
Message-ID: <1387659539.36.0.629484655922.issue20048@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

This problem happens when I unpack a file from a 200+ MB zip archive as follows:

with zipfile.ZipFile(archive) as z:
    data = b''
    with z.open(filename, 'rU') as f:
        for line in f:
      	    data += line


I cannot reduce it to a test case suitable for posting here, but the culprit is the following code in zipfile.py:

    def peek(self, n=1):
        """Returns buffered bytes without advancing the position."""
        if n > len(self._readbuffer) - self._offset:
            chunk = self.read(n)
            self._offset -= len(chunk)

See http://hg.python.org/cpython/file/81f8375e60ce/Lib/zipfile.py#l605

The problem occurs when peek() is called on the boundary of the uncompress buffer and read() goes through more than one readbuffer.  The result is that self._offset is smaller than len(chunk) leading to a non-sensical negative self._offset upon return from peek().

This problem does not seem to appear in 3.x since 028e8e0b03e8.

----------
messages: 206779
nosy: belopolsky
priority: normal
severity: normal
status: open
title: zipfile's readline() drops data in universal newline mode
versions: Python 2.7

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

From report at bugs.python.org  Sat Dec 21 22:38:37 2013
From: report at bugs.python.org (Alexander Pyhalov)
Date: Sat, 21 Dec 2013 21:38:37 +0000
Subject: [New-bugs-announce] [issue20049] string.lowercase and
	string.uppercase can contain garbage
Message-ID: <1387661917.11.0.929433274966.issue20049@psf.upfronthosting.co.za>


New submission from Alexander Pyhalov:

When Python 2.6 (or 2.7) compiled with _XOPEN_SOURCE=600 on illumos  string.lowercase and string.uppercase contain garbage when UTF-8 locale is used. 
(OpenIndiana bug report - https://www.illumos.org/issues/4411 ).
The reason is that with UTF-8 locale islower()/isupper() and similar functions are not expected to work with non-ascii symbols. 
So, code like 

    n = 0;
    for (c = 0; c < 256; c++) {
        if (islower(c))
            buf[n++] = c;
    }

is expected to fail, because it calls islower on illegal UTF-8 symbols (with codes 128-255). It should be converted to something like

    n = 0;
    for (c = 0; c < 256; c++) {
        if (isascii(c) && islower(c))
            buf[n++] = c;
    }

or to 

    n = 0;
    for (c = 0; c < 128; c++) {
        if (islower(c))
            buf[n++] = c;
    }

Before doing this you should check if locale is UTF-8. However, almost all non-C locales on illumos are UTF-8. 


Example of incorrect behavior: 

Python 2.6.9 (unknown, Nov 12 2013, 13:54:48) 
[GCC 4.7.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import string
>>> string.lowercase
'abcdefghijklmnopqrstuvwxyz\\xaa\\xb5\\xba\\xdf\\xe0\\xe1\\xe2\\xe3\\xe4\\xe5\\xe6\\xe7\\xe8\\xe9\\xea\\xeb\\xec\\xed\\xee\\xef\\xf0\\xf1\\xf2\\xf3\\xf4\\xf5\\xf6\\xf8\\xf9\\xfa\\xfb\\xfc\\xfd\\xfe\\xff'
>>> string.uppercase
'ABCDEFGHIJKLMNOPQRSTUVWXYZ\\xc0\\xc1\\xc2\\xc3\\xc4\\xc5\\xc6\\xc7\\xc8\\xc9\\xca\\xcb\\xcc\\xcd\\xce\\xcf\\xd0\\xd1\\xd2\\xd3\\xd4\\xd5\\xd6\\xd8\\xd9\\xda\\xdb\\xdc\\xdd\\xde'
>>>

----------
components: Unicode
messages: 206786
nosy: Alexander.Pyhalov, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: string.lowercase and string.uppercase can contain garbage
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Dec 22 01:52:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 00:52:05 +0000
Subject: [New-bugs-announce] [issue20050] distutils should check PyPI certs
	when connecting to it
Message-ID: <1387673525.81.0.630232623355.issue20050@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Spun off from #12226: distutils now uses HTTPS by default to connect PyPI, but certs aren't checked at all.

----------
components: Library (Lib)
messages: 206800
nosy: Giovanni.Bajo, alexis, benjamin.peterson, christian.heimes, dstufft, eric.araujo, georg.brandl, pitrou
priority: high
severity: normal
status: open
title: distutils should check PyPI certs when connecting to it
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/issue20050>
_______________________________________

From report at bugs.python.org  Sun Dec 22 22:16:32 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 22 Dec 2013 21:16:32 +0000
Subject: [New-bugs-announce] [issue20051] PA-RISC buildbot: compiler cannot
	create executables
Message-ID: <1387746992.49.0.56287185551.issue20051@psf.upfronthosting.co.za>


New submission from Stefan Krah:

I think the demo mode for aCC has expired on h2 | HP-UX 11iv2 | PA-RISC:
  

bash-4.0$ cc +DD32 -o xxx xxx.c 
Error: Demo mode has expired.
Contact your Hewlett-Packard sales office to order HP C Compiler

----------
keywords: buildbot
messages: 206831
nosy: skrah, trent
priority: normal
severity: normal
status: open
title: PA-RISC buildbot: compiler cannot create executables
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec 23 00:29:59 2013
From: report at bugs.python.org (VeloxAmbitum)
Date: Sun, 22 Dec 2013 23:29:59 +0000
Subject: [New-bugs-announce] [issue20052] input() crashes in 2.7.6
Message-ID: <1387754999.65.0.50719623287.issue20052@psf.upfronthosting.co.za>


New submission from VeloxAmbitum:

Using input(string) to read a number crashes whenever the number is "0*8*" or "0*9*" where * can be any number (i.e., "09", "08", and "0102393" all cause the code to crash).

Crash occurs on Windows 7 x64 running 32 bit Python version 2.7.6 as a Syntax Error:

----------------------------------------------------
Enter a number
>01239123
Traceback (most recent call last):
  File "python2.7.6 bug", line 6, in <module>
    bug()
  File "python2.7.6 bug", line 2, in bug
    number = input("Enter a number\n>");
  File "<string>", line 1
    01239123
           ^
SyntaxError: invalid token

----------------------------------------------------

Can be reproduced from:


def bug():
	number = input("Enter a number\n>");

while True:
	print("0*8* or 0*9* causes bug to appear (* is wildcard):\n");
	bug()

----------
components: Windows
files: python2.7.6 bug.py
messages: 206835
nosy: VeloxAmbitum
priority: normal
severity: normal
status: open
title: input() crashes in 2.7.6
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file33255/python2.7.6 bug.py

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

From report at bugs.python.org  Mon Dec 23 07:41:08 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Dec 2013 06:41:08 +0000
Subject: [New-bugs-announce] [issue20053] venv and ensurepip are affected by
	default pip config	file
Message-ID: <1387780868.34.0.410698465934.issue20053@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

In resolving issue 19734, I realised venv and ensurepip are actually in a similar situation with respect to the default pip configuration file as they were with respect to environment variables: those settings are unlikely to be appropriate for ensurepip, but pip will still pay attention to them during the bootstrapping process.

However, it's a bit trickier to test, since PIP_CONFIG_FILE will be ignored (due to the resolution of issue 19734).

The approach I will run with (if nobody has any better suggestions):

- create a temporary directory
- set os.environ["HOME"] to point to that directory
- create a platform appropriate file (pip\pip.ini on Windows, .pip/pip.conf elsewhere) containing the settings:

    [global]
    no-install=1

That should cause the test_venv tests to fail, just as setting PIP_NO_INSTALL in the environment caused them to fail as a test for the issue 19734 resolution.

In terms of forcing pip to *ignore* the global config file, the best option I have found is setting PIP_CONFIG_FILE=/dev/null (I believe the Windows equivalent would be PIP_CONFIG_FILE=NUL). The fact the file exists means pip uses it without falling back to the default file location, while the fact it is always read as empty means it has no effect on pip's operation.

I'm open to better suggestions on how to do that, but it seems like the best available option without an "isolated mode" equivalent in pip.

----------
assignee: ncoghlan
messages: 206843
nosy: dstufft, ncoghlan, pmoore
priority: normal
severity: normal
status: open
title: venv and ensurepip are affected by default pip config file
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec 23 15:23:54 2013
From: report at bugs.python.org (Sophie Chancheong)
Date: Mon, 23 Dec 2013 14:23:54 +0000
Subject: [New-bugs-announce] [issue20054] IDLE won't work (Mac)
Message-ID: <1387808634.38.0.491200238888.issue20054@psf.upfronthosting.co.za>


New submission from Sophie Chancheong:

I'm having trouble with running Idle on my macbook pro os x 10.9.1 . two days ago it was running with absolutely no problem and now it won't start up. I've tried uninstalling and reinstalling, and I have updated the Tkinter and Tcl/Tk etc. It appears in the dock for a second then disappears. Any help would be appreciated.

Thanks,
Sophie

----------
components: IDLE
messages: 206859
nosy: Sophie.Chancheong
priority: normal
severity: normal
status: open
title: IDLE won't work (Mac)
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Dec 23 15:48:44 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 23 Dec 2013 14:48:44 +0000
Subject: [New-bugs-announce] [issue20055] On Windows NT 6 with administrator
	account, there are two failing tests on test_shutil.py
Message-ID: <1387810124.3.0.485695266122.issue20055@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Use administrator account and run Lib\test\test_shutil.py! You will get two failing tests.

======================================================================
FAIL: test_move_dangling_symlink (__main__.TestMove)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_shutil.py", line 60, in wrap
    return func(*args, **kwargs)
  File "Lib\test\test_shutil.py", line 1557, in test_move_dangling_symlink
    self.assertEqual(os.path.realpath(src), os.path.realpath(dst_link))
AssertionError: 'C:\\Users\\compaq\\AppData\\Local\\Temp\\tmp9kkaex06\\baz' != '
C:\\Users\\compaq\\AppData\\Local\\Temp\\tmpuuretujv\\quux'
- C:\Users\compaq\AppData\Local\Temp\tmp9kkaex06\baz
?                                       ^^^^  ------
+ C:\Users\compaq\AppData\Local\Temp\tmpuuretujv\quux
?                                       ^^^ ++++++++


======================================================================
FAIL: test_copymode_follow_symlinks (__main__.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_shutil.py", line 298, in test_copymode_follow_symlinks
    self.assertEqual(os.stat(src).st_mode, os.stat(dst).st_mode)
AssertionError: 33206 != 33060

----------------------------------------------------------------------
Ran 85 tests in 0.872s

FAILED (failures=2, skipped=12)

Attached the patch which contains the explanation as well to fix the tests.

----------
components: Library (Lib)
files: fix_test_shutil_with_admin_on_windows.patch
keywords: patch
messages: 206860
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: On Windows NT 6 with administrator account, there are two failing tests on test_shutil.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33257/fix_test_shutil_with_admin_on_windows.patch

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

From report at bugs.python.org  Mon Dec 23 15:52:44 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 23 Dec 2013 14:52:44 +0000
Subject: [New-bugs-announce] [issue20056] Got deprecation warning when
	running test_shutil.py on	Windows NT 6
Message-ID: <1387810364.09.0.723584968408.issue20056@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

You don't have to be an administrator get this deprecation warning. I am not sure whether showing the deprecation warning is intended behaviour or not.

C:\Users\vajrasky\Code\cpython>PCbuild\python.exe Lib\test\test_shutil.py
..s..........s..s....ss...s..ss.ss..ssssssss....s.ss.ss..........ss.C:\Users\vaj
rasky\Code\cpython\lib\ntpath.py:309: DeprecationWarning: The Windows bytes API
has been deprecated, use Unicode filenames instead
  st = os.lstat(path)
C:\Users\vajrasky\Code\cpython\lib\shutil.py:357: DeprecationWarning: The Window
s bytes API has been deprecated, use Unicode filenames instead
  names = os.listdir(path)
C:\Users\vajrasky\Code\cpython\lib\shutil.py:363: DeprecationWarning: The Window
s bytes API has been deprecated, use Unicode filenames instead
  mode = os.lstat(fullname).st_mode
C:\Users\vajrasky\Code\cpython\lib\shutil.py:370: DeprecationWarning: The Window
s bytes API has been deprecated, use Unicode filenames instead
  os.unlink(fullname)
C:\Users\vajrasky\Code\cpython\lib\shutil.py:374: DeprecationWarning: The Window
s bytes API has been deprecated, use Unicode filenames instead
  os.rmdir(path)
.sss.............
----------------------------------------------------------------------
Ran 85 tests in 0.741s

OK (skipped=28)

----------
components: Tests
messages: 206861
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Got deprecation warning when running test_shutil.py on Windows NT 6
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec 23 22:05:19 2013
From: report at bugs.python.org (Brett Tiplitz)
Date: Mon, 23 Dec 2013 21:05:19 +0000
Subject: [New-bugs-announce] [issue20057] wrong behavior with fork and mmap
Message-ID: <1387832719.01.0.39752700346.issue20057@psf.upfronthosting.co.za>


New submission from Brett Tiplitz:

When running the example mmap library (with a slight modification, plus I did not handle all the changes for the 3.3 string handling as the example posted does not work with 3.x) 

When looking at the subprocess, the spawned process will have all the mmap'd file descriptors open.  The spawned process has the responsibility of closing any FD's that are in use.  However, since the shared memory segment get's closed and the program has no knowledge of private FD's, the mmap's private FD becomes a leak in the FD table.  It seems python should set the close-on-exec attribute on the dup'd FD that it maintains.  Examples of fixing this issue are found on http://stackoverflow.com/questions/1643304/how-to-set-close-on-exec-by-default
import mmap,os

# write a simple example file
with open("hello.txt", "wb") as f:
    f.write(bytes("Hello Python!\n", 'UTF-8'))

with open("hello.txt", "r+b") as f:
    # memory-map the file, size 0 means whole file
    os.system("/bin/ls -l /proc/"+str(os.getpid())+"/fd")

    mm = mmap.mmap(f.fileno(), 0)
    os.system("/bin/ls -l /proc/"+str(os.getpid())+"/fd")
    os.system("/bin/ls -l /proc/self/fd")

    # read content via standard file methods
    t1 = mm.readline() # used to print out
  # prints "Hello Python!"
    # read content via slice notation
    t2=mm[:5]
#    print mm[:5]  # prints "Hello"
    # update content using slice notation;
    # note that new content must have same size
    mm[6:] = bytes(" world!\n", 'UTF-8')
    # ... and read again using standard file methods
    mm.seek(0)
    t3=mm.readline()
 #   print mm.readline()  # prints "Hello  world!"
    # close the map
    mm.close()
~

----------
components: Library (Lib)
messages: 206871
nosy: btiplitz
priority: normal
severity: normal
status: open
title: wrong behavior with fork and mmap
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Dec 23 23:28:33 2013
From: report at bugs.python.org (Steven Barker)
Date: Mon, 23 Dec 2013 22:28:33 +0000
Subject: [New-bugs-announce] [issue20058] IDLE's shell returns a
	multiple-line string to input()	or readline() when multiple
	lines of text are pasted by the user
Message-ID: <1387837713.58.0.522558553698.issue20058@psf.upfronthosting.co.za>


New submission from Steven Barker:

Pasting multiple lines of input and then pressing Enter when IDLE is waiting to read a single line (such as when input() or sys.stdin.readline() have been called) will result is a multi-line string being given as the input, rather than a single line.

This may be most easily understood by looking at an example. Run this code in IDLE (either by typing it in the shell, or from a file with F5):

    s = "X"
    while s:
        s = input()
        print(repr(s))

First, try typing in several lines. Each will be printed separately, with no newlines inside the strings (since input() strips a trailing newline).

    foo
    'foo'
    bar
    'bar'
    baz
    'baz'

Next, copy several lines of text from somewhere. It doesn't matter what the lines' contents are. Here I grabbed a list of Python version numbers, as I was on the download page after grabbing 3.4.0b1 for testing this bug:

    3.1.5
    3.0.1
    2.7.6
    2.6.9
    2.5.6
    2.4.6
    2.3.7
    2.2.3 <all the preceding lines were pasted in one go, followed by enter pressed here>
    '3.1.5\n3.0.1\n2.7.6\n2.6.9\n2.5.6\n2.4.6\n2.3.7\n2.2.3'

This behavior is different than what the Python interpreter does in a regular console shell. When running in cmd.exe on Windows, Python treats a multi-line paste just like typed input:

    3.1.5
    '3.1.5'
    3.0.1
    '3.0.1'
    2.7.6
    '2.7.6'
    2.6.9
    '2.6.9'
    2.5.6
    '2.5.6'
    2.4.6
    '2.4.6'
    2.3.7
    '2.3.7'
    2.2.3 <enter typed here>
    '2.2.3'

I expect the same behavior will be common in other kinds of terminals on other platforms.

This issue makes testing certain kinds of programs very frustrating. If your program needs to read certain text from STDIN, and you want to paste that text in quickly, you need to update your code with special logic just for use in IDLE's console. As an example of the kind of pain you may experience, try copying and pasting a block of text with a blank line into the input loop above. On a regular console session it will exit the loop after the blank line. In IDLE, it will keep running.

I've traced the source of this issue through IDLE's sys.stdin file object and an RPC call, and found it probably is located in the idlelib.PyShell.PyShell.readline method (or the surrounding code). This grabs a string from the Text object in the shell window and returns it to the Python code running in the subprocess.

Probably it should have some extra steps added to check if it got multiple lines. If so, it should split the string on newlines and return just one line of text for each readline call. I'm not sure exactly what should be done with the rest of the lines, but perhaps they could be queued up (or somehow "put back" by moving the markers in the Text object) so later lines would be grabbed by later input requests.

Or alternatively, maybe the event where the multi-line paste arrives should be handled differently, as several single-line input events, rather than a single multiple-line one.

----------
components: IDLE
messages: 206879
nosy: Steven.Barker
priority: normal
severity: normal
status: open
title: IDLE's shell returns a multiple-line string to input() or readline() when multiple lines of text are pasted by the user
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec 24 00:51:50 2013
From: report at bugs.python.org (Chad Birch)
Date: Mon, 23 Dec 2013 23:51:50 +0000
Subject: [New-bugs-announce] [issue20059] Inconsistent urlparse/urllib.parse
	handling of invalid	port values?
Message-ID: <1387842710.57.0.78188368243.issue20059@psf.upfronthosting.co.za>


New submission from Chad Birch:

I'm not sure if this is something that needs adjustment, but it seems somewhat inconsistent to me.

After using urlparse() on various urls with invalid port values, trying to access .port on the result will raise a ValueError. This case includes urls such as:

"http://www.example.com:asdf"

"http://www.example.com:1.5"

"http://www.example.com:"

However, as of May 24 2012 (http://hg.python.org/cpython/diff/d769e64aed79/Lib/urllib/parse.py), if the invalid port value is an integer, accessing .port will result in None. So this includes urls such as:

"http://www.example.com:66000"

"http://www.example.com:-1"

Should these two cases be made consistent, so that either .port is always None or always results in a ValueError if the port section of the url is invalid? I'd be happy to write a patch for it if it's wanted, but I thought I'd check first (and see which of the two options would be correct, if so).

----------
components: Library (Lib)
messages: 206881
nosy: chad.birch
priority: normal
severity: normal
status: open
title: Inconsistent urlparse/urllib.parse handling of invalid port values?
type: behavior

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

From report at bugs.python.org  Tue Dec 24 15:29:12 2013
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 24 Dec 2013 14:29:12 +0000
Subject: [New-bugs-announce] [issue20060] float() and int() TypeError
	messages differ
Message-ID: <1387895352.05.0.912673240315.issue20060@psf.upfronthosting.co.za>


New submission from Mitchell Model:

[Sorry if ctypes is wrong component -- don't know which to use.]
Given an invalid type, int()'s TypeError message includes the name of the invalid type, but float()'s doesn't. (Nor does complex()'s.) All three should give analogous error messages. int()'s version, with the name of the offending type, seems better.

----------
components: ctypes
messages: 206892
nosy: MLModel
priority: normal
severity: normal
status: open
title: float() and int() TypeError messages differ
versions: Python 3.3

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

From report at bugs.python.org  Tue Dec 24 16:09:20 2013
From: report at bugs.python.org (Chiel ten Brinke)
Date: Tue, 24 Dec 2013 15:09:20 +0000
Subject: [New-bugs-announce] [issue20061] pdb through separate terminal not
	working properly
Message-ID: <1387897760.7.0.840181972955.issue20061@psf.upfronthosting.co.za>


New submission from Chiel ten Brinke:

There are several reasons why one would need to debug in a terminal window other than the debuggee terminal window, for instance when we have a curses application.
The pdb doesn't support a tty command like gdb, which would allow this.
Instead, it is possible to manually create a Pdb object with the stdin/stdout set to the terminal you want to use (e.g. /dev/pts/6). However, this is quite cumbersome, as command history, autocompletion etc don't work this way. Also, it seems that post mortem debugging cannot easily be done this way, like when running `python3.3 -m pdb myscript.py`. 

There should be an easy way to debug properly through a second terminal window.

----------
messages: 206895
nosy: Chiel92
priority: normal
severity: normal
status: open
title: pdb through separate terminal not working properly
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Dec 24 16:23:36 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 15:23:36 +0000
Subject: [New-bugs-announce] [issue20062] Add section on vim to devguide
Message-ID: <1387898616.8.0.449305088689.issue20062@psf.upfronthosting.co.za>


New submission from R. David Murray:

This is a followup to issue 9893.  There should be a section on vim in the devguide just like there is currently a section on emacs.

----------
components: Devguide
messages: 206897
nosy: ezio.melotti, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Add section on vim to devguide
type: behavior

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

From report at bugs.python.org  Tue Dec 24 16:33:15 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 24 Dec 2013 15:33:15 +0000
Subject: [New-bugs-announce] [issue20063] Docs imply that set does not
	support .pop() method
Message-ID: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>


New submission from Madison May:

Note item 6 of http://docs.python.org/2.7/library/stdtypes.html#mutable-sequence-types is a bit misleading.  

It states: "The pop() method is only supported by the list and array types. The optional argument i defaults to -1, so that by default the last item is removed and returned."  

However, pop() is also a method of sets, which are neither lists or arrays.

----------
assignee: docs at python
components: Documentation
messages: 206899
nosy: docs at python, madison.may
priority: normal
severity: normal
status: open
title: Docs imply that set does not support .pop() method
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec 24 20:39:20 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 19:39:20 +0000
Subject: [New-bugs-announce] [issue20064] PyObject_Malloc is not documented
Message-ID: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>


New submission from R. David Murray:

At least, a doc ref to :c:func:`PyObject_Malloc` does not turn into a link, and I can't find anything in the docs that it looks like it should link to.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 206910
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: PyObject_Malloc is not documented
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Dec 25 09:46:36 2013
From: report at bugs.python.org (Igor Franchuk)
Date: Wed, 25 Dec 2013 08:46:36 +0000
Subject: [New-bugs-announce] [issue20065]
	Python-3.3.3/Modules/socketmodule.c:1660:14: error:	'CAN_RAW'
	undeclared (first use in this function)
Message-ID: <1387961196.27.0.560814998744.issue20065@psf.upfronthosting.co.za>


New submission from Igor Franchuk:

Missing CAN_RAW check in Python 3.3.3

Python 3.3.3 assumes that if AF_CAN is defined then CAN_RAW is defined as well.

It won't assemble with old kernels. 

Either an additional check for CAN_RAW should be applied in the configuration script or Python 3.3.3 dependence on the newest kernels should be made mandatory
(configure check). It could be back to normal if a CAN_RAW check is applied and the problematic part of code is excluded. 

Python 3.3.3 can work with sockets without full CAN support but it won't.

Environment:

System uname: Linux-2.6.33-gentoo-i686-Intel-R-_Pentium-R-_D_CPU_3.00GHz-with-gentoo-1.12.1
Timestamp of tree: Sun, 22 Dec 2013 09:30:01 +0000
ld GNU ld (GNU Binutils) 2.21
app-shells/bash:          4.2_p37
dev-lang/python:          2.4.3-r1::<unknown repository>, 2.6.8, 2.7.3-r3, 3.1.1-r1, 3.2.3-r2
dev-util/pkgconfig:       0.27.1
sys-apps/baselayout:      1.12.1::<unknown repository>
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.13::<unknown repository>, 2.69
sys-devel/automake:       1.4_p6::<unknown repository>, 1.5::<unknown repository>, 1.6.3::<unknown repository>, 1.7.9-r1::<unknown repository>, 1.8.5-r3::<unknown repository>, 1.9.6-r2::<unknown repository>, 1.10::<unknown repository>, 1.11.1, 1.13.1
sys-devel/binutils:       2.21
sys-devel/gcc:            4.1.1::<unknown repository>, 4.2.4-r1, 4.4.2
sys-devel/gcc-config:     1.4.1
sys-devel/libtool:        1.5.23b::<unknown repository>, 2.4-r1
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 2.6.21::<unknown repository> (virtual/os-headers)
sys-libs/glibc:           2.10.1-r1
Repositories: gentoo
ACCEPT_KEYWORDS="x86"
ACCEPT_LICENSE="* - at EULA"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -O2 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /var/bind"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=pentium4 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -march=i686 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS="-O2 -march=i686 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="acl alsa arts avi berkdb bitmap-fonts bzip2 cairo cdr cli cracklib crypt cups cxx dbus dlloader dri dvd dvdr eds emboss encode esd fam fortran gdbm gif gnutls gpm gstreamer gtk hal iconv isdnlog jpeg kde ldap libg++ mad mikmod modules mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp oss pam pcre pdflib perl png ppds pppd python qt3 qt4 quicktime readline reflection sdl session spell spl ssl svg symlink tcpd truetype truetype-fonts type1-fonts udev unicode vorbis win32codecs x86 xml xorg xv zlib" ABI_X86="32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

----------
components: Build
files: build.log
messages: 206919
nosy: lanthruster
priority: normal
severity: normal
status: open
title: Python-3.3.3/Modules/socketmodule.c:1660:14: error: 'CAN_RAW' undeclared (first use in this function)
versions: Python 3.3
Added file: http://bugs.python.org/file33264/build.log

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

From report at bugs.python.org  Wed Dec 25 14:33:19 2013
From: report at bugs.python.org (Wolf Ihlenfeldt)
Date: Wed, 25 Dec 2013 13:33:19 +0000
Subject: [New-bugs-announce] [issue20066] PyStructSequence_NewType() not
	setting proper heap	allocation flag?
Message-ID: <1387978399.6.0.58819819413.issue20066@psf.upfronthosting.co.za>


New submission from Wolf Ihlenfeldt:

If I am not mistaken, I think that PyStructSequence_NewType() should set the Py_TPFLAGS_HEAPTYPE flag in tp->flags (which it currently does not). The original version initially works fine, but ultimately crashes at exit time in finalization with

Fatal Python error: type_traverse() called for non-heap type 'E_FILE'

#0  0x00007ffff12913d5 in raise () from /lib64/libc.so.6
#1  0x00007ffff1292858 in abort () from /lib64/libc.so.6
#2  0x00007ffff2360484 in Py_FatalError (msg=<optimized out>) at Python/pythonrun.c:2364
#3  0x00007ffff22e5354 in type_traverse (type=0x10b47a0, visit=0x7ffff2374350 <visit_decref>, arg=0x0)
    at Objects/typeobject.c:2892
#4  0x00007ffff2374bd1 in subtract_refs (containers=0x7ffff26466c0) at Modules/gcmodule.c:386
#5  collect (n_uncollectable=<synthetic pointer>, n_collected=<synthetic pointer>, generation=2)
    at Modules/gcmodule.c:891
#6  collect_with_callback (generation=2) at Modules/gcmodule.c:1048
#7  0x00007ffff2375436 in PyGC_Collect () at Modules/gcmodule.c:1476
#8  0x00007ffff235f698 in Py_Finalize () at Python/pythonrun.c:521
#9  0x00007ffff6e70b70 in CSpythonFinalize () at nmds_python.c:44652
#10 0x0000000000407399 in main ()

Setting the flag manually after creation lets the problem disappear.

----------
messages: 206923
nosy: Wolf.Ihlenfeldt
priority: normal
severity: normal
status: open
title: PyStructSequence_NewType() not setting proper heap allocation flag?
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Wed Dec 25 17:16:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Dec 2013 16:16:22 +0000
Subject: [New-bugs-announce] [issue20067] Tkinter variables no works with
	wantobject is false
Message-ID: <1387988182.68.0.509066568991.issue20067@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Tkinter variables test fails when wantobjects is false:

======================================================================
ERROR: test_default (__main__.TestVariable)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/tkinter/test/test_tkinter/test_variables.py", line 29, in test_default
    self.assertEqual("", v.get())
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 239, in get
    return self._tk.globalgetvar(self._name)
_tkinter.TclError: can't read "PY_VAR0": no such variable

======================================================================
ERROR: test_default (__main__.TestStringVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/tkinter/test/test_tkinter/test_variables.py", line 79, in test_default
    self.assertEqual("", v.get())
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 291, in get
    value = self._tk.globalgetvar(self._name)
_tkinter.TclError: can't read "PY_VAR2": no such variable

======================================================================
ERROR: test_default (__main__.TestIntVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/tkinter/test/test_tkinter/test_variables.py", line 92, in test_default
    self.assertEqual(0, v.get())
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 313, in get
    return getint(self._tk.globalgetvar(self._name))
_tkinter.TclError: can't read "PY_VAR3": no such variable

======================================================================
ERROR: test_default (__main__.TestDoubleVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/tkinter/test/test_tkinter/test_variables.py", line 114, in test_default
    self.assertEqual(0.0, v.get())
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 332, in get
    return getdouble(self._tk.globalgetvar(self._name))
_tkinter.TclError: can't read "PY_VAR4": no such variable

======================================================================
ERROR: test_default (__main__.TestBooleanVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 352, in get
    return self._tk.getboolean(self._tk.globalgetvar(self._name))
_tkinter.TclError: can't read "PY_VAR5": no such variable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "Lib/tkinter/test/test_tkinter/test_variables.py", line 141, in test_default
    self.assertEqual(False, v.get())
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 354, in get
    raise ValueError("invalid literal for getboolean()")
ValueError: invalid literal for getboolean()

======================================================================
FAIL: test___del__ (__main__.TestVariable)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/tkinter/test/test_tkinter/test_variables.py", line 38, in test___del__
    self.assertFalse(self.root.call("info", "exists", "varname"))
AssertionError: '0' is not false

======================================================================
FAIL: test_dont_unset_not_existing (__main__.TestVariable)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/tkinter/test/test_tkinter/test_variables.py", line 45, in test_dont_unset_not_existing
    self.assertFalse(self.root.call("info", "exists", "varname"))
AssertionError: '0' is not false

----------------------------------------------------------------------

Here is a patch which fixes tkinter and tests.

----------
assignee: serhiy.storchaka
components: Tkinter
files: tkinter_variables_wantobjects.patch
keywords: patch
messages: 206926
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Tkinter variables no works with wantobject is false
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33265/tkinter_variables_wantobjects.patch

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

From report at bugs.python.org  Thu Dec 26 07:42:47 2013
From: report at bugs.python.org (Julian Gindi)
Date: Thu, 26 Dec 2013 06:42:47 +0000
Subject: [New-bugs-announce] [issue20068] collections.Counter documentation
	leaves out interesting	usecase
Message-ID: <1388040167.94.0.902280065341.issue20068@psf.upfronthosting.co.za>


New submission from Julian Gindi:

I think the documentation for collections.Counter can be updated slightly to include an example showing the initialization of a counter object from a list. For example, it explains how to manually iterate through a list and increment the values...

for word in ['red', 'blue', 'red', 'green', 'blue', 'blue']:
...     cnt[word] += 1

I think it is more useful and powerful to do something like this:

cnt = Counter(['red', 'blue', 'red', 'green', 'blue', 'blue'])

where the result would be:

Counter({'blue': 3, 'red': 2, 'green': 1})

Just a thought. I'm curious to see what other people think.

----------
assignee: docs at python
components: Documentation
messages: 206935
nosy: Julian.Gindi, docs at python, rhettinger
priority: normal
severity: normal
status: open
title: collections.Counter documentation leaves out interesting usecase
type: enhancement
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/issue20068>
_______________________________________

From report at bugs.python.org  Thu Dec 26 11:28:23 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 26 Dec 2013 10:28:23 +0000
Subject: [New-bugs-announce] [issue20069] Add unit test for os.chown
Message-ID: <1388053703.09.0.645818054692.issue20069@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

There is no tests for os.chown except for the invalid input.

Attached the patch to add tests for os.chown. This test has not exercised the keyword `dir_fd` and `follow_symlinks` because `follow_symlinks` (I think) is kinda broken on Windows and I prefer to add unit test for `dir_fd` keyword in different ticket.

----------
components: Tests
files: add_unit_test_os_chown.patch
keywords: patch
messages: 206936
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Add unit test for os.chown
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33266/add_unit_test_os_chown.patch

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

From report at bugs.python.org  Thu Dec 26 16:32:01 2013
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 26 Dec 2013 15:32:01 +0000
Subject: [New-bugs-announce] [issue20070] test_urllib2net is run even when
	the network resource is	disabled
Message-ID: <1388071921.38.0.169844845527.issue20070@psf.upfronthosting.co.za>


New submission from Matthias Klose:

test_urllib2net is run even when the network resource is disabled, unlike test_urllibnet:

run_tests.py -j 1 -w -uall,-network,-urlfetch
...
[349/380/6] test_urllib2net
Resource 'http://www.python.org/' is not available
Resource 'http://www.example.com' is not available
Resource 'http://bitly.com/urllibredirecttest' is not available
Resource 'http://www.imdb.com' is not available
Resource 'http://docs.python.org/2/glossary.html#glossary' is not available
Resource 'ftp://ftp.mirror.nl/pub/gnu/' is not available
Resource 'ftp://ftp.mirror.nl/pub/gnu/' is not available
Resource 'ftp://ftp.mirror.nl/pub/gnu/' is not available
Resource 'ftp://ftp.mirror.nl/pub/gnu/' is not available
Resource 'http://www.python.org' is not available
Resource 'http://www.python.org' is not available
Resource 'http://www.python.org' is not available
Resource 'http://www.python.org' is not available
[350/380/6] test_urllib_response
[351/380/6] test_urllibnet
test_urllibnet skipped -- Use of the 'network' resource not enabled
[352/380/6] test_urlparse
...

----------
components: Tests
messages: 206942
nosy: doko
priority: normal
severity: normal
status: open
title: test_urllib2net is run even when the network resource is disabled
versions: Python 3.4

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

From report at bugs.python.org  Thu Dec 26 18:25:26 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 Dec 2013 17:25:26 +0000
Subject: [New-bugs-announce] [issue20071] What should happen if someone runs
	./python -m ensurepip	in the build environment?
Message-ID: <1388078726.11.0.20000173411.issue20071@psf.upfronthosting.co.za>


New submission from R. David Murray:

Someone on IRC reported doing this, and it (logically enough) gave a permission error trying to install into /opt.  That may be exactly what it should do...but if he'd done it as root, presumably it would have tried to install PIP without python having been installed first, which might be wrong.

(Donald says it would indeed install it, creating the directories as needed.)

----------
messages: 206948
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: What should happen if someone runs ./python -m ensurepip in the build environment?

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

From report at bugs.python.org  Thu Dec 26 19:20:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 18:20:06 +0000
Subject: [New-bugs-announce] [issue20072] Ttk tests fail when wantobjects is
	false
Message-ID: <1388082006.36.0.0879597768975.issue20072@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Ttk tests fail when wantobjects is false. See attached log file.

----------
assignee: serhiy.storchaka
components: Tkinter
files: test_ttk_guionly.log
messages: 206951
nosy: gpolo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Ttk tests fail when wantobjects is false
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33270/test_ttk_guionly.log

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

From report at bugs.python.org  Thu Dec 26 20:34:57 2013
From: report at bugs.python.org (Benjamin Eggerstedt)
Date: Thu, 26 Dec 2013 19:34:57 +0000
Subject: [New-bugs-announce] [issue20073] IDLE crashes on Unicode characters
Message-ID: <1388086497.78.0.557218598478.issue20073@psf.upfronthosting.co.za>


New submission from Benjamin Eggerstedt:

Hi,

On Mac OS the following crash happens in IDLE if you have fat fingers and hit some unexpected keys ...

e.g. 
? (Alt + u)

In case that the online tool somehow changes the characters, here is some hopefully safe way to deliver the details ...

Benny$ python
Python 2.7.6 (v2.7.6:3a1db0d2747e, Nov 10 2013, 00:42:54) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "?"
>>> a
'\xc2\xa8'

I believe this is related to ...
http://bugs.python.org/issue13153
http://bugs.python.org/issue10973

Crash information:
Process:         Python [14161]
Path:            /Applications/Python 2.7/IDLE.app/Contents/MacOS/Python
Identifier:      org.python.IDLE
Version:         2.7.6 (2.7.6)
Code Type:       X86 (Native)
Parent Process:  launchd [261]
Responsible:     Python [14161]
User ID:         501

Date/Time:       2013-12-26 19:59:35.756 +0100
OS Version:      Mac OS X 10.9.1 (13B42)
Report Version:  11
Anonymous UUID:  38E44FC5-9CFA-A636-C42D-307294DC13E7

Sleep/Wake UUID: A5C29C67-2DA5-4435-BC79-B6208FF60B16

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 'NSRangeException', reason: '-[__NSCFConstantString characterAtIndex:]: Range or index out of bounds'

Application Specific Backtrace 1:
0   CoreFoundation                      0x9846d6b1 __raiseError + 193
1   libobjc.A.dylib                     0x9bceb091 objc_exception_throw + 162
2   CoreFoundation                      0x9846d5cb +[NSException raise:format:] + 139
3   CoreFoundation                      0x9833faed -[__NSCFString characterAtIndex:] + 109
4   Tk                                  0x020baac7 TkpInitKeymapInfo + 722
5   Tk                                  0x020b670f TkpRedirectKeyEvent + 1232
6   Tk                                  0x020c0efe Tk_MacOSXSetupTkNotifier + 954
7   Tcl                                 0x006f240e Tcl_DoOneEvent + 308
8   _tkinter.so                         0x002d4322 Tkapp_MainLoop + 450
9   Python                              0x000c4230 PyEval_EvalFrameEx + 25344
10  Python                              0x000c6a2c PyEval_EvalCodeEx + 2012
11  Python                              0x000c4825 PyEval_EvalFrameEx + 26869
12  Python                              0x000c554c PyEval_EvalFrameEx + 30236
13  Python                              0x000c6a2c PyEval_EvalCodeEx + 2012
14  Python                              0x000c6b77 PyEval_EvalCode + 87
15  Python                              0x000eaf5c PyRun_FileExFlags + 172
16  Python                              0x000eb284 PyRun_SimpleFileExFlags + 532
17  Python                              0x00103412 Py_Main + 3410
18  Python                              0x00001f65 start + 53
19  ???                                 0x00000002 0x0 + 2

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.CoreFoundation      	0x9846e007 ___TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION___ + 7
1   com.apple.CoreFoundation      	0x9846d9b0 __raiseError + 960
2   libobjc.A.dylib               	0x9bceb091 objc_exception_throw + 162
3   com.apple.CoreFoundation      	0x9846d5cb +[NSException raise:format:] + 139
4   com.apple.CoreFoundation      	0x9833faed -[__NSCFString characterAtIndex:] + 109
5   Tk                            	0x020baac7 0x2000000 + 764615
6   Tk                            	0x020b670f 0x2000000 + 747279
7   Tk                            	0x020c0efe 0x2000000 + 790270
8   Tcl                           	0x006f240e Tcl_DoOneEvent + 308
9   _tkinter.so                   	0x002d4322 Tkapp_MainLoop + 450
10  org.python.python             	0x000c4230 PyEval_EvalFrameEx + 25344
11  org.python.python             	0x000c6a2c PyEval_EvalCodeEx + 2012
12  org.python.python             	0x000c4825 PyEval_EvalFrameEx + 26869
13  org.python.python             	0x000c554c PyEval_EvalFrameEx + 30236
14  org.python.python             	0x000c6a2c PyEval_EvalCodeEx + 2012
15  org.python.python             	0x000c6b77 PyEval_EvalCode + 87
16  org.python.python             	0x000eaf5c PyRun_FileExFlags + 172
17  org.python.python             	0x000eb284 PyRun_SimpleFileExFlags + 532
18  org.python.python             	0x00103412 Py_Main + 3410
19  Python                        	0x00001f65 start + 53

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib        	0x92ab7992 kevent64 + 10
1   libdispatch.dylib             	0x9331f8bd _dispatch_mgr_invoke + 238
2   libdispatch.dylib             	0x9331f556 _dispatch_mgr_thread + 52

Thread 2:
0   libsystem_kernel.dylib        	0x92ab7046 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x94719dcf _pthread_wqthread + 372
2   libsystem_pthread.dylib       	0x9471dcce start_wqthread + 30

Thread 3:
0   libsystem_kernel.dylib        	0x92ab7046 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x94719dcf _pthread_wqthread + 372
2   libsystem_pthread.dylib       	0x9471dcce start_wqthread + 30

Thread 4:
0   libsystem_kernel.dylib        	0x92ab6ace __select + 10
1   Tcl                           	0x007248e0 0x677000 + 710880
2   libsystem_pthread.dylib       	0x947185fb _pthread_body + 144
3   libsystem_pthread.dylib       	0x94718485 _pthread_start + 130
4   libsystem_pthread.dylib       	0x9471dcf2 thread_start + 34

Thread 5:
0   libsystem_kernel.dylib        	0x92ab1f7a mach_msg_trap + 10
1   libsystem_kernel.dylib        	0x92ab116c mach_msg + 68
2   com.apple.CoreFoundation      	0x9837ef69 __CFRunLoopServiceMachPort + 169
3   com.apple.CoreFoundation      	0x9837e541 __CFRunLoopRun + 1393
4   com.apple.CoreFoundation      	0x9837dd5a CFRunLoopRunSpecific + 394
5   com.apple.CoreFoundation      	0x9837dbbb CFRunLoopRunInMode + 123
6   com.apple.AppKit              	0x9b291f18 _NSEventThread + 283
7   libsystem_pthread.dylib       	0x947185fb _pthread_body + 144
8   libsystem_pthread.dylib       	0x94718485 _pthread_start + 130
9   libsystem_pthread.dylib       	0x9471dcf2 thread_start + 34

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x00000001  ebx: 0x014db000  ecx: 0x00000000  edx: 0x00000000
  edi: 0x004ec5b0  esi: 0x9846d5fe  ebp: 0xbfffe708  esp: 0xbfffe700
   ss: 0x00000023  efl: 0x00000286  eip: 0x9846e007   cs: 0x0000001b
   ds: 0x00000023   es: 0x00000023   fs: 0x00000000   gs: 0x0000000f
  cr2: 0x0468a000
  
Logical CPU:     0
Error Code:      0x00000000
Trap Number:     3


Binary Images:
    0x1000 -     0x1ff7 +Python (???) <5E42C8AF-4D60-8991-99DF-D9F7D9BE5018> /Applications/Python 2.7/IDLE.app/Contents/MacOS/Python
    0x4000 -   0x146fff +org.python.python (2.7.6, [c] 2004-2013 Python Software Foundation. - 2.7.6) <9C0C57BD-C006-1A8D-90F5-422FD3D05652> /Library/Frameworks/Python.framework/Versions/2.7/Python
  0x2d0000 -   0x2d7ff7 +_tkinter.so (???) <7DDA96E8-45E2-2385-2045-37F603882100> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so
  0x677000 -   0x741ff7  Tcl (8.5.9 - 8.5.9) <B4D8EBCA-4404-3367-9656-141348996C28> /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
  0x7f5000 -   0x7f8ff7 +strop.so (???) <099FF8EE-ED78-C47B-C64F-6B0510025DEF> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/strop.so
 0x2000000 -  0x20ecffc  Tk (8.5.9 - 8.5.9) <BEA92DB4-E461-33E6-89C6-402837548EF8> /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk
 0x211a000 -  0x2123ff7 +_socket.so (???) <B989F71D-43D0-8163-05EE-29462ABD15A8> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_socket.so
 0x212e000 -  0x212fff7 +_functools.so (???) <A69F8971-17DD-6EF8-4ACB-ACADE9A3001B> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_functools.so
 0x2132000 -  0x2136ff7 +_ssl.so (???) <5B67DF16-508B-3839-42DE-0270C85627CA> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_ssl.so
 0x213b000 -  0x213cff7 +cStringIO.so (???) <721E10B1-65B4-ABA6-90E6-D92952BE3AF8> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cStringIO.so
 0x2140000 -  0x2141ff7 +time.so (???) <5ECA4EBE-2EC9-3107-DCF4-45050F936643> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/time.so
 0x2186000 -  0x2189ff7 +_collections.so (???) <78F6EE64-6C57-7632-ADBE-FABDF9630120> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_collections.so
 0x218e000 -  0x2191ff7 +operator.so (???) <C61843E8-61D2-104C-C3BC-A296888E7B24> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/operator.so
 0x21f7000 -  0x21f8ff7 +_heapq.so (???) <FA517395-8DD2-B833-7C71-297CA2E5CC71> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_heapq.so
 0x21fc000 -  0x21fdff7 +fcntl.so (???) <7D79E04D-6165-E55E-0917-AC482EB3FC59> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/fcntl.so
 0x2600000 -  0x2605ff7 +itertools.so (???) <7FAA1ED6-582E-BEEA-379F-F82A7923D051> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/itertools.so
 0x260d000 -  0x2620ff7 +_io.so (???) <1B9DFDC8-9D70-4256-B603-31A943100A2F> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
 0x2675000 -  0x2677ff7 +select.so (???) <5DF162CA-80BD-B25D-0243-E8D56AC37868> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/select.so
 0x267c000 -  0x267fff7 +_struct.so (???) <21694FA7-1A29-5746-7D5C-4F57EB4BA72A> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_struct.so
 0x2686000 -  0x2688fe7 +binascii.so (???) <600CFC44-CBCF-E606-E378-AA5D6F00CB56> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/binascii.so
 0x274c000 -  0x2750ff7 +math.so (???) <E69F8DAC-CC96-392E-FFDE-749ACA982564> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/math.so
 0x2755000 -  0x2756ff7 +_hashlib.so (???) <8E1D90CA-C55F-B334-F047-8743905D87BD> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_hashlib.so
 0x275a000 -  0x275bff7 +_random.so (???) <BCF247FD-CE8B-1290-4A4F-419542E24D4A> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_random.so
 0x275e000 -  0x275fff7 +_locale.so (???) <C642A507-EFA8-4FB6-133A-4DF30A04C569> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_locale.so
 0x2762000 -  0x2770ff7 +cPickle.so (???) <F739315F-6A1E-86E9-88EC-CEFCCA285AE6> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cPickle.so
 0x46e6000 -  0x46f1ffa  com.apple.CommerceCore (1.0 - 42) <E59717F2-6770-3DBC-8510-F7AA61E60F57> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore
 0x6e25000 -  0x6e4aff9  com.apple.framework.familycontrols (4.1 - 410) <A33A97EE-C735-38BA-9B49-5D78DAA3DEDA> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
 0x74a3000 -  0x74a3ffd +cl_kernels (???) <EDFF895E-8B10-42FD-8BB9-6DAE1FF30917> cl_kernels
 0x74a5000 -  0x7590ff7  unorm8_bgra.dylib (2.3.58) <44644D3C-3D0E-3CBB-9265-664D95EC791F> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/ImageFormats/unorm8_bgra.dylib
0x8fe91000 - 0x8fec3417  dyld (239.3) <4B280BB1-55F8-313F-86A6-8ADD644ED69E> /usr/lib/dyld
0x90008000 - 0x90030ff7  libRIP.A.dylib (599.7) <461297C0-DDA9-3613-8F27-D7F1AC57208F> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
0x90031000 - 0x90032fff  libsystem_blocks.dylib (63) <2AC67D5E-ECD4-3644-A53C-9684F9B7AA33> /usr/lib/system/libsystem_blocks.dylib
0x90092000 - 0x900fdff9  com.apple.Heimdal (4.0 - 2.0) <E3091095-A893-3089-8DA1-8705B3BE5BF9> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
0x900fe000 - 0x90102fff  com.apple.CommonPanels (1.2.6 - 96) <E7CA63C6-CEE9-3F0A-93A7-C12C653FFB80> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
0x90122000 - 0x9013eff9  com.apple.Ubiquity (1.3 - 289) <1CEDC83D-7282-3B4D-8CF7-4FE045012391> /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity
0x904be000 - 0x904eeff3  libtidy.A.dylib (15.12) <3DBE95FE-8FA7-3584-9202-E37B54B3B064> /usr/lib/libtidy.A.dylib
0x904ef000 - 0x90520ffa  libsystem_m.dylib (3047.16) <28E614E8-7802-3E84-960A-AD4721EF10F7> /usr/lib/system/libsystem_m.dylib
0x90521000 - 0x90528ff2  com.apple.NetFS (6.0 - 4.0) <915AA303-C02B-3B0C-8208-D8AAA4350DB4> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
0x90529000 - 0x90551fff  libsystem_info.dylib (449.1.3) <BB68E8CC-422F-3121-8C86-D0F766FB696D> /usr/lib/system/libsystem_info.dylib
0x90552000 - 0x90564fff  libbsm.0.dylib (33) <1BE92DB5-0D2F-3BB5-BCC6-8A71EF2A3450> /usr/lib/libbsm.0.dylib
0x90565000 - 0x9056effa  com.apple.CommonAuth (4.0 - 2.0) <6CB82D57-3C55-39E5-9036-8047DF3E6F57> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
0x905de000 - 0x907a4ffb  libicucore.A.dylib (511.27) <653147E9-7326-337A-99E1-B42E4D801E53> /usr/lib/libicucore.A.dylib
0x907a5000 - 0x90868ff1  com.apple.CoreText (352.0 - 367.15) <746AD442-F7B4-3273-A36D-C7103D26F727> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
0x90bee000 - 0x90c11ff7  libc++abi.dylib (48) <5367BE5A-D475-3FB4-972D-E1DC999A709A> /usr/lib/libc++abi.dylib
0x90d91000 - 0x90d9fff7  com.apple.Sharing (132.2 - 132.2) <87DBFC7A-9689-3B8E-AD16-5A9DFF9DE625> /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing
0x90da0000 - 0x90e3cfff  com.apple.QD (3.50 - 298) <F73FD4D4-17A4-37D6-AC06-7CA5A8BA1212> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
0x90e3d000 - 0x90e4bff3  com.apple.opengl (9.0.83 - 9.0.83) <16CFFD50-217E-3E18-88AF-7F2AD980628B> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
0x90e4c000 - 0x90e4cfff  com.apple.Accelerate (1.9 - Accelerate 1.9) <C85070A7-D942-3CFA-981F-5864480788C8> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x90e4d000 - 0x91137fd2  com.apple.vImage (7.0 - 7.0) <256972F0-3DBC-3CE1-9EE8-B48243868729> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x9119f000 - 0x91491ff8  com.apple.CoreImage (9.0.54) <D7BC3E53-EF5B-3A14-8808-8D45EE505B48> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage
0x91492000 - 0x9149bfff  com.apple.speech.recognition.framework (4.2.4 - 4.2.4) <CF8E5706-F744-3139-8A51-D52BF055D19F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
0x914fb000 - 0x91513fff  com.apple.CFOpenDirectory (10.9 - 173.1.1) <630A5CCF-8FC3-379D-B0BD-41DCE1F0B624> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
0x91514000 - 0x91515fff  libSystem.B.dylib (1197.1.1) <C58F0CC9-C1FD-3024-9358-D3359A6BBCAD> /usr/lib/libSystem.B.dylib
0x91516000 - 0x91553ffb  libGLImage.dylib (9.0.83) <FA15FEB5-54E4-313B-8E78-A2D2E6C88FE1> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x91bf7000 - 0x91bfaffb  libutil.dylib (34) <B496031E-E763-3DEB-84D2-85C0F3DF2012> /usr/lib/libutil.dylib
0x91bfb000 - 0x91cf9fff  libJP2.dylib (1038) <EE0B9985-625D-39E6-B425-03FB75BA2594> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
0x91cfa000 - 0x91de5ff4  com.apple.DiskImagesFramework (10.9 - 371.1) <FC13BD5A-0FB7-35D5-A8DF-0510CFA996FE> /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages
0x91e4e000 - 0x91eceff7  com.apple.CoreServices.OSServices (600.4 - 600.4) <1227DF22-E2DA-3764-A1CA-10CC0CEBE377> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x91ecf000 - 0x91f1bff7  libcups.2.dylib (372) <9A2BE8DC-37E4-3019-B665-1036FE7868EA> /usr/lib/libcups.2.dylib
0x91f1c000 - 0x91f1cfff  com.apple.Accelerate.vecLib (3.9 - vecLib 3.9) <DDAC0B59-F886-3AB1-98E8-C71FFF161CD4> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x9237f000 - 0x92385ffc  libCGXCoreImage.A.dylib (599.7) <87F9F4B2-487E-3B11-A869-D6CBDAB39055> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXCoreImage.A.dylib
0x92386000 - 0x92393ff7  com.apple.HelpData (2.1.4 - 90) <5BACC236-5B40-33AC-B088-87EDEFAF1D3E> /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData
0x92394000 - 0x923d6fff  libGLU.dylib (9.0.83) <0D9BFE5A-435E-3C66-AF96-D3567B8FC87B> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x923d7000 - 0x92401fff  libxslt.1.dylib (13) <249D54AB-1D82-38FE-ABEC-0D575450C73B> /usr/lib/libxslt.1.dylib
0x9240a000 - 0x9249cffe  libsystem_c.dylib (997.1.1) <D06FD754-8CE3-3EB7-BE05-2EF939BBE05F> /usr/lib/system/libsystem_c.dylib
0x92665000 - 0x92665fff  com.apple.ApplicationServices (48 - 48) <7967F6FA-2984-3CC3-AD9A-7B9AEC562A2A> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
0x92666000 - 0x9266ffff  libsystem_notify.dylib (121) <623269F5-1518-3035-A916-8AF83C972154> /usr/lib/system/libsystem_notify.dylib
0x92670000 - 0x9267bfff  com.apple.CrashReporterSupport (10.9 - 538) <7A5FF845-433C-33E3-99B5-F6AA5B825734> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport
0x9267c000 - 0x926c4fff  com.apple.PerformanceAnalysis (1.47 - 47) <16935C0F-7F9F-316E-9D46-11973DE0904A> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
0x926c5000 - 0x92718fff  com.apple.htmlrendering (77 - 1.1.4) <408FA30F-4FE9-3162-9FFD-677E8569C1EA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
0x92719000 - 0x92724fff  libcsfde.dylib (380) <C9E61AFB-1A9D-324B-9827-06B182CDD7B0> /usr/lib/libcsfde.dylib
0x92725000 - 0x92749fff  libxpc.dylib (300.1.17) <252BC88F-A5CA-3E67-AEDB-3D7B9F4537E2> /usr/lib/system/libxpc.dylib
0x92853000 - 0x92866fff  com.apple.ImageCapture (9.0 - 9.0) <63D5C96F-1893-3F35-ADFB-EE451AFD87E6> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
0x92867000 - 0x9286bffa  libcache.dylib (62) <9730D7F2-D226-3F30-8D26-BF598CB781F6> /usr/lib/system/libcache.dylib
0x9286c000 - 0x928cdff7  com.apple.Symbolication (1.4 - 129) <E5948C08-6ADF-3D86-9134-6AE49CF1DA0F> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
0x928ce000 - 0x928fcff3  com.apple.DebugSymbols (106 - 106) <FC70F4C9-B2A6-352F-9563-6C085E9DDDB8> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
0x928fd000 - 0x92a09fff  com.apple.ImageIO.framework (3.3.0 - 1038) <0B4A6607-9FBC-3A6C-984A-0542DE8385FB> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
0x92a90000 - 0x92a90fff  libodfde.dylib (20) <98FC02AE-C596-3ED5-80D1-C502FF6115ED> /usr/lib/libodfde.dylib
0x92a91000 - 0x92a96ff7  com.apple.print.framework.Print (9.0 - 260) <A6C465F6-C5D1-353A-9F33-19B9CEDBBC2A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
0x92a9f000 - 0x92abcff4  libsystem_kernel.dylib (2422.1.72) <C5641F6C-E271-380A-A656-AE4C04345602> /usr/lib/system/libsystem_kernel.dylib
0x92abd000 - 0x92ba0ff7  libcrypto.0.9.8.dylib (50) <B367D3A3-FC1F-326C-92EC-CAD81666524D> /usr/lib/libcrypto.0.9.8.dylib
0x92ba1000 - 0x92ba1ffd  libOpenScriptingUtil.dylib (157) <4D06E8ED-D312-34EA-A448-DFF45ADC3CE5> /usr/lib/libOpenScriptingUtil.dylib
0x92c43000 - 0x92c4bfff  libcopyfile.dylib (103) <1B1484BD-08B6-3BA9-94CA-A7C24B610EB3> /usr/lib/system/libcopyfile.dylib
0x92c4c000 - 0x92d32ff7  com.apple.coreui (2.1 - 231) <1C1AE894-C5C2-3F1C-BF29-B152ECD9BD88> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
0x92d33000 - 0x92d68ffd  libssl.0.9.8.dylib (50) <F3BEA2DF-DB84-37F0-B4C7-97C0A4DF19C9> /usr/lib/libssl.0.9.8.dylib
0x92d69000 - 0x92d99ff7  com.apple.CoreServicesInternal (184.8 - 184.8) <88528205-9452-3EEC-BB27-DAAA7EC81E04> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal
0x92d9a000 - 0x92e6afef  libvDSP.dylib (423.32) <E2FA7230-A001-3F6B-9ACF-6998C51AD7DC> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
0x92e6b000 - 0x92e73fff  liblaunch.dylib (842.1.4) <3798500D-4436-3AEB-B273-7F2428C33A4A> /usr/lib/system/liblaunch.dylib
0x92e74000 - 0x92ebafff  libcurl.4.dylib (78) <EC84399F-5EA8-321B-B122-99730CC557C8> /usr/lib/libcurl.4.dylib
0x92ec6000 - 0x92ecaffa  libGIF.dylib (1038) <5CEB4EDF-B0B6-33A6-BDDE-8C0D3226FA72> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
0x92ecb000 - 0x92edfff9  com.apple.MultitouchSupport.framework (245.13 - 245.13) <6860A0D0-3654-3B02-B2E9-C4D2637167B8> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
0x92ee0000 - 0x92ee3ffa  libCGXType.A.dylib (599.7) <2738FF52-4B47-31AD-B7E5-412F6AFACC2A> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib
0x92ee4000 - 0x92ef0ffc  libbz2.1.0.dylib (29) <3CEF1E92-BA42-3F8A-8E8D-9E1F7658E5C7> /usr/lib/libbz2.1.0.dylib
0x92ef1000 - 0x9321cff6  com.apple.Foundation (6.9 - 1056) <C8AE9C03-3460-354A-A8B6-EF4955BE600D> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x9321d000 - 0x93309ff7  libxml2.2.dylib (26) <32040145-6FD6-3AD2-B98B-39F73BF9AC47> /usr/lib/libxml2.2.dylib
0x93317000 - 0x9331bfff  libheimdal-asn1.dylib (323.12) <9EA2A221-301B-3B9A-BBF2-38134145B5A8> /usr/lib/libheimdal-asn1.dylib
0x9331c000 - 0x93334ffd  libdispatch.dylib (339.1.9) <6249BAE5-044F-3A7A-9CCC-03FF7E6B405B> /usr/lib/system/libdispatch.dylib
0x93368000 - 0x933c4ffa  com.apple.print.framework.PrintCore (9.0 - 428) <3E248391-2669-328B-B84F-8763FE8E92BB> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x933c5000 - 0x9344efff  com.apple.CoreSymbolication (3.0 - 141) <178DDF5C-B6DA-39BD-84F5-FD3FA7E93BF8> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
0x93472000 - 0x93474fff  com.apple.securityhi (9.0 - 55005) <51765C73-80D1-33E3-9589-3E88380CE007> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
0x93480000 - 0x9351fff7  libCoreStorage.dylib (380) <55467C87-E1A3-3057-B428-9BCEFD39E36D> /usr/lib/libCoreStorage.dylib
0x93520000 - 0x935e7ff7  com.apple.DiscRecording (8.0 - 8000.4.6) <84A7EC09-3BBD-3E04-A88C-6D3B724448FF> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording
0x935e8000 - 0x9367fff7  com.apple.ink.framework (10.9 - 207) <EF00BCCB-B270-3F3D-9424-EF5F4BC23E25> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
0x93682000 - 0x9368effe  libkxld.dylib (2422.1.72) <F9B35FA5-C936-3286-A055-2B0780A674AC> /usr/lib/system/libkxld.dylib
0x9368f000 - 0x93690ffc  com.apple.TrustEvaluationAgent (2.0 - 25) <064B485D-56E0-3DD7-BBE2-E08A5BFFF8B3> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
0x93695000 - 0x9369bffb  libunwind.dylib (35.3) <099D1A6F-A1F0-3D05-BF1C-0A7BB32D39C2> /usr/lib/system/libunwind.dylib
0x9369c000 - 0x936acff5  com.apple.LangAnalysis (1.7.0 - 1.7.0) <71DE7754-0A47-3F35-B1BF-B1FE7E1311E0> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
0x936ad000 - 0x936adfff  com.apple.Cocoa (6.8 - 20) <407DC9E6-BBCE-3D34-9BBB-00C90584FFDF> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
0x936ba000 - 0x937ccffc  libsqlite3.dylib (158) <B3DB0FED-FE4C-314D-8329-CF7708C8AAF4> /usr/lib/libsqlite3.dylib
0x9385a000 - 0x938ebfff  com.apple.ColorSync (4.9.0 - 4.9.0) <8366AE10-0396-3100-B87A-A176E8ECE7B6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
0x938ec000 - 0x938f4fee  libcldcpuengine.dylib (2.3.58) <713322D8-A643-3B9F-8194-9C4020D8A4D6> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libcldcpuengine.dylib
0x938f5000 - 0x938f5fff  com.apple.Carbon (154 - 157) <6E680560-FD53-3C00-BDF7-7AFA28747DC8> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x939a2000 - 0x939bdff5  com.apple.openscripting (1.4 - 157) <5C161A52-8D2F-3D56-A988-05727BED7A59> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
0x939be000 - 0x939c4ff7  com.apple.AOSNotification (1.7.0 - 760.3) <63F7E7F8-6FA3-38D3-9907-CDF360CA9354> /System/Library/PrivateFrameworks/AOSNotification.framework/Versions/A/AOSNotification
0x939ef000 - 0x93a3fff7  libcorecrypto.dylib (161.1) <135FD99E-2211-3DF4-825C-C9F816107F0C> /usr/lib/system/libcorecrypto.dylib
0x93a40000 - 0x93a45ff3  libsystem_platform.dylib (24.1.4) <875321B9-34EF-3FCC-880C-633FA05223F5> /usr/lib/system/libsystem_platform.dylib
0x93a46000 - 0x93b7dff3  com.apple.desktopservices (1.8 - 1.8) <4D853961-F911-3FE2-A7DF-3130EA1D8CEB> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
0x93b92000 - 0x93c86fff  libFontParser.dylib (111.1) <D8F9B2A4-41A6-3407-8D80-13A841F97BE5> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
0x93d9f000 - 0x93da1fff  libquarantine.dylib (71) <EE3B510E-1AEC-3171-8A1A-D6A5A42CF35C> /usr/lib/system/libquarantine.dylib
0x93da2000 - 0x93dbbfff  com.apple.Kerberos (3.0 - 1) <91F17EB2-C70C-359C-B09D-96B52D2A9C9F> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
0x94717000 - 0x9471effb  libsystem_pthread.dylib (53.1.4) <8B1B7B84-1B5D-32A8-AC0D-1E689E5C8A4C> /usr/lib/system/libsystem_pthread.dylib
0x9471f000 - 0x9475bff4  com.apple.RemoteViewServices (2.0 - 94) <BEEE6ADF-7DA3-3D68-BCB0-9863BE1A1F46> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices
0x9475c000 - 0x947b2ff6  com.apple.ScalableUserInterface (1.0 - 1) <2C81641B-FA30-32FF-8B3E-3CB9BF53B2D9> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface
0x947d3000 - 0x947ebff7  libsystem_malloc.dylib (23.1.10) <69F485C9-B3E7-3E36-A06C-D7DFD29D22E1> /usr/lib/system/libsystem_malloc.dylib
0x947ec000 - 0x94822fff  com.apple.IconServices (25 - 25.17) <A4B5242B-765E-3D58-B066-BBEDB5947AAD> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices
0x9483a000 - 0x9483effc  com.apple.IOSurface (91 - 91) <DECEEB72-3C7E-3C21-9237-E5AD293F8B09> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
0x9483f000 - 0x9488dff9  com.apple.HIServices (1.22 - 466) <30636237-408A-3552-90C1-1279348DF7CB> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
0x9488e000 - 0x9497effb  libiconv.2.dylib (41) <848FEBA7-2E3E-3ECB-BD59-007F32468787> /usr/lib/libiconv.2.dylib
0x949d3000 - 0x949d7ff7  libmacho.dylib (845) <D8E93E59-1F80-3413-B9CF-78B848F6E873> /usr/lib/system/libmacho.dylib
0x951a8000 - 0x95354ff1  com.apple.QuartzCore (1.8 - 332.0) <07F9B77F-35A2-3D21-99FA-CD3FCE5B9C7B> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x95357000 - 0x95395ff7  com.apple.NavigationServices (3.8 - 215) <A093AAF0-248E-313E-BA82-01F69E269895> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices
0x95396000 - 0x9539affc  libpam.2.dylib (20) <50623D44-795F-3E28-AA85-23E0E7E2AE0E> /usr/lib/libpam.2.dylib
0x9539b000 - 0x953c2fff  com.apple.CoreVideo (1.8 - 117.2) <A53FDD90-F200-3F7C-8A8E-5DE36D3DFBB0> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
0x953c3000 - 0x953c5ffe  libCVMSPluginSupport.dylib (9.0.83) <BD30BDD1-DD5B-3F31-A09B-C274EA93CD7C> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
0x953c6000 - 0x953c6fff  com.apple.CoreServices (59 - 59) <06747539-5035-3307-8645-9BC4E7F89023> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x953c7000 - 0x953f0ff5  com.apple.shortcut (2.6 - 2.6) <F9F32E6F-E641-36D0-B648-058D5E146D38> /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut
0x95657000 - 0x9565aff7  com.apple.help (1.3.3 - 46) <AB6292FA-D3BC-3D56-B3A5-2BE630A503E7> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
0x956aa000 - 0x956aeffe  libCoreVMClient.dylib (58.1) <0EB8FFD7-AFED-3A63-810E-29629831D43D> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
0x956af000 - 0x956bbff7  com.apple.OpenDirectory (10.9 - 173.1.1) <2AA24814-2DC6-3E28-B71B-186B686F0F19> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
0x956bc000 - 0x956bfff9  com.apple.TCC (1.0 - 1) <A5FCF7AA-3F56-3A19-9DF1-661F1F02F79D> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
0x956c0000 - 0x956c1fff  liblangid.dylib (117) <F18F76C6-7E4B-34AD-AE81-C1C031BF2F7D> /usr/lib/liblangid.dylib
0x959c4000 - 0x959c4ffd  com.apple.audio.units.AudioUnit (1.9 - 1.9) <8A37963C-DF6F-3DFF-94E9-407DC5DFEDA9> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x959ce000 - 0x95ccfff7  com.apple.CoreServices.CarbonCore (1077.14 - 1077.14) <42E10BD1-995B-3FB4-8A6D-5FD071FB8BD1> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x95cd0000 - 0x95cdaff7  com.apple.speech.synthesis.framework (4.6.2 - 4.6.2) <16E20DCD-89F4-3C8E-9DBA-EED359807038> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x95e88000 - 0x95e92ff7  com.apple.DirectoryService.Framework (10.9 - 173.1.1) <D6735614-EF4B-389F-BF99-7D8416A504BA> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
0x95e95000 - 0x95e98ffe  com.apple.LoginUICore (3.0 - 3.0) <6FE961A4-3C17-3004-B50B-FD78FDC28350> /System/Library/PrivateFrameworks/LoginUIKit.framework/Versions/A/Frameworks/LoginUICore.framework/Versions/A/LoginUICore
0x95e99000 - 0x95f31ff7  com.apple.Metadata (10.7.0 - 800.12.2) <5E9EA0AC-EE9E-362E-9DAC-9B7D21A53A2A> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x95f32000 - 0x95f3afff  libsystem_dnssd.dylib (522.1.11) <1C015806-B971-34F9-B162-3DF7897351D0> /usr/lib/system/libsystem_dnssd.dylib
0x95f3b000 - 0x96008ff7  com.apple.backup.framework (1.5.1 - 1.5.1) <91998CDF-3547-3183-A962-D9E981C14891> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup
0x96009000 - 0x96016ff7  com.apple.AppleFSCompression (56 - 1.0) <0C44B3E4-C4A7-3A65-9C1A-334CA3E35BDB> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
0x961f1000 - 0x96566ff9  com.apple.HIToolbox (2.1 - 696) <43CB31D6-4C2B-30FA-A374-DB7C5728E7AD> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x96567000 - 0x96568ffa  libsystem_sandbox.dylib (278.10) <F3C9C427-AF9F-3CE0-95FF-DC9ACA0B5760> /usr/lib/system/libsystem_sandbox.dylib
0x96569000 - 0x965c2ffa  libTIFF.dylib (1038) <691DAAFD-D72B-3BE9-AE5C-84AF86BE66CD> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x965c3000 - 0x96636fff  com.apple.SearchKit (1.4.0 - 1.4.0) <6F607AB6-7553-37BA-BEC5-98FD7C27FAD7> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x96773000 - 0x967abff7  com.apple.MediaKit (15 - 709) <82E0F8C0-313C-379C-9994-4D21587D0C0C> /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit
0x96de5000 - 0x96f57ffb  com.apple.audio.toolbox.AudioToolbox (1.9 - 1.9) <E5FFD35D-18CF-333C-BECE-39F8E47BE707> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
0x98040000 - 0x98071ffd  com.apple.GSS (4.0 - 2.0) <6BA01155-4DAD-30EE-B480-D224650EA010> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
0x980d5000 - 0x980e0ffb  libcommonCrypto.dylib (60049) <F8E60C43-22EE-3E0B-9546-3365056901F1> /usr/lib/system/libcommonCrypto.dylib
0x980f9000 - 0x981a5ffb  libvMisc.dylib (423.32) <43873EFF-FB43-3301-BEE8-F2C3A046D7A6> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x98252000 - 0x98291ff7  com.apple.bom (12.0 - 192) <50F9D23C-9C9A-38BF-B4E2-66D93BE2A174> /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom
0x98292000 - 0x98307ffb  com.apple.framework.IOKit (2.0.1 - 907.1.13) <86D72735-9DFB-35C8-83F7-CE0DCF17D354> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x98308000 - 0x9850aff7  com.apple.CoreFoundation (6.9 - 855.11) <50F70E07-043A-3A2F-87EF-A36BA6C5C9D9> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x9850e000 - 0x98563fff  libc++.1.dylib (120) <10C0A136-64F9-3CC2-9420-013247032120> /usr/lib/libc++.1.dylib
0x98564000 - 0x98572fff  libxar.1.dylib (202) <B73748D4-F830-3C71-98B3-7A3ABF5136FD> /usr/lib/libxar.1.dylib
0x98576000 - 0x985bcff7  libFontRegistry.dylib (127) <A0930DB2-A6C6-3C6E-B4A2-119E0D76FD7D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
0x985bd000 - 0x98612ff7  com.apple.audio.CoreAudio (4.2.0 - 4.2.0) <0F1C111F-1E64-33BB-A69F-14643B3037D5> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x98640000 - 0x9865cfff  libCRFSuite.dylib (34) <FFF76EBA-DF35-3A5F-857F-3F4B1C9F4C77> /usr/lib/libCRFSuite.dylib
0x9865d000 - 0x98681fff  libJPEG.dylib (1038) <212B0986-9227-397C-9493-BCB190EC020E> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
0x9869c000 - 0x98711ff1  com.apple.ApplicationServices.ATS (360 - 363.1) <5C9BC698-0CC1-3F6A-9F9D-BCC3A9C3D6DC> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
0x98712000 - 0x98788ff3  com.apple.securityfoundation (6.0 - 55122) <25149798-A37E-316F-84AB-93029EAF33D8> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
0x98789000 - 0x98b4eff6  libLAPACK.dylib (1094.5) <E6286E68-3501-31AC-813E-75B3B3968011> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
0x98b4f000 - 0x98b69ff7  com.apple.GenerationalStorage (2.0 - 160.2) <8755F7F1-2402-387C-A32A-2270E7D680C8> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage
0x98b6a000 - 0x98b85ff6  libPng.dylib (1038) <F39168D4-ABEB-3C2D-A763-B9D3E1EF43BC> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
0x98b86000 - 0x98b87fff  libDiagnosticMessagesClient.dylib (100) <B936B1D4-90BB-395D-8EA9-E1237608E7D0> /usr/lib/libDiagnosticMessagesClient.dylib
0x98ba9000 - 0x98ba9fff  libkeymgr.dylib (28) <1B097DEA-011E-3B1C-86D5-6C7FAD5C765A> /usr/lib/system/libkeymgr.dylib
0x98baa000 - 0x98babfff  libremovefile.dylib (33) <ED35EA79-EB06-3B84-A6D4-B1A9D6B8648D> /usr/lib/system/libremovefile.dylib
0x98ef3000 - 0x98f5cfff  com.apple.SystemConfiguration (1.13 - 1.13) <542075CD-9085-3F30-B84B-DD0277D6A40E> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x98f5d000 - 0x98f65ff7  libCGCMS.A.dylib (599.7) <A7404924-9A2B-3324-A934-BD08953E7098> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGCMS.A.dylib
0x98f66000 - 0x98f6bff6  libcompiler_rt.dylib (35) <9924DF2E-D80B-3A21-920D-544A4597203F> /usr/lib/system/libcompiler_rt.dylib
0x98f6c000 - 0x98f7cff7  libsasl2.2.dylib (170) <CA1C07F6-8E17-315E-AE49-AB696DDE6707> /usr/lib/libsasl2.2.dylib
0x98f7d000 - 0x98fafff7  libTrueTypeScaler.dylib (111.1) <A568EE4C-1588-3F8B-8640-F02CEFC5AF09> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib
0x98fb0000 - 0x9921dff6  com.apple.security (7.0 - 55471) <5FCF76B2-92C6-3404-87D3-91B3F6E203AA> /System/Library/Frameworks/Security.framework/Versions/A/Security
0x9921e000 - 0x99256fff  com.apple.LDAPFramework (2.4.28 - 194.5) <0C42A932-15E8-3CD1-AC35-1DF7D41B25A2> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP
0x99257000 - 0x992a6fff  com.apple.opencl (2.3.57 - 2.3.57) <93385E1C-00D9-31BE-9652-7F3C09484B3E> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
0x992a7000 - 0x992e4ff7  libauto.dylib (185.5) <CD008E66-4A0C-35F5-8D72-80D76A716A03> /usr/lib/libauto.dylib
0x992e5000 - 0x992e6ffd  libunc.dylib (28) <22A126A1-DCFB-3BE5-A66B-C973F0A5D839> /usr/lib/system/libunc.dylib
0x992e7000 - 0x992eafff  libdyld.dylib (239.3) <729B32AC-EEE2-3739-8CE3-F90838D51906> /usr/lib/system/libdyld.dylib
0x99340000 - 0x9934bff6  com.apple.NetAuth (5.0 - 5.0) <3B2E9615-EE12-38FC-BDCF-09529FF9464B> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
0x993a8000 - 0x993b2fff  com.apple.bsd.ServiceManagement (2.0 - 2.0) <B84F3916-236A-347B-9C1F-3DE571496737> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
0x993b3000 - 0x997e7ff7  com.apple.vision.FaceCore (3.0.0 - 3.0.0) <5B12F3E9-84F6-3183-B85D-FD19EF800ADB> /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore
0x997e8000 - 0x997fafff  libsystem_asl.dylib (217.1.4) <51EB17C9-9F5B-39F3-B6CD-8EF238B05B89> /usr/lib/system/libsystem_asl.dylib
0x99896000 - 0x99898ffb  libRadiance.dylib (1038) <F0D3F13B-5628-3DF9-8B86-A4D914567B25> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x99a7f000 - 0x99a8dff7  libz.1.dylib (53) <858B4D9F-D87E-3D81-B07A-DF9632BD185F> /usr/lib/libz.1.dylib
0x9a92a000 - 0x9a956ff7  com.apple.DictionaryServices (1.2 - 208) <33873336-BECD-3F62-A315-C45F24C1818C> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
0x9a957000 - 0x9a982ff7  libsystem_network.dylib (241.3) <71EBA489-386D-3608-ADE6-CB50EBD1AB1B> /usr/lib/system/libsystem_network.dylib
0x9a983000 - 0x9a9e1ffd  com.apple.AE (665.5 - 665.5) <54F2F247-160C-3A22-A6E3-5D49655A67AB> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x9a9e7000 - 0x9ab49ff3  com.apple.CFNetwork (673.0.3 - 673.0.3) <5E0E9AE8-073B-3F2B-B0C7-A0129DE787F6> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
0x9ab4a000 - 0x9ab4cfff  libsystem_configuration.dylib (596.12) <1C31C3F6-568D-3854-AE03-A5DA2F39297E> /usr/lib/system/libsystem_configuration.dylib
0x9ab4d000 - 0x9ab78ff5  com.apple.ChunkingLibrary (2.0 - 155.1) <50BBBBF8-F30B-39EA-A512-11A47F429F2C> /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary
0x9ab79000 - 0x9ab82fff  com.apple.audio.SoundManager (4.1 - 4.1) <68B7CEB7-AF09-3E24-8548-6ABF065B5186> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound
0x9ab83000 - 0x9acd9ff0  libBLAS.dylib (1094.5) <74310C2F-4FDB-3995-A01A-5AFB83010A43> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x9acda000 - 0x9ace2ffe  libGFXShared.dylib (9.0.83) <35644AAA-B1E7-367C-90C0-378024F8A46A> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
0x9ace3000 - 0x9ad12fff  com.apple.framework.SystemAdministration (1.0 - 1.0) <05E81260-7DC7-3546-B45D-15B3E5DF056D> /System/Library/PrivateFrameworks/SystemAdministration.framework/Versions/A/SystemAdministration
0x9ad1b000 - 0x9ad1dff2  com.apple.EFILogin (2.0 - 2) <BC558029-74C0-3A69-B376-8F4CBF8C338F> /System/Library/PrivateFrameworks/EFILogin.framework/Versions/A/EFILogin
0x9ad1e000 - 0x9ad27fff  com.apple.DiskArbitration (2.6 - 2.6) <6379523D-3196-370C-AE4A-8EA586E36909> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x9ad28000 - 0x9ad35fff  com.apple.Librarian (1.2 - 1) <F85681E3-3398-327B-829B-1D8078C38C22> /System/Library/PrivateFrameworks/Librarian.framework/Versions/A/Librarian
0x9ad36000 - 0x9ae11ff7  com.apple.LaunchServices (572.23 - 572.23) <7E52FB5C-9ECF-3CB9-BF18-6652B8D8CDE0> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x9ae12000 - 0x9ae2fffb  libresolv.9.dylib (54) <3EC12A7F-6BA1-3976-9F1F-6A4B76303028> /usr/lib/libresolv.9.dylib
0x9ae30000 - 0x9b094fff  com.apple.CoreData (107 - 481) <F699EC21-57D9-3AE6-A17B-C1D1092780BD> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
0x9b0c1000 - 0x9bcdcff3  com.apple.AppKit (6.9 - 1265) <AE258D94-0272-394F-BBB7-9B5C165A4A78> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x9bcdd000 - 0x9be854af  libobjc.A.dylib (551.1) <31CBE178-E972-30D1-ADC6-4B8345CAE326> /usr/lib/libobjc.A.dylib
0x9bebc000 - 0x9becbfff  libGL.dylib (9.0.83) <E76D1F2A-D98B-3464-AD0B-FC1EBBADF027> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x9becc000 - 0x9bf35fff  com.apple.datadetectorscore (5.0 - 354.0) <0C6C812D-3E7A-31A4-BFDE-CD3316AA35B6> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
0x9bf36000 - 0x9c32eff3  com.apple.CoreGraphics (1.600.0 - 599.7) <DB004990-F06F-3768-AE4C-191B3C748EFC> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics

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

VM Region Summary:
ReadOnly portion of Libraries: Total=140.6M resident=69.2M(49%) swapped_out_or_unallocated=71.5M(51%)
Writable regions: Total=76.2M written=10.2M(13%) resident=20.2M(26%) swapped_out=0K(0%) unallocated=56.0M(74%)
 
REGION TYPE                      VIRTUAL
===========                      =======
CG backing stores                  3920K
CG image                            536K
CG raster data                       24K
CG shared images                    204K
CoreGraphics                          4K
CoreImage                             4K
CoreServices                        256K
Kernel Alloc Once                     4K
MALLOC                             45.2M
MALLOC (admin)                       48K
Memory Tag 242                       12K
OpenCL                                8K
Stack                              65.7M
VM_ALLOCATE                        16.5M
__DATA                             14.4M
__IMAGE                             528K
__LINKEDIT                         44.0M
__OBJC                             1880K
__PAGEZERO                            4K
__TEXT                             96.6M
__UNICODE                           544K
mapped file                       160.1M
shared memory                         4K
===========                      =======
TOTAL                             450.2M

Model: MacBookPro6,2, BootROM MBP61.0057.B0F, 2 processors, Intel Core i7, 2.8 GHz, 8 GB, SMC 1.58f17
Graphics: Intel HD Graphics, Intel HD Graphics, Built-In, 288 MB
Graphics: NVIDIA GeForce GT 330M, NVIDIA GeForce GT 330M, PCIe, 512 MB
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1067 MHz, 0x802C, 0x31364A53533531323634485A2D3147314131
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1067 MHz, 0x802C, 0x31364A53533531323634485A2D3147314131
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x93), Broadcom BCM43xx 1.0 (5.106.98.100.22)
Bluetooth: Version 4.2.0f6 12982, 3 services, 23 devices, 1 incoming serial ports
Network Service: Ethernet, Ethernet, en0
Network Service: Wi-Fi, AirPort, en1
Serial ATA Device: Hitachi HTS725050A9A362, 500,11 GB
Serial ATA Device: HL-DT-ST DVDRW  GS23N
USB Device: Hub
USB Device: External HDD
USB Device: Apple Internal Keyboard / Trackpad
USB Device: BRCM2070 Hub
USB Device: Bluetooth USB Host Controller
USB Device: Internal Memory Card Reader
USB Device: Hub
USB Device: Keyboard Hub
USB Device: Apple Keyboard
USB Device: Built-in iSight
USB Device: IR Receiver
Thunderbolt Bus: 


Thanks,
Regards,
Benny

----------
components: IDLE
messages: 206956
nosy: Benjamin.Eggerstedt
priority: normal
severity: normal
status: open
title: IDLE crashes on Unicode characters
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec 26 21:01:49 2013
From: report at bugs.python.org (Dolda2000)
Date: Thu, 26 Dec 2013 20:01:49 +0000
Subject: [New-bugs-announce] [issue20074] open() of read-write non-seekable
	streams broken
Message-ID: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>


New submission from Dolda2000:

It seems open() is slightly broken in Python 3, in that one cannot open non-seekable files in read-write mode. One such common use is open("/dev/tty", "r+") for interacting directly with the controlling TTY regardless of standard stream redirections. Note that this is a regression for Python 2, where this worked as expected.

What happens is the following:
>>> open("/dev/tty", "r+")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: File or stream is not seekable.

Just for the record, the same thing happens with "w+" and "rb+".

This also means that the getpass module is slightly broken, since it will always fail whenever stdin is redirected.

----------
components: IO
messages: 206957
nosy: Dolda2000
priority: normal
severity: normal
status: open
title: open() of read-write non-seekable streams broken
type: behavior
versions: Python 3.1, Python 3.3

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

From report at bugs.python.org  Thu Dec 26 21:35:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 20:35:20 +0000
Subject: [New-bugs-announce] [issue20075] help(open) eats first line
Message-ID: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The output of help(open) (and `pydoc open`) in 3.4 is:

Help on built-in function open in module io:

open(...)
    errors=None, newline=None, closefd=True, opener=None) -> file object
    
    Open file and return a stream.  Raise IOError upon failure.
...

In 3.3 and older it works correctly:

Help on built-in function open in module io:

open(...)
    open(file, mode='r', buffering=-1, encoding=None,
         errors=None, newline=None, closefd=True, opener=None) -> file object
    
    Open file and return a stream.  Raise IOError upon failure.
...

----------
components: Interpreter Core
keywords: 3.3regression
messages: 206962
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: help(open) eats first line
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Dec 27 00:29:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 23:29:08 +0000
Subject: [New-bugs-announce] [issue20076] Add UTF-8 locale aliases
Message-ID: <1388100548.94.0.295897364372.issue20076@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The makelocalealias.py ignores UTF-8 mapping. Expected that this encoding is available for all locales. After enabling UTF-8 mapping in makelocalealias.py most aliases are optimized out except following:

+    'be_bg.utf8':                           'bg_BG.UTF-8',
+    'c.utf8':                               'en_US.UTF-8',
+    'en_dl.utf8':                           'en_DL.UTF-8',
+    'en_zw.utf8':                           'en_ZS.UTF-8',
+    'ks_in at devanagari.utf8':                'ks_IN.UTF-8 at devanagari',
+    'pa_pk.utf8':                           'pa_PK.UTF-8',
+    'sd_in at devanagari.utf8':                'sd_IN.UTF-8 at devanagari',
+    'sr_yu.utf8':                           'sr_RS.UTF-8',
+    'sr_yu.utf8 at cyrillic':                  'sr_RS.UTF-8',
+    'te_in.utf8':                           'te_IN.UTF-8',
+    'zh_sg.utf8':                           'zh_SG.UTF-8',

Some of them maps to other country (en_zw.utf8 to en_ZS.UTF-8, sr_yu.utf8 to sr_RS.UTF-8) and these mappings are different from base mappings (en_zw to en_ZW.ISO8859-1, sr_yu to sr_RS.UTF-8 at latin). The devanagari mappings just maps illformed locales. c.utf8 is yet one special case. Other mappings have no base entity without encoding.

Here is a patch which enables UTF-8 mapping in makelocalealias.py and adds all these mappings to locale alias table.

----------
components: Library (Lib)
files: locale_utf8_aliases.patch
keywords: patch
messages: 206974
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add UTF-8 locale aliases
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33275/locale_utf8_aliases.patch

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

From report at bugs.python.org  Fri Dec 27 02:16:10 2013
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 27 Dec 2013 01:16:10 +0000
Subject: [New-bugs-announce] [issue20077] Format of TypeError differs
	between comparison and	arithmetic operators
Message-ID: <1388106970.8.0.6745803605.issue20077@psf.upfronthosting.co.za>


New submission from Mitchell Model:

[ctypes correct component for this?]

The TypeError messages given for incompatible types in comparison operators differ from incompatible types in arithmetic operators. The arithmetic operator error messages show the names of the types in single quotes, while the comparison error messages do not use quotes but follow the name of the type with a pair of parens. Seems like these should be analogous.

 class foo(): pass
... 
>>> foo() + 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'foo' and 'int'
>>> foo() < 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: foo() < int()

----------
components: ctypes
messages: 206977
nosy: MLModel
priority: normal
severity: normal
status: open
title: Format of TypeError differs between comparison and arithmetic operators
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec 27 03:11:20 2013
From: report at bugs.python.org (Nandiya)
Date: Fri, 27 Dec 2013 02:11:20 +0000
Subject: [New-bugs-announce] [issue20078] zipfile - ZipExtFile.read goes
	into 100% CPU infinite	loop on maliciously binary edited zips
Message-ID: <1388110280.6.0.508484621949.issue20078@psf.upfronthosting.co.za>


New submission from Nandiya:

I am using the zipfile module on a webserver which provides a service which processes files in zips uploaded by users, while hardening against zip bombs, I tried binary editing a zip to put in false file size information. The result is interesting, when with a ZIP_STORED file, or with carefully crafted ZIP_DEFLATED file (and perhaps ZIP_BZIP2 and ZIP_LZMA for craftier hackers than I), when the stated file size exceeds the size of the archive itself, ZipExtFile.read goes into an infinite loop, consuming 100% CPU.

The following methods on such an archive all result in an infinite loop:
ZipExtFile.read
ZipExtFile.read(n)
ZipExtFile.readlines
ZipFile.extract
ZipFile.extractall


ZipExtFile.read1 silently returns corrupt data but does not hang.

Obviously the module doesn't need to bend over backwards to deal gracefully with deliberately and maliciously crafted input, since all the user hopes for is to bring the program crashing down, but the 100% CPU infinite loop is probably one of the less satisfactory possible failure modes. It should either raise an exception or do something like read1 and silently return corrupt data.

This is low priority except for security since unless a zip is maliciously crafted some kind of exception will almost certainly be raised due to a decompression or invalid zip exception.

----------
components: IO, Library (Lib)
files: malzip.py
messages: 206978
nosy: nandiya
priority: normal
severity: normal
status: open
title: zipfile - ZipExtFile.read goes into 100% CPU infinite loop on maliciously binary edited zips
type: security
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file33277/malzip.py

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

From report at bugs.python.org  Fri Dec 27 11:12:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Dec 2013 10:12:27 +0000
Subject: [New-bugs-announce] [issue20079] Add support for glibc supported
	locales
Message-ID: <1388139147.62.0.637898307439.issue20079@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds to locale alias table the mappings for locales supported in recent glibc (v 2.18). It also modifies the makelocalealias.py script so that it parses the SUPPORTED file from glibc sources and supports command line options for source paths.

----------
components: Library (Lib)
files: locale_glibc_supported.patch
keywords: patch
messages: 206987
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add support for glibc supported locales
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33278/locale_glibc_supported.patch

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

From report at bugs.python.org  Fri Dec 27 11:56:02 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 27 Dec 2013 10:56:02 +0000
Subject: [New-bugs-announce] [issue20080] Unused variable in
	Lib/sqlite3/test/factory.py
Message-ID: <1388141762.46.0.0728784342465.issue20080@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

There is unused variable t in Lib/sqlite3/test/factory.py.

    def CheckSqliteRowAsTuple(self):
        """Checks if the row object can be converted to a tuple"""
        self.con.row_factory = sqlite.Row
        row = self.con.execute("select 1 as a, 2 as b").fetchone()
        t = tuple(row)

    def CheckSqliteRowAsDict(self):

Attached the patch to give the purpose to variable t.

----------
components: Tests
files: unused_variable_in_factory_py.patch
keywords: patch
messages: 206990
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Unused variable in Lib/sqlite3/test/factory.py
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33279/unused_variable_in_factory_py.patch

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

From report at bugs.python.org  Fri Dec 27 18:45:42 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 27 Dec 2013 17:45:42 +0000
Subject: [New-bugs-announce] [issue20081] sys.getwindowsversion does nto
	show some fields
Message-ID: <1388166342.38.0.63182866145.issue20081@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

On Windows 7:

>>> v = sys.getwindowsversion()
>>> v
sys.getwindowsversion(major=6, minor=1, build=7600, platform=2, service_pack='')
>>> v.service_pack_major
0
>>> v.service_pack_minor
0
>>> v.suite_mask
254

Doc states:

> For compatibility with prior versions, only the first 5 elements are retrievable by indexing.

...so I guess that's why service_pack_minor, service_pack_major and suite_mask fields are not shown.
Nevertheless I think this is a inconvenience which should be fixed, at least in the next major Python version.

----------
messages: 207005
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: sys.getwindowsversion does nto show some fields
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Dec 28 00:33:12 2013
From: report at bugs.python.org (Erik Bray)
Date: Fri, 27 Dec 2013 23:33:12 +0000
Subject: [New-bugs-announce] [issue20082] Misbehavior of
	BufferedRandom.write with raw file in	append mode
Message-ID: <1388187192.84.0.682821163597.issue20082@psf.upfronthosting.co.za>


New submission from Erik Bray:

In #18876 I pointed out the following issue:

BufferedWriter/Random doesn't know the raw file was opened with O_APPEND so the writes it shows in the buffer differ from what will actually end up in the file.  For example:

>>> f = open('test', 'wb')
>>> f.write(b'testest')
7
>>> f.close()
>>> f = open('test', 'ab+')
>>> f.tell()
7
>>> f.write(b'A')
1
>>> f.seek(0)
0
>>> f.read()
b'testestA'
>>> f.seek(0)
0
>>> f.read(1)
b't'
>>> f.write(b'B')
1
>>> f.seek(0)
0
>>> f.read()
b'tBstestA'
>>> f.flush()
>>> f.seek(0)
0
>>> f.read()
b'testestAB'

In this example, I read 1 byte from the beginning of the file, then write one byte.  Because of O_APPEND, the effect of the write() call on the raw file is to append, regardless of where BufferedWriter seeks it to first.  But before the f.flush() call f.read() just shows what's in the buffer which is not what will actually be written to the file.  (Naturally, unbuffered io does not have this particular problem.)


Now that #18876 we can test if a file was opened in append mode and correct for this.  The attach patch includes a pretty simple solution that manually calls buffered_seek at the beginning of bufferedwriter_write if the raw file is in append mode.  In doing so it made sense to split buffered_seek into two separate functions.

This might be overkill, however.

----------
components: IO
files: buffered-append-1.patch
keywords: patch
messages: 207015
nosy: erik.bray
priority: normal
severity: normal
status: open
title: Misbehavior of BufferedRandom.write with raw file in append mode
type: behavior
Added file: http://bugs.python.org/file33282/buffered-append-1.patch

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

From report at bugs.python.org  Sat Dec 28 02:49:23 2013
From: report at bugs.python.org (Freek Dijkstra)
Date: Sat, 28 Dec 2013 01:49:23 +0000
Subject: [New-bugs-announce] [issue20083] smtplib: support for IDN
	(international domain names)
Message-ID: <1388195363.36.0.929515660511.issue20083@psf.upfronthosting.co.za>


New submission from Freek Dijkstra:

smtplib has limited support for non-ASCII domain names in the From to To mail address. It only works for punycode-encoded domain names, submitted as unicode string (e.g. server.rcpt(u"user at xn--e1afmkfd.ru").

The following two calls fail:

server.rcpt(u"user@??????.ru"):
  File smtplib.py, line 332, in send
    s = s.encode("ascii")
UnicodeEncodeError: 'ascii' codec can't encode character '\u03c0' in position 19: ordinal not in range(128)
http://hg.python.org/cpython/file/3.3/Lib/smtplib.py#l332

server.rcpt(b"user at xn--e1afmkfd.ru"):
  File email/_parseaddr.py, line 236, in gotonext
    if self.field[self.pos] in self.LWS + '\n\r':
TypeError: 'in <string>' requires string as left operand, not int
http://hg.python.org/cpython/file/3.3/Lib/email/_parseaddr.py#l236

There are three ways to solve this (from trivial to complex):
* Make it clear in the documentation what type of input is expected.
* Accept punycode-encoded domain names in email addresses, either in string or binary format.
* Accept Unicode-encoded domain names, and do the punycode encoding in the smtplib if required.

See also 

References:
https://tools.ietf.org/html/rfc5891: Internationalized Domain Names in Applications (IDNA): Protocol

----------
components: Library (Lib)
messages: 207017
nosy: macfreek
priority: normal
severity: normal
status: open
title: smtplib: support for IDN (international domain names)
type: enhancement

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

From report at bugs.python.org  Sat Dec 28 02:51:55 2013
From: report at bugs.python.org (Freek Dijkstra)
Date: Sat, 28 Dec 2013 01:51:55 +0000
Subject: [New-bugs-announce] [issue20084] smtplib: support for UTF-8 encoded
	headers (SMTPUTF8)
Message-ID: <1388195515.33.0.10832843598.issue20084@psf.upfronthosting.co.za>


New submission from Freek Dijkstra:

smtplib has no support for non-ASCII user names in the From to To mail address.

The following two calls fail:

server.rcpt(u"?????@example.com"):
  File smtplib.py, line 332, in send
    s = s.encode("ascii")
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-4: ordinal not in range(128)
http://hg.python.org/cpython/file/3.3/Lib/smtplib.py#l332

server.rcpt(b'\xcf\x8c\xce\xbd\xce\xbf\xce\xbc\xce\xb1 at example.com'):
  File email/_parseaddr.py, line 236, in gotonext
    if self.field[self.pos] in self.LWS + '\n\r':
TypeError: 'in <string>' requires string as left operand, not int
http://hg.python.org/cpython/file/3.3/Lib/email/_parseaddr.py#l236

There are two ways to solve this:
* Allow users of smptlib to support internationalised email by passing already encoded headers and email addresses. The users is responsible for the encoding and setting the SMTPUTF8 ESMTP option.
* Accept Unicode-encoded email addresses, and convert that to UTF-8 in the library. smtplib is responsible for the encoding and setting the SMTPUTF8 ESMTP option.

References:
https://tools.ietf.org/html/rfc6531: SMTP Extension for Internationalized Email

See also Issue20083, which deals with international domain names in email addresses (the part behind the "@"). This issue deals with the part before the "@".

Note that this is different from RFC 2047, which merely allows non-ASCII encoding in text values in the headers (such as the name of a recipient or the mail subject).

----------
components: Library (Lib)
messages: 207018
nosy: macfreek
priority: normal
severity: normal
status: open
title: smtplib: support for UTF-8 encoded headers (SMTPUTF8)
type: enhancement

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

From report at bugs.python.org  Sat Dec 28 04:01:32 2013
From: report at bugs.python.org (stubz)
Date: Sat, 28 Dec 2013 03:01:32 +0000
Subject: [New-bugs-announce] [issue20085] Python2.7, wxPython and IDLE 2.7
Message-ID: <1388199692.1.0.186486001282.issue20085@psf.upfronthosting.co.za>


New submission from stubz:

I new to this so I have no idea what's going on ...
I'm using Mint 16 Cinnamon and apparently Python 2.7+ 3.3 are installed
I started puttering with wxPython 2.8 and I have issues ...

I started a tutorial, saved some work.py and got things to run, I guess ...

When I try to open and edit a work.py file I get a blank window ... ?

I also lose my number pad, auto indents and can't close that blank window, I basically have to show down the computer to get it to go away ...

I don't know if this is Mint, Python, IDLE or me, but it's annoying ...

Can anyone giving me an idea as to what's going on ?

----------
messages: 207021
nosy: stubz
priority: normal
severity: normal
status: open
title: Python2.7, wxPython and IDLE 2.7
type: behavior

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

From report at bugs.python.org  Sat Dec 28 10:00:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Dec 2013 09:00:19 +0000
Subject: [New-bugs-announce] [issue20086] test_locale fails on PPC64
	PowerLinux
Message-ID: <1388221219.09.0.925570468901.issue20086@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

See http://buildbot.python.org/all/builders/PPC64%20PowerLinux%202.7/builds/396/steps/test/logs/stdio.

======================================================================
ERROR: test_getsetlocale_issue1813 (test.test_locale.TestMiscellaneous)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/2.7.edelsohn-powerlinux-ppc64/build/Lib/test/test_locale.py", line 480, in test_getsetlocale_issue1813
    locale.setlocale(locale.LC_CTYPE, loc)
  File "/home/shager/cpython-buildarea/2.7.edelsohn-powerlinux-ppc64/build/Lib/locale.py", line 579, in setlocale
    return _setlocale(category, locale)
Error: unsupported locale setting

----------------------------------------------------------------------

----------
components: Library (Lib), Tests
messages: 207024
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_locale fails on PPC64 PowerLinux
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Dec 28 10:29:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Dec 2013 09:29:49 +0000
Subject: [New-bugs-announce] [issue20087] Mismatch between glibc and X11
	locale.alias
Message-ID: <1388222989.89.0.773650778168.issue20087@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The locale module uses locale alias table derived from X11 locale.alias file for mapping bare locale names without encodings to locale names with encodings. However sometimes glibc default encoding for a locale differs from that used in X11 locale.alias.

Here is full differences table:

                 GLibc                 X11 locale.alias

az_az            az_AZ.UTF-8           az_AZ.ISO8859-9E
ca_ad            ca_AD.ISO8859-15      ca_AD.ISO8859-1
ca_fr            ca_FR.ISO8859-15      ca_FR.ISO8859-1
ca_it            ca_IT.ISO8859-15      ca_IT.ISO8859-1
cy_gb            cy_GB.ISO8859-14      cy_GB.ISO8859-1
en_in            en_IN.UTF-8           en_IN.ISO8859-1
et_ee            et_EE.ISO8859-1       et_EE.ISO8859-15
fi_fi            fi_FI.ISO8859-1       fi_FI.ISO8859-15
gd_gb            gd_GB.ISO8859-15      gd_GB.ISO8859-1
hi_in            hi_IN.UTF-8           hi_IN.ISCII-DEV
iu_ca            iu_CA.UTF-8           iu_CA.NUNACOM-8
iw_il            iw_IL.ISO8859-8       he_IL.ISO8859-8
ka_ge            ka_GE.GEORGIAN_PS     ka_GE.GEORGIAN-ACADEMY
lo_la            lo_LA.UTF-8           lo_LA.MULELAO-1
mi_nz            mi_NZ.ISO8859-13      mi_NZ.ISO8859-1
nr_za            nr_ZA.UTF-8           nr_ZA.ISO8859-1
nso_za           nso_ZA.UTF-8          nso_ZA.ISO8859-15
ru_ru            ru_RU.ISO8859-5       ru_RU.UTF-8
rw_rw            rw_RW.UTF-8           rw_RW.ISO8859-1
sq_al            sq_AL.ISO8859-1       sq_AL.ISO8859-2
ss_za            ss_ZA.UTF-8           ss_ZA.ISO8859-1
ta_in            ta_IN.UTF-8           ta_IN.TSCII-0
tg_tj            tg_TJ.KOI8_T          tg_TJ.KOI8-C
th_th            th_TH.TIS_620         th_TH.ISO8859-11
tn_za            tn_ZA.UTF-8           tn_ZA.ISO8859-15
ts_za            ts_ZA.UTF-8           ts_ZA.ISO8859-1
tt_ru            tt_RU.UTF-8           tt_RU.TATAR-CYR
ur_pk            ur_PK.UTF-8           ur_PK.CP1256
uz_uz            uz_UZ.ISO8859-1       uz_UZ.UTF-8
uz_uz at cyrillic   uz_UZ.UTF-8 at cyrillic  uz_UZ.UTF-8
vi_vn            vi_VN.UTF-8           vi_VN.TCVN
zh_cn            zh_CN.GB2312          zh_CN.gb2312
zh_tw            zh_TW.BIG5            zh_TW.big5
zh_tw.euctw      zh_TW.EUC_TW          zh_TW.eucTW

For example with the en_IN encoding:

>>> import locale, _locale
>>> _locale.setlocale(locale.LC_CTYPE)
'en_IN'
>>> locale.getlocale()
('en_IN', 'ISO8859-1')
>>> locale.nl_langinfo(locale.CODESET)
'UTF-8'
>>> locale.setlocale(locale.LC_CTYPE, locale.getlocale())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/locale.py", line 592, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

----------
components: Library (Lib)
messages: 207025
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Mismatch between glibc and X11 locale.alias
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Dec 28 10:44:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Dec 2013 09:44:02 +0000
Subject: [New-bugs-announce] [issue20088] locale.getlocale() fails if locale
	name doesn't include	encoding
Message-ID: <1388223842.98.0.521951916148.issue20088@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import locale, _locale
>>> _locale.setlocale(locale.LC_CTYPE, 'en_AG')
'en_AG'
>>> _locale.setlocale(locale.LC_CTYPE)
'en_AG'
>>> locale.getlocale(locale.LC_CTYPE)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/locale.py", line 575, in getlocale
    return _parse_localename(localename)
  File "/home/serhiy/py/cpython/Lib/locale.py", line 484, in _parse_localename
    raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: en_AG

One solution is proposed in issue20079: map all supported in glibc locale names without encoding to locale names with encoding. But see issue20087. And default encoding can be different on other systems (not based on glibc).

Other solution is not guess an encoding, but use locale.nl_langinfo(locale.CODESET) in locale.getlocale(). And left in locale alias table only nonstandard mappings (such as english_uk -> en_GB.ISO8859-1 and sr_yu.iso88595 -> sr_CS.ISO8859-5).

----------
components: Library (Lib)
messages: 207026
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: locale.getlocale() fails if locale name doesn't include encoding
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Dec 28 15:09:03 2013
From: report at bugs.python.org (Florian Apolloner)
Date: Sat, 28 Dec 2013 14:09:03 +0000
Subject: [New-bugs-announce] [issue20089] email.message_from_string no
	longer working in Python 3.4
Message-ID: <1388239743.81.0.886859790367.issue20089@psf.upfronthosting.co.za>


New submission from Florian Apolloner:

Given this email:
---
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: =?utf-8?q?Ch=C3=A8re_maman?=
From: from at example.com
To: to at example.com
Date: Sat, 28 Dec 2013 13:08:07 -0000
Message-ID: <20131228130807.3669.79195 at localhost>

Je t'aime tr?s fort
---

I get this traceback:
---
  File "/home/florian/sources/cpython/Lib/email/__init__.py", line 40, in message_from_string
    return Parser(*args, **kws).parsestr(s)
  File "/home/florian/sources/cpython/Lib/email/parser.py", line 70, in parsestr
    return self.parse(StringIO(text), headersonly=headersonly)
  File "/home/florian/sources/cpython/Lib/email/parser.py", line 60, in parse
    return feedparser.close()
  File "/home/florian/sources/cpython/Lib/email/feedparser.py", line 170, in close
    self._call_parse()
  File "/home/florian/sources/cpython/Lib/email/feedparser.py", line 163, in _call_parse
    self._parse()
  File "/home/florian/sources/cpython/Lib/email/feedparser.py", line 449, in _parsegen
    self._cur.set_payload(EMPTYSTRING.join(lines))
  File "/home/florian/sources/cpython/Lib/email/message.py", line 311, in set_payload
    " payload") from None
TypeError: charset argument must be specified when non-ASCII characters are used in the payload
---

This is new in 3.4 since that's the first version which requires set_payload to provide a charset argument, imo message_from_string should figure that out from the message.

----------
messages: 207028
nosy: apollo13
priority: normal
severity: normal
status: open
title: email.message_from_string no longer working in Python 3.4

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

From report at bugs.python.org  Sat Dec 28 16:14:34 2013
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 28 Dec 2013 15:14:34 +0000
Subject: [New-bugs-announce] [issue20090] slight ambiguity in README.txt
	instructions for building	docs
Message-ID: <1388243674.59.0.297728620179.issue20090@psf.upfronthosting.co.za>


New submission from Mitchell Model:

I tried to build the docs for v3.4.0b1 following the instructions in the Doc/README.txt. My default python is v3.3. I got the following error message:
"Error: Sphinx needs to be executed with Python 2.4 or newer (not 3.0 though)."
I wondered what was weird about 3.0 as opposed to later versions that it wouldn't work. Fortunately I had run into other situations where tools expected Python 2 but wouldn't work with Python 3, so after a few minutes of head scratching I tried using Python 2, whi

Sphinx needs to be executed with Python 2 (v. 2.4 or newer), not Python 3

 so that it makes clear that it requires Python 2 not Python 3 and puts the grammatical emphasis where it belongs.

More importantly, perhaps, the Doc README should be changed to state that make must use Python 2.

----------
assignee: docs at python
components: Build, Documentation
messages: 207029
nosy: MLModel, docs at python
priority: normal
severity: normal
status: open
title: slight ambiguity in README.txt instructions for building docs
versions: Python 3.4

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

From report at bugs.python.org  Sat Dec 28 16:17:22 2013
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 28 Dec 2013 15:17:22 +0000
Subject: [New-bugs-announce] [issue20091] An index entery for __main__ in
	"30.5 runpy" is missing
Message-ID: <1388243842.91.0.578293707742.issue20091@psf.upfronthosting.co.za>


New submission from Mitchell Model:

An index entry should be added for __main__ as it appears in the documentation of runpy (30.5 in 3.3, 31.5 in 3.4).

----------
assignee: docs at python
components: Documentation
messages: 207030
nosy: MLModel, docs at python
priority: normal
severity: normal
status: open
title: An index entery for __main__ in "30.5 runpy" is missing
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Dec 28 20:56:32 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 28 Dec 2013 19:56:32 +0000
Subject: [New-bugs-announce] [issue20092] type() constructor should bind
	__int__ to __index__ when	__index__ is defined and __int__ is not
Message-ID: <1388260592.79.0.323683192221.issue20092@psf.upfronthosting.co.za>


New submission from Ethan Furman:

In order to create a coherent integer type class both __int__ and __index__ must be defined or the resulting instances will behave inconsistently in different places.

For example, if __index__ is not defined then the class cannot be used in slices, and if __int__ is not defined then int(integer_type) will fail.

At this point the programmer must remember to define both, but since they should return the same value we can have the type constructor automatically assign __int__ to __index__ when the latter is defined and the former is not.  This would be similar to how we currently treat __ne__ when __eq__ is defined.

----------
messages: 207048
nosy: ethan.furman
priority: low
severity: normal
status: open
title: type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Dec 29 01:50:27 2013
From: report at bugs.python.org (Jason Gerard DeRose)
Date: Sun, 29 Dec 2013 00:50:27 +0000
Subject: [New-bugs-announce] [issue20093] Wrong OSError message from
	os.rename() when dst is a	non-empty directory
Message-ID: <1388278227.56.0.603151192526.issue20093@psf.upfronthosting.co.za>


New submission from Jason Gerard DeRose:

Under Python 3.3, if renaming a directory with `os.rename()` when the destination is an existing, non-empty directory, like this:

os.rename('/tmp/foo', '/tmp/bar')

You'll get an OSError with a message like this:

OSError: [Errno 39] Directory not empty: '/tmp/bar'

However, in the current Python 3.4.0b1 package in Ubuntu Trusty, this error message will contain the source directory name instead of the destination directory name, like this:

OSError: [Errno 39] Directory not empty: '/tmp/foo'

I've attached a test case, which also covers renaming directories relative to an open directory descriptor. This test case works on Python 3.3, fails on Python 3.4 Beta1.

----------
components: Library (Lib)
files: test_os_rename.py
messages: 207058
nosy: jderose
priority: normal
severity: normal
status: open
title: Wrong OSError message from os.rename() when dst is a non-empty directory
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33285/test_os_rename.py

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

From report at bugs.python.org  Sun Dec 29 17:46:38 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 29 Dec 2013 16:46:38 +0000
Subject: [New-bugs-announce] [issue20094] intermitent failures with test_dbm
Message-ID: <1388335598.36.0.994619281921.issue20094@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Following errors occur about half the time:

======================================================================
ERROR: test_anydbm_creation (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ethan/source/python/issue19995/Lib/test/test_dbm.py", line 75, in test_anydbm_creation
    self.read_helper(f)
  File "/home/ethan/source/python/issue19995/Lib/test/test_dbm.py", line 117, in read_helper
    self.assertEqual(self._dict[key], f[key.encode("ascii")])
KeyError: b'0'

======================================================================
ERROR: test_anydbm_modification (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ethan/source/python/issue19995/Lib/test/test_dbm.py", line 90, in test_anydbm_modification
    self.read_helper(f)
  File "/home/ethan/source/python/issue19995/Lib/test/test_dbm.py", line 117, in read_helper
    self.assertEqual(self._dict[key], f[key.encode("ascii")])
KeyError: b'0'

======================================================================
ERROR: test_anydbm_read (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ethan/source/python/issue19995/Lib/test/test_dbm.py", line 96, in test_anydbm_read
    self.read_helper(f)
  File "/home/ethan/source/python/issue19995/Lib/test/test_dbm.py", line 117, in read_helper
    self.assertEqual(self._dict[key], f[key.encode("ascii")])
KeyError: b'0'

----------
messages: 207079
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: intermitent failures with test_dbm
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec 30 11:18:22 2013
From: report at bugs.python.org (Liam Marsh)
Date: Mon, 30 Dec 2013 10:18:22 +0000
Subject: [New-bugs-announce] [issue20095] what is that result!?
Message-ID: <1388398702.19.0.462802956175.issue20095@psf.upfronthosting.co.za>


New submission from Liam Marsh:

when does 3*0.1 make 0.30000000000000004 ?
YES it is the same program!

----------
components: Regular Expressions
messages: 207092
nosy: Liam.Marsh, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: what is that result!?
versions: Python 3.3

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

From report at bugs.python.org  Mon Dec 30 20:43:50 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Dec 2013 19:43:50 +0000
Subject: [New-bugs-announce] [issue20096] Mention modernize and future in
	Python 2/3 porting HOWTO
Message-ID: <1388432630.2.0.0690952057164.issue20096@psf.upfronthosting.co.za>


New submission from Brett Cannon:

https://github.com/mitsuhiko/python-modernize
http://python-future.org/

Should also restructure to de-emphasize 2to3 and other approaches. In all honesty it should probably be nearly gutted to just "here are examples of how to write Python 2/3 compatible code", point to appropriate libraries, and be done with it with a minimal mention of 2to3 and 3to2.

----------
assignee: docs at python
components: Documentation
messages: 207103
nosy: brett.cannon, docs at python
priority: normal
severity: normal
status: open
title: Mention modernize and future in Python 2/3 porting HOWTO
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec 30 21:26:42 2013
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 30 Dec 2013 20:26:42 +0000
Subject: [New-bugs-announce] [issue20097] Bad use of `self` in importlib
Message-ID: <1388435202.0.0.988564041108.issue20097@psf.upfronthosting.co.za>


New submission from Ram Rachum:

There's a bad usage of `self` here:

    http://hg.python.org/cpython/file/fd846837492d/Lib/importlib/_bootstrap.py#l1431

`self` isn't defined because it's a class method.

----------
components: Library (Lib)
messages: 207105
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Bad use of `self` in importlib
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec 31 00:35:17 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Dec 2013 23:35:17 +0000
Subject: [New-bugs-announce] [issue20098] email policy needs a mangle_from
	setting
Message-ID: <1388446517.27.0.863185292033.issue20098@psf.upfronthosting.co.za>


New submission from R. David Murray:

I missed this.  It still defaults to True in Generator.  It should default to False in the new policies (but True in compat32).

----------
components: email
keywords: easy
messages: 207116
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: email policy needs a mangle_from setting
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Dec 31 16:18:51 2013
From: report at bugs.python.org (Liam Marsh)
Date: Tue, 31 Dec 2013 15:18:51 +0000
Subject: [New-bugs-announce] [issue20099] a new idea
Message-ID: <1388503131.58.0.100306022546.issue20099@psf.upfronthosting.co.za>


New submission from Liam Marsh:

idea:
var():
input var name (str),
outputs var value
useful for(example in a chess program):

>>>count=1
>>>while count<=8:
...    var('a', count)='black queen'
...    count=count+1

----------
messages: 207118
nosy: Liam.Marsh
priority: normal
severity: normal
status: open
title: a new idea
versions: Python 3.3

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

From report at bugs.python.org  Tue Dec 31 16:58:14 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 Dec 2013 15:58:14 +0000
Subject: [New-bugs-announce] [issue20100] epoll docs are not clear with
	regards to CLOEXEC.
Message-ID: <1388505494.08.0.643576998185.issue20100@psf.upfronthosting.co.za>


New submission from R. David Murray:

http://docs.python.org/dev/library/select.html#select.epoll documents the EPOLL_CLOEXEC flag as something you can specify that makes the file descriptor be closed on exec.  But then it goes on to say that the file descriptor is non-inheritable.  So is the flag useless and should be removed from the docs, or is the documentation just unclear as to its purpose?  Or, conversely, do we need a way to say that the file descriptor should *not* be closed on exec?

----------
assignee: docs at python
components: Documentation
messages: 207121
nosy: docs at python, haypo, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: epoll docs are not clear with regards to CLOEXEC.
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec 31 22:42:32 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 31 Dec 2013 21:42:32 +0000
Subject: [New-bugs-announce] [issue20101] Determine correct behavior for
	time functions on Windows
Message-ID: <1388526152.52.0.960629914987.issue20101@psf.upfronthosting.co.za>


New submission from Zachary Ware:

For previous discussion, see issue19999.

To summarize, time on Windows is far from straight-forward, and currently for

"""
t1 = time.monotonic()
time.sleep(0.5)
t2 = time.monotonic()
dt = t2-t1
"""

dt may end up as very slightly smaller than 0.5 (0.4990000003017485 or so), 0.5, or somewhat larger than 0.5 (0.5150000001303852 or so); or 0.5 almost all of the time, depending on the machine in question.  So far, two very different Win7 machines of mine both produced the first result, and Tim Peters' Vista machine produced the second.  Both of mine report the resolution as 0.015600099999999999, Tim's reports 0.015625.

See also http://stackoverflow.com/questions/7685762/windows-7-timing-functions-how-to-use-getsystemtimeadjustment-correctly and http://www.windowstimestamp.com/description for more related reading.

Due to the issue, test_monotonic regularly fails for me.  A simple workaround is to relax the lower bound of 0.5 <= dt <= 1.0 to 0.45; I intend to commit that workaround soon, but it won't close this issue.

In preparation for creating this issue I also checked the other time functions (time, clock, and perf_counter) for the same issue, and on my test machine all of them have it (although it is apparently intermittent for time (earlier I got straight failures, now it won't fail), and clock and perf_counter are implemented by the same underlying function).

Here is some output from my machine, formatted slightly for nicer presentation:

3.4.0b1 (default:fd846837492d+, Dec 30 2013, 11:01:01) [MSC v.1600 32 bit (Intel)]
Windows-7-6.1.7601-SP1
Running:
"""
import time
import sys
import platform
print(sys.version)
print(platform.platform())

with open(__file__) as file:
    print('Running:\n"""')
    print(file.read())
    print('"""')

clock_info = {}

for time_func in (time.monotonic, time.time, time.clock, time.perf_counter):
    name = time_func.__name__
    info = str(time.get_clock_info(name))
    print(name, info)
    if info in clock_info:
        print('Same clock as time.{}'.format(clock_info[info]))
        continue
    else:
        clock_info[info] = name
    good = 0
    values = {}
    count = 0
    try:
        while count < 25:
            # basic test copied from test_monotonic, extras bolted on
            t1 = time_func()
            time.sleep(0.5)
            t2 = time_func()
            dt = t2 - t1
            if values.get(dt):
                values[dt] += 1
            else:
                values[dt] = 1
            assert t2 > t1
            passed = 0.5 <= dt <= 1.0
            print('.' if passed else 'F', end='', flush=True)
            if passed:
                good += 1
            count += 1
    except KeyboardInterrupt:
        pass

    print()
    print('total:', count,
          'good:', good,
          'bad:', count - good)
    print(sorted(values.items()))
    print()

"""
monotonic namespace(adjustable=False, implementation='GetTickCount64()', monotonic=True, resolution=0.015600099999999999)
FF.FFFF.FFF.FF.FFF.FFFF.F
total: 25 good: 6 bad: 19
[(0.4989999998360872, 13), (0.4990000003017485, 6), (0.5, 5), (0.5150000001303852, 1)]

time namespace(adjustable=True, implementation='GetSystemTimeAsFileTime()', monotonic=False, resolution=0.015600099999999999)
.........................
total: 25 good: 25 bad: 0
[(0.5, 25)]

clock namespace(adjustable=False, implementation='QueryPerformanceCounter()', monotonic=True, resolution=2.851518034140655e-07)
.FFFFFFFFFFFFFFFFFF.FFFFF
total: 25 good: 2 bad: 23
[(0.49929681565278194, 1), (0.49941258728496685, 1), (0.4995377689266647,  1),
(0.4995543077312634,   1), (0.49955459288306736, 1), (0.4995597256155282,  1),
(0.4995602959191352,   1), (0.4995659989552035,  1), (0.4995679950178271,  1),
(0.49956970592864813,  1), (0.4995748386611094,  1), (0.499581967456195,   1),
(0.4995956547427589,   1), (0.49961304900276726, 1), (0.49961761143162153, 1),
(0.49961846688703204,  1), (0.49962445507490294, 1), (0.499629017503759,   1),
(0.4996355759952369,   1), (0.4996401384240914,  1), (0.49964042357589467, 1),
(0.4996486929781927,   1), (0.4996555366214759,  1), (0.5000139724383673,  1),
(0.5036356854935278,   1)]

perf_counter namespace(adjustable=False, implementation='QueryPerformanceCounter()', monotonic=True, resolution=2.851518034140655e-07)
Same clock as time.clock


And here's results from time.time earlier today (produced by an earlier version of the above script, same machine and interpreter):

time
FFFFFFFFFFFFFFFFFFFFFF.FF
total: 25 good: 1 bad: 24
[(0.49969983100891113, 7), (0.49970006942749023, 17), (0.5006990432739258, 1)]

----------
components: Extension Modules, Windows
messages: 207125
nosy: haypo, tim.peters, zach.ware
priority: normal
severity: normal
status: open
title: Determine correct behavior for time functions on Windows
type: behavior
versions: Python 3.3, Python 3.4

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