From report at bugs.python.org  Fri Jul  1 07:25:23 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 01 Jul 2011 05:25:23 +0000
Subject: [New-bugs-announce] [issue12456] Hangs in concurrent.futures
In-Reply-To: <1309497923.23.0.957560996312.issue12456@psf.upfronthosting.co.za>
Message-ID: <1309497923.23.0.957560996312.issue12456@psf.upfronthosting.co.za>


New submission from Ross Lagerwall <rosslagerwall at gmail.com>:

6d6099f7fe89 introduced a regression.

It causes the following code to hang fairly reliably for me:
"""
import concurrent.futures
import math

def is_prime(n):
    print(sqt(81))  <---- Note the type error!

def main():
    with concurrent.futures.ProcessPoolExecutor(2) as executor:
        executor.map(is_prime, [1, 2])

if __name__ == '__main__':
    main()
"""

>From my limited knowledge of multiprocessing and concurrent futures, it seems that in shutdown_worker(), call_queue.put(None) hangs because the queue is full and there are no more workers consuming items in the queue (they exited early).

Increasing EXTRA_QUEUED_CALLS fixes the problem, though its probably not the correct solution.

----------
components: Library (Lib)
messages: 139541
nosy: pitrou, rosslagerwall
priority: normal
severity: normal
status: open
title: Hangs in concurrent.futures
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  1 07:25:40 2011
From: report at bugs.python.org (Peter Williams)
Date: Fri, 01 Jul 2011 05:25:40 +0000
Subject: [New-bugs-announce] [issue12457] type() returns incorrect type for
	nested classes
In-Reply-To: <1309497940.68.0.603392922196.issue12457@psf.upfronthosting.co.za>
Message-ID: <1309497940.68.0.603392922196.issue12457@psf.upfronthosting.co.za>


New submission from Peter Williams <pwil3058 at bigpond.net.au>:

The built in type() function returns incorrect type names for nested classes which in turn causes pickle to crash when used with nested classes as it cannot find the nested class definitions from the using the string returned by type().

e.g. if I have an instance "inner" of class Inner which is defined inside (nested in) the class Outer:

type(inner) returns <class '__main__.Inner'> instead of <class '__main__.Outer.Inner'>

The isinstance() function, as expected, returns True for isinstance(inner, Outer.Inner) and raises a NameError exception for isinstance(inner, Inner).

However, isinstance(inner, type(inner)) returns True which indicates the core functionality is OK and this conforms to the fact that no problems were encountered until I tried to pickle an object containing nested classes.

My system is Fedora 15 x86_64 and Python versions are 2.7.1 and 3.2.

A short program illustrating the problem is attached.

----------
components: None
files: nested_class_bug.py
messages: 139542
nosy: pwil3058
priority: normal
severity: normal
status: open
title: type() returns incorrect type for nested classes
type: crash
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22531/nested_class_bug.py

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

From report at bugs.python.org  Fri Jul  1 07:46:47 2011
From: report at bugs.python.org (Petr Splichal)
Date: Fri, 01 Jul 2011 05:46:47 +0000
Subject: [New-bugs-announce] [issue12458] Tracebacks should contain the
	first line of continuation	lines
In-Reply-To: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za>
Message-ID: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za>


New submission from Petr Splichal <psssssss at gmail.com>:

Currently, python tracebacks shows the last of continuation lines
when a function spans across multiple lines. This line usually
contains some function parameter only and thus is not very useful
for debugging the problem.

For example:

    Traceback (most recent call last):
    File "./tcms-run", line 48, in <module>
        summary=options.summary)
    File "/tmp/nitrate/Nitrate.py", line 600, in __init__
        raise NitrateError("Need either id or test plan")

If the traceback contained the beginning of the continuation line
it would be IMHO much more clear where/how the problem happened.

    Traceback (most recent call last):
    File "./tcms-run", line 48, in <module>
        run = TestRun(plan=plan, distro=options.distro,
    File "/tmp/nitrate/Nitrate.py", line 600, in __init__
        raise NitrateError("Need either id or test plan")

Version: Both Python 2 and Python 3.

Trivial reproducer:

    def fun1(par):
        raise Exception
    def fun2():
        fun1(
                par="value")
    fun2()

Actual results:

    Traceback (most recent call last):
    File "/tmp/traceback.py", line 10, in <module>
        fun2()
    File "/tmp/traceback.py", line 8, in fun2
        par="value")
    File "/tmp/traceback.py", line 4, in fun1
        raise Exception
    Exception

----------
components: Interpreter Core
messages: 139544
nosy: psss
priority: normal
severity: normal
status: open
title: Tracebacks should contain the first line of continuation lines
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul  1 08:45:50 2011
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Fri, 01 Jul 2011 06:45:50 +0000
Subject: [New-bugs-announce] [issue12459] time.sleep(-1.0) behaviour
In-Reply-To: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>
Message-ID: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

For reference, see the thread on the users' mailinglist/newsgroup from 2011-06-29 "how to call a function for evry 10 seconds" and the thread on the developers' mailinglist from 2011-06-30 "time.sleep(-1) behaviour".

The problem is how negative arguments to time.sleep() are handled. Python 2.x (tested 2.5 and 2.7) implementations on MS Windows seems to have a 32-bit underflow while converting the given argument to the DWORD that is passed to win32's Sleep() function. This causes a small negative value to sleep for a long time.

On Linux, using Python 2.6, you get an IOError instead. While an error is better than blocking effectively forever, the use of an IOError to signal the wrong argument is at least confusing. I guess it is an artifact of the implementation, but that shouldn't be visible prominently.

IMHH, both versions should raise a ValueError to signal invalid arguments. However, there was also the suggestion to simply treat negative values as zero, after all time.sleep() is already documented to possibly sleep longer than specified.

----------
messages: 139548
nosy: eckhardt
priority: normal
severity: normal
status: open
title: time.sleep(-1.0) behaviour
type: behavior

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

From report at bugs.python.org  Fri Jul  1 11:31:28 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 01 Jul 2011 09:31:28 +0000
Subject: [New-bugs-announce] [issue12460] SocketServer.shutdown() does not
	have "timeout=None"	parameter
In-Reply-To: <1309512688.11.0.74406934883.issue12460@psf.upfronthosting.co.za>
Message-ID: <1309512688.11.0.74406934883.issue12460@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

Suppose i'm trying to correctly terminate thread with socketserver during application termination.

I do not want to wait too long (also do not want to hang), I want to protect against long-lived operations in SimpleServer

so something like
myserver.shutdown(2)
will be nice.

Also it should return True or False depending on successfull shutting down.

It's easy to implement - thanks to Threading.event.wait(timeout=...)

Don't know if it is applicable to python 3.x

----------
components: Library (Lib)
messages: 139557
nosy: mmarkk
priority: normal
severity: normal
status: open
title: SocketServer.shutdown() does not have "timeout=None" parameter
type: feature request
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Jul  1 11:42:38 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 01 Jul 2011 09:42:38 +0000
Subject: [New-bugs-announce] [issue12461] it's not clear how the
	shutil.copystat() should work on	symlinks
In-Reply-To: <1309513358.23.0.446931887968.issue12461@psf.upfronthosting.co.za>
Message-ID: <1309513358.23.0.446931887968.issue12461@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

According to
http://hg.python.org/cpython/file/588fe0fc7160/Lib/shutil.py

it uses utimes(), stat() ans so on,
For some people, it's preferable to use lutimes() and lstat(),but for some people it's not.

For example, in old implementation, exception will raise on broken symlink during os.utime().

Also, copystat() does not check that chown can not be applied to a symlink.

I do not think that it's good to add two parameters like
shutil.copystat(src, dst, followsrc, followdst)

Adding just one parameter (followsymlinks) is not sufficient.

----------
components: Library (Lib)
messages: 139561
nosy: mmarkk
priority: normal
severity: normal
status: open
title: it's not clear how the shutil.copystat() should work on symlinks
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul  1 12:25:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 10:25:06 +0000
Subject: [New-bugs-announce] [issue12462] time.sleep(1): call
	PyErr_CheckSignals() if the sleep	was interrupted
In-Reply-To: <1309515906.33.0.927447956049.issue12462@psf.upfronthosting.co.za>
Message-ID: <1309515906.33.0.927447956049.issue12462@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

While reading floatsleep() (time.sleep) code for issue #12459, I noticed that the Python signal handler is not called in floatsleep() if a signal interrupted the sleep. Well, it just "works" because the bytecode evaluation loop will call PyErr_CheckSignals() before executing the next instruction (the C signal handler signals calls Py_AddPendingCall whichs signals that the pending call to the eval loop using "eval_breaker"), but it would be better to call it directly.

Attached calls explicitly and immediatly PyErr_CheckSignals() in the sleep and Windows implementations of floatsleep().

It's not really a bug, so I prefer to not touch Python 2.7 and 3.2, only Python 3.3.

----------
components: Library (Lib)
files: sleep_signal.patch
keywords: patch
messages: 139562
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: time.sleep(1): call PyErr_CheckSignals() if the sleep was interrupted
versions: Python 3.3
Added file: http://bugs.python.org/file22534/sleep_signal.patch

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

From report at bugs.python.org  Fri Jul  1 12:46:38 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 01 Jul 2011 10:46:38 +0000
Subject: [New-bugs-announce] [issue12463] Calling SocketServer.shutdown()
	when server_forever()	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

Why not to call self.__is_shut_down.set() in constructor ?

In reality, if event loop was not started, it mean that server is shut down.

----------
components: Library (Lib)
messages: 139565
nosy: mmarkk
priority: normal
severity: normal
status: open
title: Calling SocketServer.shutdown() when server_forever() was not called will hang
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jul  1 14:30:45 2011
From: report at bugs.python.org (Evgeny Kapun)
Date: Fri, 01 Jul 2011 12:30:45 +0000
Subject: [New-bugs-announce] [issue12464]
	tempfile.TemporaryDirectory.cleanup follows symbolic	links
In-Reply-To: <1309523445.96.0.359988980171.issue12464@psf.upfronthosting.co.za>
Message-ID: <1309523445.96.0.359988980171.issue12464@psf.upfronthosting.co.za>


New submission from Evgeny Kapun <abacabadabacaba at gmail.com>:

TemporaryDirectory.cleanup follows symbolic links to directories and tries to clean them as well. Try this (on Linux):

import os, tempfile
with tempfile.TemporaryDirectory() as d:
	os.symlink("/proc", d + "/test")

----------
components: Library (Lib)
messages: 139571
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: tempfile.TemporaryDirectory.cleanup follows symbolic links
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul  1 14:43:55 2011
From: report at bugs.python.org (Evgeny Kapun)
Date: Fri, 01 Jul 2011 12:43:55 +0000
Subject: [New-bugs-announce] [issue12465] gc.get_referents can be used to
	crash Python
In-Reply-To: <1309524235.61.0.692133767187.issue12465@psf.upfronthosting.co.za>
Message-ID: <1309524235.61.0.692133767187.issue12465@psf.upfronthosting.co.za>


New submission from Evgeny Kapun <abacabadabacaba at gmail.com>:

This code crashes Python:

import gc
gc.get_referents(object.__dict__)[0].clear()
gc.get_referents(type.__dict__)[0].clear()
type("A", (), {})()

----------
components: Interpreter Core
messages: 139572
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: gc.get_referents can be used to crash Python
type: crash
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Jul  1 14:56:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 12:56:22 +0000
Subject: [New-bugs-announce] [issue12466] test_subprocess.test_close_fds()
	sporadic failures on	Mac OS X Tiger
In-Reply-To: <1309524982.22.0.267480095279.issue12466@psf.upfronthosting.co.za>
Message-ID: <1309524982.22.0.267480095279.issue12466@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

======================================================================
FAIL: test_close_fds (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_subprocess.py", line 1302, in test_close_fds
    "Some fds were left open")
AssertionError: {9} is not false : Some fds were left open

http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/2825/steps/test/logs/stdio

test_pass_fds() is already skipped on Mac OS X Tiger because of an OS bug: see issue #12230.

----------
messages: 139575
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: test_subprocess.test_close_fds() sporadic failures on Mac OS X Tiger

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

From report at bugs.python.org  Fri Jul  1 15:21:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 13:21:23 +0000
Subject: [New-bugs-announce] [issue12467]
	test_threading.test_6_daemon_threads(): Assertion	failed:
	PyUnicode_Check(*filename), file ..\Python\_warnings.c, line 501
In-Reply-To: <1309526483.44.0.248959975063.issue12467@psf.upfronthosting.co.za>
Message-ID: <1309526483.44.0.248959975063.issue12467@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

======================================================================
FAIL: test_6_daemon_threads (test.test_threading.ThreadJoinOnShutdown)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_threading.py", line 677, in test_6_daemon_threads
    rc, out, err = assert_python_ok('-c', script)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\script_helper.py", line 50, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\script_helper.py", line 42, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 3, stderr follows:

Assertion failed: PyUnicode_Check(*filename), file ..\Python\_warnings.c, line 501

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4881/steps/test/logs/stdio

----------
components: Library (Lib), Tests, Windows
messages: 139577
nosy: haypo
priority: normal
severity: normal
status: open
title: test_threading.test_6_daemon_threads(): Assertion failed: PyUnicode_Check(*filename), file ..\Python\_warnings.c, line 501
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  1 19:34:08 2011
From: report at bugs.python.org (Kiril Mikos)
Date: Fri, 01 Jul 2011 17:34:08 +0000
Subject: [New-bugs-announce] [issue12468] longjmp causes uninitialized stack
	frame
In-Reply-To: <1309541648.47.0.579386081097.issue12468@psf.upfronthosting.co.za>
Message-ID: <1309541648.47.0.579386081097.issue12468@psf.upfronthosting.co.za>


New submission from Kiril Mikos <kiril.mik.os at gmail.com>:

*** longjmp causes uninitialized stack frame ***: /usr/bin/python2.7 terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f2415de61d7]
/lib/x86_64-linux-gnu/libc.so.6(+0xfe169)[0x7f2415de6169]
/lib/x86_64-linux-gnu/libc.so.6(__longjmp_chk+0x33)[0x7f2415de60d3]
/usr/lib/libcurl-gnutls.so.4(+0xbb45)[0x7f241528bb45]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfc60)[0x7f2416f11c60]
/lib/x86_64-linux-gnu/libpthread.so.0(sem_wait+0x30)[0x7f2416f0fea0]
/usr/bin/python2.7(PyThread_acquire_lock+0x11)[0x4aed31]
/usr/bin/python2.7[0x4afd3e]
/usr/bin/python2.7(PyEval_EvalFrameEx+0x361)[0x4965f1]
/usr/bin/python2.7(PyEval_EvalCodeEx+0x145)[0x49d325]
/usr/bin/python2.7(PyEval_EvalFrameEx+0x802)[0x496a92]
/usr/bin/python2.7(PyEval_EvalCodeEx+0x145)[0x49d325]
/usr/bin/python2.7(PyEval_EvalFrameEx+0x802)[0x496a92]
/usr/bin/python2.7(PyEval_EvalCodeEx+0x145)[0x49d325]
/usr/bin/python2.7[0x4c4526]
/usr/bin/python2.7(PyObject_Call+0x44)[0x45d864]
/usr/bin/python2.7[0x45f43f]
/usr/bin/python2.7[0x45b8ff]
/usr/bin/python2.7(PyObject_CallMethod+0xa8)[0x4c7e68]
/usr/bin/python2.7(Py_Finalize+0x4a)[0x42cf19]
/usr/bin/python2.7(Py_Main+0xb5d)[0x418d32]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xff)[0x7f2415d06eff]
/usr/bin/python2.7[0x4c62b1]
======= Memory map: ========
00400000-0062f000 r-xp 00000000 08:13 524506                             /usr/bin/python2.7
0082e000-0082f000 r--p 0022e000 08:13 524506                             /usr/bin/python2.7
0082f000-00897000 rw-p 0022f000 08:13 524506                             /usr/bin/python2.7
00897000-008a9000 rw-p 00000000 00:00 0 
02243000-024f3000 rw-p 00000000 00:00 0                                  [heap]
7f2408ffa000-7f2408ffb000 ---p 00000000 00:00 0 
7f2408ffb000-7f24097fb000 rw-p 00000000 00:00 0 
7f24097fb000-7f24097fc000 ---p 00000000 00:00 0 
7f24097fc000-7f2409ffc000 rw-p 00000000 00:00 0 
7f2409ffc000-7f2409ffd000 ---p 00000000 00:00 0 
7f2409ffd000-7f240a7fd000 rw-p 00000000 00:00 0 
7f240a7fd000-7f240a7fe000 ---p 00000000 00:00 0 
7f240a7fe000-7f240affe000 rw-p 00000000 00:00 0 
7f240affe000-7f240afff000 ---p 00000000 00:00 0 
7f240afff000-7f240b7ff000 rw-p 00000000 00:00 0 
7f240b7ff000-7f240b800000 ---p 00000000 00:00 0 
7f240b800000-7f240c000000 rw-p 00000000 00:00 0 
7f240c000000-7f240c047000 rw-p 00000000 00:00 0 
7f240c047000-7f2410000000 ---p 00000000 00:00 0 
7f24100fb000-7f2410110000 r-xp 00000000 08:13 1317460                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f2410110000-7f241030f000 ---p 00015000 08:13 1317460                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f241030f000-7f2410310000 r--p 00014000 08:13 1317460                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f2410310000-7f2410311000 rw-p 00015000 08:13 1317460                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f2410311000-7f2410352000 rw-p 00000000 00:00 0 
7f2410352000-7f2410353000 ---p 00000000 00:00 0 
7f2410353000-7f2410b53000 rw-p 00000000 00:00 0 
7f2410b53000-7f2410b54000 ---p 00000000 00:00 0 
7f2410b54000-7f2411354000 rw-p 00000000 00:00 0 
7f2411354000-7f2411355000 ---p 00000000 00:00 0 
7f2411355000-7f2411b55000 rw-p 00000000 00:00 0 
7f2411b55000-7f2411b56000 ---p 00000000 00:00 0 
7f2411b56000-7f2412458000 rw-p 00000000 00:00 0 
7f2412458000-7f241247f000 r-xp 00000000 08:13 1317525                    /lib/x86_64-linux-gnu/libexpat.so.1.5.2
7f241247f000-7f241267f000 ---p 00027000 08:13 1317525                    /lib/x86_64-linux-gnu/libexpat.so.1.5.2
7f241267f000-7f2412681000 r--p 00027000 08:13 1317525                    /lib/x86_64-linux-gnu/libexpat.so.1.5.2
7f2412681000-7f2412682000 rw-p 00029000 08:13 1317525                    /lib/x86_64-linux-gnu/libexpat.so.1.5.2
7f2412682000-7f2412691000 r-xp 00000000 08:13 538071                     /usr/lib/python2.7/lib-dynload/pyexpat.so
7f2412691000-7f2412890000 ---p 0000f000 08:13 538071                     /usr/lib/python2.7/lib-dynload/pyexpat.so
7f2412890000-7f2412891000 r--p 0000e000 08:13 538071                     /usr/lib/python2.7/lib-dynload/pyexpat.so
7f2412891000-7f2412893000 rw-p 0000f000 08:13 538071                     /usr/lib/python2.7/lib-dynload/pyexpat.so
7f2412893000-7f24128a6000 r-xp 00000000 08:13 538046                     /usr/lib/python2.7/lib-dynload/datetime.so
7f24128a6000-7f2412aa6000 ---p 00013000 08:13 538046                     /usr/lib/python2.7/lib-dynload/datetime.so
7f2412aa6000-7f2412aa7000 r--p 00013000 08:13 538046                     /usr/lib/python2.7/lib-dynload/datetime.so
7f2412aa7000-7f2412aab000 rw-p 00014000 08:13 538046                     /usr/lib/python2.7/lib-dynload/datetime.so
7f2412aab000-7f2412aec000 rw-p 00000000 00:00 0 
7f2412aec000-7f2412b09000 r-xp 00000000 08:13 538049                     /usr/lib/python2.7/lib-dynload/_io.so
7f2412b09000-7f2412d08000 ---p 0001d000 08:13 538049                     /usr/lib/python2.7/lib-dynload/_io.so
7f2412d08000-7f2412d09000 r--p 0001c000 08:13 538049                     /usr/lib/python2.7/lib-dynload/_io.so
7f2412d09000-7f2412d12000 rw-p 0001d000 08:13 538049                     /usr/lib/python2.7/lib-dynload/_io.so
7f2412d12000-7f2412d53000 rw-p 00000000 00:00 0 
7f2412d53000-7f2412d56000 r-xp 00000000 08:13 538048                     /usr/lib/python2.7/lib-dynload/_heapq.so
7f2412d56000-7f2412f55000 ---p 00003000 08:13 538048                     /usr/lib/python2.7/lib-dynload/_heapq.so
7f2412f55000-7f2412f56000 r--p 00002000 08:13 538048                     /usr/lib/python2.7/lib-dynload/_heapq.so
7f2412f56000-7f2412f58000 rw-p 00003000 08:13 538048                     /usr/lib/python2.7/lib-dynload/_heapq.so
7f2412f58000-7f2412f67000 r-xp 00000000 08:13 527185                     /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.9
7f2412f67000-7f2413167000 ---p 0000f000 08:13 527185                     /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.9
7f2413167000-7f2413168000 r--p 0000f000 08:13 527185                     /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.9
7f2413168000-7f2413169000 rw-p 00010000 08:13 527185                     /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.9
7f2413169000-7f241316b000 r-xp 00000000 08:13 1320416                    /lib/x86_64-linux-gnu/libkeyutils.so.1.3
7f241316b000-7f241336a000 ---p 00002000 08:13 1320416                    /lib/x86_64-linux-gnu/libkeyutils.so.1.3
7f241336a000-7f241336b000 r--p 00001000 08:13 1320416                    /lib/x86_64-linux-gnu/libkeyutils.so.1.3
7f241336b000-7f241336c000 rw-p 00002000 08:13 1320416                    /lib/x86_64-linux-gnu/libkeyutils.so.1.3
7f241336c000-7f2413373000 r-xp 00000000 08:13 526951                     /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f2413373000-7f2413572000 ---p 00007000 08:13 526951                     /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f2413572000-7f2413573000 r--p 00006000 08:13 526951                     /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f2413573000-7f2413574000 rw-p 00007000 08:13 526951                     /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f2413574000-7f2413577000 r-xp 00000000 08:13 1320411                    /lib/x86_64-linux-gnu/libcom_err.so.2.1
7f2413577000-7f2413776000 ---p 00003000 08:13 1320411                    /lib/x86_64-linux-gnu/libcom_err.so.2.1
7f2413776000-7f2413777000 r--p 00002000 08:13 1320411                    /lib/x86_64-linux-gnu/libcom_err.so.2.1
7f2413777000-7f2413778000 rw-p 00003000 08:13 1320411                    /lib/x86_64-linux-gnu/libcom_err.so.2.1
7f2413778000-7f241379d000 r-xp 00000000 08:13 527485                     /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1
7f241379d000-7f241399d000 ---p 00025000 08:13 527485                     /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1
7f241399d000-7f241399e000 r--p 00025000 08:13 527485                     /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1
7f241399e000-7f241399f000 rw-p 00026000 08:13 527485                     /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1
7f241399f000-7f2413a59000 r-xp 00000000 08:13 527489                     /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3
7f2413a59000-7f2413c59000 ---p 000ba000 08:13 527489                     /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3
7f2413c59000-7f2413c62000 r--p 000ba000 08:13 527489                     /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3
7f2413c62000-7f2413c63000 rw-p 000c3000 08:13 527489                     /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3
7f2413c63000-7f2413c7c000 r-xp 00000000 08:13 533107                     /usr/lib/libsasl2.so.2.0.23
7f2413c7c000-7f2413e7b000 ---p 00019000 08:13 533107                     /usr/lib/libsasl2.so.2.0.23
7f2413e7b000-7f2413e7c000 r--p 00018000 08:13 533107                     /usr/lib/libsasl2.so.2.0.23
7f2413e7c000-7f2413e7d000 rw-p 00019000 08:13 533107                     /usr/lib/libsasl2.so.2.0.23
7f2413e7d000-7f2413e94000 r-xp 00000000 08:13 1317029                    /lib/x86_64-linux-gnu/libresolv-2.13.so
7f2413e94000-7f2414094000 ---p 00017000 08:13 1317029                    /lib/x86_64-linux-gnu/libresolv-2.13.so
7f2414094000-7f2414095000 r--p 00017000 08:13 1317029                    /lib/x86_64-linux-gnu/libresolv-2.13.so
7f2414095000-7f2414096000 rw-p 00018000 08:13 1317029                    /lib/x86_64-linux-gnu/libresolv-2.13.so
7f2414096000-7f2414098000 rw-p 00000000 00:00 0 
7f2414098000-7f241409b000 r-xp 00000000 08:13 1320378                    /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7f241409b000-7f241429a000 ---p 00003000 08:13 1320378                    /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7f241429a000-7f241429b000 r--p 00002000 08:13 1320378                    /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7f241429b000-7f241429c000 rw-p 00003000 08:13 1320378                    /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7f241429c000-7f2414336000 r-xp 00000000 08:13 527680                     /usr/lib/x86_64-linux-gnu/libgnutls.so.26.14.12
7f2414336000-7f2414536000 ---p 0009a000 08:13 527680                     /usr/lib/x86_64-linux-gnu/libgnutls.so.26.14.12
7f2414536000-7f241453c000 r--p 0009a000 08:13 527680                     /usr/lib/x86_64-linux-gnu/libgnutls.so.26.14.12
7f241453c000-7f241453d000 rw-p 000a0000 08:13 527680                     /usr/lib/x86_64-linux-gnu/libgnutls.so.26.14.12
7f241453d000-7f2414570000 r-xp 00000000 08:13 527487                     /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2
7f2414570000-7f2414770000 ---p 00033000 08:13 527487                     /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2
7f2414770000-7f2414771000 r--p 00033000 08:13 527487                     /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2
7f2414771000-7f2414772000 rw-p 00034000 08:13 527487                     /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2
7f2414772000-7f2414779000 r-xp 00000000 08:13 1317030                    /lib/x86_64-linux-gnu/librt-2.13.so
7f2414779000-7f2414978000 ---p 00007000 08:13 1317030                    /lib/x86_64-linux-gnu/librt-2.13.so
7f2414978000-7f2414979000 r--p 00006000 08:13 1317030                    /lib/x86_64-linux-gnu/librt-2.13.so
7f2414979000-7f241497a000 rw-p 00007000 08:13 1317030                    /lib/x86_64-linux-gnu/librt-2.13.so
7f241497a000-7f24149c1000 r-xp 00000000 08:13 527911                     /usr/lib/libldap_r-2.4.so.2.5.6
7f24149c1000-7f2414bc0000 ---p 00047000 08:13 527911                     /usr/lib/libldap_r-2.4.so.2.5.6
7f2414bc0000-7f2414bc2000 r--p 00046000 08:13 527911                     /usr/lib/libldap_r-2.4.so.2.5.6
7f2414bc2000-7f2414bc3000 rw-p 00048000 08:13 527911                     /usr/lib/libldap_r-2.4.so.2.5.6
7f2414bc3000-7f2414bc5000 rw-p 00000000 00:00 0 
7f2414bc5000-7f2414bd2000 r-xp 00000000 08:13 533112                     /usr/lib/liblber-2.4.so.2.5.6
7f2414bd2000-7f2414dd1000 ---p 0000d000 08:13 533112                     /usr/lib/liblber-2.4.so.2.5.6
7f2414dd1000-7f2414dd2000 r--p 0000c000 08:13 533112                     /usr/lib/liblber-2.4.so.2.5.6
7f2414dd2000-7f2414dd3000 rw-p 0000d000 08:13 533112                     /usr/lib/liblber-2.4.so.2.5.6
7f2414dd3000-7f2414e04000 r-xp 00000000 08:13 524380                     /usr/lib/libidn.so.11.6.1
7f2414e04000-7f2415004000 ---p 00031000 08:13 524380                     /usr/lib/libidn.so.11.6.1
7f2415004000-7f2415005000 r--p 00031000 08:13 524380                     /usr/lib/libidn.so.11.6.1
7f2415005000-7f2415006000 rw-p 00032000 08:13 524380                     /usr/lib/libidn.so.11.6.1
7f2415006000-7f241507c000 r-xp 00000000 08:13 1320380                    /lib/x86_64-linux-gnu/libgcrypt.so.11.6.0
7f241507c000-7f241527c000 ---p 00076000 08:13 1320380                    /lib/x86_64-linux-gnu/libgcrypt.so.11.6.0
7f241527c000-7f241527d000 r--p 00076000 08:13 1320380                    /lib/x86_64-linux-gnu/libgcrypt.so.11.6.0
7f241527d000-7f2415280000 rw-p 00077000 08:13 1320380                    /lib/x86_64-linux-gnu/libgcrypt.so.11.6.0
7f2415280000-7f24152d2000 r-xp 00000000 08:13 530086                     /usr/lib/libcurl-gnutls.so.4.2.0
7f24152d2000-7f24154d1000 ---p 00052000 08:13 530086                     /usr/lib/libcurl-gnutls.so.4.2.0
7f24154d1000-7f24154d3000 r--p 00051000 08:13 530086                     /usr/lib/libcurl-gnutls.so.4.2.0
7f24154d3000-7f24154d4000 rw-p 00053000 08:13 530086                     /usr/lib/libcurl-gnutls.so.4.2.0
7f24154d4000-7f24154e3000 r-xp 00000000 08:13 1189747                    /usr/lib/pyshared/python2.7/pycurl.so
7f24154e3000-7f24156e2000 ---p 0000f000 08:13 1189747                    /usr/lib/pyshared/python2.7/pycurl.so
7f24156e2000-7f24156e3000 r--p 0000e000 08:13 1189747                    /usr/lib/pyshared/python2.7/pycurl.so
7f24156e3000-7f24156e5000 rw-p 0000f000 08:13 1189747                    /usr/lib/pyshared/python2.7/pycurl.so
7f24156e5000-7f2415ae2000 r--p 00000000 08:13 524688                     /usr/lib/locale/locale-archive
7f2415ae2000-7f2415ae6000 r-xp 00000000 08:13 538064                     /usr/lib/python2.7/lib-dynload/termios.so
7f2415ae6000-7f2415ce5000 ---p 00004000 08:13 538064                     /usr/lib/python2.7/lib-dynload/termios.so
7f2415ce5000-7f2415ce6000 r--p 00003000 08:13 538064                     /usr/lib/python2.7/lib-dynload/termios.so
7f2415ce6000-7f2415ce8000 rw-p 00004000 08:13 538064                     /usr/lib/python2.7/lib-dynload/termios.so
7f2415ce8000-7f2415e72000 r-xp 00000000 08:13 1317014                    /lib/x86_64-linux-gnu/libc-2.13.so
7f2415e72000-7f2416071000 ---p 0018a000 08:13 1317014                    /lib/x86_64-linux-gnu/libc-2.13.so
7f2416071000-7f2416075000 r--p 00189000 08:13 1317014                    /lib/x86_64-linux-gnu/libc-2.13.so
7f2416075000-7f2416076000 rw-p 0018d000 08:13 1317014                    /lib/x86_64-linux-gnu/libc-2.13.so
7f2416076000-7f241607c000 rw-p 00000000 00:00 0 
7f241607c000-7f2416100000 r-xp 00000000 08:13 1317018                    /lib/x86_64-linux-gnu/libm-2.13.so
7f2416100000-7f24162ff000 ---p 00084000 08:13 1317018                    /lib/x86_64-linux-gnu/libm-2.13.so
7f24162ff000-7f2416300000 r--p 00083000 08:13 1317018                    /lib/x86_64-linux-gnu/libm-2.13.so
7f2416300000-7f2416301000 rw-p 00084000 08:13 1317018                    /lib/x86_64-linux-gnu/libm-2.13.so
7f2416301000-7f2416318000 r-xp 00000000 08:13 1317381                    /lib/x86_64-linux-gnu/libz.so.1.2.3.4
7f2416318000-7f2416517000 ---p 00017000 08:13 1317381                    /lib/x86_64-linux-gnu/libz.so.1.2.3.4
7f2416517000-7f2416518000 r--p 00016000 08:13 1317381                    /lib/x86_64-linux-gnu/libz.so.1.2.3.4
7f2416518000-7f2416519000 rw-p 00017000 08:13 1317381                    /lib/x86_64-linux-gnu/libz.so.1.2.3.4
7f2416519000-7f241667f000 r-xp 00000000 08:13 922820                     /lib/libcrypto.so.0.9.8
7f241667f000-7f241687f000 ---p 00166000 08:13 922820                     /lib/libcrypto.so.0.9.8
7f241687f000-7f241688c000 r--p 00166000 08:13 922820                     /lib/libcrypto.so.0.9.8
7f241688c000-7f24168a5000 rw-p 00173000 08:13 922820                     /lib/libcrypto.so.0.9.8
7f24168a5000-7f24168a8000 rw-p 00000000 00:00 0 
7f24168a8000-7f24168f4000 r-xp 00000000 08:13 922821                     /lib/libssl.so.0.9.8
7f24168f4000-7f2416af4000 ---p 0004c000 08:13 922821                     /lib/libssl.so.0.9.8
7f2416af4000-7f2416af5000 r--p 0004c000 08:13 922821                     /lib/libssl.so.0.9.8
7f2416af5000-7f2416afb000 rw-p 0004d000 08:13 922821                     /lib/libssl.so.0.9.8
7f2416afb000-7f2416afd000 r-xp 00000000 08:13 1317033                    /lib/x86_64-linux-gnu/libutil-2.13.so
7f2416afd000-7f2416cfc000 ---p 00002000 08:13 1317033                    /lib/x86_64-linux-gnu/libutil-2.13.so
7f2416cfc000-7f2416cfd000 r--p 00001000 08:13 1317033                    /lib/x86_64-linux-gnu/libutil-2.13.so
7f2416cfd000-7f2416cfe000 rw-p 00002000 08:13 1317033                    /lib/x86_64-linux-gnu/libutil-2.13.so
7f2416cfe000-7f2416d00000 r-xp 00000000 08:13 1317017                    /lib/x86_64-linux-gnu/libdl-2.13.so
7f2416d00000-7f2416f00000 ---p 00002000 08:13 1317017                    /lib/x86_64-linux-gnu/libdl-2.13.so
7f2416f00000-7f2416f01000 r--p 00002000 08:13 1317017                    /lib/x86_64-linux-gnu/libdl-2.13.so
7f2416f01000-7f2416f02000 rw-p 00003000 08:13 1317017                    /lib/x86_64-linux-gnu/libdl-2.13.so
7f2416f02000-7f2416f1a000 r-xp 00000000 08:13 1317028                    /lib/x86_64-linux-gnu/libpthread-2.13.so
7f2416f1a000-7f241711a000 ---p 00018000 08:13 1317028                    /lib/x86_64-linux-gnu/libpthread-2.13.so
7f241711a000-7f241711b000 r--p 00018000 08:13 1317028                    /lib/x86_64-linux-gnu/libpthread-2.13.so
7f241711b000-7f241711c000 rw-p 00019000 08:13 1317028                    /lib/x86_64-linux-gnu/libpthread-2.13.so
7f241711c000-7f2417120000 rw-p 00000000 00:00 0 
7f2417120000-7f2417141000 r-xp 00000000 08:13 1317011                    /lib/x86_64-linux-gnu/ld-2.13.so
7f241715d000-7f2417261000 rw-p 00000000 00:00 0 
7f2417293000-7f241731a000 rw-p 00000000 00:00 0 
7f2417339000-7f241733a000 rw-p 00000000 00:00 0 
7f241733c000-7f2417340000 rw-p 00000000 00:00 0 
7f2417340000-7f2417341000 r--p 00020000 08:13 1317011                    /lib/x86_64-linux-gnu/ld-2.13.so
7f2417341000-7f2417343000 rw-p 00021000 08:13 1317011                    /lib/x86_64-linux-gnu/ld-2.13.so
7fff510e6000-7fff51107000 rw-p 00000000 00:00 0                          [stack]
7fff511ff000-7fff51200000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

Modules used:
import pycurl
import os
import ConfigParser
import re
import xmlrpclib
import urllib2
import Queue
import threading

----------
components: Interpreter Core
messages: 139590
nosy: mik_os
priority: normal
severity: normal
status: open
title: longjmp causes uninitialized stack frame
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul  1 21:28:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 19:28:16 +0000
Subject: [New-bugs-announce] [issue12469] test_faulthandler failures on
	FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_faulthandler fails on the FreeBSD 6 buildbot since my commit 024827a9db64990865d29f9d525694f51197e770:

Issue #12392: fix thread initialization on FreeBSD 6

On FreeBSD6, pthread_kill() doesn't work on the main thread before the creation
of the first thread. Create therefore a dummy thread (no-op) a startup to
initialize the pthread library.

Add also a test for this use case, test written by Charles-Fran?ois Natali.

----------
components: Library (Lib)
messages: 139595
nosy: haypo
priority: normal
severity: normal
status: open
title: test_faulthandler failures on FreeBSD 6
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  1 23:02:33 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 01 Jul 2011 21:02:33 +0000
Subject: [New-bugs-announce] [issue12470] Fix cut&paste typo in test_shutil
In-Reply-To: <1309554153.12.0.611513852686.issue12470@psf.upfronthosting.co.za>
Message-ID: <1309554153.12.0.611513852686.issue12470@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

There is a cut & paste typo in test_shutil file, this patch fixes it.

----------
components: Tests
files: shutil_tests_cut_paste_typo.patch
keywords: patch
messages: 139606
nosy: sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Fix cut&paste typo in test_shutil
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22541/shutil_tests_cut_paste_typo.patch

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

From report at bugs.python.org  Fri Jul  1 23:05:18 2011
From: report at bugs.python.org (Renaud Blanch)
Date: Fri, 01 Jul 2011 21:05:18 +0000
Subject: [New-bugs-announce] [issue12471] wrong TypeError message on '%i'
	formatting
In-Reply-To: <1309554318.72.0.913120070593.issue12471@psf.upfronthosting.co.za>
Message-ID: <1309554318.72.0.913120070593.issue12471@psf.upfronthosting.co.za>


New submission from Renaud Blanch <rndblnch at gmail.com>:

The TypeError message is erroneous when attempting to format a non number object with a '%i' string (notice the '%d' in the error message):

    >>> '%i' % 's'
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: %d format: a number is required, not str

This is because PyUnicode_Format aliases i to d for the formatting handling, but this has the side effect of performing the substitution in the error message too.

The attached patch (against 3.3, but this behaviour has been there since 2.6) suppress the side effect and corrects the error message.

----------
components: Interpreter Core
files: PyUnicode_Format_TypeError_message.patch
keywords: patch
messages: 139607
nosy: rndblnch
priority: normal
severity: normal
status: open
title: wrong TypeError message on '%i' formatting
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file22542/PyUnicode_Format_TypeError_message.patch

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

From report at bugs.python.org  Fri Jul  1 23:29:46 2011
From: report at bugs.python.org (kais58)
Date: Fri, 01 Jul 2011 21:29:46 +0000
Subject: [New-bugs-announce] [issue12472] Build failure on IRIX
In-Reply-To: <1309555786.28.0.894707521073.issue12472@psf.upfronthosting.co.za>
Message-ID: <1309555786.28.0.894707521073.issue12472@psf.upfronthosting.co.za>


New submission from kais58 <kais58 at sucs.org>:

I'm trying to build Python 2.7.2 on IRIX 6.5.30 and get the attached error in ./Modules/signalmodule.c

----------
components: None
files: error.txt
messages: 139609
nosy: kais58
priority: normal
severity: normal
status: open
title: Build failure on IRIX
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file22543/error.txt

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

From report at bugs.python.org  Sat Jul  2 09:21:10 2011
From: report at bugs.python.org (HaiYun Yan)
Date: Sat, 02 Jul 2011 07:21:10 +0000
Subject: [New-bugs-announce] [issue12473] factory func of
	collections.defaultdict should receive	the "missing key" as
	args when called.
In-Reply-To: <1309591270.02.0.438510682407.issue12473@psf.upfronthosting.co.za>
Message-ID: <1309591270.02.0.438510682407.issue12473@psf.upfronthosting.co.za>


New submission from HaiYun Yan <lyricconch at gmail.com>:

for example:

def calc(params):
    """ i am factoring numbers. """
    # an expensive CPU cost function but 
    # passin params and return result are both lightweight

cachedcalc = collections.defaultdict(calc)
result = cachedcalc[0xFFFFFFFFFFFFFFFFFFF0AC0FFF1]

----------
components: Library (Lib)
messages: 139624
nosy: lyricconch
priority: normal
severity: normal
status: open
title: factory func of collections.defaultdict should receive the "missing key" as args when called.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Jul  2 13:43:15 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 02 Jul 2011 11:43:15 +0000
Subject: [New-bugs-announce] [issue12474] Invalid read in symtable.c
In-Reply-To: <1309606995.45.0.154486187515.issue12474@psf.upfronthosting.co.za>
Message-ID: <1309606995.45.0.154486187515.issue12474@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

After 151142c0c5b1 Valgrind finds an invalid read in symtable.c, line 907:

  st->st_cur = (PySTEntryObject *)PyList_GET_ITEM(st->st_stack, size - 2);


==14301== Memcheck, a memory error detector
==14301== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==14301== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==14301== Command: ./python
==14301== 
==14301== Invalid read of size 8
==14301==    at 0x4A1B30: symtable_exit_block (symtable.c:907)
==14301==    by 0x49FFA3: PySymtable_Build (symtable.c:276)
==14301==    by 0x473B42: PyAST_CompileEx (compile.c:295)
==14301==    by 0x49E37D: run_mod (pythonrun.c:1790)
==14301==    by 0x49E10E: PyRun_StringFlags (pythonrun.c:1727)
==14301==    by 0x45EBFB: builtin_exec (bltinmodule.c:818)
==14301==    by 0x54E2FF: PyCFunction_Call (methodobject.c:81)
==14301==    by 0x471B4C: call_function (ceval.c:3957)
==14301==    by 0x46D482: PyEval_EvalFrameEx (ceval.c:2663)
==14301==    by 0x470060: PyEval_EvalCodeEx (ceval.c:3393)
==14301==    by 0x47208A: fast_function (ceval.c:4055)
==14301==    by 0x471C9F: call_function (ceval.c:3978)
==14301==  Address 0x691df18 is 8 bytes before a block of size 32 alloc'd
==14301==    at 0x4C27972: realloc (vg_replace_malloc.c:525)
==14301==    by 0x5367FB: list_resize (listobject.c:62)
==14301==    by 0x537F5B: list_ass_slice (listobject.c:643)
==14301==    by 0x5381BA: PyList_SetSlice (listobject.c:677)
==14301==    by 0x4A1B61: symtable_exit_block (symtable.c:909)
==14301==    by 0x4A2997: symtable_visit_stmt (symtable.c:1128)
==14301==    by 0x49FED2: PySymtable_Build (symtable.c:256)
==14301==    by 0x473B42: PyAST_CompileEx (compile.c:295)
==14301==    by 0x49E37D: run_mod (pythonrun.c:1790)
==14301==    by 0x49E10E: PyRun_StringFlags (pythonrun.c:1727)
==14301==    by 0x45EBFB: builtin_exec (bltinmodule.c:818)
==14301==    by 0x54E2FF: PyCFunction_Call (methodobject.c:81)

----------
components: Interpreter Core
messages: 139636
nosy: benjamin.peterson, skrah
priority: normal
severity: normal
status: open
title: Invalid read in symtable.c
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul  3 09:07:44 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Sun, 03 Jul 2011 07:07:44 +0000
Subject: [New-bugs-announce] [issue12475] Generator bug allows you to chain
	arbitrary tracebacks	to the next raised exception
In-Reply-To: <1309676864.45.0.345140180481.issue12475@psf.upfronthosting.co.za>
Message-ID: <1309676864.45.0.345140180481.issue12475@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

It's probably best shown by example:

http://ideone.com/4YkqV

Have fun! This one looks hard.

Some notes: Exchanging g2() for iter([1]) makes this go away. Wrapping g2 inside a non-generator iterator does not make this go away. 

Removing the call to next(it) after it = g2() makes the problem go away, as does replacing those two lines with next(g2()).

The file used in that ideone paste is attached for your convenience.

---

Debugging is impractical for me with this bug in existence. It never stopped printing the traceback before I killed the process. (And let's forget about debug prints!)

----------
components: Interpreter Core
files: exception_chaining.py
messages: 139670
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: Generator bug allows you to chain arbitrary tracebacks to the next raised exception
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file22550/exception_chaining.py

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

From report at bugs.python.org  Sun Jul  3 10:02:37 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 03 Jul 2011 08:02:37 +0000
Subject: [New-bugs-announce] [issue12476] ctypes: need example how to pass
	raw data from Python
In-Reply-To: <1309680157.38.0.0819979072917.issue12476@psf.upfronthosting.co.za>
Message-ID: <1309680157.38.0.0819979072917.issue12476@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

ctypes documentation lacks an example, how to pass a raw data block from Python to a C function. For example, how to pass this chunk:

data = open('somefile', 'rb').read()

to this function:

int checkBuffer(LPSTR lpData, DWORD dwBufferLength);

?

----------
assignee: docs at python
components: Documentation, ctypes
messages: 139675
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: ctypes: need example how to pass raw data from Python
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Jul  3 13:03:38 2011
From: report at bugs.python.org (Atsushi Odagiri)
Date: Sun, 03 Jul 2011 11:03:38 +0000
Subject: [New-bugs-announce] [issue12477] input() does'nt strip CR
In-Reply-To: <1309691018.52.0.674006633314.issue12477@psf.upfronthosting.co.za>
Message-ID: <1309691018.52.0.674006633314.issue12477@psf.upfronthosting.co.za>


New submission from Atsushi Odagiri <aodagx at gmail.com>:

Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> input()
a
'a\r'


Python 3.1.3 (r313:86834, Nov 27 2010, 17:20:37) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> input()
a
'a'

----------
messages: 139682
nosy: Atsushi.Odagiri
priority: normal
severity: normal
status: open
title: input() does'nt strip CR
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Jul  3 14:14:28 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 03 Jul 2011 12:14:28 +0000
Subject: [New-bugs-announce] [issue12478] Possible error in
	HTTPErrorProcessor documentation
In-Reply-To: <1309695268.0.0.0456155108685.issue12478@psf.upfronthosting.co.za>
Message-ID: <1309695268.0.0.0456155108685.issue12478@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, I think HTTPErrorProcessor documentation at [1] contains a cut&paste error (from UnknownHandler) for the only method available

[1] http://docs.python.org/py3k/library/urllib.request.html#httperrorprocessor-objects

because:

./python -c "import urllib.request as ur; print ('unknown_open' in dir(ur.HTTPErrorProcessor))"
False

If you can confirm that http_response() should be used instead, I'll provide a patch to fix it.

----------
assignee: docs at python
components: Documentation
messages: 139685
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: Possible error in HTTPErrorProcessor documentation
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul  3 14:53:39 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 03 Jul 2011 12:53:39 +0000
Subject: [New-bugs-announce] [issue12479] Add HTTPErrorProcessor class
	definition
In-Reply-To: <1309697619.94.0.838258559522.issue12479@psf.upfronthosting.co.za>
Message-ID: <1309697619.94.0.838258559522.issue12479@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

As reported in http://mail.python.org/pipermail/docs/2011-June/004879.html urllibs/urllib.request misses the definition of HTTPErrorProcessor class; the attached patches add it to the documentation.

----------
assignee: docs at python
components: Documentation
files: HTTPErrorProcessor_class-default.patch
keywords: patch
messages: 139687
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Add HTTPErrorProcessor class definition
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22552/HTTPErrorProcessor_class-default.patch

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

From report at bugs.python.org  Sun Jul  3 17:16:12 2011
From: report at bugs.python.org (Or)
Date: Sun, 03 Jul 2011 15:16:12 +0000
Subject: [New-bugs-announce] [issue12480] urllib2 doesn't use proxy
	(fieddler2), configed the proxy with ProxyHandler
In-Reply-To: <1309706172.79.0.961224445373.issue12480@psf.upfronthosting.co.za>
Message-ID: <1309706172.79.0.961224445373.issue12480@psf.upfronthosting.co.za>


New submission from Or <yellowslider at gmail.com>:

I have fieddler2 listening on 0.0.0.0:8888.

this code is suppose to use the proxy on my localhost.

try:
    data = '' 
    proxy = urllib2.ProxyHandler({'http': '127.0.0.1:8888'})  //also tried {'http': 'http://127.0.0.1:8888/'}
    opener = urllib2.build_opener(proxy)
    urllib2.install_opener(opener)
    req = urllib2.Request('http://www.google.com')
    response = urllib2.urlopen(req)
    the_page = response.read()
        print the_page
except Exception, detail:
    print "Err ", detail


	

I have fieddler2 listening on 0.0.0.0:8888.

try:
    proxy = urllib2.ProxyHandler({'http': '127.0.0.1:8888'})  //also tried {'http': 'http://127.0.0.1:8888/'}
    opener = urllib2.build_opener(proxy)
    urllib2.install_opener(opener)
    req = urllib2.Request('http://www.google.com')
    response = urllib2.urlopen(req)
    the_page = response.read()
        print the_page
except Exception, detail:
    print "Err ", detail

I don't see the GET or any request to google in fieddler (but I can see other requests) is there a way to debug it? is seems like python bypasses fieddler or ignores the proxy.

the code is working, but it's not using the proxy to fetch google, it bypasses the proxy.

I also configured win7 to work with fieddler -

C:\Windows\system32>netsh winhttp set proxy 127.0.0.1:8888

Current WinHTTP proxy settings:

    Proxy Server(s) :  127.0.0.1:8888
    Bypass List     :  (none)

In order to check if the code is using the porxy I've changed fieddler to require proxy authentication and I had to use a user\pass on my browser when browsing, run the python code again and it worked, so it defiantly doesn't use the proxy.

----------
components: Extension Modules, Library (Lib), Windows
messages: 139688
nosy: Or.Wilder
priority: normal
severity: normal
status: open
title: urllib2 doesn't use proxy (fieddler2), configed the proxy with ProxyHandler
versions: Python 2.7

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

From report at bugs.python.org  Sun Jul  3 18:33:10 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 03 Jul 2011 16:33:10 +0000
Subject: [New-bugs-announce] [issue12481] test_faulthandler: popups on
	Windows/Debug/x64
In-Reply-To: <1309710790.64.0.229703159898.issue12481@psf.upfronthosting.co.za>
Message-ID: <1309710790.64.0.229703159898.issue12481@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

I'm getting the dreaded "python_d.exe has stopped working" popups
in test_faulthandler on Windows 7 + VisualStudioPro + "Debug|x64".

----------
components: Tests
messages: 139691
nosy: haypo, skrah
priority: normal
severity: normal
status: open
title: test_faulthandler: popups on Windows/Debug/x64
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul  3 21:23:50 2011
From: report at bugs.python.org (Dmitriy Gorbachev)
Date: Sun, 03 Jul 2011 19:23:50 +0000
Subject: [New-bugs-announce] [issue12482] input() not working correctly on
	Mac OS X
In-Reply-To: <1309721030.16.0.565553010826.issue12482@psf.upfronthosting.co.za>
Message-ID: <1309721030.16.0.565553010826.issue12482@psf.upfronthosting.co.za>


New submission from Dmitriy Gorbachev <dgorbachev at yahoo.com>:

I am learning Python by running exercises from "Programming Python", Mark Lutz on both Windows and Mac. While exercises run flawlessly on Windows, sometimes they do not run on Mac.
In particular, in Chapter 1, Step 2: Storing Records Persistently there is a script called make_db_file.py. The following function loadDbase (called by dump_db_file_test.py-see attached) is not working at all on Mac, but working fine of Windows. 
The code breaks on the line: key = input(). 
The Traceback message is as follows:
Traceback (most recent call last):
  File "dump_db_file_test.py", line 2, in <module>
    db = loadDbase()
  File "/Users/DMITRY/PythonScripts/make_db_file_test.py", line 22, in loadDbase
    key = input()
  File "<string>", line 1, in <module>
NameError: name 'bob' is not defined

Where 'bob' is the first line of the text file "people-file" that make_db_file_test.py refers.
All related files attached in BugReport.zip

Best regards

Dmitry

----------
assignee: ronaldoussoren
components: Macintosh
files: BugReport.zip
messages: 139697
nosy: dgorbachev, ronaldoussoren
priority: normal
severity: normal
status: open
title: input() not working correctly on Mac OS X
versions: Python 2.7
Added file: http://bugs.python.org/file22554/BugReport.zip

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

From report at bugs.python.org  Mon Jul  4 02:56:40 2011
From: report at bugs.python.org (Ryan Kelly)
Date: Mon, 04 Jul 2011 00:56:40 +0000
Subject: [New-bugs-announce] [issue12483] CThunkObject_dealloc should call
	PyObject_GC_UnTrack?
In-Reply-To: <1309741000.66.0.461732700198.issue12483@psf.upfronthosting.co.za>
Message-ID: <1309741000.66.0.461732700198.issue12483@psf.upfronthosting.co.za>


New submission from Ryan Kelly <ryan at rfk.id.au>:

According to the docs here:

  http://docs.python.org/c-api/gcsupport.html

Any object that uses PyObject_GC_Track in its constructor must call PyObject_GC_UnTrack in its deallocator.  The CThunkObject in _ctypes does the former but not the later.  Attached patch adds a call to PyObject_GC_UnTrack.

This doesn't fix any particular bug I was seeing, I just happened to be going through the _ctypes sources (you know, for fun...) and noticed this discrepancy.

----------
components: ctypes
files: ctypes_gcuntrack.patch
keywords: patch
messages: 139724
nosy: rfk
priority: normal
severity: normal
status: open
title: CThunkObject_dealloc should call PyObject_GC_UnTrack?
versions: Python 3.3
Added file: http://bugs.python.org/file22560/ctypes_gcuntrack.patch

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

From report at bugs.python.org  Mon Jul  4 03:15:06 2011
From: report at bugs.python.org (Alejandro Santos)
Date: Mon, 04 Jul 2011 01:15:06 +0000
Subject: [New-bugs-announce] [issue12484] The Py_InitModule functions no
	longer exist, but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>


New submission from Alejandro Santos <alejolp at alejolp.com>:

While the "Py_InitModule" does not exists on Py3k it is still mentioned on the docs:

http://docs.python.org/py3k/extending/extending.html#keyword-parameters-for-extension-functions
http://docs.python.org/py3k/extending/windows.html#a-cookbook-approach
http://docs.python.org/py3k/faq/extending.html#what-does-systemerror-pyimport-fixupextension-module-yourmodule-not-loaded-mean

----------
assignee: docs at python
components: Documentation
messages: 139728
nosy: alejolp, docs at python
priority: normal
severity: normal
status: open
title: The Py_InitModule functions no longer exist, but remain in the docs
versions: Python 3.2

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

From report at bugs.python.org  Mon Jul  4 04:13:01 2011
From: report at bugs.python.org (Tyler Romeo)
Date: Mon, 04 Jul 2011 02:13:01 +0000
Subject: [New-bugs-announce] [issue12485] Improvement of textwrap module
In-Reply-To: <1309745581.79.0.51605072509.issue12485@psf.upfronthosting.co.za>
Message-ID: <1309745581.79.0.51605072509.issue12485@psf.upfronthosting.co.za>


New submission from Tyler Romeo <tylerromeo at gmail.com>:

Python's textwrap module can be helpful at times, but personally I think there are a couple of things that could be added.

First, when it comes to text wrapping, usually you're not dealing with a monospace font where each letter is the same size. If you're working with the Python Imaging Library for example, there is a function that you pass the text to in order to determine how wide (or tall) a font is. Therefore, it would be useful to have a parameter where the user can pass a function that gives a custom width for a set of text. The default for this parameter, of course, would be len.

Also, this module uses a rough and efficient algorithm for wrapping text, but the results are not always aesthetically pleasing (one word hanging off on a line). Sometimes the user may want something that is wrapped more beautifully, so to say, such as is found in TeX. So there should also be a beautiful option that goes back and redistributes the text so that it is more aesthetically pleasing.

This isn't exactly that important (minor improvements to a module that is probably not used much), but I figured I'd get it out there as I run into the problem all the time when trying to wrap text to be put in images of a set size.

----------
components: Extension Modules
files: textwrap.py-improvement.diff
keywords: patch
messages: 139731
nosy: parent5446
priority: normal
severity: normal
status: open
title: Improvement of textwrap module
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file22561/textwrap.py-improvement.diff

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

From report at bugs.python.org  Mon Jul  4 05:58:17 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Mon, 04 Jul 2011 03:58:17 +0000
Subject: [New-bugs-announce] [issue12486] tokenize module should have a
	unicode API
In-Reply-To: <1309751897.67.0.332272921906.issue12486@psf.upfronthosting.co.za>
Message-ID: <1309751897.67.0.332272921906.issue12486@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

tokenize only deals with bytes. Users might want to deal with unicode source (for example, if python source is embedded into a document with an already-known encoding).

The naive approach might be something like:

  def my_readline():
      return my_oldreadline().encode('utf-8')

But this doesn't work for python source that declares its encoding, which might be something other than utf-8. The only safe ways are to either manually add a coding line yourself (there are lots of ways, I picked a dumb one):

  def my_readline_safe(was_read=[]):
      if not was_read:
          was_read.append(True)can 
          return b'# coding: utf-8'
      return my_oldreadline().encode('utf-8')

  tokenstream = tokenize.tokenize(my_readline_safe)

Or to use the same my_readline as before (no added coding line), but instead of passing it to tokenize.tokenize, you could pass it to the undocumented _tokenize function:

    tokenstream = tokenize._tokenize(my_readline, 'utf-8')

Or, ideally, you'd just pass the original readline that produces unicode into a utokenize function:

    tokenstream = tokenize.utokenize(my_oldreadline)

----------
components: Library (Lib)
messages: 139733
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: tokenize module should have a unicode API

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

From report at bugs.python.org  Mon Jul  4 12:18:25 2011
From: report at bugs.python.org (Peter Schuller)
Date: Mon, 04 Jul 2011 10:18:25 +0000
Subject: [New-bugs-announce] [issue12487] urllib2.urlopen() returns object
	missing context manager
In-Reply-To: <1309774705.31.0.473593328364.issue12487@psf.upfronthosting.co.za>
Message-ID: <1309774705.31.0.473593328364.issue12487@psf.upfronthosting.co.za>


New submission from Peter Schuller <peter.schuller at infidyne.com>:

The documentation states it returns a "file-like object". In Python 2.5+ I expect such file-like objects to have a context manager for use with the with statement.

In my particular use-case, the lack comes from urllib.addinfourl but I have not investigated what the possible types returned may be.

----------
components: Library (Lib)
messages: 139746
nosy: scode
priority: normal
severity: normal
status: open
title: urllib2.urlopen() returns object missing context manager
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jul  4 13:43:29 2011
From: report at bugs.python.org (Luke)
Date: Mon, 04 Jul 2011 11:43:29 +0000
Subject: [New-bugs-announce] [issue12488] multiprocessing.Connection does
	not communicate pipe	closure between parent and child
In-Reply-To: <1309779809.62.0.10199189289.issue12488@psf.upfronthosting.co.za>
Message-ID: <1309779809.62.0.10199189289.issue12488@psf.upfronthosting.co.za>


New submission from Luke <lcampagn at email.unc.edu>:

I have found that when using multiprocessing.Connection objects to pass data between two processes, closing one end of the pipe is not properly communicated to the other end. My expectation was that when calling recv() on the remote end, it should raise EOFError if the pipe has been closed. Instead, the remote recv() blocks indefinitely. This behavior exists on Linux and Cygwin, but NOT on native Windows.

Example:

    import multiprocessing as m

    def fn(pipe):
        print "recv:", pipe.recv()
        print "recv:", pipe.recv()

    if __name__ == '__main__':
        p1, p2 = m.Pipe()
        pr = m.Process(target=fn, args=(p2,))
        pr.start()
        p1.send(1)
        p1.close()  ## should generate EOFError in remote process

----------
messages: 139754
nosy: lcampagn
priority: normal
severity: normal
status: open
title: multiprocessing.Connection does not communicate pipe closure between parent and child
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul  4 16:38:20 2011
From: report at bugs.python.org (Thomas Guettler)
Date: Mon, 04 Jul 2011 14:38:20 +0000
Subject: [New-bugs-announce] [issue12489] email.errors.HeaderParseError if
	base64url is used
In-Reply-To: <1309790300.23.0.111625308862.issue12489@psf.upfronthosting.co.za>
Message-ID: <1309790300.23.0.111625308862.issue12489@psf.upfronthosting.co.za>


New submission from Thomas Guettler <guettli at thomas-guettler.de>:

from email.header import decode_header
decode_header('=?iso-8859-1?B?QW5tZWxkdW5nIE5ldHphbnNjaGx1c3MgU_xkcmluZzNwLmpwZw==?=')

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/email/header.py", line 101, in decode_header
    raise HeaderParseError
email.errors.HeaderParseError

thunderbird is able to decode the header:
"Anmeldung Netzanschluss S?dring3p.jpg"

According to Peter Otten base64url encoding was used:

My question in the newsgroup:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/9cf9ccd4109481cc/9f76bd627676b5f1?show_docid=9f76bd627676b5f1

----------
components: Library (Lib)
messages: 139776
nosy: guettli
priority: normal
severity: normal
status: open
title: email.errors.HeaderParseError if base64url is used
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul  4 22:42:12 2011
From: report at bugs.python.org (Rodolpho Eckhardt)
Date: Mon, 04 Jul 2011 20:42:12 +0000
Subject: [New-bugs-announce] [issue12490] Documentation for
	itertools.chain.from_iterable is	incorrect
In-Reply-To: <1309812132.83.0.229828200889.issue12490@psf.upfronthosting.co.za>
Message-ID: <1309812132.83.0.229828200889.issue12490@psf.upfronthosting.co.za>


New submission from Rodolpho Eckhardt <rodolpho.eckhardt at gmail.com>:

The documentation at http://docs.python.org/py3k/library/itertools.html#itertools.chain and http://docs.python.org/library/itertools.html#itertools.chain is inconsistent.

At the definition of the class it states that itertools.chain.from_iterable can receive one iterable "Gets chained inputs from a single iterable argument that is evaluated lazily.", but then it contradicts itself by using the following example:

@classmethod
def from_iterable(iterables):
    # chain.from_iterable(['ABC', 'DEF']) --> A B C D E F
    for it in iterables:
        for element in it:
            yield element

This example could lead the reader to believe this alternative constructor can receive multiple iterable objects, when in fact it can receive only one.

----------
assignee: docs at python
components: Documentation
messages: 139802
nosy: RodolphoEckhardt, docs at python
priority: normal
severity: normal
status: open
title: Documentation for itertools.chain.from_iterable is incorrect
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Jul  4 23:24:35 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 04 Jul 2011 21:24:35 +0000
Subject: [New-bugs-announce] [issue12491] Update glossary documentation for
	the term 'attribute'
In-Reply-To: <1309814675.46.0.717017747157.issue12491@psf.upfronthosting.co.za>
Message-ID: <1309814675.46.0.717017747157.issue12491@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <senthil at uthcode.com>:

Update the term 'attribute' in the glossary http://docs.python.org/dev/glossary.html#term-attribute so that the reader can understand that the term attribute in Python can mean both 'data-attribute' and a 'callable' method.

----------
assignee: docs at python
components: Documentation
messages: 139809
nosy: docs at python, orsenthil
priority: normal
severity: normal
status: open
title: Update glossary documentation for the term 'attribute'
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jul  4 23:48:38 2011
From: report at bugs.python.org (Juan Gonzalez)
Date: Mon, 04 Jul 2011 21:48:38 +0000
Subject: [New-bugs-announce] [issue12492] Inconsistent Python find() behavior
In-Reply-To: <1309816118.48.0.732382168551.issue12492@psf.upfronthosting.co.za>
Message-ID: <1309816118.48.0.732382168551.issue12492@psf.upfronthosting.co.za>


New submission from Juan Gonzalez <juan.gonzalez at ti.com>:

Something really weird going on in python find() string function.  When I call <string>.find() and python returns -1 it crashes when compared against 0 using the ">" operator.

The statement in which crash condition occurs is the following:

    if url.find(str) > 0:
        print "RSS Item:", url
	break; 

However, if I change the statement to be "<" instead it does not crash.
The error that the python compiler reports is:

AttributeError: 'int' object has no attribute 'find'

My version of python is:

tony at ubuntu:~/auto/sel/scripts$ python -V
Python 2.7.1+

----------
components: Regular Expressions
messages: 139810
nosy: juan.gonzalez
priority: normal
severity: normal
status: open
title: Inconsistent Python find() behavior
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul  5 00:03:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 22:03:10 +0000
Subject: [New-bugs-announce] [issue12493] subprocess: Popen.communicate()
	doesn't handle EINTR in	some cases
In-Reply-To: <1309816990.23.0.880296531528.issue12493@psf.upfronthosting.co.za>
Message-ID: <1309816990.23.0.880296531528.issue12493@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

subprocess.Popen.communicate() doesn't catch EINTR error if it is called without timeout and if there is only one PIPE (stdout or stderr).

Attached patch fixes these cases. It may need a test.

I found this bug while working on test_signal, especially on the inter process signal tests.

----------
components: Library (Lib)
files: subprocess_communicate_eintr.patch
keywords: patch
messages: 139811
nosy: haypo
priority: normal
severity: normal
status: open
title: subprocess: Popen.communicate() doesn't handle EINTR in some cases
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22571/subprocess_communicate_eintr.patch

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

From report at bugs.python.org  Tue Jul  5 00:13:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 22:13:45 +0000
Subject: [New-bugs-announce] [issue12494] subprocess: check_output() doesn't
	close pipes on error
In-Reply-To: <1309817625.67.0.269796238759.issue12494@psf.upfronthosting.co.za>
Message-ID: <1309817625.67.0.269796238759.issue12494@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

subprocess.check_output() doesn't close explicitly pipes if an error occurs. See for example issue #12493 for an example of an error on .communicate().

Attached patch uses a context manager to ensure that all pipes are always closed and that the status is read to avoid zombies.

Other subprocess functions should be fixed:
 - call() (will fix check_call)
 - getstatusoutput() (will fix getoutput): see patch attached to the issue #10197 to replace os.popen() by subprocess.Popen

----------
components: Library (Lib)
files: subprocess_check_output.patch
keywords: patch
messages: 139812
nosy: haypo
priority: normal
severity: normal
status: open
title: subprocess: check_output() doesn't close pipes on error
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22572/subprocess_check_output.patch

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

From report at bugs.python.org  Tue Jul  5 00:33:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 22:33:21 +0000
Subject: [New-bugs-announce] [issue12495] Rewrite InterProcessSignalTests
In-Reply-To: <1309818801.22.0.236460194103.issue12495@psf.upfronthosting.co.za>
Message-ID: <1309818801.22.0.236460194103.issue12495@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

InterProcessSignalTests uses 4 different signal handlers (SIGUSR1, SIGUSR2, SIGALRM, SIGHUP) and uses 2 methods to raise a signal (a subprocess executing "kill -SIG pid" or signal.alarm(1)). It uses signal.pause() and/or time.sleep(1) to wait the signal, or just nothing for SIGUSR2 (configured to be ignored).

The testcase tests too many unrelated things.

signal.alarm(1) is not an interprocess signal: it is a signal send to the process itself.

Why using two different signal handlers? A modifies a_called, B modifies b_called but raise also a Python exception. How is it related to interprocess signal handling?

Why checking that the handler A (SIGHUP) has not been called when the signal handler B (SIGUSR1) is called?

Why is the garbage collector disabled?

I propose to write a new simple testcase: install a signal handler raising a Python exception, send a signal using a child process, ensure that the signal has been received (wait for the exception). Pseudo-code:

--------
s = signal.SIGUSR1
def handler(signum, frame): 1/0
signal.signal(s, handler)
try:
  subprocess.call([sys.executable, '-c', '... kill(%s, %s)' % (os.getpid(), s))
  ... wait the signal ...
except ZeroDivisionError:
  pass
else:
  raise Exception("ZeroDivisionError not raised"
--------

The whole test has to be run in a subprocess.

The new test may pass on freebsd 6, it should be checked (see issue #12469).

----------
components: Tests
messages: 139813
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: Rewrite InterProcessSignalTests
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul  5 02:28:29 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Jul 2011 00:28:29 +0000
Subject: [New-bugs-announce] [issue12496] test_ssl test_connect_capath fails
	with "certificate	verify failed"
In-Reply-To: <1309825709.83.0.777324872875.issue12496@psf.upfronthosting.co.za>
Message-ID: <1309825709.83.0.777324872875.issue12496@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

======================================================================
ERROR: test_connect_capath (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/test/test_ssl.py", line 584, in test_connect_capath
    s.connect(("svn.python.org", 443))
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/ssl.py", line 471, in connect
    self._real_connect(addr, False)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/ssl.py", line 461, in _real_connect
    self.do_handshake()
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/ssl.py", line 441, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [Errno 1] _ssl.c:392: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

----------
assignee: ned.deily
components: Tests
messages: 139818
nosy: ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ssl test_connect_capath fails with "certificate verify failed"
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jul  5 03:54:16 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Jul 2011 01:54:16 +0000
Subject: [New-bugs-announce] [issue12497] test_codecmaps_* skipped - Could
	not retrieve *
In-Reply-To: <1309830856.17.0.0825089437233.issue12497@psf.upfronthosting.co.za>
Message-ID: <1309830856.17.0.0825089437233.issue12497@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

[ 54/352] test_codecmaps_cn
	fetching http://source.icu-project.org/repos/icu/data/trunk/charset/data/xml/gb-18030-2000.xml ...
test_codecmaps_cn skipped -- Could not retrieve http://source.icu-project.org/repos/icu/data/trunk/charset/data/xml/gb-18030-2000.xml
[ 55/352] test_codecmaps_hk
	fetching http://people.freebsd.org/~perky/i18n/BIG5HKSCS-2004.TXT ...
test_codecmaps_hk skipped -- Could not retrieve http://people.freebsd.org/~perky/i18n/BIG5HKSCS-2004.TXT
[ 56/352] test_codecmaps_jp
	fetching http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT ...
test_codecmaps_jp skipped -- Could not retrieve http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
[ 57/352] test_codecmaps_kr
	fetching http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP949.TXT ...
test_codecmaps_kr skipped -- Could not retrieve http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP949.TXT
[ 58/352] test_codecmaps_tw
	fetching http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/OTHER/BIG5.TXT ...
test_codecmaps_tw skipped -- Could not retrieve http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/OTHER/BIG5.TXT

----------
assignee: ned.deily
components: Tests
messages: 139820
nosy: ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: test_codecmaps_* skipped - Could not retrieve *
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jul  5 03:55:30 2011
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois-Xavier_Bourlet?=)
Date: Tue, 05 Jul 2011 01:55:30 +0000
Subject: [New-bugs-announce] [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>


New submission from Fran?ois-Xavier Bourlet <bombela at gmail.com>:

Actually the class asyncore.dispatcher_with_send do not handle properly disconnection. When the endpoint shutdown his sending part of the socket, but keep the socket open in reading, the current implementation of dispatcher_with_send will close the socket without sending pending data.

Adding this method to the class fix the problem:

    def handle_close(self):
        if not self.writable():
            dispatcher.close()

Note also that this class try to initiate a send even if the socket is maybe not ready for writing:

Here's a simple fix:
    def send(self, data):
        if self.debug:
            self.log_info('sending %s' % repr(data))
        self.out_buffer = self.out_buffer + data
-       self.initiate_send()

Last but not last, the buffer size of each socket send are way to small (512, a third of an usual TCP frame). Here's the code with a bumped value:

    def initiate_send(self):
        num_sent = 0
-       num_sent = dispatcher.send(self, self.out_buffer[:512])
+       num_sent = dispatcher.send(self, self.out_buffer[:8192])
        self.out_buffer = self.out_buffer[num_sent:]

Thanks for reading,

----------
components: IO
messages: 139821
nosy: Fran?ois-Xavier.Bourlet
priority: normal
severity: normal
status: open
title: asyncore.dispatcher_with_send, disconnection problem + miss-conception
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul  5 05:03:24 2011
From: report at bugs.python.org (Tyler Romeo)
Date: Tue, 05 Jul 2011 03:03:24 +0000
Subject: [New-bugs-announce] [issue12499] textwrap.wrap: add control for
	fonts with different	character widths
In-Reply-To: <1309835004.91.0.584156217993.issue12499@psf.upfronthosting.co.za>
Message-ID: <1309835004.91.0.584156217993.issue12499@psf.upfronthosting.co.za>


New submission from Tyler Romeo <tylerromeo at gmail.com>:

Originally from http://bugs.python.org/issue12485 but separated.

The textwrap modules uses len to determine the length of text, but in many (if not most) fonts, the width of a character differs depending on the letter, so it would be useful to have an option to pass a custom function that returns the width of a given string of text.

----------
components: Library (Lib)
files: textwrap.py-widthfunction-2011-07-04_22-57-49_r71219+.diff
keywords: patch
messages: 139828
nosy: parent5446
priority: normal
severity: normal
status: open
title: textwrap.wrap: add control for fonts with different character widths
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22574/textwrap.py-widthfunction-2011-07-04_22-57-49_r71219+.diff

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

From report at bugs.python.org  Tue Jul  5 10:25:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 08:25:15 +0000
Subject: [New-bugs-announce] [issue12500] support.transient_internet():
	catch also Windows socket	errors
In-Reply-To: <1309854315.46.0.604055413236.issue12500@psf.upfronthosting.co.za>
Message-ID: <1309854315.46.0.604055413236.issue12500@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

======================================================================
ERROR: test_non_blocking_connect_ex (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_ssl.py", line 518, in test_non_blocking_connect_ex
    s.do_handshake()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\ssl.py", line 442, in do_handshake
    self._sslobj.do_handshake()
socket.error: [Errno 10057] A request to send or receive data was disallowed because the socket is not connected and (when sending on a datagram socket using a sendto call) no address was supplied

======================================================================
FAIL: test_connect_ex (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_ssl.py", line 495, in test_connect_ex
    self.assertEqual(0, s.connect_ex(("svn.python.org", 443)))
AssertionError: 0 != 10061

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4918/steps/test/logs/stdio

WSAECONNREFUSED (10061): "Connection refused."

WSAENOTCONN (10057): "Socket is not connected."

It is obvious that transient_internet() should catch WSAECONNREFUSED, but for WSAENOTCONN, I don't understand why it happens on a SSL handshake.

Attached patch catchs both errors. We may start with only WSAECONNREFUSED, and maybe add a specific code for test_ssl?

----------
components: Tests
files: transient_internet_windows.patch
keywords: patch
messages: 139833
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: support.transient_internet(): catch also Windows socket errors
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22575/transient_internet_windows.patch

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

From report at bugs.python.org  Tue Jul  5 13:35:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 11:35:50 +0000
Subject: [New-bugs-announce] [issue12501] callable(): remove the deprecation
	warning from Python	2.7
In-Reply-To: <1309865750.34.0.541248470896.issue12501@psf.upfronthosting.co.za>
Message-ID: <1309865750.34.0.541248470896.issue12501@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Python 2.7 emits a DeprecationWarning warning if callable() is called and python has the -3 option. callable() was removed in Python 3.0, but it was also added again in Python 3.2 (issue #10518).

$ ./python -bb -3 -Werror 
Python 2.7.2+ (2.7:7bfedb159e82, Jul  5 2011, 13:23:38) 
>>> callable(int)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
DeprecationWarning: callable() not supported in 3.x; use isinstance(x, collections.Callable)

I propose to drop the warning from Python 2.7. Use the six module if you would like to support Python 3.1, or use directly the following workaround in your code:

def callable(obj):
   return any("__call__" in klass.__dict__ for klass in type(obj).__mro__)

Attached patch removes the warning.

By the way, the six should be updated for Python 3.2: callable is a builtin again ;-)

----------
files: callable_warning.patch
keywords: patch
messages: 139853
nosy: benjamin.peterson, haypo, pitrou
priority: normal
severity: normal
status: open
title: callable(): remove the deprecation warning from Python 2.7
versions: Python 2.7
Added file: http://bugs.python.org/file22581/callable_warning.patch

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

From report at bugs.python.org  Tue Jul  5 19:25:37 2011
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdC10Lkg0JDQs9Cw0L/QuNGC0L7Qsg==?=)
Date: Tue, 05 Jul 2011 17:25:37 +0000
Subject: [New-bugs-announce] [issue12502] 100% cpu usage when using asyncore
	with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>


New submission from ??????? ???????? <marwinxxii at gmail.com>:

When using asyncore server with UNIX socket, I got 100% CPU usage.
I run modified code example from asyncore doc page.
This code was tested on two systems:

Ubuntu 10.04 2.6.32-32-generic #62-Ubuntu SMP

with two versions of Python:
Python 3.2 (r32:88445, Mar 29 2011, 08:55:36)

Python 3.2.1rc2 (default, Jul  5 2011, 20:33:19) Built from sources

and
Gentoo 2.6.36-hardened-r9 #6 SMP

with Python 3.1.3 (r313:86834, Mar 12 2011, 20:06:24)

I'm not sure, maybe it's because of the characteristics of UNIX socket?

----------
components: Library (Lib)
files: asyncore_test.py
messages: 139898
nosy: Alexey.Agapitov
priority: normal
severity: normal
status: open
title: 100% cpu usage when using asyncore with UNIX socket
type: resource usage
versions: Python 3.2
Added file: http://bugs.python.org/file22585/asyncore_test.py

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

From report at bugs.python.org  Wed Jul  6 05:58:03 2011
From: report at bugs.python.org (Ismael Garrido)
Date: Wed, 06 Jul 2011 03:58:03 +0000
Subject: [New-bugs-announce] [issue12503] "with" statement error message is
	more confusing in Py2.7
In-Reply-To: <1309924683.37.0.310972531328.issue12503@psf.upfronthosting.co.za>
Message-ID: <1309924683.37.0.310972531328.issue12503@psf.upfronthosting.co.za>


New submission from Ismael Garrido <ismaelgfk at gmail.com>:

Using the "with" statement wrongly results in a confusing error message.

Code (originally written by Alex Gaynor):

class Timer(object):
    def __enter__(self):
        self.start = time.time()
    def __exit__(self, exc_type, exc_val, tb):
        print "Section time: ", time.time() - self.start

#Note the error here, I call the class, not an instance
with Timer:
    pass


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


Compare the Python 2.6 error:

ismael at chaos:~/Escritorio$ python bad.py 
Traceback (most recent call last):
  File "bad.py", line 8, in <module>
    with Timer:
TypeError: unbound method __enter__() must be called with Timer instance as first argument (got nothing instead)

Against Python 2.7:

ismael at chaos:~/Escritorio$ python2.7 bad.py 
Traceback (most recent call last):
  File "bad.py", line 8, in <module>
    with Timer:
AttributeError: __exit__

----------
components: Interpreter Core
messages: 139918
nosy: Ismael.Garrido
priority: normal
severity: normal
status: open
title: "with" statement error message is more confusing in Py2.7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul  6 06:29:39 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 06 Jul 2011 04:29:39 +0000
Subject: [New-bugs-announce] [issue12504] Uninstall has disabled windows
	tests
Message-ID: <1309926579.84.0.641208908004.issue12504@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


----------
assignee: tarek
components: Distutils2
nosy: alexis, eric.araujo, tarek, thomas.holmes
priority: normal
severity: normal
status: open
title: Uninstall has disabled windows tests
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul  6 12:54:57 2011
From: report at bugs.python.org (yoch)
Date: Wed, 06 Jul 2011 10:54:57 +0000
Subject: [New-bugs-announce] [issue12505] python interpreter not handle
	wildards properly
In-Reply-To: <1309949697.3.0.655246491715.issue12505@psf.upfronthosting.co.za>
Message-ID: <1309949697.3.0.655246491715.issue12505@psf.upfronthosting.co.za>


New submission from yoch <yoch.melka at gmail.com>:

Hi,

I'm using sys.argv to retrieve files and process them on the command line.
Wildcards arguments (like : test.py *.txt) works fine under Linux (expanded), but not on Windows.
It also affects the fileinput functions.
The solution is to change the compilation options msvc, as mentioned here:
http://msdn.microsoft.com/en-us/library/8bch7bkk.aspx

Regards,
yoch

----------
components: Windows
files: test_argv_1.py
messages: 139930
nosy: yoch.melka
priority: normal
severity: normal
status: open
title: python interpreter not handle wildards properly
versions: Python 3.2
Added file: http://bugs.python.org/file22592/test_argv_1.py

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

From report at bugs.python.org  Wed Jul  6 14:48:57 2011
From: report at bugs.python.org (bjorn lofdahl)
Date: Wed, 06 Jul 2011 12:48:57 +0000
Subject: [New-bugs-announce] [issue12506] NIS module cant handle multiple
	NIS map entries for the	same GID
In-Reply-To: <1309956537.93.0.737876319543.issue12506@psf.upfronthosting.co.za>
Message-ID: <1309956537.93.0.737876319543.issue12506@psf.upfronthosting.co.za>


New submission from bjorn lofdahl <bjorn.lofdahl at gmail.com>:

I think i have found an issue with the module that is only visible on larger sites that are using multiple group entries for the same group in the NIS maps. This comes from the bug that NIS can only handle 1024 chars per line, so if a group has more members that exceeds 1024 chars, a new line is added with the same GID and NAME. yp tools handles this fine, it simply reports several "lines" for the same group. For ex:

> ypcat group | grep FOO | cut -d ':' -f 1-3
FOO:x:17776
FOO:x:17776
FOO:x:17776
FOO:x:17776
FOO:x:17776

when i do the same using the python NIS module it only gives me the users for one of the maps for this group. I guess the "correct" behavior from the module should be to concatenate/append all users from all the maps for each specific group.

----------
messages: 139934
nosy: bjorn.lofdahl
priority: normal
severity: normal
status: open
title: NIS module cant handle multiple NIS map entries for the same GID
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Jul  6 19:14:51 2011
From: report at bugs.python.org (LMO)
Date: Wed, 06 Jul 2011 17:14:51 +0000
Subject: [New-bugs-announce] [issue12507] tkSimpleDialog problem
In-Reply-To: <1309972491.94.0.855067439806.issue12507@psf.upfronthosting.co.za>
Message-ID: <1309972491.94.0.855067439806.issue12507@psf.upfronthosting.co.za>


New submission from LMO <raycores at gmail.com>:

tkSimpleDialog displays blank rectangle and hangs with version 2.7.  Works fine on version 2.6.  In attached program, click on button labeled "Press this Button" which will call tkSimpleDialog.

----------
components: Tkinter
files: ACSDtest.py
messages: 139939
nosy: rzn8tr
priority: normal
severity: normal
status: open
title: tkSimpleDialog problem
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file22594/ACSDtest.py

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

From report at bugs.python.org  Thu Jul  7 00:45:49 2011
From: report at bugs.python.org (Saul Spatz)
Date: Wed, 06 Jul 2011 22:45:49 +0000
Subject: [New-bugs-announce] [issue12508] Codecs Anomaly
In-Reply-To: <1309992349.71.0.826004213615.issue12508@psf.upfronthosting.co.za>
Message-ID: <1309992349.71.0.826004213615.issue12508@psf.upfronthosting.co.za>


New submission from Saul Spatz <saul.spatz at gmail.com>:

The attached script produces the output 

'A\ufffdBC\ufffd'
'A\ufffdBC'

although it seems to me that both lines should be the same.  The first line is correct, I think, since the <F4> at the end is a maximal subpart of an ill-formed subsequence, according to the definition in the Unicode standard.

----------
components: Unicode
files: fffd.py
messages: 139954
nosy: spatz123
priority: normal
severity: normal
status: open
title: Codecs Anomaly
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22597/fffd.py

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

From report at bugs.python.org  Thu Jul  7 01:25:15 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 06 Jul 2011 23:25:15 +0000
Subject: [New-bugs-announce] [issue12509] test_gdb fails on debug build when
	builddir != srcdir
In-Reply-To: <1309994715.39.0.391727043164.issue12509@psf.upfronthosting.co.za>
Message-ID: <1309994715.39.0.391727043164.issue12509@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

test_gdb.py fails when builddir != srcdir: the regex tries to match lines like this:
  #0  builtin_id (self=<module at remote 0x7ffff20d3240>, v=()) at ../Python/bltinmodule.c:919

but isn't expecting the "../" before the "Python/bltinmodule.c"

2.7 uses a different regexp, and I don't think it's affected by an analogous problem.

----------
assignee: dmalcolm
components: None
files: fix-test_gdb-regexp.patch
keywords: patch
messages: 139960
nosy: dmalcolm, haypo
priority: normal
severity: normal
stage: patch review
status: open
title: test_gdb fails on debug build when builddir != srcdir
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file22600/fix-test_gdb-regexp.patch

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

From report at bugs.python.org  Thu Jul  7 01:27:22 2011
From: report at bugs.python.org (Roy Fox)
Date: Wed, 06 Jul 2011 23:27:22 +0000
Subject: [New-bugs-announce] [issue12510] IDLE get_the_calltip mishandles
	raw strings
In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za>
Message-ID: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za>


New submission from Roy Fox <roy.d.fox at gmail.com>:

Hi,

When you type (not copy-paste!) into an IDLE shell a string literal followed by (
you get a calltip.

When the string contains a bad unicode escaping you get an error (see example below), which makes some sense.

But when the string is raw, it isn't treated as such, and you may get the same error, though now it doesn't make any sense.

Non-raw example:

>>> '\xyz'(

>>> *** Internal Error: rpc.py:SocketIO.localcall()

 Object: exec 
 Method: <bound method Executive.get_the_calltip of <idlelib.run.Executive object at 0x021C2910>> 
 Args: ("'\\xyz'",)

Traceback (most recent call last):
  File "C:\Python32\lib\idlelib\rpc.py", line 188, in localcall
    ret = method(*args, **kwargs)
  File "C:\Python32\lib\idlelib\run.py", line 324, in get_the_calltip
    return self.calltip.fetch_tip(name)
  File "C:\Python32\lib\idlelib\CallTips.py", line 103, in fetch_tip
    entity = self.get_entity(name)
  File "C:\Python32\lib\idlelib\CallTips.py", line 112, in get_entity
    return eval(name, namespace)
  File "<string>", line 1
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-2: truncated \xXX escape


Raw example:

>>> r'\xyz'(

>>> *** Internal Error: rpc.py:SocketIO.localcall()

 Object: exec 
 Method: <bound method Executive.get_the_calltip of <idlelib.run.Executive object at 0x021C2910>> 
 Args: ("'\\xyz'",)

Traceback (most recent call last):
  File "C:\Python32\lib\idlelib\rpc.py", line 188, in localcall
    ret = method(*args, **kwargs)
  File "C:\Python32\lib\idlelib\run.py", line 324, in get_the_calltip
    return self.calltip.fetch_tip(name)
  File "C:\Python32\lib\idlelib\CallTips.py", line 103, in fetch_tip
    entity = self.get_entity(name)
  File "C:\Python32\lib\idlelib\CallTips.py", line 112, in get_entity
    return eval(name, namespace)
  File "<string>", line 1
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-2: truncated \xXX escape

----------
components: IDLE
messages: 139961
nosy: Roy.Fox
priority: normal
severity: normal
status: open
title: IDLE get_the_calltip mishandles raw strings
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul  7 12:13:10 2011
From: report at bugs.python.org (Andreas Hasenkopf)
Date: Thu, 07 Jul 2011 10:13:10 +0000
Subject: [New-bugs-announce] [issue12511] class/instance xyz has no
	attribute '_abc'
In-Reply-To: <1310033590.5.0.471814241717.issue12511@psf.upfronthosting.co.za>
Message-ID: <1310033590.5.0.471814241717.issue12511@psf.upfronthosting.co.za>


New submission from Andreas Hasenkopf <webmaster at hasenkopf2000.net>:

I'm using 64bit Arch Linux and Python 2.7.2 compiled with GCC 4.6.1.

I have noticed in several ocassions that the interpreter is complaining about

AttributeError: XMLGenerator instance has no attribute '_write' (in case of module xml.sax.saxutils.XMLGenerator)

or

AttributeError: RendererGDK instance has no attribute '_text2path' (in case of matplotlib when trying to use TeX formatting of text)

When I have a look into the corresponding modules I can clearly see method definitions (e.g. def _write(self, text) in line 97 of xml/sax/saxutils.py

I have no clue, why it is happening in some modules, but not in others. If a write my own module containing a class with a _write method it is working fine.
If I write a class derived from xml.sax.saxutils.XMLGenerator and overwrite the _write method it is known to the system, but many of the attributes beginning with an underscore appear still to be unknown...

This is very odd?!

----------
components: XML
messages: 139966
nosy: Andreas.Hasenkopf
priority: normal
severity: normal
status: open
title: class/instance xyz has no attribute '_abc'
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul  7 13:14:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 11:14:35 +0000
Subject: [New-bugs-announce] [issue12512] codecs: StreamWriter issue with
	stateful codecs after a	seek
In-Reply-To: <1310037275.84.0.0119141520986.issue12512@psf.upfronthosting.co.za>
Message-ID: <1310037275.84.0.0119141520986.issue12512@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The following code fails with an AssertionError('###\ufeffdef'):

import codecs
_open = codecs.open
#_open = open
filename = "test"
with _open(filename, 'w', encoding='utf_16') as f:
    f.write('abc')
    pos = f.tell()
with _open(filename, 'w', encoding='utf_16') as f:
    f.seek(pos)
    f.write('def')
    f.seek(0)
    f.write('###')
with _open(filename, 'r', encoding='utf_16') as f:
    content = f.read()
    assert content == '###def', ascii(content)

It is a bug in StreamWriter.seek(): it should update the encoder state to not write a new BOM. It has to be fixed in the StreamWriter class of each stateful codec, or a stateful StreamWriter class should be implemented in the codecs module.

Python supports the following stateful codecs:

 * cp932
 * cp949
 * cp950
 * euc_jis_2004
 * euc_jisx2003
 * euc_jp
 * euc_kr
 * gb18030
 * gbk
 * hz
 * iso2022_jp
 * iso2022_jp_1
 * iso2022_jp_2
 * iso2022_jp_2004
 * iso2022_jp_3
 * iso2022_jp_ext
 * iso2022_kr
 * shift_jis
 * shift_jis_2004
 * shift_jisx0213
 * utf_8_sig
 * utf_16
 * utf_32

This bug has already been fixed in TextIOWrapper: issue #5006.

----------
messages: 139969
nosy: haypo
priority: normal
severity: normal
status: open
title: codecs: StreamWriter issue with stateful codecs after a seek
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jul  7 15:12:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 13:12:47 +0000
Subject: [New-bugs-announce] [issue12513] codec.StreamReaderWriter: issues
	with interlaced	read-write
In-Reply-To: <1310044367.3.0.915426685652.issue12513@psf.upfronthosting.co.za>
Message-ID: <1310044367.3.0.915426685652.issue12513@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The following test fails with an AssertionError('a' != 'b') on the first read.

import codecs

FILENAME = 'test'

with open(FILENAME, 'wb') as f:
    f.write('abcd'.encode('utf-8'))
with codecs.open(FILENAME, 'r+', encoding='utf-8') as f:
    f.write("1")

    pos = f.writer.tell()
    assert pos == 1, "writer pos: %s != 1" % pos
    pos = f.reader.tell()
    assert pos == 1, "reader pos: %s != 1" % pos
    pos = f.stream.tell()
    assert pos == 1, "stream pos: %s != 1" % pos

    # read() must call writer.flush()
    char = f.read(1)
    assert char == 'b', "%r != 'b'" % (char,)
    # write() must rewind the raw stream
    f.write('3')
    tail = f.read()
    assert tail == 'd', "%r != 'd'" % (tail,)
    f.flush()
    with open(FILENAME, 'rb') as f:
        assert f.read() == b'1b3d'

I suppose that readline(), readlines() and __next__() have also issues.

See also issue #12215: similar issue with io.TextIOWrapper.

----------
components: Library (Lib), Unicode
messages: 139975
nosy: haypo
priority: normal
severity: normal
status: open
title: codec.StreamReaderWriter: issues with interlaced read-write
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jul  7 16:58:53 2011
From: report at bugs.python.org (Gareth Rees)
Date: Thu, 07 Jul 2011 14:58:53 +0000
Subject: [New-bugs-announce] [issue12514] timeit disables garbage collection
	if timed code raises	an exception
In-Reply-To: <1310050733.66.0.963908910352.issue12514@psf.upfronthosting.co.za>
Message-ID: <1310050733.66.0.963908910352.issue12514@psf.upfronthosting.co.za>


New submission from Gareth Rees <gdr at garethrees.org>:

If you call timeit.timeit and the timed code raises an exception, then garbage collection is disabled. I have verified this in Python 2.7 and 3.2. Here's an interaction with Python 3.2:

    Python 3.2 (r32:88445, Jul  7 2011, 15:52:49) 
    [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import timeit, gc
    >>> gc.isenabled()
    True
    >>> timeit.timeit('raise Exception')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/timeit.py", line 228, in timeit
        return Timer(stmt, setup, timer).timeit(number)
      File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/timeit.py", line 194, in timeit
        timing = self.inner(it, self.timer)
      File "<timeit-src>", line 6, in inner
    Exception
    >>> gc.isenabled()
    False

The problem is with the following code in Lib/timeit.py (lines 192?196):

    gcold = gc.isenabled()
    gc.disable()
    timing = self.inner(it, self.timer)
    if gcold:
        gc.enable()

This should be changed to something like this:

    gcold = gc.isenabled()
    gc.disable()
    try:
        timing = self.inner(it, self.timer)
    finally:
        if gcold:
            gc.enable()

----------
components: Library (Lib)
messages: 139978
nosy: Gareth.Rees
priority: normal
severity: normal
status: open
title: timeit disables garbage collection if timed code raises an exception
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Jul  7 18:37:22 2011
From: report at bugs.python.org (xavierd)
Date: Thu, 07 Jul 2011 16:37:22 +0000
Subject: [New-bugs-announce] [issue12515] The email package modifies the
	message structure (when	the parsed email is invalid)
In-Reply-To: <1310056642.88.0.39667287194.issue12515@psf.upfronthosting.co.za>
Message-ID: <1310056642.88.0.39667287194.issue12515@psf.upfronthosting.co.za>


New submission from xavierd <xdelannoy at cloudmark.com>:

the function 'email.message_from_file' modifies the message structure when the parsed is invalid (for example, when a closed boudary is missing). The attribute defects is also empty

In the attachment (sample.tgz) you will find:
   - orig.eml : an email with an invalid structure The boundary
"000101020201080900040301" isn't closed
   - after_parsing.eml: same email after calling email.message_from_file()
The boundary is now closed. And the defects attribute is empty
   - test.py: python script to reproduce.

----------
components: None
files: sample.tgz
messages: 139982
nosy: r.david.murray, xavierd
priority: normal
severity: normal
status: open
title: The email package modifies the message structure (when the parsed email is invalid)
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file22606/sample.tgz

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

From report at bugs.python.org  Thu Jul  7 21:56:46 2011
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Thu, 07 Jul 2011 19:56:46 +0000
Subject: [New-bugs-announce] [issue12516] imghdr.what should take one
	argument
In-Reply-To: <1310068606.02.0.0739859897948.issue12516@psf.upfronthosting.co.za>
Message-ID: <1310068606.02.0.0739859897948.issue12516@psf.upfronthosting.co.za>


New submission from Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com>:

Currently imghdr.what() accepts two parameters. The first is a file or filename and the second is a byte stream. If the second is not None, the first is ignored. This is clunky. It would be simpler to accept just one argument, which can be either an open file or a byte stream.

I have attached a patch which implements this one argument approach as private function imghdr_what(). I have left imghdr.what() as a wrapper around this new function for backwards compatibility (in the hopes that it will eventually be replaced).

In addition, there did not seem to be any tests for the imghdr module, so I added a few simple tests.

----------
components: Library (Lib)
files: imghdr.patch
keywords: patch
messages: 139993
nosy: jfinkels
priority: normal
severity: normal
status: open
title: imghdr.what should take one argument
type: feature request
versions: Python 3.4
Added file: http://bugs.python.org/file22608/imghdr.patch

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

From report at bugs.python.org  Fri Jul  8 00:54:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 22:54:10 +0000
Subject: [New-bugs-announce] [issue12517] Large file support on Windows:
	sizeof(off_t) is 32 bits
In-Reply-To: <1310079250.24.0.0290880980981.issue12517@psf.upfronthosting.co.za>
Message-ID: <1310079250.24.0.0290880980981.issue12517@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

FileIO.readall() and _parse_off_t() help of the posix module use the off_t type. This type is only 32 bits long and so don't support files bigger than 4 GB (or maybe just 2 GB?). The Py_off_t type should be used instead.

----------
components: Windows
messages: 139997
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: Large file support on Windows: sizeof(off_t) is 32 bits
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul  8 02:36:49 2011
From: report at bugs.python.org (py.user)
Date: Fri, 08 Jul 2011 00:36:49 +0000
Subject: [New-bugs-announce] [issue12518] In string.Template it's impossible
	to transform	delimiter in the derived class
In-Reply-To: <1310085409.68.0.478281072881.issue12518@psf.upfronthosting.co.za>
Message-ID: <1310085409.68.0.478281072881.issue12518@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

>>> import string
>>> class MyTemplate(string.Template):
...   delimiter = '.'
... 
>>> MyTemplate.delimiter = 'x'
>>> mt = MyTemplate('.field xfield')
>>> mt.substitute(field=None)
'None xfield'
>>> mt.delimiter
'x'
>>>


If I want to change the pattern string by any delimiter, I should create a new class for every delimiter

I would change the delimiter either in the object or in the class at any time

----------
components: Library (Lib)
messages: 140010
nosy: py.user
priority: normal
severity: normal
status: open
title: In string.Template it's impossible to transform delimiter in the derived class
type: feature request
versions: Python 3.1

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

From report at bugs.python.org  Fri Jul  8 15:53:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Jul 2011 13:53:46 +0000
Subject: [New-bugs-announce] [issue12519] Call next version 3.3.0
In-Reply-To: <1310133226.52.0.80498205219.issue12519@psf.upfronthosting.co.za>
Message-ID: <1310133226.52.0.80498205219.issue12519@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

As discussed and agreed shortly before the 3.2 release, it?d be best to call the first 3.3 release 3.3.0.

----------
assignee: georg.brandl
messages: 140025
nosy: eric.araujo, georg.brandl, terry.reedy
priority: normal
severity: normal
status: open
title: Call next version 3.3.0
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  8 23:54:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jul 2011 21:54:47 +0000
Subject: [New-bugs-announce] [issue12520] spurious output in test_warnings
In-Reply-To: <1310162087.96.0.0645657657853.issue12520@psf.upfronthosting.co.za>
Message-ID: <1310162087.96.0.0645657657853.issue12520@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

$ ./python -m test test_warnings
[1/1] test_warnings
test.test_warnings:553: UserWarning: test

Also, I don't understand how test_filename_none is supposed to check for issue #12467 (it doesn't use a subprocess).

----------
assignee: haypo
components: Tests
messages: 140043
nosy: haypo, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: spurious output in test_warnings
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul  9 04:03:57 2011
From: report at bugs.python.org (Alastair McCann)
Date: Sat, 09 Jul 2011 02:03:57 +0000
Subject: [New-bugs-announce] [issue12521] Mac OS 10.6 Tcl/Tk 8.5 -
	ActiveState Tcl/Tk 8.5
In-Reply-To: <1310177037.34.0.820762578532.issue12521@psf.upfronthosting.co.za>
Message-ID: <1310177037.34.0.820762578532.issue12521@psf.upfronthosting.co.za>


New submission from Alastair McCann <alastair.mccann at gmail.com>:

I am running Python 3.2 on Mac OSX 10.6.8 I have installed ActiveState Tcl/Tk 8.5.

I installed Python first, and then Tcl/Tk.

When I create a simple script, IDLE crashes every time I try to execute it.

Any suggestions??

----------
components: IDLE
messages: 140046
nosy: almccann
priority: normal
severity: normal
status: open
title: Mac OS 10.6 Tcl/Tk 8.5 - ActiveState Tcl/Tk 8.5
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Sat Jul  9 13:59:06 2011
From: report at bugs.python.org (Ram Rachum)
Date: Sat, 09 Jul 2011 11:59:06 +0000
Subject: [New-bugs-announce] [issue12522] Implement `os.startfile` under
	Linux and Mac
In-Reply-To: <1310212746.09.0.561501840609.issue12522@psf.upfronthosting.co.za>
Message-ID: <1310212746.09.0.561501840609.issue12522@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

I want to use `os.startfile` to open a folder in Explorer/Nautilus/Finder. The documentation says that it's only implemented on Windows:

http://docs.python.org/dev/library/os.html#os.startfile

See discussion on Python-ideas here:
https://groups.google.com/forum/?hl=en#!topic/python-ideas/LL0SavbKrEA


Is there a good reason why `os.startfile` is implemented only on Windows?

----------
components: Library (Lib)
messages: 140057
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Implement `os.startfile` under Linux and Mac
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul 10 02:04:24 2011
From: report at bugs.python.org (Gry)
Date: Sun, 10 Jul 2011 00:04:24 +0000
Subject: [New-bugs-announce] [issue12523] 'str' object has no attribute
	'more'	[/usr/lib/python3.2/asynchat.py|initiate_send|245]
In-Reply-To: <1310256264.97.0.142665013721.issue12523@psf.upfronthosting.co.za>
Message-ID: <1310256264.97.0.142665013721.issue12523@psf.upfronthosting.co.za>


New submission from Gry <gryllida at gmail.com>:

Asynchat push() function has a bug which prevents it from functioning.

This code worked fine with Python 2.

---------------------------------------------------------------
# https://github.com/jstoker/BasicBot
import asynchat,asyncore,socket
class asynchat_bot(asynchat.async_chat):
def __init__(self, host, port):
asynchat.async_chat.__init__(self)
self.create_socket(socket.AF_INET,socket.SOCK_STREAM)
self.set_terminator('\r\n')
self.data=''
self.remote=(host,port)
self.connect(self.remote)

def handle_connect(self):
self.push('USER BasicBot 8 %s :BasicBot! http://github.com/jstoker/BasicBot\r\nNICK testbot\r\n' % self.remote[0])

def get_data(self):
r=self.data
self.data=''
return r
def collect_incoming_data(self, data):
self.data+=data
def found_terminator(self):
data=self.get_data()
if data[:4] == 'PING':
self.push('PONG %s' % data[5:]+'\r\n')
if '001' in data:
self.push('JOIN #bots\r\n')
if '~hi' in data:
self.push('PRIVMSG #bots :hi.\r\n')
if __name__ == '__main__':
asynchat_bot('127.0.0.1',16667)
asyncore.loop()
---------------------------------------------------------------


In Python 3 however, the exception follows:


---------------------------------------------------------------
~/tests/BasicBot$ python3 asynchat_bot.py
error: uncaptured python exception, closing channel <__main__.asynchat_bot connected at 0xb70078ac> (<class 'AttributeError'>:'str' object has no attribute 'more' [/usr/lib/python3.2/asyncore.py|write|89] [/usr/lib/python3.2/asyncore.py|handle_write_event|462] [/usr/lib/python3.2/asynchat.py|handle_write|194] [/usr/lib/python3.2/asynchat.py|initiate_send|245])
~/tests/BasicBot$ python3 -V
Python 3.2
~/tests/BasicBot$
---------------------------------------------------------------

A comment from Stackoverflow on why it happens:

---------------------------------------------------------------
The error seems to be raised in /usr/lib/python3.2/asynchat.py|initiate_send|245.

def initiate_send(self):
    while self.producer_fifo and self.connected:
        first = self.producer_fifo[0]
        ...
        try:
            data = buffer(first, 0, obs)
        except TypeError:
            data = first.more() <--- here 

Seems like somebody put a string in self.producer_fifo instead of an asyncchat.simple_producer, which is the only class in async*.py with a more() method.

----------
components: None
messages: 140073
nosy: Gry
priority: normal
severity: normal
status: open
title: 'str' object has no attribute 'more' [/usr/lib/python3.2/asynchat.py|initiate_send|245]
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Sun Jul 10 11:05:32 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 10 Jul 2011 09:05:32 +0000
Subject: [New-bugs-announce] [issue12524] change httplib docs POST example
In-Reply-To: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
Message-ID: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

The POST example in the httplib docs references musi-cal.mojam.com, which is now defunct.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 140074
nosy: docs at python, georg.brandl
priority: low
severity: normal
status: open
title: change httplib docs POST example

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

From report at bugs.python.org  Sun Jul 10 14:49:42 2011
From: report at bugs.python.org (Amandeep Singh)
Date: Sun, 10 Jul 2011 12:49:42 +0000
Subject: [New-bugs-announce] [issue12525] Unable to run a thread
In-Reply-To: <1310302182.7.0.901350004785.issue12525@psf.upfronthosting.co.za>
Message-ID: <1310302182.7.0.901350004785.issue12525@psf.upfronthosting.co.za>


New submission from Amandeep Singh <newtodisworld at gmail.com>:

I created a thread, and started it and then called its run method. It raised an AttributeError exception


from threading import Thread

def func():
  print 'abc'

t = Thread(None, func)
t.start()
t.run()

here t.run() raises an exception.

----------
components: Build
messages: 140077
nosy: newtodisworld
priority: normal
severity: normal
status: open
title: Unable to run a thread
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jul 10 17:40:48 2011
From: report at bugs.python.org (Michael Mulich)
Date: Sun, 10 Jul 2011 15:40:48 +0000
Subject: [New-bugs-announce] [issue12526] packaging.pypi.Crawler and
	resulting objects have a	circular API
In-Reply-To: <1310312448.84.0.700662725694.issue12526@psf.upfronthosting.co.za>
Message-ID: <1310312448.84.0.700662725694.issue12526@psf.upfronthosting.co.za>


New submission from Michael Mulich <michael.mulich at gmail.com>:

The issue, as best I can describe it, is in how the a release list (packaging.pypi.dist.ReleaseList) looks up releases.

Here is a simple example using a random package on PyPI.

>>> crawler = Crawler()
>>> projects = crawler.search_projects('snimpy')
>>> projects
[<Project "snimpy">]
>>> project = projects[0]
>>> [x for x in project]
[]

The results show that project 'snimpy' has no releases, but this is incorrect because distribution 'snimpy' has five releases.

Even after calling sort_releases and fetch_releases on the project which both refer back to the crawler instance (see the project's _index attribute) the project fails to get the releases.

>>> project.fetch_releases()
[]
>>> project.sort_releases()
>>> [x for x in project]
[]

In order to get the releases, one is forced to use the crawler's
API rather than the resulting project's API.

>>> crawler.get_releases(project.name, force_update=True)
<Project "snimpy" versions: 0.5, 0.4, 0.3, 0.2.1, 0.2>
>>> [x for x in project]
[<snimpy 0.5>, <snimpy 0.4>, <snimpy 0.3>, <snimpy 0.2.1>, <snimpy 0.2>]

So as far as I can gather, We lack the ability to forcibly update the project (or ReleaseList). I don't have a solution at this time, but we may want to look into adding a force_update argument to the get_release method on the Crawler.

----------
assignee: tarek
components: Distutils2
messages: 140083
nosy: alexis, eric.araujo, michael.mulich, tarek
priority: normal
severity: normal
status: open
title: packaging.pypi.Crawler and resulting objects have a circular API
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul 10 18:34:50 2011
From: report at bugs.python.org (Brian Jones)
Date: Sun, 10 Jul 2011 16:34:50 +0000
Subject: [New-bugs-announce] [issue12527] assertRaisesRegex doc'd with 'msg'
	arg, but it's not implemented?
In-Reply-To: <1310315690.64.0.281773065195.issue12527@psf.upfronthosting.co.za>
Message-ID: <1310315690.64.0.281773065195.issue12527@psf.upfronthosting.co.za>


New submission from Brian Jones <bkjones at gmail.com>:

The documentation here:
http://docs.python.org/dev/library/unittest.html#unittest.TestCase.assertRaisesRegex

Indicates that, when used as a context manager, assertRaisesRegex should accept a keyword argument 'msg'. However, that doesn't appear to actually be implemented. I've just now done an hg pull, and in Lib/unittest/case.py, the source is here: 

    def assertRaisesRegex(self, expected_exception, expected_regex,
                          callable_obj=None, *args, **kwargs):
        """Asserts that the message in a raised exception matches a regex.

        Args:
            expected_exception: Exception class expected to be raised.
            expected_regex: Regex (re pattern object or string) expected
                    to be found in error message.
            callable_obj: Function to be called.
            msg: Optional message used in case of failure. Can only be used
                    when assertRaisesRegex is used as a context manager.
            args: Extra args.
            kwargs: Extra kwargs.
        """
        context = _AssertRaisesContext(expected_exception, self, callable_obj,
                                       expected_regex)

        return context.handle('assertRaisesRegex', callable_obj, args, kwargs)

I noticed this after attempting some simple example uses of assertRaisesRegex. Perhaps I'm just missing something that will be made obvious to others by seeing them. These are just various attempts to get my msg shown somewhere in the output: 

#!/usr/bin/env python3.3
import unittest

class TestInt(unittest.TestCase):
    def test_intfail(self):
        # this test should *not* fail, and doesn't
        with self.assertRaisesRegex(ValueError, 'literal'):
            int('XYZ')

    def test_intfail2(self):
        # should not fail, and doesn't
        with self.assertRaisesRegex(ValueError, 'lambda', msg='Foo!'):
            int('ABC')

    def test_intfail3(self):
        # should fail, and does, but no msg to be found.
        with self.assertRaisesRegex(ValueError, 'literal', msg='Foo!'):
            int(1)

    def test_intfail4(self):
        # should fail, and does, but no msg to be found.
        with self.assertRaisesRegex(TypeError, 'literal', msg='Foo!'):
            int('ABC')

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

----------
components: Library (Lib)
messages: 140084
nosy: Brian.Jones
priority: normal
severity: normal
status: open
title: assertRaisesRegex doc'd with 'msg' arg, but it's not implemented?
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul 10 21:52:37 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sun, 10 Jul 2011 19:52:37 +0000
Subject: [New-bugs-announce] [issue12528] Implement configurable bitfield
	allocation strategy
In-Reply-To: <1310327557.36.0.947857913804.issue12528@psf.upfronthosting.co.za>
Message-ID: <1310327557.36.0.947857913804.issue12528@psf.upfronthosting.co.za>


New submission from Vlad Riscutia <riscutiavlad at gmail.com>:

Opened this issue to track configurable bitfield allocation strategy. This will address issues like http://bugs.python.org/issue6069, http://bugs.python.org/issue11920.

Summary: the way bitfields are allocated is up to the compiler not defined by standard. MSVC and GCC have different strategies to perform the allocation so the size of bitfield structures can be different depending on compiler. Currently we hardcode allocation strategy to be GCC-way on non-Windows and MSVC-way on Windows which raises issues when trying to interop on Windows with GCC binaries.

Short term this solution will enable interop between MSVC compiled Python with GCC compiled binaries under Windows. It will also enable addressing other possible compiler interop issues in the future, for compilers that don't use GCC strategy.

Following is copied from thread discussing this:


On 6/25/2011 12:33 PM, Vlad Riscutia wrote:
I recently started looking at some ctypes issues. I dug a bit into
http://bugs.python.org/issue6069 and then I found
http://bugs.python.org/issue11920. They both boil down to the fact that
bitfield allocation is up to the compiler, which is different in GCC and
MSVC. Currently we have hard-coded allocation strategy based on paltform
in cfields.c:

 if (bitsize /* this is a bitfield request */

       &&  *pfield_size /* we have a bitfield open */
 #ifdef MS_WIN32
       /* MSVC, GCC with -mms-bitfields */
       &&  dict->size * 8 == *pfield_size
 #else
       /* GCC */
       &&  dict->size * 8<= *pfield_size
 #endif
       &&  (*pbitofs + bitsize)<= *pfield_size) {
       /* continue bit field */
       fieldtype = CONT_BITFIELD;
 #ifndef MS_WIN32
   } else if (bitsize /* this is a bitfield request */
       &&  *pfield_size /* we have a bitfield open */
       &&  dict->size * 8>= *pfield_size
       &&  (*pbitofs + bitsize)<= dict->size * 8) {
       /* expand bit field */
       fieldtype = EXPAND_BITFIELD;
 #endif

So when creating a bitfield structure, it's size can be different on
Linux vs Windows.

class MyStructure(ctypes.BigEndianStructure):
    _pack_      = 1    # aligned to 8 bits, not ctypes default of 32
    _fields_    = [
                   ("Data0",   ctypes.c_uint32, 32),
                   ("Data1",   ctypes.c_uint8, 3),
                   ("Data2",   ctypes.c_uint16, 12),
                  ]

sizeof for above structure is 6 on GCC build and 7 on MSVC build. This
leads to some confusion and issues, because we can't always interop
correctly with code compiled with different compiler than the one Python
is compiled with on the platform.

Just curious, are you saying that this is the 'cause' of the two bug reports, or 'just' something you discovered while investigating them?


> Short term solution is to add a warning in the documentation about this.

For 2.7/3.2, yes.


> Longer term though, I think it
would be better to add a property on the Structure class for
configurable allocation strategy, for example Native (default), GCC,
MSVC and when allocating the bitfield, use given strategy. Native would
behave similar to what happens now, but we would also allow GCC-style
allocation on Windows for example and the ability to extend this if we
ever run into similar issues with other compilers. This shouldn't be too
difficult to implement, will be backwards compatible and it would
improve interop. I would like to hear some opinions on this.

If this would allow the MSVC-compilied Python to better access dlls compiled with gcc (cygwin) on Windows, definitely -- in 3.3.
If the new feature is (currently) only useful on Windows, doc should say so.

-- 
Terry Jan Reedy

/copy

Attached is patch with initial refactoring of cfield.c to enable configurable allocation. Next step is to provide a way to configure this through Python library. I will also look at updating documentation to point out the known issue.

----------
components: ctypes
files: cfield_bitfield_refactoring.diff
keywords: patch
messages: 140088
nosy: terry.reedy, vladris
priority: normal
severity: normal
status: open
title: Implement configurable bitfield allocation strategy
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22617/cfield_bitfield_refactoring.diff

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

From report at bugs.python.org  Sun Jul 10 22:56:05 2011
From: report at bugs.python.org (Ben Darnell)
Date: Sun, 10 Jul 2011 20:56:05 +0000
Subject: [New-bugs-announce] [issue12529] cgi.parse_header fails on double
	quotes and semicolons
In-Reply-To: <1310331365.35.0.0304262740475.issue12529@psf.upfronthosting.co.za>
Message-ID: <1310331365.35.0.0304262740475.issue12529@psf.upfronthosting.co.za>


New submission from Ben Darnell <ben.darnell at gmail.com>:

cgi.parse_header doesn't work on headers that contain combinations of double quotes and semicolons (although it works with either type of character individually).  

>>> cgi.parse_header('form-data; name="files"; filename="fo\\"o;bar"')
('form-data', {'name': 'files', 'filename': '"fo\\"o'})

This issue is present in python 2.7 and 3.2.  One solution is to change _parseparam as follows (same as email.message._parseparam):

def _parseparam(s):
    while s[:1] == ';':
        s = s[1:]
        end = s.find(';')
        while end > 0 and (s.count('"', 0, end) - s.count('\\"', 0, end)) % 2:
            end = s.find(';', end + 1)
        if end < 0:
            end = len(s)
        f = s[:end]
        yield f.strip()
        s = s[end:]

----------
messages: 140091
nosy: Ben.Darnell
priority: normal
severity: normal
status: open
title: cgi.parse_header fails on double quotes and semicolons

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

From report at bugs.python.org  Mon Jul 11 06:47:56 2011
From: report at bugs.python.org (Campbell Barton)
Date: Mon, 11 Jul 2011 04:47:56 +0000
Subject: [New-bugs-announce] [issue12530] cpython 3.3, __class__ missing.
In-Reply-To: <1310359676.9.0.347835677335.issue12530@psf.upfronthosting.co.za>
Message-ID: <1310359676.9.0.347835677335.issue12530@psf.upfronthosting.co.za>


New submission from Campbell Barton <ideasman42 at gmail.com>:

In python 3.2 this works and prints <class '__main__.Test'>,
in cpython hg: 71296:ab162f925761 it fails with:
 NameError: global name '__class__' is not defined

Since this change is not documented I assume its a bug.

--- snip ---
class Test:
  def __init__(self): print(__class__)

----------
components: Interpreter Core
messages: 140099
nosy: ideasman42
priority: normal
severity: normal
status: open
title: cpython 3.3, __class__ missing.
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 11 14:03:43 2011
From: report at bugs.python.org (Peter Eisentraut)
Date: Mon, 11 Jul 2011 12:03:43 +0000
Subject: [New-bugs-announce] [issue12531] documentation index entries for *
	and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>


New submission from Peter Eisentraut <peter_e at gmx.net>:

The existing documentation index entries for * and ** only point to their use in function definitions but not to their use in function calls.  I was looking for the latter, and it was difficult to find without this.  Here is a small patch to add the additional entries.

----------
assignee: docs at python
components: Documentation
files: python-doc-index-**.patch
keywords: patch
messages: 140113
nosy: docs at python, petere
priority: normal
severity: normal
status: open
title: documentation index entries for * and **
versions: Python 3.3
Added file: http://bugs.python.org/file22619/python-doc-index-**.patch

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

From report at bugs.python.org  Mon Jul 11 15:01:38 2011
From: report at bugs.python.org (Michael Mulich)
Date: Mon, 11 Jul 2011 13:01:38 +0000
Subject: [New-bugs-announce] [issue12532] PyPI server index names with '/'
	in them
In-Reply-To: <1310389298.77.0.644675423284.issue12532@psf.upfronthosting.co.za>
Message-ID: <1310389298.77.0.644675423284.issue12532@psf.upfronthosting.co.za>


New submission from Michael Mulich <michael.mulich at gmail.com>:

Forward slashes show up in a project's (packaging.pypi.dist.ReleaseList) name when using a crawler (packaging.pypi.simple.Crawler) against, say and Apache index page. The packaging.tests:/pypiserver/foo_bar_baz directory is a perfect example of this type of data, but it isn't used anywhere in the current tests.

If a crawl is run on the index, results will come back with '/' in there name.

The issue was found when I was attempting to use a Crawler against the packaging.tests.pypi_server.PyPIServer in my package's tests.

----------
assignee: tarek
components: Distutils2
files: test_name.py
messages: 140117
nosy: alexis, eric.araujo, michael.mulich, tarek
priority: normal
severity: normal
status: open
title: PyPI server index names with '/' in them
versions: Python 3.3
Added file: http://bugs.python.org/file22621/test_name.py

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

From report at bugs.python.org  Mon Jul 11 16:32:24 2011
From: report at bugs.python.org (=?utf-8?q?Kristoffer_Grundstr=C3=B6m?=)
Date: Mon, 11 Jul 2011 14:32:24 +0000
Subject: [New-bugs-announce] [issue12533] python-celementtree prevents me
	from running python	develop.py to compile Imprudence Viewer
In-Reply-To: <1310394744.41.0.195161655519.issue12533@psf.upfronthosting.co.za>
Message-ID: <1310394744.41.0.195161655519.issue12533@psf.upfronthosting.co.za>


New submission from Kristoffer Grundstr?m <kristoffer.grundstrom1983 at gmail.com>:

I went to the wiki of Imprudence Viewer & then I went to the Compiling-part. Then I downloaded latest code from git. I installed everything needed. Then I went into Desktop/imprudence/linden/indra & wrote python develop.py & that resulted in this: http://pastebin.mandriva.com/23157

I then tried to import using the interpreter, but still I got the same issue.

I then uninstalled python-celementtree & ran python develop.py & then everything went on OK.

----------
components: Interpreter Core
messages: 140126
nosy: Kristoffer.Grundstr?m
priority: normal
severity: normal
status: open
title: python-celementtree prevents me from running python develop.py to compile Imprudence Viewer
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 11 18:56:28 2011
From: report at bugs.python.org (Aaron Stevens)
Date: Mon, 11 Jul 2011 16:56:28 +0000
Subject: [New-bugs-announce] [issue12534] Tkinter doesn't support property
	attributes
In-Reply-To: <1310403388.57.0.795196885284.issue12534@psf.upfronthosting.co.za>
Message-ID: <1310403388.57.0.795196885284.issue12534@psf.upfronthosting.co.za>


New submission from Aaron Stevens <aaron.stevens at molex.com>:

When using Tkinter in Python 2.6.6, it is impossible to use the new-style properties, as the base classes (Misc, Pack, Place, and Grid) do not use the new style classes.

It is easily fixed by changing the class declarations, i.e.:
  class Misc:
 becomes
  class Misc(object):

----------
components: Tkinter
messages: 140148
nosy: bheklilr
priority: normal
severity: normal
status: open
title: Tkinter doesn't support property attributes
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jul 11 19:33:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jul 2011 17:33:03 +0000
Subject: [New-bugs-announce] [issue12535] Chained tracebacks are confusing
	because the first	traceback is minimal
In-Reply-To: <1310405583.64.0.419150537523.issue12535@psf.upfronthosting.co.za>
Message-ID: <1310405583.64.0.419150537523.issue12535@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Consider the following traceback:

Traceback (most recent call last):
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 466, in __getattr__
    return getattr(self._headers, key)
AttributeError: '_Header_List' object has no attribute 'header_factory'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rdmurray/python/email6/Lib/mailbox.py", line 1631, in set_flags
    self.replace_header('Status', status_flags)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 495, in replace_header
    print('rep', self.header_factory)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 469, in __getattr__
    self.__class__.__name__, key))
AttributeError: 'mboxMessage' object has no attribute 'header_factory'


The first traceback, which is supposed to be the "primary" error, gives
no indication of where the problem occured.  It starts with a fairly
deeply nested call.  The second traceback does show the line where the
error occured in the except statement, but you have to read the lines
above it to find the line that actually triggered the original
traceback.

I think it would be much better if either the full traceback were
given for the first traceback, or for both of them.  I realize
that the short traceback for the first traceback is how things
have "traditionally" worked when exceptions are caught, but as
evidenced by issue 1553375 this is often not the desired behavior
even before the existence of chained exceptions.

----------
components: Interpreter Core
messages: 140153
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: Chained tracebacks are confusing because the first traceback is minimal
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jul 11 19:58:21 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 11 Jul 2011 17:58:21 +0000
Subject: [New-bugs-announce] [issue12536] lib2to3 BaseFix class creates
	un-needed loggers leading	to refleaks
In-Reply-To: <1310407101.06.0.821103833142.issue12536@psf.upfronthosting.co.za>
Message-ID: <1310407101.06.0.821103833142.issue12536@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

See #12167 for background.

The BaseFix class creates a logger named with the filename when the set_filename method is called. This logger appears to never be used, but since set_filename could be called any number of times and loggers are effectively singletons and not garbage collected, this could lead to refleaks and unbounded memory usage for no benefit.

It's possible to output contextual information about a file being worked on without needing to create a logger with the filename.

I'm proposing that the references to the logger in BaseFix be removed, as the logger isn't used anyway, and the test suite runs without failures when the references are removed. This will allow progress on #12167.

----------
components: 2to3 (2.x to 3.0 conversion tool), Library (Lib)
keywords: easy
messages: 140155
nosy: benjamin.peterson, eric.araujo, vinay.sajip
priority: normal
severity: normal
status: open
title: lib2to3 BaseFix class creates un-needed loggers leading to refleaks
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 11 20:31:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jul 2011 18:31:15 +0000
Subject: [New-bugs-announce] [issue12537] mailbox's _become_message is very
	fragile
In-Reply-To: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za>
Message-ID: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The mailbox module has a method _become_message that copies attributes from an object that is an email.message.Message subclass to the calling object (which is also a subclass of email.message.Message).  This method is very fragile in the face of any changes to the email.message.Message attribute set.

Instead it would be better to decouple the mailbox and email modules by copying *all* __dict__ attributes from the source message to the new object, and then rewrite the _explain_to methods to not only convert the 'special attributes' to the correct format for the new subclass, but also delete any leftover "special" attributes.

----------
components: Library (Lib)
keywords: easy
messages: 140157
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: mailbox's _become_message is very fragile
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 11 22:26:03 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Mon, 11 Jul 2011 20:26:03 +0000
Subject: [New-bugs-announce] [issue12538] Extending int class
In-Reply-To: <1310415963.68.0.740269303687.issue12538@psf.upfronthosting.co.za>
Message-ID: <1310415963.68.0.740269303687.issue12538@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo <jbvsmo at gmail.com>:

I'm having trouble subclassing the int type and I think this behavior is a bug... (Python 3.2)

>>> class One(int):
	def __init__(self):
		super().__init__(1)

>>> one = One()
>>> one + 2
2
>>> one == 0
True

I know `int` objects are immutable but my `One` class should be mutable... and why it doesn't raise an error?

That gives the same result on Python 2.7 using super properly.

Also, if that's not a bug, how it should be done to achieve "one + 2 == 3" without creating another attribute.

Things I also tried:
    self.real = 1  #readonly attribute error
    int.__init__(self, 1)  #same behavior

I Couldn't find any related issues... sorry if it's repeated.

----------
components: Interpreter Core
messages: 140161
nosy: JBernardo
priority: normal
severity: normal
status: open
title: Extending int class
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Jul 12 01:06:22 2011
From: report at bugs.python.org (mokrates)
Date: Mon, 11 Jul 2011 23:06:22 +0000
Subject: [New-bugs-announce] [issue12539] multiprocessing.Event.wait(n)
	doesn't time out properly
In-Reply-To: <1310425582.71.0.534887879142.issue12539@psf.upfronthosting.co.za>
Message-ID: <1310425582.71.0.534887879142.issue12539@psf.upfronthosting.co.za>


New submission from mokrates <mmolle at gmx.net>:

Following is my problem:
I have two processes, connected via multiprocessing.Event
The one waits for the other with .wait(300). After 300 seconds it should look if there's work, even if it has not been awoken by the other process.
So. This runs on my Laptop, and when I fold it shut, sending it to suspend, and open it again, lets say, 10 minutes later (which are 600 seconds), then the .wait()-timeout has already gone. I would assume, cause it's a /timeout/ that it should then fire ASAP, but it fires never. The worker process is just frozen and has to be awoken by .set()ing the Event.

I workarounded it by creating another thread, which uses time.sleep(300) instead of multiprocessing.Event.wait(300) to wait 300 seconds and some glue to put it all together.

some stats:
me at mybox:~$ python2.7
Python 2.7.1+ (default, Apr 20 2011, 22:33:39) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
me at mybox:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux testing (wheezy)
Release:	testing
Codename:	wheezy

----------
messages: 140165
nosy: mokrates
priority: normal
severity: normal
status: open
title: multiprocessing.Event.wait(n) doesn't time out properly
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul 12 11:21:41 2011
From: report at bugs.python.org (Peter Caven)
Date: Tue, 12 Jul 2011 09:21:41 +0000
Subject: [New-bugs-announce] [issue12540] "Restart Shell" command leaves
	pythonw.exe processes	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>


New submission from Peter Caven <pcaven at gmail.com>:

On Windows Vista (x64) the IDLE "Restart Shell" command leaves a "pythonw.exe" process running each time that the command is used.
Observed in Python 3.2.1 release and RC2.

----------
components: IDLE
messages: 140179
nosy: Peter.Caven
priority: normal
severity: normal
status: open
title: "Restart Shell" command leaves pythonw.exe processes running
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Tue Jul 12 15:48:19 2011
From: report at bugs.python.org (Alex Leon)
Date: Tue, 12 Jul 2011 13:48:19 +0000
Subject: [New-bugs-announce] [issue12541] Accepting Badly formed headers in
	urllib HTTPBasicAuth
In-Reply-To: <1310478499.65.0.178767259424.issue12541@psf.upfronthosting.co.za>
Message-ID: <1310478499.65.0.178767259424.issue12541@psf.upfronthosting.co.za>


New submission from Alex Leon <aeleon at gmail.com>:

It looks like some servers using basic authentication don't include quotes around the realm (example https://api.connect2field.com) as required by rfc 2617. urllib wont handle these requests and silently fails, but a simple change to the regex in AbstractBasicAuthHandler from
 
'realm=(["\'])(.*?)\\2', re.I)
to
'realm=(["\']?)(["\']*)\\2', re.I)

would make authentication more flexible.

----------
components: Library (Lib)
messages: 140191
nosy: Alex.Leon
priority: normal
severity: normal
status: open
title: Accepting Badly formed headers in urllib HTTPBasicAuth
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Jul 12 15:59:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 13:59:46 +0000
Subject: [New-bugs-announce] [issue12542] Remove duplicates of cmp_to_key
	used in tests
In-Reply-To: <1310479186.26.0.28744944835.issue12542@psf.upfronthosting.co.za>
Message-ID: <1310479186.26.0.28744944835.issue12542@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Two test files still use their own CmpToKey after the introduction of functools.cmp_to_key.

----------
components: Tests
files: remove-custom-cmptokey.diff
keywords: patch
messages: 140193
nosy: eric.araujo, rhettinger
priority: normal
severity: normal
stage: commit review
status: open
title: Remove duplicates of cmp_to_key used in tests
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22634/remove-custom-cmptokey.diff

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

From report at bugs.python.org  Tue Jul 12 21:16:10 2011
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 12 Jul 2011 19:16:10 +0000
Subject: [New-bugs-announce] [issue12543] `issubclass(collections.deque,
	collections.Sequence) == False`
In-Reply-To: <1310498170.97.0.558143295678.issue12543@psf.upfronthosting.co.za>
Message-ID: <1310498170.97.0.558143295678.issue12543@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

Is there a good reason that `issubclass(collections.deque, collections.Sequence) == False`? What's not-sequence-y about `deque`?

----------
messages: 140206
nosy: cool-RR
priority: normal
severity: normal
status: open
title: `issubclass(collections.deque, collections.Sequence) == False`

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

From report at bugs.python.org  Wed Jul 13 02:05:54 2011
From: report at bugs.python.org (Martin)
Date: Wed, 13 Jul 2011 00:05:54 +0000
Subject: [New-bugs-announce] [issue12544] Avoid using a pseudo-dict for
	_type_equality_funcs in	unittest
In-Reply-To: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>
Message-ID: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>


New submission from Martin <gzlist at googlemail.com>:

The fix for issue 10326 landing on Python 2.7 trunk has interfered with a hack I wrote in Bazaar to break the reference cycles the private `unittest.TestCase._type_equality_funcs` member creates.

As the change to make pickling work is nearly enough to avoid the test and the dict referencing each other, it would be good to remove that breakage and the need for the hack in the first place.

Downstream bug:

<https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/809048>

----------
components: Library (Lib)
messages: 140217
nosy: MarkRoddy, gz, michael.foord
priority: normal
severity: normal
status: open
title: Avoid using a pseudo-dict for _type_equality_funcs in unittest
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jul 13 05:29:19 2011
From: report at bugs.python.org (Kuberan Naganathan)
Date: Wed, 13 Jul 2011 03:29:19 +0000
Subject: [New-bugs-announce] [issue12545] Incorrect handling of return codes
	in the posix_lseek	function in posixmodule.c
In-Reply-To: <1310527759.4.0.117442331882.issue12545@psf.upfronthosting.co.za>
Message-ID: <1310527759.4.0.117442331882.issue12545@psf.upfronthosting.co.za>


New submission from Kuberan Naganathan <kubiyak at gmail.com>:

The lseek function can legitimately return a code less then zero ( except for -1 ) when seeking beyond an offset of 2^63.  This behavior should be supported in order to permit the python interpreter to seek in files with valid data at locations greater than or equal to 2^63.  This can happen in a sparse file or in the /proc file system address space file.  

The fix is simple.  In the posix_lseek function check for result != -1 instead of checking for result < 0 in return code checks of the value returned by lseek.

----------
components: IO
messages: 140222
nosy: Kuberan.Naganathan
priority: normal
severity: normal
status: open
title: Incorrect handling of return codes in the posix_lseek function in posixmodule.c
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul 13 08:58:06 2011
From: report at bugs.python.org (Gavin Andresen)
Date: Wed, 13 Jul 2011 06:58:06 +0000
Subject: [New-bugs-announce] [issue12546] str.format cannot fill with \x00
	char
In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za>
Message-ID: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za>


New submission from Gavin Andresen <gavinandresen at gmail.com>:

This gives me "foo   " instead of expected "foo\x00\x00\x00" :

"{0:\x00<6}".format('foo')

----------
components: Library (Lib)
messages: 140225
nosy: Gavin.Andresen
priority: normal
severity: normal
status: open
title: str.format cannot fill with \x00 char
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul 13 10:13:31 2011
From: report at bugs.python.org (July Tikhonov)
Date: Wed, 13 Jul 2011 08:13:31 +0000
Subject: [New-bugs-announce] [issue12547] whatsnew/3.3: error in example
	about nntplib
In-Reply-To: <1310544811.28.0.517615627121.issue12547@psf.upfronthosting.co.za>
Message-ID: <1310544811.28.0.517615627121.issue12547@psf.upfronthosting.co.za>


New submission from July Tikhonov <july.tikh at gmail.com>:

>>> from nntplib import NNTP
>>> with nntplib.NNTP('news.gmane.org') as n:

will not work. It should be

>>> import nntplib
>>> with nntplib.NNTP('news.gmane.org') as n:

or

>>> from nntplib import NNTP
>>> with NNTP('news.gmane.org') as n:

----------
assignee: docs at python
components: Documentation
files: whatsnew.3.3.nntplib.example.diff
keywords: patch
messages: 140228
nosy: docs at python, july
priority: normal
severity: normal
status: open
title: whatsnew/3.3: error in example about nntplib
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file22638/whatsnew.3.3.nntplib.example.diff

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

From report at bugs.python.org  Wed Jul 13 11:35:28 2011
From: report at bugs.python.org (yura levchenko)
Date: Wed, 13 Jul 2011 09:35:28 +0000
Subject: [New-bugs-announce] [issue12548] Add suport native Functor
In-Reply-To: <1310549728.28.0.863675817161.issue12548@psf.upfronthosting.co.za>
Message-ID: <1310549728.28.0.863675817161.issue12548@psf.upfronthosting.co.za>


New submission from yura levchenko <levchenko.yuriy.vladimirovich at gmail.com>:

sample:

def foo(a,b):
 print a,b

foo(1,2)
fa = foo%(1)
fa(2)
fab = foo%(1,2)
fab()

result

12
12
12

----------
components: None
messages: 140239
nosy: yura.levchenko
priority: normal
severity: normal
status: open
title: Add suport native Functor
type: feature request
versions: Python 3.4

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

From report at bugs.python.org  Wed Jul 13 11:49:23 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Wed, 13 Jul 2011 09:49:23 +0000
Subject: [New-bugs-announce] [issue12549] test_platform test_mac_ver fails
	on Darwin x86_64
In-Reply-To: <1310550563.79.0.541656133968.issue12549@psf.upfronthosting.co.za>
Message-ID: <1310550563.79.0.541656133968.issue12549@psf.upfronthosting.co.za>


New submission from Davide Rizzo <sorcio at gmail.com>:

test test_platform failed -- Traceback (most recent call last):
  File "/Users/davide/cpython/Lib/test/test_platform.py", line 194, in test_mac_ver
    self.assertEqual(res[2], 'i386')
AssertionError: 'x86_64' != 'i386'
- x86_64
+ i386


uname reports machine as "x86_64", but the test expects "i386".

Related: the Gestalt call makes no difference between i386 and x86_64 and may only return "i386" as the machine.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 140241
nosy: davide.rizzo, ronaldoussoren
priority: normal
severity: normal
status: open
title: test_platform test_mac_ver fails on Darwin x86_64
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jul 13 12:14:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jul 2011 10:14:12 +0000
Subject: [New-bugs-announce] [issue12550] regrtest: register SIGALRM signal
	using faulthandler
In-Reply-To: <1310552052.01.0.62401562822.issue12550@psf.upfronthosting.co.za>
Message-ID: <1310552052.01.0.62401562822.issue12550@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Sometimes, some tests are stopped because of SIGALRM. A recent example:
-----------------------
[157/357] test_socketserver
Alarm clock
*** Error code 142
-----------------------
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1647/steps/test/logs/stdio

faulthandler is able to dump the Python backtrace in such case, we just have to register the SIGALRM signal handler. regrtest should be patched: just add faulthandler.register(signal.SIGALRM).

It would be nice if faulthandler calls the previous signal handler. By default, it replaces the existing signal handler and so it changes the behaviour.

A test should also be added to faulthandler for SIGALRM, this signal is special because of its default signal handler (it exits the process).

----------
components: Tests
messages: 140243
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest: register SIGALRM signal using faulthandler
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul 13 13:33:25 2011
From: report at bugs.python.org (Jacek Konieczny)
Date: Wed, 13 Jul 2011 11:33:25 +0000
Subject: [New-bugs-announce] [issue12551] Provide data for TLS channel
	binding
In-Reply-To: <1310556805.74.0.156740266858.issue12551@psf.upfronthosting.co.za>
Message-ID: <1310556805.74.0.156740266858.issue12551@psf.upfronthosting.co.za>


New submission from Jacek Konieczny <jajcus at jajcus.net>:

Recently IETF encourages using of the SCRAM-SHA-1-PLUS SASL authentication mechanism (5802) in new protocols. That is a requirement e.g. of the current XMPP specification (RFC6120). Any compliant implementation needs to support the 'SCRAM-SHA-1-PLUS' mechanism, and that requires obtaining the 'tls-unique' channel-binding data from a TLS connection used. Python doesn't provide this information and it seems the only detail stopping anyone from fully implementing XMPP or SCRAM-SHA-1-PLUS alone in Python.

The 'tls-unique' channel binding is defined as:

> Description: The first TLS Finished message sent (note: the Finished
> struct, not the TLS record layer message containing it) in the most
> recent TLS handshake of the TLS connection being bound to

?and is (they say), available via OpenSSL API. This should be exposed by the python SSLSocket object too.

The other channel-binding data type, 'tls-server-end-point' can be computed using current Python API, but it is not enough for most uses ('tls-unique' is the required channel binding data in most cases) and still not trivial (one needs to ASN.1-decode the certificate to get the hash function name to compute proper digest).

----------
components: Library (Lib)
messages: 140247
nosy: Jajcus
priority: normal
severity: normal
status: open
title: Provide data for TLS channel binding
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jul 13 16:37:35 2011
From: report at bugs.python.org (Blame-me Jaillie)
Date: Wed, 13 Jul 2011 14:37:35 +0000
Subject: [New-bugs-announce] [issue12552] email.MIMEText overide BASE64 on
	TEXT/HTML
In-Reply-To: <1310567855.09.0.336758038294.issue12552@psf.upfronthosting.co.za>
Message-ID: <1310567855.09.0.336758038294.issue12552@psf.upfronthosting.co.za>


New submission from Blame-me Jaillie <darkshado.1972 at gmail.com>:

Apologies if this is in the wrong place.

Simple enough issue. This line of code from email.mime:

MIMEText(textonly, 'plain', _charset='UTF-8')
Where 'textonly' is just a plain text email message to be displayed on a multipart message in a client that does not support HTML email.

This always results in: Content-Transfer-Encoding: BASE64
rather than allowing selection of the encoder (7 or 8 bit MIME/quoted printable). The option to set this with _encoders was removed.

This presents a couple of issues. First of all, BASE64 is not optimal for text - it adds (granted small) amounts of overhead and CPU usage. Second, commercial and O/S anti-spam scanners have rules that penalise messages solely BASE64 encoded.

As this is part of the mime email package, a simple flag to set the Content-Transfer-Encoding by hand would be help anyone trying to produce sensible email applications with Python.

Whilst my version of Python is old - I believe this issue remains in later versions.

----------
components: None
messages: 140259
nosy: Blame-me.Jaillie
priority: normal
severity: normal
status: open
title: email.MIMEText overide BASE64 on TEXT/HTML
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Wed Jul 13 18:47:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Jul 2011 16:47:26 +0000
Subject: [New-bugs-announce] [issue12553] email should default to 8bit CTE
	unless	policy.must_be_7bit is set
In-Reply-To: <1310575646.04.0.928731351527.issue12553@psf.upfronthosting.co.za>
Message-ID: <1310575646.04.0.928731351527.issue12553@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Most MTA/MTUs these days can handle 8bit just fine.  I think that the CTE for MIMEText parts should default to 8bit unless policy.must_be_7bit is set.  This will require adding support for this CTE to Charset.  The Policy docs imply that this is already the case, but it is not true for MIMEText objects.

----------
components: Library (Lib)
messages: 140287
nosy: Blame-me.Jaillie, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: email should default to 8bit CTE unless policy.must_be_7bit is set
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul 13 21:44:23 2011
From: report at bugs.python.org (Calvin Spealman)
Date: Wed, 13 Jul 2011 19:44:23 +0000
Subject: [New-bugs-announce] [issue12554] Failed imports clean up module,
	but not sub modules
In-Reply-To: <1310586263.14.0.144683029757.issue12554@psf.upfronthosting.co.za>
Message-ID: <1310586263.14.0.144683029757.issue12554@psf.upfronthosting.co.za>


New submission from Calvin Spealman <ironfroggy at gmail.com>:

I came across this behavior when it was related to the shadowing of a small typo bug and took me forever to find. In my case, the original error was shadowed in a way that is unrelated to this bug, but lead to the module being imported twice (because it was removed when it failed the first time) and then the second import caused a completely unexpected error, because the state of the submodules conflicted with the import-time logic of the top-level package.

I think when a module fails to load, all of its sub-modules should be removed from sys.modules, not just itself.

calvin at willow-delta:/tmp$ mkdir foo/
calvin at willow-delta:/tmp$ cat >> foo/__init__.py
import foo.bar
1/0
calvin at willow-delta:/tmp$ cat >> foo/bar.py
name = "bar"
calvin at willow-delta:/tmp$ python
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "foo/__init__.py", line 2, in <module>
    1/0
ZeroDivisionError: integer division or modulo by zero
>>> import sys
>>> sys.modules['foo.bar']
<module 'foo.bar' from 'foo/bar.py'>
>>>

----------
components: Interpreter Core
messages: 140298
nosy: Calvin.Spealman
priority: normal
severity: normal
status: open
title: Failed imports clean up module, but not sub modules
type: behavior

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

From report at bugs.python.org  Thu Jul 14 00:19:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jul 2011 22:19:32 +0000
Subject: [New-bugs-announce] [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I now have a working PEP 3151 implementation, working on various platforms (tested on Linux, Windows, FreeBSD and OpenIndiana buildbots).

The implementation has all the semantic changes and additions in PEP 3151. It still lacks the deprecation mechanism mentioned in "step 1" of the PEP.

The implementation is at http://hg.python.org/features/pep-3151/ in the branch named "pep-3151".

----------
assignee: pitrou
components: Interpreter Core
messages: 140314
nosy: barry, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: PEP 3151 implementation
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Thu Jul 14 15:21:00 2011
From: report at bugs.python.org (Sergei Lebedev)
Date: Thu, 14 Jul 2011 13:21:00 +0000
Subject: [New-bugs-announce] [issue12556] Disable size checks in mmap.mmap()
In-Reply-To: <1310649660.01.0.028468381149.issue12556@psf.upfronthosting.co.za>
Message-ID: <1310649660.01.0.028468381149.issue12556@psf.upfronthosting.co.za>


New submission from Sergei Lebedev <superbobry at gmail.com>:

Current `mmap` implementation raises a ValueError if a sum of offset and length exceeds file size, as reported by `fstat`. While perfectly valid for most use-cases, it doesn't work for "special" files, for example:

>>> with open("/proc/sys/debug/exception-trace", "r+b") as f:
...     mmap.mmap(f.fileno(), 0)
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
ValueError: mmap offset is greater than file size

Same goes for almost any other /proc file, because most of them have S_ISREG() == True and st_size = 0.

How about adding a keyword argument to `mmap.mmap()`, which disables fstat-based size checks?

----------
components: Library (Lib)
messages: 140330
nosy: superbobry
priority: normal
severity: normal
status: open
title: Disable size checks in mmap.mmap()
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Thu Jul 14 16:27:13 2011
From: report at bugs.python.org (Arsouze)
Date: Thu, 14 Jul 2011 14:27:13 +0000
Subject: [New-bugs-announce] [issue12557] Crash idle on mac
In-Reply-To: <1310653633.65.0.219490792238.issue12557@psf.upfronthosting.co.za>
Message-ID: <1310653633.65.0.219490792238.issue12557@psf.upfronthosting.co.za>


New submission from Arsouze <georges.arsouze at gmail.com>:

Hi
Sorry for my poor english
I'am working on mac os snow leopard with Pyton 3.1
I want to use widgets Tix ot ttk
I have a error message : require Tile

Can you tell me step by step what i must do 
regards

----------
messages: 140337
nosy: georgesarsouze
priority: normal
severity: normal
status: open
title: Crash idle on mac
type: crash

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

From report at bugs.python.org  Thu Jul 14 17:05:06 2011
From: report at bugs.python.org (Hans Bering)
Date: Thu, 14 Jul 2011 15:05:06 +0000
Subject: [New-bugs-announce] [issue12558] Locale-dependent crash for float
	width argument to	Tkinter widget constructor
In-Reply-To: <1310655906.95.0.630445767575.issue12558@psf.upfronthosting.co.za>
Message-ID: <1310655906.95.0.630445767575.issue12558@psf.upfronthosting.co.za>


New submission from Hans Bering <hans.bering at arcor.de>:

The attached script will crash on a current Ubuntu with Python 3.2 + tcl/tk when using a locale which uses a comma as a decimal separator (e.g., German). It will not crash when using a locale which uses a dot as the decimal separator (e.g., English). In case of the crash, the output and stacktrace are as follows:

locale = ('de_DE', 'UTF8')
Traceback (most recent call last):
  File "tkinterCrash.py", line 20, in <module>
    tkcanvas = Canvas(master=master, width=w, height=2, borderwidth=4)
  File "/usr/lib/python3.2/tkinter/__init__.py", line 2101, in __init__
    Widget.__init__(self, master, 'canvas', cnf, kw)
  File "/usr/lib/python3.2/tkinter/__init__.py", line 1961, in __init__
    (widgetName, self._w) + extra + self._options(cnf))
_tkinter.TclError: bad screen distance "10.0"

Originally, we stumbled over this problem when using matplotlib, which passes/passed down float types as width arguments on occasions. It has been fixed there since (see https://github.com/matplotlib/matplotlib/pull/387).

The locale dependency can make this problem difficult to debug when it occurs. In our setup, we had a program work on one machine, but it crashed on the next machine, which we believed to have an identical setup; it took us a day to figure out what the difference was. We would expect the constructor to either always work with float arguments, or to always reject them, regardless of locale.

We have been able to reproduce this issue both with Python 2.7.2 and Python 3.2, both under a current Ubuntu and Windows 7.

----------
components: Tkinter
files: badScreenSizeTk.py
messages: 140338
nosy: hans.bering
priority: normal
severity: normal
status: open
title: Locale-dependent crash for float width argument to Tkinter widget constructor
type: crash
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22653/badScreenSizeTk.py

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

From report at bugs.python.org  Thu Jul 14 17:31:22 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 Jul 2011 15:31:22 +0000
Subject: [New-bugs-announce] [issue12559] gzip.open() needs an optional
	encoding argument
In-Reply-To: <1310657482.81.0.606922001994.issue12559@psf.upfronthosting.co.za>
Message-ID: <1310657482.81.0.606922001994.issue12559@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

gzip.open() should parallel file.open() so that that zipped files can be read in the same way as regular files:

for line in gzip.open('notes.txt', 'r', encoding='latin-1'):
    print(line.rstrip())

----------
components: Library (Lib)
messages: 140341
nosy: rhettinger
priority: normal
severity: normal
status: open
title: gzip.open() needs an optional encoding argument
type: feature request
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jul 14 18:58:12 2011
From: report at bugs.python.org (Stefan Sperling)
Date: Thu, 14 Jul 2011 16:58:12 +0000
Subject: [New-bugs-announce] [issue12560] libpython.so not built on OpenBSD
In-Reply-To: <1310662692.29.0.747944730785.issue12560@psf.upfronthosting.co.za>
Message-ID: <1310662692.29.0.747944730785.issue12560@psf.upfronthosting.co.za>


New submission from Stefan Sperling <stsp at apache.org>:

In Python-2.7.2 (I have not checked other versions, sorry),
the configure script doesn't not define LDLIBRARY on OpenBSD.
Because of this libpython.so does not get built.

----------
components: Build
files: python-2.7.2-configure.diff
keywords: patch
messages: 140343
nosy: stsp
priority: normal
severity: normal
status: open
title: libpython.so not built on OpenBSD
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file22654/python-2.7.2-configure.diff

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

From report at bugs.python.org  Thu Jul 14 19:59:41 2011
From: report at bugs.python.org (Jim Schneider)
Date: Thu, 14 Jul 2011 17:59:41 +0000
Subject: [New-bugs-announce] [issue12561] Compiler workaround for wide
	string constants in	Modules/getpath.c (patch)
In-Reply-To: <1310666381.22.0.322884709649.issue12561@psf.upfronthosting.co.za>
Message-ID: <1310666381.22.0.322884709649.issue12561@psf.upfronthosting.co.za>


New submission from Jim Schneider <jim.schneider at dataflux.com>:

In Modules/getpath.c, the following line (#138) causes problems with some compilers (HP/UX 11, in particular - there could be others):

static wchar_t *lib_python = L"lib/python" VERSION;

Similarly, line #644:

        module_search_path = L"" PYTHONPATH;

The default HP/UX compiler fails to compile this file with the error "Cannot concatenate character string literal and wide string literal".  The attached patch converts these two string literals to wide string literals that the HP/UX compiler can understand.

Very limited testing indicates that the patch is benign (it does not affect the build on Linux running on x86_64).

----------
components: Build
files: getpath.patch
keywords: patch
messages: 140348
nosy: jschneid
priority: normal
severity: normal
status: open
title: Compiler workaround for wide string constants in Modules/getpath.c (patch)
type: compile error
versions: Python 3.2
Added file: http://bugs.python.org/file22655/getpath.patch

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

From report at bugs.python.org  Thu Jul 14 20:00:02 2011
From: report at bugs.python.org (Piotr Zolnierczuk)
Date: Thu, 14 Jul 2011 18:00:02 +0000
Subject: [New-bugs-announce] [issue12562] calling mmap twice fails on Windows
In-Reply-To: <1310666402.94.0.718224462838.issue12562@psf.upfronthosting.co.za>
Message-ID: <1310666402.94.0.718224462838.issue12562@psf.upfronthosting.co.za>


New submission from Piotr Zolnierczuk <piotr.zolnierczuk at gmail.com>:

Hi,
I am trying to migrate from Python 2.5 to Python 2.7 I found though the mmap behaves differently on Windows XP between the two versions. It boils down to the following code:
import mmap
map1 = mmap.mmap(fileno=0, tagname='MyData', length=4096)
map2 = mmap.mmap(fileno=0, tagname='MyData', length=8192)

It runs fine (so I can "resize" shared memory) on XP with 2.5.4, but when running on 2.7.2 I get the following error

Traceback (most recent call last):
  File "D:\Workspace\memmap_test.py", line 3, in <module>
    map2 = mmap.mmap(fileno=0, tagname='MyData', length=8192)
WindowsError: [Error 5] Access is denied

----------
messages: 140349
nosy: zolnie
priority: normal
severity: normal
status: open
title: calling mmap twice fails on Windows
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 14 20:35:11 2011
From: report at bugs.python.org (gungor)
Date: Thu, 14 Jul 2011 18:35:11 +0000
Subject: [New-bugs-announce] [issue12563] Check out my about.me profile!
In-Reply-To: <1310668507.7559571892889138@mf32.sendgrid.net>
Message-ID: <1310668507.7559571892889138@mf32.sendgrid.net>


New submission from gungor <gungorbasa at gmail.com>:

Hi Python,

I set up my about.me splash page and want to share it with you: <http://about.me/gungorbasa?promo=share_1856_378462>.

If you don't have an about.me splash page, you can get one for free at <http://about.me?promo=share_1856_378462>. Names are going fast so you might want to get yours now.

G??ng??rIf you would like to unsubscribe and stop receiving these emails click here: http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&u=pALbODzFR4KGDIyxaHqpmw%2Fut

----------
files: unnamed
messages: 140357
nosy: gungorbasa
priority: normal
severity: normal
status: open
title: Check out my about.me profile!
Added file: http://bugs.python.org/file22657/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12563>
_______________________________________
-------------- next part --------------
Hi Python,<br><br>I set up my about.me splash page and want to share it with you: <a href="http://about.me/gungorbasa?promo=share_1856_378462">http://about.me/gungorbasa</a>.<br><br>If you don't have an about.me splash page, you can get one for free at <a href="http://about.me?promo=share_1856_378462">http://about.me</a>. Names are going fast so you might want to get yours now.<br><br>G??ng??r<p>
	If you would like to unsubscribe and stop receiving these emails <a href="http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=pALbODzFR4KGDIyxaHqpmw%2Fuh">click here</a>.</p>

<img src="http://email.about.me/wf/open?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=pALbODzFR4KGDIyxaHqpmw%2Foo0.gif" alt="">

From report at bugs.python.org  Thu Jul 14 20:36:11 2011
From: report at bugs.python.org (gungor)
Date: Thu, 14 Jul 2011 18:36:11 +0000
Subject: [New-bugs-announce] [issue12564] Check out my about.me profile!
In-Reply-To: <1310668567.7988300458482942@mf38.sendgrid.net>
Message-ID: <1310668567.7988300458482942@mf38.sendgrid.net>


New submission from gungor <gungorbasa at gmail.com>:

Hi Python,

I set up my about.me splash page and want to share it with you: <http://about.me/gungorbasa?promo=share_1857_378462>.

If you don't have an about.me splash page, you can get one for free at <http://about.me?promo=share_1857_378462>. Names are going fast so you might want to get yours now.

G??ng??rIf you would like to unsubscribe and stop receiving these emails click here: http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&u=TNIvc_YfTw6bmZBeA3uDMA%2Fut

----------
files: unnamed
messages: 140358
nosy: gungorbasa
priority: normal
severity: normal
status: open
title: Check out my about.me profile!
Added file: http://bugs.python.org/file22658/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12564>
_______________________________________
-------------- next part --------------
Hi Python,<br><br>I set up my about.me splash page and want to share it with you: <a href="http://about.me/gungorbasa?promo=share_1857_378462">http://about.me/gungorbasa</a>.<br><br>If you don't have an about.me splash page, you can get one for free at <a href="http://about.me?promo=share_1857_378462">http://about.me</a>. Names are going fast so you might want to get yours now.<br><br>G??ng??r<p>
	If you would like to unsubscribe and stop receiving these emails <a href="http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=TNIvc_YfTw6bmZBeA3uDMA%2Fuh">click here</a>.</p>

<img src="http://email.about.me/wf/open?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=TNIvc_YfTw6bmZBeA3uDMA%2Foo0.gif" alt="">

From report at bugs.python.org  Thu Jul 14 20:37:11 2011
From: report at bugs.python.org (gungor)
Date: Thu, 14 Jul 2011 18:37:11 +0000
Subject: [New-bugs-announce] [issue12565] Check out my about.me profile!
In-Reply-To: <1310668628.2834231238001778@mf8.sendgrid.net>
Message-ID: <1310668628.2834231238001778@mf8.sendgrid.net>


New submission from gungor <gungorbasa at gmail.com>:

Hi Python,

I set up my about.me splash page and want to share it with you: <http://about.me/gungorbasa?promo=share_1858_378462>.

If you don't have an about.me splash page, you can get one for free at <http://about.me?promo=share_1858_378462>. Names are going fast so you might want to get yours now.

G??ng??rIf you would like to unsubscribe and stop receiving these emails click here: http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&u=sKR-vgz5SBKaB5LfWMBuDg%2Fut

----------
files: unnamed
messages: 140360
nosy: gungorbasa
priority: normal
severity: normal
status: open
title: Check out my about.me profile!
Added file: http://bugs.python.org/file22659/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12565>
_______________________________________
-------------- next part --------------
Hi Python,<br><br>I set up my about.me splash page and want to share it with you: <a href="http://about.me/gungorbasa?promo=share_1858_378462">http://about.me/gungorbasa</a>.<br><br>If you don't have an about.me splash page, you can get one for free at <a href="http://about.me?promo=share_1858_378462">http://about.me</a>. Names are going fast so you might want to get yours now.<br><br>G??ng??r<p>
	If you would like to unsubscribe and stop receiving these emails <a href="http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=sKR-vgz5SBKaB5LfWMBuDg%2Fuh">click here</a>.</p>

<img src="http://email.about.me/wf/open?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=sKR-vgz5SBKaB5LfWMBuDg%2Foo0.gif" alt="">

From report at bugs.python.org  Thu Jul 14 20:38:13 2011
From: report at bugs.python.org (gungor)
Date: Thu, 14 Jul 2011 18:38:13 +0000
Subject: [New-bugs-announce] [issue12566] Check out my about.me profile!
In-Reply-To: <1310668688.5031802608087416@mf19>
Message-ID: <1310668688.5031802608087416@mf19>


New submission from gungor <gungorbasa at gmail.com>:

Hi Python,

I set up my about.me splash page and want to share it with you: <http://about.me/gungorbasa?promo=share_1859_378462>.

If you don't have an about.me splash page, you can get one for free at <http://about.me?promo=share_1859_378462>. Names are going fast so you might want to get yours now.

G??ng??rIf you would like to unsubscribe and stop receiving these emails click here: http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&u=O-EGT9YnTHaZ2hKIsi8xlw%2Fut

----------
files: unnamed
messages: 140362
nosy: gungorbasa
priority: normal
severity: normal
status: open
title: Check out my about.me profile!
Added file: http://bugs.python.org/file22660/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12566>
_______________________________________
-------------- next part --------------
Hi Python,<br><br>I set up my about.me splash page and want to share it with you: <a href="http://about.me/gungorbasa?promo=share_1859_378462">http://about.me/gungorbasa</a>.<br><br>If you don't have an about.me splash page, you can get one for free at <a href="http://about.me?promo=share_1859_378462">http://about.me</a>. Names are going fast so you might want to get yours now.<br><br>G??ng??r<p>
	If you would like to unsubscribe and stop receiving these emails <a href="http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=O-EGT9YnTHaZ2hKIsi8xlw%2Fuh">click here</a>.</p>

<img src="http://email.about.me/wf/open?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=O-EGT9YnTHaZ2hKIsi8xlw%2Foo0.gif" alt="">

From report at bugs.python.org  Fri Jul 15 00:33:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jul 2011 22:33:37 +0000
Subject: [New-bugs-announce] [issue12567] curses implementation of Unicode
	is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

curses functions accepting strings encode implicitly character strings to UTF-8. This is wrong. We should add a function to set the encoding (see issue #6745) or use the wide character C functions. I don't think that UTF-8 is the right default encoding, I suppose that the locale encoding is a better choice.

Accepting characters (and character strings) but calling byte functions is wrong. For example, addch('?') doesn't work with UTF-8 locale encoding. It calls waddch(0xE9) (? is U+00E9), whereas waddch(0xC3)+waddch(0xA9) should be called. Workaround in Python:

    for byte in '?'.encode('utf-8'):
        win.addch(byte)

I see two possible solutions:

A) Add a new functions only accepting characters, and not accept characters in the existing functions

B) The function should be fixed to call the right C function depending on the input type. For example, Python addch(10) and addch(b'\n') would call waddch(10), whereas addch('?') would call wadd_wch(233).

I prefer solution (B) because addch('?') would just work as expected.

----------
components: Library (Lib)
messages: 140375
nosy: Nicholas.Cole, akuchling, cben, gpolo, haypo, inigoserna, python-dev, r.david.murray, schodet, zeha
priority: normal
severity: normal
status: open
title: curses implementation of Unicode is wrong in Python 3
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul 15 00:43:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jul 2011 22:43:56 +0000
Subject: [New-bugs-announce] [issue12568] Add functions to get the width in
	columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Some characters take more than one column in a terminal, especially CJK (chinese, japanese, korean) characters. If you use such character in a terminal without taking care of the width in columns of each character, the text alignment can be broken. Issue #2382 is an example of this problem.

#2382 and #6755 have patches implementing such function:
- unicode_width.patch of #2382 adds unicode.width() method
- ucs2w.c of #6755 creates a new ucs2w module with two functions: unichr2w() (width of a character) and ucs2w() (width of a string)

Use test_ucs2w.py of #6755 to test these new functions/methods.

----------
components: Unicode
messages: 140376
nosy: haypo, inigoserna
priority: normal
severity: normal
status: open
title: Add functions to get the width in columns of a character
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul 15 01:23:42 2011
From: report at bugs.python.org (Jeremy Banks)
Date: Thu, 14 Jul 2011 23:23:42 +0000
Subject: [New-bugs-announce] [issue12569] sqlite3 segfaults and bus errors
	when given certain	unicode strings as queries
In-Reply-To: <1310685822.64.0.0540241463817.issue12569@psf.upfronthosting.co.za>
Message-ID: <1310685822.64.0.0540241463817.issue12569@psf.upfronthosting.co.za>


New submission from Jeremy Banks <jeremy at jeremybanks.ca>:

I was experimenting with the sqlite3 library and noticed that using certain strings as identifiers cause bus errors or segfaults. I'm not very familiar with unicode, but after some Googling I'm pretty sure this happens when I use non-characters or surrogate characters incorrectly.

This causes a bus error:

import sqlite3
c = sqlite3.connect(":memory:")
table_name = '"' + chr(0xD800) + '"'
c.execute("create table " + table_name + " (bar)")

The equivalent Python 2 (replacing chr with unichr) works properly.

----------
components: Library (Lib)
messages: 140381
nosy: jeremybanks
priority: normal
severity: normal
status: open
title: sqlite3 segfaults and bus errors when given certain unicode strings as queries
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Fri Jul 15 01:49:05 2011
From: report at bugs.python.org (Philip Horger)
Date: Thu, 14 Jul 2011 23:49:05 +0000
Subject: [New-bugs-announce] [issue12570] BaseHTTPServer.shutdown() locks if
	the last request 404'd
In-Reply-To: <1310687345.57.0.299486964146.issue12570@psf.upfronthosting.co.za>
Message-ID: <1310687345.57.0.299486964146.issue12570@psf.upfronthosting.co.za>


New submission from Philip Horger <campadrenalin at gmail.com>:

I haven't yet checked to see if other errors mess it up, but it refuses to exit the serve_forever() loop if the last request had a 404 error.

----------
components: Library (Lib)
messages: 140382
nosy: Philip.Horger
priority: normal
severity: normal
status: open
title: BaseHTTPServer.shutdown() locks if the last request 404'd
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 15 09:36:10 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 15 Jul 2011 07:36:10 +0000
Subject: [New-bugs-announce] [issue12571] Python built on Linux 3.0 doesn't
	include DLFCN
In-Reply-To: <1310715370.45.0.338132318055.issue12571@psf.upfronthosting.co.za>
Message-ID: <1310715370.45.0.338132318055.issue12571@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

This seems similar to issue 12326, but it doesn't seem similar enough to include it there: the DLFCN module seems to not be built when running against a 3.0 kernel. See https://bugs.gentoo.org/show_bug.cgi?id=374579.

----------
messages: 140391
nosy: djc
priority: normal
severity: normal
status: open
title: Python built on Linux 3.0 doesn't include DLFCN

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

From report at bugs.python.org  Fri Jul 15 17:40:25 2011
From: report at bugs.python.org (Jim Schneider)
Date: Fri, 15 Jul 2011 15:40:25 +0000
Subject: [New-bugs-announce] [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>


New submission from Jim Schneider <jim.schneider at dataflux.com>:

The C compiler that comes with HP/UX 11 has some shortcomings that prevent building Python 3.2.1 out of the box.  I am attaching patches here as I work through issues.

The first patch fixes namespace shortcomings when trying to use struct termios.

----------
components: Build
files: termios.patch
keywords: patch
messages: 140423
nosy: jschneid
priority: normal
severity: normal
status: open
title: HP/UX compiler workarounds
type: compile error
versions: Python 3.2
Added file: http://bugs.python.org/file22664/termios.patch

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

From report at bugs.python.org  Fri Jul 15 21:56:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 19:56:34 +0000
Subject: [New-bugs-announce] [issue12573] add resource checks for dangling
	threads and processes
In-Reply-To: <1310759794.84.0.887335776522.issue12573@psf.upfronthosting.co.za>
Message-ID: <1310759794.84.0.887335776522.issue12573@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch adds resource checks for dangling Thread and Process objects to the test suite runner. This should make it easier to spot the cause of some potential sporadic reference leaks.

----------
components: Tests
files: dangling.patch
keywords: patch
messages: 140472
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: add resource checks for dangling threads and processes
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22673/dangling.patch

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

From report at bugs.python.org  Sat Jul 16 01:25:48 2011
From: report at bugs.python.org (Rafe Kettler)
Date: Fri, 15 Jul 2011 23:25:48 +0000
Subject: [New-bugs-announce] [issue12574] Documentation for Queue in 2.x has
	an incorrect title
In-Reply-To: <1310772348.87.0.605438364285.issue12574@psf.upfronthosting.co.za>
Message-ID: <1310772348.87.0.605438364285.issue12574@psf.upfronthosting.co.za>


New submission from Rafe Kettler <rafe.kettler at gmail.com>:

The documentation for Queue in all versions of Python 2.7 and 2.6 (see http://docs.python.org/release/2.6.7/library/queue.html#module-Queue for the 2.7 docs) has the title "queue -- A synchronized queue class." The module, however, is named "Queue" in all of 2.x. So, while the title is appropiate for 3.x, it's incorrect for 2.x.

I can make a patch, as well.

----------
assignee: docs at python
components: Documentation
messages: 140475
nosy: docs at python, rafe.kettler
priority: normal
severity: normal
status: open
title: Documentation for Queue in 2.x has an incorrect title
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat Jul 16 19:10:08 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Jul 2011 17:10:08 +0000
Subject: [New-bugs-announce] [issue12575] add a AST validator
In-Reply-To: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>
Message-ID: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

The goal of this patch to keep people doing silly things like producing a Try with no finalbody or excepthandlers and segfaulting the compiler in unpleasant ways.

----------
components: Interpreter Core
files: ast_validator.patch
keywords: patch
messages: 140505
nosy: benjamin.peterson, ncoghlan
priority: normal
severity: normal
status: open
title: add a AST validator
versions: Python 3.3
Added file: http://bugs.python.org/file22678/ast_validator.patch

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

From report at bugs.python.org  Sun Jul 17 02:07:44 2011
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Sun, 17 Jul 2011 00:07:44 +0000
Subject: [New-bugs-announce] [issue12576] urlib.request fails to open some
	sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>


New submission from Ugra D?niel <daniel.ugra at gmail.com>:

Issue #12133 introduced a patch which seems to cause problems.
I'm using Python 3.2.1 on 64-bit Arch Linux (this version already incorporates the changes from #12133).

The following code:

with urllib.request.urlopen(url) as page:
    pass

raises "ValueError: I/O operation on closed file." exception when url is "http://www.imdb.com/".
When I removed "h.close()" (added by the patch) from request.py everything worked as expected.
Other URLs work flawlessly with patched code ("http://www.google.com/" for example).

Maybe it is something to do with differences in HTTP responses or in server-side behavior.
For example IMDb's "Cneonction: close" (not a typo) feature.
But this could be totally unrelated, I am by no means an HTTP expert.

----------
components: Library (Lib)
messages: 140512
nosy: daniel.ugra
priority: normal
severity: normal
status: open
title: urlib.request fails to open some sites
type: behavior
versions: Python 3.2

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

From senthil at uthcode.com  Sun Jul 17 03:29:18 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sun, 17 Jul 2011 09:29:18 +0800
Subject: [New-bugs-announce] [issue12576] urlib.request fails to open
 some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
References: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
	<1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <20110717012918.GC2879@mathmagic>

On Sun, Jul 17, 2011 at 12:07:44AM +0000, Ugra D?niel wrote:

> For example IMDb's "Cneonction: close" (not a typo) feature.  But

This is a mistake at the server and urllib relies on the
Connection: close header at some point in time in the process.

You could try with few other sites and see that context manager should
work.

From report at bugs.python.org  Sun Jul 17 10:59:21 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Sun, 17 Jul 2011 08:59:21 +0000
Subject: [New-bugs-announce] [issue12577] Misleading shutil.move docs
	regarding when os.rename is	used
In-Reply-To: <1310893161.81.0.334547060207.issue12577@psf.upfronthosting.co.za>
Message-ID: <1310893161.81.0.334547060207.issue12577@psf.upfronthosting.co.za>


New submission from Catalin Iacob <iacobcatalin at gmail.com>:

I recently tried to answer the question: "When moving a file to a destination that is an already existing file, is the destination overwritten?"

>From the current docs I understood that if src and dst are on the same filesystem then os.rename is used, if they are on different filesystems then copy + remove is used instead. Since os.rename fails on Windows if the destination exists I concluded that shutil.move would fail on Windows and overwrite dst on Unix.

----------
assignee: docs at python
components: Documentation
messages: 140520
nosy: catalin.iacob, docs at python
priority: normal
severity: normal
status: open
title: Misleading shutil.move docs regarding when os.rename is used
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul 17 13:39:39 2011
From: report at bugs.python.org (David Ward)
Date: Sun, 17 Jul 2011 11:39:39 +0000
Subject: [New-bugs-announce] [issue12578] Erratic socket.gaierror: [Errno
	11004] when using smtplib
In-Reply-To: <1310902779.89.0.705938348131.issue12578@psf.upfronthosting.co.za>
Message-ID: <1310902779.89.0.705938348131.issue12578@psf.upfronthosting.co.za>


New submission from David Ward <d.j.ward.94 at gmail.com>:

When migrating from python 2.7.1 to 2.7.2 (or 3.2) I get unpredictable /erratic exceptions thrown on constucting smtplib.SMTP:

socket.gaierror: [Errno 11004] getaddrinfo failed 

Here is the call stack:

  File "**********\mail.py", line 41, in Mail
    server = smtplib.SMTP(MAILSERVER)
  File "c:\python27\lib\smtplib.py", line 250, in __init__
    (code, msg) = self.connect(host, port)
  File "c:\python27\lib\smtplib.py", line 306, in connect
    self.sock = self._get_socket(host, port, self.timeout)
  File "c:\python27\lib\smtplib.py", line 284, in _get_socket
    return socket.create_connection((host, port), timeout)
  File "c:\python27\lib\socket.py", line 380, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
socket.gaierror: [Errno 11004] getaddrinfo failed

MAILSERVER is a local address. There are no known DNS issues on our local network. 

If I try to reduce the code to a small repro (e.g. sending mail in a loop or calling getaddrinfo), I cannot reproduce the problem.

This code had worked unchanged for many years and many previous python releases all the way back to 2.3.

Platform is Windows 7 x64, AMD64 build of python 2.7.2 (or 3.2).

Reverting back to 2.7.1 solves the problem.

----------
components: Library (Lib)
messages: 140525
nosy: David.Ward
priority: normal
severity: normal
status: open
title: Erratic socket.gaierror: [Errno 11004] when using smtplib
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jul 17 16:43:42 2011
From: report at bugs.python.org (Julian)
Date: Sun, 17 Jul 2011 14:43:42 +0000
Subject: [New-bugs-announce] [issue12579] str.format_map raises a
	SystemError for non-mapping
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>


New submission from Julian <Julian+Python.org at GrayVines.com>:

Attached is just a failing test case (just `print("{}".format_map(12))`), haven't been able to decipher the chain of calls in the unicodeobject.c code yet to see where the best place to put the fix would be (inside do_format_map before the pass back upwards maybe?).

Assuming this should be a TypeError obviously, soon as I can figure out where to put the fix I'll update the patch.

----------
components: Interpreter Core
files: format_map_err.patch
keywords: patch
messages: 140528
nosy: Julian
priority: normal
severity: normal
status: open
title: str.format_map raises a SystemError for non-mapping
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22681/format_map_err.patch

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

From report at bugs.python.org  Sun Jul 17 20:30:02 2011
From: report at bugs.python.org (Steve Holden)
Date: Sun, 17 Jul 2011 18:30:02 +0000
Subject: [New-bugs-announce] [issue12580] Documentation error in Decimal
	module
In-Reply-To: <1310927402.36.0.418806971374.issue12580@psf.upfronthosting.co.za>
Message-ID: <1310927402.36.0.418806971374.issue12580@psf.upfronthosting.co.za>


New submission from Steve Holden <steve at holdenweb.com>:

We see in the "Quick-Start Tutorial" (py3k section 8.4.1) the following example:

>>> Decimal(3.14)
Decimal('3.140000000000000124344978758017532527446746826171875')

In actua; fact one would expect an exception from that code, which should perhaps instead read

>>> Decimal.from_float(3.14)
Decimal('3.140000000000000124344978758017532527446746826171875')

This class method is the recommended way to convert floats to decimal when necessary.

----------
assignee: georg.brandl
messages: 140531
nosy: georg.brandl, holdenweb
priority: normal
severity: normal
status: open
title: Documentation error in Decimal module
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Jul 18 07:46:29 2011
From: report at bugs.python.org (Petter Haggholm)
Date: Mon, 18 Jul 2011 05:46:29 +0000
Subject: [New-bugs-announce] [issue12581] Increased test coverage of
	test_urlparse
In-Reply-To: <1310967989.12.0.947671103278.issue12581@psf.upfronthosting.co.za>
Message-ID: <1310967989.12.0.947671103278.issue12581@psf.upfronthosting.co.za>


New submission from Petter Haggholm <petter at petterhaggholm.net>:

Some very trivial tests to increase the test coverage on test_urlparse a bit; also changed a single line to use an ABC instead of attempting to use len() to verify that an object is "sequence-like" (as the comment put it). Mostly I?m trying to get my feet wet in submitting a patch in the manner suggested by the guide.

(Curiously, the full test suite coverage report cites 99%, even though the path in question does run: coverage.py fails somehow to mark an else branch consisting of a lone continue statement.)

Looking at this, I have some questions, but figured I might as well ask them along with a patch: First, whether this is appropriate use of ABCs in the library; second, whether it?s appropriate to submit related stuff like modified tests and (lightly) modified code in one patch, or whether I should rather open two issues.

Third, and more generally, I?m wondering whether the tests are appropriate. These are trivial in scope and nature, but I would be interested to know for future reference (and perhaps it would be useful to mention in the docs?) what the policy is on this. Essentially, I encoded expectations of current behaviour as ?correct? and covered the 30-odd statements in urllib/parse.py that were not already covered by a full test run (explicit coverage by test_urlparse is still much lower!) on the assumption that, as the coverage guide suggests, more coverage is always better ? and even without domain expertise assurance that current behaviour is correct, it at least provides some assurance that changes in behaviour will be discovered. Still, it?s perhaps *too* easy to get hung up on those coverage percentages: Is it *always* better to cover more (keeping in mind the limitations of once-over coverage), or would contributors be better advised not to cover code unless they are very, very confident that current behaviour is correct?

----------
components: Tests
files: urlparsetest.patch
keywords: patch
messages: 140560
nosy: haggholm
priority: normal
severity: normal
status: open
title: Increased test coverage of test_urlparse
versions: Python 3.3
Added file: http://bugs.python.org/file22684/urlparsetest.patch

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

From report at bugs.python.org  Mon Jul 18 15:47:29 2011
From: report at bugs.python.org (Paul Weiss)
Date: Mon, 18 Jul 2011 13:47:29 +0000
Subject: [New-bugs-announce] [issue12582] lib-dynload missing in python
	install
In-Reply-To: <1310996849.21.0.605822400677.issue12582@psf.upfronthosting.co.za>
Message-ID: <1310996849.21.0.605822400677.issue12582@psf.upfronthosting.co.za>


New submission from Paul Weiss <psw208 at gmail.com>:

I am trying to install python 2.7 on my Redhat machine. It installs most of the files, but it doesn't install the lib-dynload directory. I have set every path, done every install and clean I could think of but I can't get it to work. I have tried 2.7, 2.7.1 and 2.7.2 and none of them install. What could cause this?

----------
components: Build, Installation
messages: 140578
nosy: Paul.Weiss
priority: normal
severity: normal
status: open
title: lib-dynload missing in python install
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 18 22:45:33 2011
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 18 Jul 2011 20:45:33 +0000
Subject: [New-bugs-announce] [issue12583] More detailed `ImportError`
	messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

I've been frustrated so many times by `ImportError: cannot import name foo`. Right now I'm debugging some problem on a PAAS server (with no SSH access), and the server returns a traceback of `cannot import name foo`, and I don't have any idea what it means. It could mean that the file isn't there. It could mean that there's a circular import problem. Sometimes it happens when you go over Windows XP's path length limit!

Please provide a useful explanation, like this:

    ImportError: Cannot import `foo` because no file foo.py* or folder foo exists.
    ImportError: Cannot import foo module because no __init__.py* file exists in the foo folder.
    ImportError: Cannot import foo because of a circular import problem with bar.
    ImportError: Cannot import foo because the foo module file's path is bigger than Windows XP's path length limit.

Etcetera for any other reason that might cause an `ImportError`.

----------
components: Interpreter Core
messages: 140614
nosy: cool-RR
priority: normal
severity: normal
status: open
title: More detailed `ImportError` messages
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 18 23:48:36 2011
From: report at bugs.python.org (Andy Wildenberg)
Date: Mon, 18 Jul 2011 21:48:36 +0000
Subject: [New-bugs-announce] [issue12584]
	win.protocol('WM_DELETE_WINDOW'...) still deletes window	on OSX
In-Reply-To: <1311025716.17.0.268047482862.issue12584@psf.upfronthosting.co.za>
Message-ID: <1311025716.17.0.268047482862.issue12584@psf.upfronthosting.co.za>


New submission from Andy Wildenberg <andy.wildenberg at gmail.com>:

This was originally posted on http://stackoverflow.com/questions/1800452/how-to-intercept-wm-delete-window-on-osx-using-tkinter but seems not to have been reported as a bug.

On OS X (10.6.8, python 2.6.1) register a protocol on 'WM_DELETE_WINDOW'.  Your callback will get called when the user clicks on the red "kill" icon in the top-left of the window, but the window will still be destroyed.  The same file on Python 2.6.5 Linux behaves as it should, i.e. the "kill" icon is effectively disabled on the "win" window.

----------
assignee: ronaldoussoren
components: Macintosh, Tkinter
files: bug.py
messages: 140624
nosy: Andy.Wildenberg, ronaldoussoren
priority: normal
severity: normal
status: open
title: win.protocol('WM_DELETE_WINDOW'...) still deletes window on OSX
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file22689/bug.py

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

From report at bugs.python.org  Tue Jul 19 16:13:57 2011
From: report at bugs.python.org (Florian Berger)
Date: Tue, 19 Jul 2011 14:13:57 +0000
Subject: [New-bugs-announce] [issue12585] distutils dereferences symlinks
	for zip but not for	bztar/gztar target
In-Reply-To: <1311084837.3.0.496870465183.issue12585@psf.upfronthosting.co.za>
Message-ID: <1311084837.3.0.496870465183.issue12585@psf.upfronthosting.co.za>


New submission from Florian Berger <fberger at florian-berger.de>:

When creating a source distribution, formats=zip will dereference symbolic links while formats=bztar,gztar will not.

Example:

$ ls -l
drwxr-xr-x 3 4096 19. Jul 15:44 dist
-rw-r--r-- 1   53 19. Jul 15:15 foo.py
-rw-r--r-- 1   42 19. Jul 15:39 MANIFEST
-rw-r--r-- 1   42 19. Jul 15:39 MANIFEST.in
-rw-r--r-- 1  167 19. Jul 15:29 setup.py
-rw-r--r-- 1    5 19. Jul 15:16 test.dat
lrwxrwxrwx 1    8 19. Jul 15:16 test.symlink.dat -> test.dat

$ cat setup.py 
from distutils.core import setup
setup(name = 'foo',
      version = '0.1.0',
      py_modules = ['foo'],
      data_files = [("", ["test.dat", "test.symlink.dat"])])

$ python setup.py sdist --formats=gztar,zip

dist/foo-0.1.0.tar.gz does preserve the symbolic link test.symlink.dat -> test.dat, while dist/foo-0.1.0.zip does not.

This can lead to unexpected behaviour when a symlink points to a file outside the source tree. In the .zip file everything will be fine, while the .tar.* file will contain a broken link.

Actual behaviour: storing of symbolic links depends on the target format.

Expected behaviour: storing of symbolic links should not depend on the target format, i.e. format switches should be transparent. Since the zipfile module apparently does not support symbolic links, symlinks should be dereferenced for formats=gztar,bztar using the dereference=True parameter of tarfile.TarFile() in archive_util.py.

----------
assignee: tarek
components: Distutils
messages: 140669
nosy: eric.araujo, fberger, tarek
priority: normal
severity: normal
status: open
title: distutils dereferences symlinks for zip but not for bztar/gztar target
type: behavior
versions: Python 2.6, Python 3.2

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

From report at bugs.python.org  Tue Jul 19 20:24:21 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jul 2011 18:24:21 +0000
Subject: [New-bugs-announce] [issue12586] Enhanced email API: header objects
In-Reply-To: <1311099861.14.0.161435767608.issue12586@psf.upfronthosting.co.za>
Message-ID: <1311099861.14.0.161435767608.issue12586@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The work I've been doing on email6 has reached a stage where I'm confident about the overall plan of the new code, and am ready for people to review it and make suggestions.  The patch represents a working state of the code, but with several omissions that I will continue to work on while the rest of the code is reviewed.  The major omissions are that address headers don't yet handle encoded words in their 'value' and related attributes, and that structured headers do not properly support unicode characters when the message is flattened.  (The traditional email5 methods for handling unicode in structured headers still work fine, though).  There are also edge-cases where the address parser does not do as well as email.utils.parseaddr (and other cases where it does better).

A goal of email6 is to be 100% backward compatible with the existing email5.1 API.  If you find any deviations please let me know.

A new policy, email6_defaults, allows you to run the code with what are intended to be the defaults in Python 3.4.  (Not specifying either email6_defaults or email5_defaults when creating a message will result in warning messages in cases where it would make a difference which policy was in force).  The only difference between the two right now is that email6_defaults sets 'use_decoded' true, which means that the string value of header objects is the fully unicode version, not the ASCII-only version that comes from the source as is true with email5_defaults.

I've also released this version of the code as email-6.0.0a1 on pypi, so that it can be tested using 3.2 (you import it as 'email6').

I will separately attach here the README from the pypi package, which details the header features that are finished and the ones that still need work.

After review, I'd like to go ahead and check this in to default and continue the work from there.  From this point until I start work on the message_factory all changes will be incremental.  When we originally planned out email6 we thought we'd be making a "compatibility break" with backward compatibility shims.  As things have turned out the work is more a matter of incremental improvement of the API while maintaining the old API, and thus it seems reasonable to me to work on it directly in default rather than continue to work on it in a separate feature branch.

If, that is, the approach here is accepted :)  The email-sig seems to like it.

Oh, yeah, and there's room for plenty of bike-shedding about certain attribute names &c.

----------
assignee: r.david.murray
components: Library (Lib)
hgrepos: 44
messages: 140687
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Enhanced email API: header objects
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul 19 23:19:00 2011
From: report at bugs.python.org (Robert Xiao)
Date: Tue, 19 Jul 2011 21:19:00 +0000
Subject: [New-bugs-announce]
	[issue12587]	tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt
	has a	UTF8 BOM signature
In-Reply-To: <1311110340.06.0.59907930521.issue12587@psf.upfronthosting.co.za>
Message-ID: <1311110340.06.0.59907930521.issue12587@psf.upfronthosting.co.za>


New submission from Robert Xiao <nneonneo at gmail.com>:

>From a fresh Python3.2.1 tarball:

nneonneo at nneonneo-mbp:~/devel/Python-3.2.1/Lib/test$ for i in tokenize_tests-*; do echo $i; xxd $i | head -n 1; done
tokenize_tests-latin1-coding-cookie-and-utf8-bom-sig.txt
0000000: efbb bf23 202d 2a2d 2063 6f64 696e 673a  ...# -*- coding:
tokenize_tests-no-coding-cookie-and-utf8-bom-sig-only.txt
0000000: efbb bf23 2049 4d50 4f52 5441 4e54 3a20  ...# IMPORTANT: 
tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt
0000000: efbb bf23 202d 2a2d 2063 6f64 696e 673a  ...# -*- coding:
tokenize_tests-utf8-coding-cookie-and-utf8-bom-sig.txt
0000000: efbb bf23 202d 2a2d 2063 6f64 696e 673a  ...# -*- coding:

>From this, it appears that the file called "tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt" actually has a UTF-8 BOM signature, which means either the comment is lying or the BOM was accidentally added to the test file at some point.

----------
messages: 140694
nosy: nneonneo
priority: normal
severity: normal
status: open
title: tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt has a UTF8 BOM signature
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Jul 19 23:36:41 2011
From: report at bugs.python.org (rpointel)
Date: Tue, 19 Jul 2011 21:36:41 +0000
Subject: [New-bugs-announce] [issue12588] test_capi.test_subinterps() failed
	on OpenBSD (powerpc)
In-Reply-To: <1311111401.9.0.18298571301.issue12588@psf.upfronthosting.co.za>
Message-ID: <1311111401.9.0.18298571301.issue12588@psf.upfronthosting.co.za>


New submission from rpointel <python at xiri.fr>:

Hello,
the test test_subinterps failed on OpenBSD on powerpc architecture.
It works fine on amd64 and sparc64.
(The test_pendingcalls_threaded has been skipped because it blocks on OpenBSD).

Don't hesitate if you need more informations.
Details:

Re-running test 'test_capi' in verbose mode
test_instancemethod (test.test_capi.CAPITest) ... ok
test_memoryview_from_NULL_pointer (test.test_capi.CAPITest) ... ok
test_no_FatalError_infinite_loop (test.test_capi.CAPITest) ... ok
test_pendingcalls_non_threaded (test.test_capi.TestPendingCalls) ... ok
test_pendingcalls_threaded (test.test_capi.TestPendingCalls) ... skipped 'blocking on OpenBSD'
test (test.test_capi.Test6012) ... ok
test_subinterps (test.test_capi.EmbeddingTest) ... test test_capi failed
FAIL

======================================================================
FAIL: test_subinterps (test.test_capi.EmbeddingTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/obj/ports/Python-3.2.1/Python-3.2.1/Lib/test/test_capi.py", line 170, in test_subinterps
    (p.returncode, err))
AssertionError: -11 != 0 : bad returncode -11, stderr is b''

----------------------------------------------------------------------
Ran 7 tests in 3.797s

FAILED (failures=1, skipped=1)

----------
components: Tests
messages: 140696
nosy: rpointel
priority: normal
severity: normal
status: open
title: test_capi.test_subinterps() failed on OpenBSD (powerpc)
versions: Python 3.2

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

From report at bugs.python.org  Tue Jul 19 23:40:34 2011
From: report at bugs.python.org (rpointel)
Date: Tue, 19 Jul 2011 21:40:34 +0000
Subject: [New-bugs-announce] [issue12589] test_long.test_nan_inf() failed on
	OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>


New submission from rpointel <python at xiri.fr>:

Hello,
the test test_nan_inf failed on OpenBSD on powerpc architecture.
It works fine on amd64 and sparc64.

Don't hesitate if you need more informations.
Details:

Re-running test 'test_long' in verbose mode
test__format__ (test.test_long.LongTest) ... ok
test_bit_length (test.test_long.LongTest) ... ok
test_bitop_identities (test.test_long.LongTest) ... ok
test_conversion (test.test_long.LongTest) ... ok
test_correctly_rounded_true_division (test.test_long.LongTest) ... ok
test_division (test.test_long.LongTest) ... ok
test_float_conversion (test.test_long.LongTest) ... ok
test_float_overflow (test.test_long.LongTest) ... ok
test_format (test.test_long.LongTest) ... ok
test_from_bytes (test.test_long.LongTest) ... ok
test_karatsuba (test.test_long.LongTest) ... ok
test_logs (test.test_long.LongTest) ... ok
test_long (test.test_long.LongTest) ... ok
test_mixed_compares (test.test_long.LongTest) ... ok
test_nan_inf (test.test_long.LongTest) ... FAIL
test_round (test.test_long.LongTest) ... ok
test_small_ints (test.test_long.LongTest) ... ok
test_to_bytes (test.test_long.LongTest) ... ok
test_true_division (test.test_long.LongTest) ... /usr/obj/ports/Python-3.2.1/Python-3.2.1/Lib/test/regrtest.py:1053: ResourceWarning: unclosed <socket.socket object, fd=11, family=2, type=1, proto=0>
  gc.collect()
/usr/obj/ports/Python-3.2.1/Python-3.2.1/Lib/test/regrtest.py:1053: ResourceWarning: unclosed <socket.socket object, fd=12, family=2, type=1, proto=0>
  gc.collect()
/usr/obj/ports/Python-3.2.1/Python-3.2.1/Lib/test/regrtest.py:1053: ResourceWarning: unclosed <socket.socket object, fd=13, family=2, type=1, proto=0>
  gc.collect()
test test_long failed
ok

======================================================================
FAIL: test_nan_inf (test.test_long.LongTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/obj/ports/Python-3.2.1/Python-3.2.1/Lib/test/test_long.py", line 633, in test_nan_inf
    self.assertRaises(OverflowError, int, float('inf'))
AssertionError: OverflowError not raised by int

----------------------------------------------------------------------
Ran 19 tests in 25.020s

FAILED (failures=1)

----------
components: Tests
messages: 140697
nosy: rpointel
priority: normal
severity: normal
status: open
title: test_long.test_nan_inf() failed on OpenBSD (powerpc)
versions: Python 3.2

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

From report at bugs.python.org  Wed Jul 20 05:12:21 2011
From: report at bugs.python.org (Simon Forman)
Date: Wed, 20 Jul 2011 03:12:21 +0000
Subject: [New-bugs-announce] [issue12590] First line and cursor not visible
	when opening files
In-Reply-To: <1311131541.7.0.783238761563.issue12590@psf.upfronthosting.co.za>
Message-ID: <1311131541.7.0.783238761563.issue12590@psf.upfronthosting.co.za>


New submission from Simon Forman <forman.simon at gmail.com>:

In IDLE if you open a file that is longer than the editor window the first line, with the cursor, is scrolled off the top of the window making it appear as though the file begins at the second line.

This can be fixed by adding 'text.see("insert")' to the end of the EditorWindow __init__() method, but see Bruce Sherwood's comment on http://bugs.python.org/issue10079#msg118618

----------
components: IDLE
messages: 140716
nosy: sforman
priority: normal
severity: normal
status: open
title: First line and cursor not visible when opening files
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Jul 20 07:24:37 2011
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 20 Jul 2011 05:24:37 +0000
Subject: [New-bugs-announce] [issue12591] configparser can't read_file the
	output of	subprocess.Popen
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

>>> a = subprocess.Popen(['cat', '/path/to/text.ini'], stdout=subprocess.PIPE, universal_newlines=True)
>>> b = configparser.ConfigParser()
>>> b.read_file(a.stdout)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/hostname/sig/local/lib/python3.2/configparser.py", line 708, in read_file
    self._read(f, source)
  File "/hostname/sig/local/lib/python3.2/configparser.py", line 994, in _read
    for lineno, line in enumerate(fp, start=1):
AttributeError: '_io.FileIO' object has no attribute 'read1'

Also this fails without universal_readlines, which is not so bad except that the name 'read_file' doesn't exactly indicate this.

I found one mildly related bug: http://bugs.python.org/issue11670

----------
components: IO, Interpreter Core, Library (Lib)
messages: 140720
nosy: anacrolix
priority: normal
severity: normal
status: open
title: configparser can't read_file the output of subprocess.Popen
versions: Python 3.2

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

From report at bugs.python.org  Wed Jul 20 10:56:21 2011
From: report at bugs.python.org (rpointel)
Date: Wed, 20 Jul 2011 08:56:21 +0000
Subject: [New-bugs-announce] [issue12592] modify configure.in to detect
	OpenBSD 5.x
In-Reply-To: <1311152181.76.0.785487294924.issue12592@psf.upfronthosting.co.za>
Message-ID: <1311152181.76.0.785487294924.issue12592@psf.upfronthosting.co.za>


New submission from rpointel <python at xiri.fr>:

Hi,
I tested to build Python 2.7 and Python 3.2.1 (it would be the same with others versions of Python) and it failed to build on OpenBSD 5.0 (beta version).

This is the diff to correctly work on OpenBSD 5.x:

--- configure.in.orig   Sat Jul  9 08:58:56 2011
+++ configure.in        Wed Jul 20 10:19:37 2011
@@ -320,7 +320,7 @@
     # As this has a different meaning on Linux, only define it on OpenBSD
     AC_DEFINE(_BSD_SOURCE, 1, [Define on OpenBSD to activate all library features])
     ;;
-  OpenBSD/4.@<:@789@:>@)
+  OpenBSD/4.@<:@789@:>@ | OpenBSD/5.*)
     # OpenBSD undoes our definition of __BSD_VISIBLE if _XOPEN_SOURCE is
     # also defined. This can be overridden by defining _BSD_SOURCE
     # As this has a different meaning on Linux, only define it on OpenBSD

Could you add this modification in the different versions of Python ?

Thanks a lot,

Remi.

----------
components: Installation
messages: 140724
nosy: rpointel
priority: normal
severity: normal
status: open
title: modify configure.in to detect OpenBSD 5.x
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Jul 20 11:04:19 2011
From: report at bugs.python.org (rpointel)
Date: Wed, 20 Jul 2011 09:04:19 +0000
Subject: [New-bugs-announce] [issue12593] define OpenBSD in configure.in if
	Py_ENABLE_SHARED == 1
In-Reply-To: <1311152659.95.0.347600213537.issue12593@psf.upfronthosting.co.za>
Message-ID: <1311152659.95.0.347600213537.issue12593@psf.upfronthosting.co.za>


New submission from rpointel <python at xiri.fr>:

Hi,

Could you define OpenBSD in enable_shared section of the configure.in ?

I just tested with Python 3.2.1, but it could be usefull to add it in the other versions of Python 3.x.

This is the diff which seems to work :

--- configure.in.orig   Sat Jul  9 08:58:56 2011
+++ configure.in        Wed Jul 20 10:19:37 2011
@@ -755,7 +755,7 @@
              PY3LIBRARY=libpython3.so
          fi
           ;;
-    Linux*|GNU*|NetBSD*|FreeBSD*|DragonFly*)
+    Linux*|GNU*|NetBSD*|FreeBSD*|OpenBSD*|DragonFly*)
          LDLIBRARY='libpython$(LDVERSION).so'
          BLDLIBRARY='-L. -lpython$(LDVERSION)'
          RUNSHARED=LD_LIBRARY_PATH=`pwd`:${LD_LIBRARY_PATH}

Thanks a lot,

Remi.

----------
components: Installation
messages: 140725
nosy: rpointel
priority: normal
severity: normal
status: open
title: define OpenBSD in configure.in if Py_ENABLE_SHARED == 1
versions: Python 3.2

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

From report at bugs.python.org  Wed Jul 20 17:00:57 2011
From: report at bugs.python.org (Christoph Schindler)
Date: Wed, 20 Jul 2011 15:00:57 +0000
Subject: [New-bugs-announce] [issue12594] Docs for py3k still refer to
	"MacPython 2.5 folder"
In-Reply-To: <1311174057.47.0.56455855185.issue12594@psf.upfronthosting.co.za>
Message-ID: <1311174057.47.0.56455855185.issue12594@psf.upfronthosting.co.za>


New submission from Christoph Schindler <hop at 30hopsmax.at>:

In http://docs.python.org/py3k/using/mac.html#getting-and-installing-macpython and http://docs.python.org/py3k/using/mac.html#distributing-python-applications-on-the-mac .

----------
assignee: docs at python
components: Documentation
messages: 140744
nosy: docs at python, hop
priority: normal
severity: normal
status: open
title: Docs for py3k still refer to "MacPython 2.5 folder"
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Jul 20 17:16:31 2011
From: report at bugs.python.org (Tobias Pfaff)
Date: Wed, 20 Jul 2011 15:16:31 +0000
Subject: [New-bugs-announce] [issue12595] python.h redundant redeclarations
In-Reply-To: <1311174991.79.0.412639363077.issue12595@psf.upfronthosting.co.za>
Message-ID: <1311174991.79.0.412639363077.issue12595@psf.upfronthosting.co.za>


New submission from Tobias Pfaff <tobias.pfaff at inf.ethz.ch>:

Compiling 'Python.h' with g++ and -Wredundant-decls produces warnings

Testcase:

test.cpp:
#include <Python.h>
int main() { return 0; }

g++ test.cpp -I/usr/include/python3.2mu/ -Wredundant-decls
In file included from /usr/include/python3.2mu/Python.h:106,
                 from test.cpp:1:
/usr/include/python3.2mu/pyerrors.h:73: warning: redundant redeclaration of ?void Py_FatalError(const char*)? in same scope
/usr/include/python3.2mu/pydebug.h:29: warning: previous declaration of ?void Py_FatalError(const char*)?

----------
components: Build
messages: 140746
nosy: verticalduck
priority: normal
severity: normal
status: open
title: python.h redundant redeclarations
type: compile error
versions: Python 3.2

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

From report at bugs.python.org  Wed Jul 20 18:20:52 2011
From: report at bugs.python.org (=?utf-8?q?Philipp_M=C3=B6lders?=)
Date: Wed, 20 Jul 2011 16:20:52 +0000
Subject: [New-bugs-announce] [issue12596] cPickle - stored data differ for
	same dictionary
In-Reply-To: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za>
Message-ID: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za>


New submission from Philipp M?lders <philipp.moelders at googlemail.com>:

I think there is a problem within cPickle. I wanted to store a dictionary with only one entry with cPickle.dump() this works fine and can be loaded with cPickle.load(). But if you store the loaded data with cPickle.dump() again, the stored data differ from the first stored data. But the load works fine only the written data on disk differ. I've written a sample script, that shows the problem within code. 
This problem occurs only in the 2.7 version of Python and only with dictionaries with one entry.

----------
components: None
files: cPickletest.py
messages: 140750
nosy: Philipp.M?lders
priority: normal
severity: normal
status: open
title: cPickle - stored data differ for same dictionary
versions: Python 2.7
Added file: http://bugs.python.org/file22706/cPickletest.py

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

From report at bugs.python.org  Wed Jul 20 18:38:59 2011
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPRltC5INCX0LDQs9C+0YDRltGP?=)
Date: Wed, 20 Jul 2011 16:38:59 +0000
Subject: [New-bugs-announce] [issue12597] List created by multiplication
	behaves different
In-Reply-To: <1311179939.37.0.721562945719.issue12597@psf.upfronthosting.co.za>
Message-ID: <1311179939.37.0.721562945719.issue12597@psf.upfronthosting.co.za>


New submission from ?????? ??????? <xintx.ua at gmail.com>:

Next code:

def ill(row):
  row[1]=1
list_manual=[[0,0,0],[0,0,0],[0,0,0]]
list_generated=[[0,0,0]]*3
ill(list_manual[1])
print(list_manual)
ill(list_generated[1])
print(list_generated)

Will output:

[[0, 0, 0], [0, 1, 0], [0, 0, 0]]
[[0, 1, 0], [0, 1, 0], [0, 1, 0]]

Is it a bug?

----------
messages: 140753
nosy: xintx-ua
priority: normal
severity: normal
status: open
title: List created by multiplication behaves different
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jul 21 01:24:44 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 20 Jul 2011 23:24:44 +0000
Subject: [New-bugs-announce] [issue12598] Move sys variable initialization
	from import.c to	sysmodule.c
In-Reply-To: <1311204284.83.0.766064550687.issue12598@psf.upfronthosting.co.za>
Message-ID: <1311204284.83.0.766064550687.issue12598@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

Several import-related sys variables are set in _PyImportHooks_Init (in Python/import.c), which is called in Python/pythonrun.c.  I have included a patch that moves that initialization from _PyImportHooks_Init to a new _SysImportState_Init function in Python/sysmodule.c, which is then called from _PyImportHooks_Init.

This may seem like an unnecessary change, but sysmodule.c is the obvious place to find the initialization of sys variables.  Other than in pythonrun.c, import.c is the only place that sys variables are set outside of sysmodule.c.

Finally, several import related projects[1] are coming up that will impact import.c and _PyImportHooks_Init specifically.  This change helps clean up import.c a little in preparation for those projects, and isolates out of import.c at least one thing that should be kept safe during any import.c refactoring.

[1] see issue #2377, PEP 402, and the GSOC import engine project.

----------
files: sys_import_state.diff
keywords: patch
messages: 140769
nosy: ericsnow
priority: normal
severity: normal
status: open
title: Move sys variable initialization from import.c to sysmodule.c
Added file: http://bugs.python.org/file22707/sys_import_state.diff

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

From report at bugs.python.org  Thu Jul 21 01:34:26 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 20 Jul 2011 23:34:26 +0000
Subject: [New-bugs-announce] [issue12599] Use 'is not None' where
	appropriate in importlib
In-Reply-To: <1311204866.94.0.868144642715.issue12599@psf.upfronthosting.co.za>
Message-ID: <1311204866.94.0.868144642715.issue12599@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Problems noted by PJE on import-sig:
====================================
For example, PathFinder's find_module treats an empty path the same as sys.path, and will also fail if for some reason the bool() of a PEP 302 finder or loader object is False.  Also, module_for_loader() will create a new module object, if you have a False module subclass in sys.modules.

...

These distinctions could be more problematic than they appear, as it's possible to inadvertently make your loader or your module subclass capable of being False (for example, if you subclassed a sequence type or implemented a __len__), and this could lead to some very subtle bugs, albeit very rare ones as well.  ;-)
===================================

The import test cases should include some examples of such pathological objects, with importlib then updated appropriately.

----------
assignee: brett.cannon
messages: 140770
nosy: brett.cannon, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Use 'is not None' where appropriate in importlib
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jul 21 07:39:29 2011
From: report at bugs.python.org (Austin Bingham)
Date: Thu, 21 Jul 2011 05:39:29 +0000
Subject: [New-bugs-announce] [issue12600] Support parameterized TestCases in
	unittest
In-Reply-To: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>
Message-ID: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>


New submission from Austin Bingham <austin.bingham at gmail.com>:

In the discussion about adding support for parameterized tests (issue 7897), it seemed clear that parameterizing individual tests was a different issue from parameterizing TestCases. This, then, is a request to support parameterization of TestCases.

The fundamental idea is that one should be able to define a TestCase - fixtures, individual tests, etc. - and then be able to reuse that TestCase with different sets of parameters. This should all mesh cleanly with the rest of the unittest system, though it's not entirely clear what that entails.

As a motivation, consider a TestCase that tests the public API for a database abstraction system. The abstraction may work against any of a number of backends, but the public API remains the same for each. A parameterized TestCase would let you write one test for the public API and then run it for each of the backends.

----------
components: Tests
messages: 140784
nosy: abingham
priority: normal
severity: normal
status: open
title: Support parameterized TestCases in unittest
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Jul 21 10:10:25 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 21 Jul 2011 08:10:25 +0000
Subject: [New-bugs-announce] [issue12601] Spelling error in the comments in
	the webbrowser module.
In-Reply-To: <1311235825.37.0.75314458473.issue12601@psf.upfronthosting.co.za>
Message-ID: <1311235825.37.0.75314458473.issue12601@psf.upfronthosting.co.za>


New submission from maniram maniram <maniandram01 at gmail.com>:

At line 235 there is a comment which contains "secons" which should be changed to seconds.

----------
components: Library (Lib)
messages: 140793
nosy: maniram.maniram
priority: normal
severity: normal
status: open
title: Spelling error in the comments in the webbrowser module.
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul 21 13:56:33 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 21 Jul 2011 11:56:33 +0000
Subject: [New-bugs-announce] [issue12602] Missing using docs cross-references
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

General untidiness in the anchor names (and lack of same for entries like <script>)

Missing incoming:
- from "Invoking the Interpreter" in the tutorial
- direct link from runpy.run_module to -m switch
- direct link from runpy.run_path to <script>

Missing outgoing:
- direct link from <script> to runpy.run_path

Also, zipfile/dir execution was added in 2.6, not 2.5.

----------
messages: 140812
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Missing using docs cross-references

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

From report at bugs.python.org  Thu Jul 21 22:33:11 2011
From: report at bugs.python.org (Josh Triplett)
Date: Thu, 21 Jul 2011 20:33:11 +0000
Subject: [New-bugs-announce] [issue12603] pydoc.synopsis breaks if
	filesystem returns mtime of 0	(common for filesystems without mtime)
In-Reply-To: <1311280391.94.0.571188388286.issue12603@psf.upfronthosting.co.za>
Message-ID: <1311280391.94.0.571188388286.issue12603@psf.upfronthosting.co.za>


New submission from Josh Triplett <josh at joshtriplett.org>:

In Python 2.7.2, pydoc.py's synopsis contains this code implementing a cache:

    mtime = os.stat(filename).st_mtime
    lastupdate, result = cache.get(filename, (0, None))
    if lastupdate < mtime:

Many filesystems don't have any concept of mtime or don't have it available, including many FUSE filesystems, as well as our implementation of stat for GRUB in BITS.  Such systems typically return an mtime of 0.  (In addition, 0 represents a valid mtime.)  Since the cache in pydoc.synopsis initializes lastupdate to 0 for entries not found in the cache, this causes synopsis to always return None.  I'd suggest either extending the conditional to check "lastupdate != 0 and lastupdate < mtime" (which would always treat an mtime of 0 as requiring an update, which would make sense for filesystems without valid mtimes) or changing the .get to return (None, None) and checking "lastupdate is not None and lastupdate < mtime", which would treat an mtime of 0 as valid but still handle the case of not having a cache entry the first time.

----------
components: Library (Lib)
messages: 140826
nosy: joshtriplett
priority: normal
severity: normal
status: open
title: pydoc.synopsis breaks if filesystem returns mtime of 0 (common for filesystems without mtime)
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 21 22:38:14 2011
From: report at bugs.python.org (Josh Triplett)
Date: Thu, 21 Jul 2011 20:38:14 +0000
Subject: [New-bugs-announce] [issue12604] VTRACE macro in _sre.c should use
	do {} while (0)
In-Reply-To: <1311280694.44.0.358463373739.issue12604@psf.upfronthosting.co.za>
Message-ID: <1311280694.44.0.358463373739.issue12604@psf.upfronthosting.co.za>


New submission from Josh Triplett <josh at joshtriplett.org>:

In _sre.c, the VTRACE macro normally gets defined to nothing.  It later gets used as the body of control structures such as "else" without braces, which causes many compilers to warn (to catch stray semicolons like "else;").  This makes it difficult to compile Python as part of a project which uses -Werror, such as GRUB.  Please consider defining VTRACE as do {} while(0) instead, as the standard convention for an empty function-like macro with no return value.

----------
messages: 140827
nosy: joshtriplett
priority: normal
severity: normal
status: open
title: VTRACE macro in _sre.c should use do {} while (0)
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 21 23:02:14 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 21 Jul 2011 21:02:14 +0000
Subject: [New-bugs-announce] [issue12605] Enhancements to gdb 7 debugging
	hooks
In-Reply-To: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za>
Message-ID: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

I'm attaching patches to handle some more "events" in the gdb7 debugging hooks for CPython (aka Tools/gdb/libpython.py).

Currently, the hooks only care about C frames that are the bytecode interpreter (i.e. PyEval_EvalFrameEx)

This patch changes this, dividing C frames into:
  - "python frames":
    - "bytecode frames" i.e. PyEval_EvalFrameEx
    - "other python frames": C frames that are of interest from a python
      perspective, but aren't bytecode
  - everything else

so that the "py-bt", "py-up" and "py-down" commands will now work on the other kinds of "python" frames, in addition to the bytecode frames.

Specifically, the following new kinds of C frame are displayed:
  - waiting on the GIL
  - garbage-collection
  - CFunctions (these weren't displayed before)

This should assist when debugging multithreaded crashes, to more easily get a sense of what every thread is doing.

Examples:
Showing a garbage-collection:
(gdb) py-bt
  Garbage-collecting
  <built-in method collect of module object at remote 0x7ffff18ea420>
  File "<string>", line 4, in foo
  File "<string>", line 6, in bar
  File "<string>", line 7, in <module>

(gdb) py-bt-full
#1 Garbage-collecting
#2 <built-in method collect of module object at remote 0x7ffff18ea420>
#5 Frame 0x7ffff20d6d48, for file <string>, line 4, in foo ()
#8 Frame 0x7ffff20d6b70, for file <string>, line 6, in bar ()
#11 Frame 0x7ffff7fb1d80, for file <string>, line 7, in <module> ()

Showing an invocation of "time.sleep()":
(gdb) py-bt-full
#0 <built-in method sleep of module object at remote 0x7ffff1af8150>
#3 Frame 0x7ffff18aa060, for file <string>, line 3, in foo ()
#6 Frame 0x7ffff20d6b70, for file <string>, line 5, in bar ()
#9 Frame 0x7ffff7fb1d80, for file <string>, line 6, in <module> ()
  

Showing multiple threads, where all but one are waiting for the GIL:

Thread 5 (Thread 0x7fffeb5fe700 (LWP 10716)):
Traceback (most recent call first):
  Waiting for the GIL
  File "<string>", line 10, in run
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 737, in _bootstrap_inner
    self.run()
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 710, in _bootstrap
    self._bootstrap_inner()

Thread 4 (Thread 0x7fffebfff700 (LWP 10715)):
Traceback (most recent call first):
  Waiting for the GIL
  File "<string>", line 10, in run
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 737, in _bootstrap_inner
    self.run()
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 710, in _bootstrap
    self._bootstrap_inner()

Thread 3 (Thread 0x7ffff0dea700 (LWP 10714)):
Traceback (most recent call first):
  Waiting for the GIL
  File "<string>", line 10, in run
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 737, in _bootstrap_inner
    self.run()
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 710, in _bootstrap
    self._bootstrap_inner()

Thread 2 (Thread 0x7ffff17eb700 (LWP 10713)):
Traceback (most recent call first):
  Waiting for the GIL
  File "<string>", line 10, in run
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 737, in _bootstrap_inner
    self.run()
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 710, in _bootstrap
    self._bootstrap_inner()

Thread 1 (Thread 0x7ffff7fdb700 (LWP 10709)):
Traceback (most recent call first):
  File "<string>", line 18, in <module>

----------
assignee: dmalcolm
components: Demos and Tools
keywords: needs review
messages: 140828
nosy: dmalcolm, haypo
priority: normal
severity: normal
status: open
title: Enhancements to gdb 7 debugging hooks
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 22 00:31:35 2011
From: report at bugs.python.org (py.user)
Date: Thu, 21 Jul 2011 22:31:35 +0000
Subject: [New-bugs-announce] [issue12606] Mutable Sequence Type works
	different for lists and	bytearrays in slice[i:j:k]
In-Reply-To: <1311287495.04.0.0852522537211.issue12606@psf.upfronthosting.co.za>
Message-ID: <1311287495.04.0.0852522537211.issue12606@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

>>> barr = bytearray(b'abcde')
>>> lst = list('abcde')
>>> barr[::-3] = ()
>>> barr
bytearray(b'acd')
>>> lst[::-3] = ()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: attempt to assign sequence of size 0 to extended slice of size 2
>>> del lst[::-3]
>>> lst
['a', 'c', 'd']
>>>

lst[::-3] = () - is more convenient way for deletion

----------
components: Interpreter Core
messages: 140832
nosy: py.user
priority: normal
severity: normal
status: open
title: Mutable Sequence Type works different for lists and bytearrays in slice[i:j:k]
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri Jul 22 11:46:25 2011
From: report at bugs.python.org (=?utf-8?b?Q2hyaXN0aWFuIEjDpGdnc3Ryw7Zt?=)
Date: Fri, 22 Jul 2011 09:46:25 +0000
Subject: [New-bugs-announce] [issue12607] subprocess(stdout=...,
	stderr=sys.stdout) breaks stderr for child
In-Reply-To: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>
Message-ID: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>


New submission from Christian H?ggstr?m <pajton at kalvdans.no-ip.org>:

I hit a variant of issue #12251, namely when you redirect both stdout and stderr of a child process and one of them uses a low fd.
Testcase:

import subprocess, sys
subprocess.call(["ls", "asda"], stderr = sys.stdout, stdout = open("/dev/null", "w"))

strace output:

open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
[child process]
dup2(3, 1)   = 1  // overwrites the stdout filedescriptor..
dup2(1, 2)   = 2  // that was supposed to be duped here.
close(3)    = 0   // okay

The testcase is supposed to print "ls: file not found" on stdout, but is silent.

----------
components: Library (Lib)
messages: 140864
nosy: Evgeny.Tarasov, alexey-smirnov, chn, haypo, mmarkk, neologix, r.david.murray
priority: normal
severity: normal
status: open
title: subprocess(stdout=..., stderr=sys.stdout) breaks stderr for child
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jul 22 15:13:27 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Fri, 22 Jul 2011 13:13:27 +0000
Subject: [New-bugs-announce] [issue12608] crash in PyAST_Compile when
	running Python code
In-Reply-To: <1311340407.01.0.0385021056908.issue12608@psf.upfronthosting.co.za>
Message-ID: <1311340407.01.0.0385021056908.issue12608@psf.upfronthosting.co.za>


New submission from Albert Zeyer <albzey at googlemail.com>:

Code:

```
import ast

globalsDict = {}

fAst = ast.FunctionDef(
	name="foo",
	args=ast.arguments(
		args=[], vararg=None, kwarg=None, defaults=[],
		kwonlyargs=[], kw_defaults=[]),
	body=[], decorator_list=[])

exprAst = ast.Interactive(body=[fAst])
ast.fix_missing_locations(exprAst)
compiled = compile(exprAst, "<foo>", "single")
eval(compiled, globalsDict, globalsDict)

print(globalsDict["foo"])
```

Also CPython 2.6, 2.7, 3.0 and PyPy 1.5 crashes on this.

----------
components: Interpreter Core
messages: 140873
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: crash in PyAST_Compile when running Python code
versions: Python 3.2

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

From report at bugs.python.org  Fri Jul 22 15:38:49 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Fri, 22 Jul 2011 13:38:49 +0000
Subject: [New-bugs-announce] [issue12609] SystemError:
	Objects/codeobject.c:64: bad argument to	internal function
In-Reply-To: <1311341929.92.0.631555163779.issue12609@psf.upfronthosting.co.za>
Message-ID: <1311341929.92.0.631555163779.issue12609@psf.upfronthosting.co.za>


New submission from Albert Zeyer <albzey at googlemail.com>:

Code:

```
from ast import *

globalsDict = {}

exprAst = Interactive(body=[FunctionDef(name=u'Py_Main', args=arguments(args=[Name(id=u'argc', ctx=Param()), Name(id=u'argv', ctx=Param())], vararg=None, kwarg=None, defaults=[]), body=[Assign(targets=[Name(id=u'argc', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[Attribute(value=Name(id=u'argc', ctx=Load()), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'argv', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='cast', ctx=Load()), args=[Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_void_p', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='cast', ctx=Load()), args=[Name(id=u'argv', ctx=Load()), Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_void_p', ctx=Load())], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None), Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='POINTER', ctx=Load()), args=[Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='POINTER', ctx=Load()), args=[Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_char', ctx=Load())], keywords=[], starargs=None, kwargs=None)], keywords=[], starargs=None, kwargs=None)], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'c', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'sts', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'command', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='cast', ctx=Load()), args=[Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_void_p', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None), Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='POINTER', ctx=Load()), args=[Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_char', ctx=Load())], keywords=[], starargs=None, kwargs=None)], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'filename', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='cast', ctx=Load()), args=[Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_void_p', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None), Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='POINTER', ctx=Load()), args=[Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_char', ctx=Load())], keywords=[], starargs=None, kwargs=None)], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'module', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='cast', ctx=Load()), args=[Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_void_p', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None), Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='POINTER', ctx=Load()), args=[Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_char', ctx=Load())], keywords=[], starargs=None, kwargs=None)], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'fp', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='cast', ctx=Load()), args=[Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_void_p', ctx=Load()), args=[Num(n=0)], keywords=[], starargs=None, kwargs=None), Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='POINTER', ctx=Load()), args=[Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load())], keywords=[], starargs=None, kwargs=None)], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'p', ctx=Store())], value=Call(func=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='POINTER', ctx=Load()), args=[Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_char', ctx=Load())], keywords=[], starargs=None, kwargs=None), args=[], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'unbuffered', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'skipfirstline', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'stdin_is_interactive', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'help_a', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'version', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'saw_unbuffered_flag', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'cf', ctx=Store())], value=Call(func=Name(id=u'PyCompilerFlags', ctx=Load()), args=[], keywords=[], starargs=None, kwargs=None)), Expr(value=Call(func=Attribute(value=Name(id='helpers', ctx=Load()), attr='assign', ctx=Load()), args=[Attribute(value=Name(id=u'cf', ctx=Load()), attr=u'cf_flags', ctx=Load()), Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Expr(value=Call(func=Attribute(value=Name(id='helpers', ctx=Load()), attr='assign', ctx=Load()), args=[Name(id=u'orig_argc', ctx=Load()), Attribute(value=Name(id=u'argc', ctx=Load()), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Expr(value=Call(func=Attribute(value=Name(id='helpers', ctx=Load()), attr='assignPtr', ctx=Load()), args=[Name(id=u'orig_argv', ctx=Load()), Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='cast', ctx=Load()), args=[Name(id=u'argv', ctx=Load()), Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_void_p', ctx=Load())], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Expr(value=Call(func=Name(id=u'PySys_ResetWarnOptions', ctx=Load()), args=[], keywords=[], starargs=None, kwargs=None)), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Expr(value=Call(func=Attribute(value=Name(id='helpers', ctx=Load()), attr='assign', ctx=Load()), args=[Name(id=u'stdin_is_interactive', ctx=Load()), Attribute(value=Call(func=Name(id=u'Py_FdIsInteractive', ctx=Load()), args=[Num(n=0), Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Expr(value=Call(func=Name(id=u'Py_Initialize', ctx=Load()), args=[], keywords=[], starargs=None, kwargs=None)), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Expr(value=Call(func=Name(id=u'PySys_SetArgv', ctx=Load()), args=[BinOp(left=Name(id=u'argc', ctx=Load()), op=Sub(), right=Name(id=u'_PyOS_optind', ctx=Load())), BinOp(left=Name(id=u'argv', ctx=Load()), op=Add(), right=Name(id=u'_PyOS_optind', ctx=Load()))], keywords=[], starargs=None, kwargs=None)), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Expr(value=Call(func=Name(id=u'Py_Finalize', ctx=Load()), args=[], keywords=[], starargs=None, kwargs=None)), Assert(test=Name(id='True', ctx=Load()), msg=None), Delete(targets=[Name(id=u'fp', ctx=Del())]), Delete(targets=[Name(id=u'c', ctx=Del())]), Delete(targets=[Name(id=u'version', ctx=Del())]), Delete(targets=[Name(id=u'saw_unbuffered_flag', ctx=Del())]), Delete(targets=[Name(id=u'stdin_is_interactive', ctx=Del())]), Delete(targets=[Name(id=u'cf', ctx=Del())]), Delete(targets=[Name(id=u'argv', ctx=Del())]), Delete(targets=[Name(id=u'filename', ctx=Del())]), Delete(targets=[Name(id=u'p', ctx=Del())]), Delete(targets=[Name(id=u'help_a', ctx=Del())]), Delete(targets=[Name(id=u'command', ctx=Del())]), Delete(targets=[Name(id=u'module', ctx=Del())]), Delete(targets=[Name(id=u'sts', ctx=Del())]), Delete(targets=[Name(id=u'unbuffered', ctx=Del())]), Delete(targets=[Name(id=u'argc', ctx=Del())]), Delete(targets=[Name(id=u'skipfirstline', ctx=Del())])], decorator_list=[])])

fix_missing_locations(exprAst)
compiled = compile(exprAst, "<foo>", "single")
eval(compiled, {}, globalsDict)

f = globalsDict["Py_Main"]
print(f)
```

This outputs:
SystemError: Objects/codeobject.c:64: bad argument to internal function

PyPy 1.5 outputs:
<function Py_Main at 0x0000000103520610>

I'll try to reduce the test case a bit further.

----------
messages: 140876
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: SystemError: Objects/codeobject.c:64: bad argument to internal function
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 22 15:49:50 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Fri, 22 Jul 2011 13:49:50 +0000
Subject: [New-bugs-announce] [issue12610] Fatal Python error: non-string
	found in code slot
In-Reply-To: <1311342590.28.0.333956728566.issue12610@psf.upfronthosting.co.za>
Message-ID: <1311342590.28.0.333956728566.issue12610@psf.upfronthosting.co.za>


New submission from Albert Zeyer <albzey at googlemail.com>:

Code:

```
from ast import *

globalsDict = {}

body = [
	Assign(targets=[Name(id=u'argc', ctx=Store())],
		   value=Name(id=u'None', ctx=Load())),
	]

exprAst = Interactive(body=[
	FunctionDef(
		name='foo',
		args=arguments(args=[Name(id=u'argc', ctx=Param()), Name(id=u'argv', ctx=Param())],
					   vararg=None, kwarg=None, defaults=[]),
		body=body,
		decorator_list=[])])

fix_missing_locations(exprAst)
compiled = compile(exprAst, "<foo>", "single")
eval(compiled, {}, globalsDict)

f = globalsDict["foo"]
print(f)
```

CPython 2.7.1: Fatal Python error: non-string found in code slot
PyPy 1.5: <function foo at 0x0000000103114430>

----------
messages: 140877
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: Fatal Python error: non-string found in code slot
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 22 17:53:02 2011
From: report at bugs.python.org (Vlada Peric)
Date: Fri, 22 Jul 2011 15:53:02 +0000
Subject: [New-bugs-announce] [issue12611] 2to3 crashes when converting
	doctest using reduce()
In-Reply-To: <1311349982.31.0.854147036767.issue12611@psf.upfronthosting.co.za>
Message-ID: <1311349982.31.0.854147036767.issue12611@psf.upfronthosting.co.za>


New submission from Vlada Peric <vlada.peric at gmail.com>:

2to3 crashes when run on a doctest which uses reduce(). This happens with both 2.7 and 3.2's 2to3. I have the following code in a compatibility file, but even using that it fails with the same error: 

try:
    from functools import reduce
except ImportError:
    reduce = reduce

This is the traceback produced:

Traceback (most recent call last):
  File "/usr/local/bin/2to3", line 6, in <module>
    sys.exit(main("lib2to3.fixes"))
  File "/usr/local/lib/python2.6/lib2to3/main.py", line 173, in main
    options.processes)
  File "/usr/local/lib/python2.6/lib2to3/refactor.py", line 620, in refactor
    items, write, doctests_only)
  File "/usr/local/lib/python2.6/lib2to3/refactor.py", line 275, in refactor
    self.refactor_file(dir_or_file, write, doctests_only)
  File "/usr/local/lib/python2.6/lib2to3/refactor.py", line 661, in refactor_file
    *args, **kwargs)
  File "/usr/local/lib/python2.6/lib2to3/refactor.py", line 321, in refactor_file
    output = self.refactor_docstring(input, filename)
  File "/usr/local/lib/python2.6/lib2to3/refactor.py", line 500, in refactor_docstring
    indent, filename))
  File "/usr/local/lib/python2.6/lib2to3/refactor.py", line 530, in refactor_doctest
    assert clipped == [u"\n"] * (lineno-1), clipped
AssertionError: [u'from functools import reduce\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n']

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 140892
nosy: VPeric
priority: normal
severity: normal
status: open
title: 2to3 crashes when converting doctest using reduce()
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul 22 18:36:11 2011
From: report at bugs.python.org (Paul Price)
Date: Fri, 22 Jul 2011 16:36:11 +0000
Subject: [New-bugs-announce] [issue12612] Valgrind suppressions
In-Reply-To: <1311352571.88.0.0623185894462.issue12612@psf.upfronthosting.co.za>
Message-ID: <1311352571.88.0.0623185894462.issue12612@psf.upfronthosting.co.za>


New submission from Paul Price <price at astro.princeton.edu>:

I am running Python 2.7.1 under Valgrind 3.6.1 on a x86_64 GNU/Linux box.  Valgrind is flagging errors that are not covered by the standard suppressions file (Misc/valgrind-python.supp; after uncommenting the part I'm supposed to), e.g.:

==5804== Use of uninitialised value of size 8
==5804==    at 0x4EBA956: PyObject_Free (obmalloc.c:958)
==5804==    by 0x4E85D65: code_dealloc (codeobject.c:317)
==5804==    by 0x4ECE23C: tupledealloc (tupleobject.c:220)
==5804==    by 0x4E85E42: code_dealloc (codeobject.c:308)
==5804==    by 0x4F3315D: load_source_module (import.c:1022)
==5804==    by 0x4F33F7E: import_submodule (import.c:2596)
==5804==    by 0x4F3420E: load_next (import.c:2416)
==5804==    by 0x4F3484F: import_module_level (import.c:2137)
==5804==    by 0x4F34DA3: PyImport_ImportModuleLevel (import.c:2189)
==5804==    by 0x4F16ABE: builtin___import__ (bltinmodule.c:49)
==5804==    by 0x4E6DA42: PyObject_Call (abstract.c:2529)
==5804==    by 0x4F16F82: PyEval_CallObjectWithKeywords (ceval.c:3881)

==5804== Use of uninitialised value of size 8
==5804==    at 0x4EBA956: PyObject_Free (obmalloc.c:958)
==5804==    by 0x4E85D65: code_dealloc (codeobject.c:317)
==5804==    by 0x4F3315D: load_source_module (import.c:1022)
==5804==    by 0x4F33F7E: import_submodule (import.c:2596)
==5804==    by 0x4F3420E: load_next (import.c:2416)
==5804==    by 0x4F3484F: import_module_level (import.c:2137)
==5804==    by 0x4F34DA3: PyImport_ImportModuleLevel (import.c:2189)
==5804==    by 0x4F16ABE: builtin___import__ (bltinmodule.c:49)
==5804==    by 0x4E6DA42: PyObject_Call (abstract.c:2529)
==5804==    by 0x4F16F82: PyEval_CallObjectWithKeywords (ceval.c:3881)
==5804==    by 0x4F1ACD3: PyEval_EvalFrameEx (ceval.c:2332)
==5804==    by 0x4F1F347: PyEval_EvalCodeEx (ceval.c:3252)

etc.

Perhaps the suppressions file covers only 32-bit machines, because if I add:

{
   ADDRESS_IN_RANGE/Use of uninitialised value of size 8
   Memcheck:Addr8
   fun:PyObject_Free
}

{
   ADDRESS_IN_RANGE/Use of uninitialised value of size 8
   Memcheck:Value8
   fun:PyObject_Free
}

{
   ADDRESS_IN_RANGE/Use of uninitialised value of size 8
   Memcheck:Addr8
   fun:PyObject_Realloc
}

{
   ADDRESS_IN_RANGE/Use of uninitialised value of size 8
   Memcheck:Value8
   fun:PyObject_Realloc
}

(i.e., "Value8" instead of "Value4") then all is clear.

----------
components: None
messages: 140895
nosy: Paul.Price
priority: normal
severity: normal
status: open
title: Valgrind suppressions
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 22 18:49:32 2011
From: report at bugs.python.org (Vlada Peric)
Date: Fri, 22 Jul 2011 16:49:32 +0000
Subject: [New-bugs-announce] [issue12613] itertools fixer fails
In-Reply-To: <1311353372.31.0.101702308601.issue12613@psf.upfronthosting.co.za>
Message-ID: <1311353372.31.0.101702308601.issue12613@psf.upfronthosting.co.za>


New submission from Vlada Peric <vlada.peric at gmail.com>:

The itertools fixer (izip -> zip, among others), fails for the following code:

from itertools import izip
print msg % str(bool(symbol_swapped) and list(izip(*swap_dict).next()) or symbols)

It gets converted to:

print(msg % str(bool(symbol_swapped) and list(next(izip(*swap_dict))) or symbols))

(note how izip is still there)

I've worked aroudn this by introducing tmp = izip(...) and using that, but it'd be nice if 2to3 caught it by default.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 140897
nosy: VPeric
priority: normal
severity: normal
status: open
title: itertools fixer fails
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul 22 19:51:27 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 22 Jul 2011 17:51:27 +0000
Subject: [New-bugs-announce] [issue12614] Allow to explicitly set the method
	of	urllib.request.Request
In-Reply-To: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>
Message-ID: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

Currently urllib.request.Request decides if it's a "GET" or "POST" by the presence of data. However sometimes you want to do an "POST" request without data (in my case, it Crucible REST API). Or provide another method. The attached patched added a `method` argument to Request __init__.

----------
files: request-method.diff
keywords: patch
messages: 140898
nosy: tebeka
priority: normal
severity: normal
status: open
title: Allow to explicitly set the method of urllib.request.Request
versions: Python 3.2
Added file: http://bugs.python.org/file22717/request-method.diff

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

From report at bugs.python.org  Fri Jul 22 20:35:12 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 22 Jul 2011 18:35:12 +0000
Subject: [New-bugs-announce] [issue12615] add array.zeroes
In-Reply-To: <1311359712.07.0.0731829142816.issue12615@psf.upfronthosting.co.za>
Message-ID: <1311359712.07.0.0731829142816.issue12615@psf.upfronthosting.co.za>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

>From python-ideas:

introduce array.zeroes, a new classmethod that provides an alternative constructor, its signature is zeroes(typecode, length), which allows for preallocating an array, with a lower overhead than methods such as array(typecode, [0]) * length, and is more readable (plus consistant with the numpy method of the same name).

----------
assignee: alex
components: Library (Lib)
messages: 140901
nosy: alex
priority: normal
severity: normal
status: open
title: add array.zeroes
type: feature request
versions: Python 3.4

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

From report at bugs.python.org  Sat Jul 23 00:11:40 2011
From: report at bugs.python.org (Vlada Peric)
Date: Fri, 22 Jul 2011 22:11:40 +0000
Subject: [New-bugs-announce] [issue12616] zip fixer fails on zip()[:-1]
In-Reply-To: <1311372700.75.0.0919550613362.issue12616@psf.upfronthosting.co.za>
Message-ID: <1311372700.75.0.0919550613362.issue12616@psf.upfronthosting.co.za>


New submission from Vlada Peric <vlada.peric at gmail.com>:

The zip fixer fails on this code:

zip(B, D)[:-1]

I fixed this by wrapping explicitly with list(), but that creates a duplicate list on Python 2. 

(Like the other fixes I reported, I assume this also applies to 3.3, but I didn't test it so I don't know; adding Eric and Benjamin to nosy, though)

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 140919
nosy: VPeric, benjamin.peterson, eric.araujo
priority: normal
severity: normal
status: open
title: zip fixer fails on zip()[:-1]
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Jul 23 03:39:58 2011
From: report at bugs.python.org (py.user)
Date: Sat, 23 Jul 2011 01:39:58 +0000
Subject: [New-bugs-announce] [issue12617] Mutable Sequence Type can work not
	only with iterable in	slice[i:j] = t
In-Reply-To: <1311385198.6.0.560721842501.issue12617@psf.upfronthosting.co.za>
Message-ID: <1311385198.6.0.560721842501.issue12617@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

1)
4.6.4 Mutable Sequence Types

| s[i:j] = t |  slice of s from i to j is replaced |
|            |  by the contents of the iterable t  |


>>> lst = list('abc')
>>> barr = bytearray(b'abc')
>>> lst[:1] = 4
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only assign an iterable
>>> barr[:1] = 4
>>> barr
bytearray(b'\x00\x00\x00\x00bc')
>>>

there is no info about this feature in the documentation

2)
4.6.4 Mutable Sequence Types

| s.extend(x) |  same as s[len(s):len(s)] = x |

>>> lst = list('abc')
>>> barr = bytearray(b'abc')
>>> lst.extend(4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable
>>> barr.extend(4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable
>>> lst[len(lst):len(lst)] = 4
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only assign an iterable
>>> barr[len(barr):len(barr)] = 4
>>> barr
bytearray(b'abc\x00\x00\x00\x00')
>>>

barr.extend(x)  !=  barr[len(barr):len(barr)] = x

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 140924
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: Mutable Sequence Type can work not only with iterable in slice[i:j] = t
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sat Jul 23 09:42:51 2011
From: report at bugs.python.org (Sjoerd de Vries)
Date: Sat, 23 Jul 2011 07:42:51 +0000
Subject: [New-bugs-announce] [issue12618] py_compile cannot create files in
	current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>


New submission from Sjoerd de Vries <sjdv1982 at gmail.com>:

When you specify cfile to be in the current directory, an error occurs (line 133).
I have fixed the file, see attached

----------
components: Library (Lib)
files: py_compile.py
messages: 140940
nosy: sjdv1982
priority: normal
severity: normal
status: open
title: py_compile cannot create files in current directory
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22722/py_compile.py

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

From report at bugs.python.org  Sat Jul 23 11:43:32 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 23 Jul 2011 09:43:32 +0000
Subject: [New-bugs-announce] [issue12619] Automatically regenerate
	platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

I suggest that platform-specific modules be automatically regenerated during installation. I'm attaching a patch.

----------
files: python-regenerate_platdir.patch
keywords: patch
messages: 140952
nosy: Arfrever, amaury.forgeotdarc, djc, doko, eric.araujo, ezio.melotti, haypo, jwilk, lemburg, loewis, maniram.maniram, neologix, petri.lehtinen, pitrou, python-dev, r.david.murray, rosslagerwall
priority: normal
severity: normal
status: open
title: Automatically regenerate platform-specific modules
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22723/python-regenerate_platdir.patch

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

From report at bugs.python.org  Sat Jul 23 13:27:35 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Jul 2011 11:27:35 +0000
Subject: [New-bugs-announce] [issue12620] pending calls: make `pendingbusy`
	flag static to	Py_MakePendingCalls()
In-Reply-To: <1311420455.91.0.738600142656.issue12620@psf.upfronthosting.co.za>
Message-ID: <1311420455.91.0.738600142656.issue12620@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

Trivial patch.
In Python/ceval.c, when compiled with threads, make the `pendingbusy` flag used to guard against reentrant calls static to Py_MakePendingCalls().
Also, make it an int and rename it to `busy` to be consistent with the non-threaded code (int might also be a bit faster).

----------
components: Interpreter Core
files: pending_busy.diff
keywords: needs review, patch
messages: 140976
nosy: neologix, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: pending calls: make `pendingbusy` flag static to Py_MakePendingCalls()
versions: Python 3.3
Added file: http://bugs.python.org/file22725/pending_busy.diff

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

From report at bugs.python.org  Sat Jul 23 20:22:40 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Jul 2011 18:22:40 +0000
Subject: [New-bugs-announce] [issue12621] Errors in docstrings of find and
	rfind methods of bytes	and bytestring
In-Reply-To: <1311445360.36.0.0968747476875.issue12621@psf.upfronthosting.co.za>
Message-ID: <1311445360.36.0.0968747476875.issue12621@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

bytes.{find,rfind} reads s[start:end]; should be B[start:end]

bytearray.{find,rfind} reads s[start,end]; should be B[start:end]

{str,unicode}.{find,rfind} reads s{start:end]; should be S[start:end]

----------
assignee: docs at python
components: Documentation, Interpreter Core
keywords: easy
messages: 141001
nosy: docs at python, petri.lehtinen
priority: normal
severity: normal
stage: needs patch
status: open
title: Errors in docstrings of find and rfind methods of bytes and bytestring
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul 23 21:08:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 19:08:28 +0000
Subject: [New-bugs-announce] [issue12622] failfast argument to
	TextTestRunner not documented
In-Reply-To: <1311448108.9.0.673600380151.issue12622@psf.upfronthosting.co.za>
Message-ID: <1311448108.9.0.673600380151.issue12622@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

http://docs.python.org/dev/library/unittest.html#unittest.TextTestRunner doesn't mention the "failfast" argument, even though it's used by unittest.main().

----------
assignee: michael.foord
components: Documentation
messages: 141004
nosy: michael.foord, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: failfast argument to TextTestRunner not documented
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul 23 22:11:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 20:11:33 +0000
Subject: [New-bugs-announce] [issue12623] "universal newlines" subprocess
	support broken with	select- and poll-based communicate()
In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za>
Message-ID: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The select() and poll() loop implementations of Popen.communicate() call os.write() instead of the write() method on the stdin pipe, meaning any newline translation *and* unicode-to-bytes encoding step is skipped.

To use the write() method on the stdin pipe, we may have to set the file descriptor in non-blocking mode, especially given that _PIPE_BUF worth of characters can amount to more than _PIPE_BUF bytes on the underlying raw fd.

See issue12591 for a simpler issue that was fixed.

----------
components: Library (Lib)
messages: 141014
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: "universal newlines" subprocess support broken with select- and poll-based communicate()
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul 23 22:28:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 20:28:10 +0000
Subject: [New-bugs-announce] [issue12624] failfast support for regrtest
In-Reply-To: <1311452890.31.0.827101478258.issue12624@psf.upfronthosting.co.za>
Message-ID: <1311452890.31.0.827101478258.issue12624@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch adds a new --failfast (-G) argument to regrtest which stops running the tests as soon as a test fails (when using unittest-based test cases). Useful with long test suites such as test_io and test_subprocess.

----------
components: Tests
files: failfast.patch
keywords: patch
messages: 141017
nosy: ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: failfast support for regrtest
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22734/failfast.patch

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

From report at bugs.python.org  Sat Jul 23 22:54:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 20:54:55 +0000
Subject: [New-bugs-announce] [issue12625] sporadic test_unittest failure
In-Reply-To: <1311454495.5.0.801093056111.issue12625@psf.upfronthosting.co.za>
Message-ID: <1311454495.5.0.801093056111.issue12625@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Seen on an OpenIndiana buildbot:

======================================================================
FAIL: testInstallHandler (unittest.test.test_break.TestBreak)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.2.cea-indiana-amd64/build/Lib/unittest/test/test_break.py", line 37, in testInstallHandler
    self.assertTrue(unittest.signals._interrupt_handler.called)
AssertionError: False is not true

http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.2/builds/454/steps/test/logs/stdio


Probably something to do with signals behaviour under that particular OS.

----------
components: Library (Lib), Tests
messages: 141019
nosy: haypo, michael.foord, neologix, pitrou
priority: normal
severity: normal
status: open
title: sporadic test_unittest failure
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul 23 23:48:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 21:48:06 +0000
Subject: [New-bugs-announce] [issue12626] run test cases based on a glob
	filter
In-Reply-To: <1311457686.18.0.680681254529.issue12626@psf.upfronthosting.co.za>
Message-ID: <1311457686.18.0.680681254529.issue12626@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch allows to only run tests which satisfy a glob filter, using the --match (-m) option to regrtest. For example:

  ./python -m test -m "*Signal*" -v test_io

will execute all the signal-related tests in test_io.

----------
components: Tests
files: regrtestglob.patch
keywords: patch
messages: 141022
nosy: ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: run test cases based on a glob filter
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22735/regrtestglob.patch

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

From report at bugs.python.org  Sun Jul 24 04:31:35 2011
From: report at bugs.python.org (Kerrick Staley)
Date: Sun, 24 Jul 2011 02:31:35 +0000
Subject: [New-bugs-announce] [issue12627] Implement PEP 394: The "python"
	Command on Unix-Like	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>


New submission from Kerrick Staley <mail at kerrickstaley.com>:

This issue was opened to track the implementation of PEP 394, which governs the way the python command and commands like python2 and python3 work on Unix-like systems.

----------
components: Installation
messages: 141034
nosy: Kerrick.Staley
priority: normal
severity: normal
status: open
title: Implement PEP 394: The "python" Command on Unix-Like Systems
type: feature request
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Jul 24 07:12:20 2011
From: report at bugs.python.org (Roy Liu)
Date: Sun, 24 Jul 2011 05:12:20 +0000
Subject: [New-bugs-announce] [issue12628] urllib.request.urlopen gives empty
	response bodies for	some sites
In-Reply-To: <1311484340.86.0.612332840201.issue12628@psf.upfronthosting.co.za>
Message-ID: <1311484340.86.0.612332840201.issue12628@psf.upfronthosting.co.za>


New submission from Roy Liu <carsomyr at gmail.com>:

When testing urllib.request.urlopen in Python 3, I found that it gave empty responses for some sites. In other words, reading from the file-like object gives zero bytes. Python 2.x's urllib2.urlopen did not give this behavior. I isolated the problem down to the following difference:

@@ -1137,8 +1137,6 @@
             r = h.getresponse()  # an HTTPResponse instance
         except socket.error as err:
             raise URLError(err)
-        finally:
-            h.close()
 
         r.url = req.get_full_url()
         # This line replaces the .msg attribute of the HTTPResponse

The "finally" clause is absent in urllib2.py but present in Python 3.2's request.py. I think it has something to do with the HTTPConnection being closed before data could be read. Still, it's puzzling because some sites still give expected answers. Please find attached a small test script for "www.wsj.com" for which the response body should be empty without applying the above patch.

----------
components: Extension Modules
files: test.py
messages: 141039
nosy: royliu
priority: normal
severity: normal
status: open
title: urllib.request.urlopen gives empty response bodies for some sites
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file22739/test.py

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

From report at bugs.python.org  Sun Jul 24 20:35:07 2011
From: report at bugs.python.org (Kevin Stock)
Date: Sun, 24 Jul 2011 18:35:07 +0000
Subject: [New-bugs-announce] [issue12629] HTMLParser silently stops parsing
	with malformed	attributes
In-Reply-To: <1311532507.83.0.00235537878353.issue12629@psf.upfronthosting.co.za>
Message-ID: <1311532507.83.0.00235537878353.issue12629@psf.upfronthosting.co.za>


New submission from Kevin Stock <teoryn at gmail.com>:

Given the input '<x><y z=""o"" /></x>', HTMLParser only detects the opening x tag, and then stops parsing. Ideally this should behave like the case '<x><y z="""" /></x>' which raises an error and then can continue parsing the close x tag.

----------
components: Library (Lib)
files: test.py
messages: 141051
nosy: teoryn
priority: normal
severity: normal
status: open
title: HTMLParser silently stops parsing with malformed attributes
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22745/test.py

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

From report at bugs.python.org  Mon Jul 25 01:05:00 2011
From: report at bugs.python.org (tkiss80)
Date: Sun, 24 Jul 2011 23:05:00 +0000
Subject: [New-bugs-announce] [issue12630] pydoc does not remove '#'-s from
	doc comments
In-Reply-To: <1311548700.89.0.657910750952.issue12630@psf.upfronthosting.co.za>
Message-ID: <1311548700.89.0.657910750952.issue12630@psf.upfronthosting.co.za>


New submission from tkiss80 <tkiss80 at gmail.com>:

If an entity does not have a docstring, pydoc.getdoc() reads the comment associated with that entity and uses that as the source of documentation. However, inspect.getcomments() returns the raw comment with the comment signs ('#') in it, thus the resulting documentation looks ugly and confusing. Is there a way to solve this problem?

I know that this is not an easy task, because by implementing a specific '#' removing solution, the format of the doc comments would be restricted to conform to that algorithm with little formatting freedom. But maybe someone can come up with a good idea, such as counting '#'-s in the first line and strip all the lines accordingly.

----------
messages: 141061
nosy: tkiss80
priority: normal
severity: normal
status: open
title: pydoc does not remove '#'-s from doc comments
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Jul 25 02:26:30 2011
From: report at bugs.python.org (py.user)
Date: Mon, 25 Jul 2011 00:26:30 +0000
Subject: [New-bugs-announce] [issue12631] Mutable Sequence Type in .remove()
	is consistent only	with lists, but not with bytearrays
In-Reply-To: <1311553590.08.0.463284730319.issue12631@psf.upfronthosting.co.za>
Message-ID: <1311553590.08.0.463284730319.issue12631@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

4.6.4 Mutable Sequence Types

|  s.remove(x)  |  same as del s[s.index(x)]  |


>>> b = bytearray()
>>> b.extend(range(1, 6))
>>> b
bytearray(b'\x01\x02\x03\x04\x05')
>>> b.remove(2)
>>> del b[b.index(2)]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Type int doesn't support the buffer API
>>>

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 141066
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: Mutable Sequence Type in .remove() is consistent only with lists, but not with bytearrays
versions: Python 3.1

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

From report at bugs.python.org  Mon Jul 25 04:24:49 2011
From: report at bugs.python.org (Bruce Ferris)
Date: Mon, 25 Jul 2011 02:24:49 +0000
Subject: [New-bugs-announce] [issue12632] Windows GPF with Code Page 65001
In-Reply-To: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za>
Message-ID: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za>


New submission from Bruce Ferris <bferris57 at bferris.co.uk>:

The following scenario GPFs on Windows Vista using cmd.exe...

  D:\>python
  Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit
   (Intel)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>> ^Z

  D:\>chcp 65001
  Active code page: 65001

  D:\>python
  Fatal Python error: Py_Initialize: can't initialize sys standard
   streams
  LookupError: unknown encoding: cp65001

  This application has requested the Runtime to terminate it in an 
  unusual way.
  Please contact the application's support team for more information.

  D:\>

This is a bit surprising since Code Page 65001 IS the official Microsoft UTF-8 Code Page.

Please see...

  http://msdn.microsoft.com/en-us/library/dd317756%28v=vs.85%29.aspx

----------
components: Unicode
messages: 141067
nosy: bferris57
priority: normal
severity: normal
status: open
title: Windows GPF with Code Page 65001
versions: Python 3.1

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

From report at bugs.python.org  Mon Jul 25 06:49:50 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 25 Jul 2011 04:49:50 +0000
Subject: [New-bugs-announce] [issue12633] sys.modules gets special treatment
In-Reply-To: <1311569390.98.0.906064511142.issue12633@psf.upfronthosting.co.za>
Message-ID: <1311569390.98.0.906064511142.issue12633@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

The sys.modules dict is a special object.  It is the only variable of the CPython interpreter object that is exposed in the sys module[1].  Everything else in sys lives in the module.  However, the modules dict lives in the interpreter object and is bound to the sys module separately.  No other variable of the interpreter object gets this treatment.

This situation sets up an unexpected behavior for sys.modules.  There are many places, mostly in Python/import.c, where the modules dict gets used and not by pulling from sys.modules.  These places use interp->modules directly[2].  So if sys.modules is re-bound, the imp module is using/reporting an out of sync modules dict.

One could argue that re-binding a module global is risky and should be avoided.  I agree.  Here is the use case that prompted me to march ahead anyway:

class BaseTest(TestCase):
    @classmethod
    def setUpClass(cls):
        cls.sysmodules = sys.modules
        sys.modules = sys.modules.copy()
    @classmethod
    def tearDownClass(cls):
        sys.modules = cls.sysmodules

I was writing some import related tests and wanted sys.modules to be returned to its initial state after each test.  I realise that Lib/test/support.py provides CleanImport and others address this, but you have to provide the module names to clean up.  This is an unfortunate hassle sometimes when several layers of imports happen during the import of the module you care about.

So the result was an exception when I tried importing an extension module, like "_sqlite3".  This is because in importdl.h the new module is added to the dict returned by PyImport_GetModuleDict(), not to the one at sys.modules.

For now I am doing the following to get the same effect:

class BaseTest(TestCase):
    @classmethod
    def setUpClass(cls):
        cls.sysmodules = sys.modules.copy()
    @classmethod
    def tearDownClass(cls):
        for name in sys.modules:
            del sys.modules[name]
        for name in cls.sysmodules:
            sys.modules[name] = cls.sysmodules[name]

However, this is less efficient, sort of.  I expect that the current direct use of interp->modules in the CPython code is [much?] more efficient than PySys_GetObject("modules") calls.

Proposal

In light of all this I recommend that either use of interp->modules be replaced by PySys_GetObject("modules") calls, or the sys module documentation[3] be updated to make clear that sys.modules should not be re-bound (in a CPython implementation detail note).  I'm guessing that the first option is right out.  The documentation addition would be just right.


[1] variables of the interpreter object found by grepping "interp->" in the CPython source:
     modules
     modules_by_index
     next
     codec_search_path
     codec_search_cache
     codec_error_registry
     codecs_initialized
     fscodec_initialized
     modules_reloading
     builtins
     sysdict
     tstate_head
     tscdump
     dlopenflags
[2] see PyImport_GetModuleDict() in Python/import.c
[3] http://docs.python.org/dev/library/sys.html#sys.modules

----------
messages: 141068
nosy: ericsnow, ncoghlan
priority: normal
severity: normal
status: open
title: sys.modules gets special treatment
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 25 08:36:50 2011
From: report at bugs.python.org (Ashutosh Swain)
Date: Mon, 25 Jul 2011 06:36:50 +0000
Subject: [New-bugs-announce] [issue12634] Random Remarks in class
	documentation
In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za>
Message-ID: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za>


New submission from Ashutosh Swain <ats.engg at gmail.com>:

URL: http://docs.python.org/tutorial/classes.html
section: 9.4 Random Remarks 

The first sentense is bit confusing:
"Data attributes override method attributes with the same name"

Is it possible to change the sentense something like this:
"Data attributes set through instance override method attributes with the same name"

----------
assignee: docs at python
components: Documentation
messages: 141073
nosy: ats.engg, docs at python
priority: normal
severity: normal
status: open
title: Random Remarks in class documentation
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 25 09:36:47 2011
From: report at bugs.python.org (HaiYun Yan)
Date: Mon, 25 Jul 2011 07:36:47 +0000
Subject: [New-bugs-announce] [issue12635] use "as" for block scope support
In-Reply-To: <1311579407.7.0.367368454098.issue12635@psf.upfronthosting.co.za>
Message-ID: <1311579407.7.0.367368454098.issue12635@psf.upfronthosting.co.za>


New submission from HaiYun Yan <lyricconch at gmail.com>:

use "as" for block scope support
just like mozilla javascript "let" extension
https://developer.mozilla.org/en/new_in_javascript_1.7#Block_scope_with_let_%28Merge_into_let_Statement%29

usage:

as_clause(as_declare): "as" NAME
as_stmt: NAME "as" test
as_expr: "(" expr "as" NAME ")" expr

var declare by as_clause is alive in <suite> only
eg:
<NAME "f" binding saved>with open(...) as f<NAME "f" bind to HEAPObj>:
   ...
<NAME "f" binding restored>

the same rule to "except E as e: "

spec:
from socket import AF_INET as IPv4
<IPv4 bind to socket.AF_INET slot>
IPv4 = None
assert socket.AF_INET == None

var in as_stmt is alive in current indentation
eg:
for i in range(10):
   <NAME "t" binding saved>
   t as f()+1 <NAME "t" bind to f()+1>
   ...
   <NAME "t" binding restored>

var in as_expr is alive in sub expr only
eg:
t = None
x = (2+3 as t) t**2
assert t == None ane  x == 25

Suggestion:
new opcode
ENTER_BLOCK #depth #varslots

----------
components: Interpreter Core
messages: 141076
nosy: lyricconch
priority: normal
severity: normal
status: open
title: use "as" for block scope support
type: feature request

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

From report at bugs.python.org  Mon Jul 25 11:52:55 2011
From: report at bugs.python.org (ledave123)
Date: Mon, 25 Jul 2011 09:52:55 +0000
Subject: [New-bugs-announce] [issue12636] IDLE ignores -*- coding -*- with
	-r option
In-Reply-To: <1311587575.82.0.250460007364.issue12636@psf.upfronthosting.co.za>
Message-ID: <1311587575.82.0.250460007364.issue12636@psf.upfronthosting.co.za>


New submission from ledave123 <ledave123 at yahoo.fr>:

I'm on Windows with cp1252 as the default encoding.
When I use -*- coding: c1252 -*- I get no problems.
When I use -*- coding: utf-8 -*- IDLE -r still opens the file with cp1252 encoding.
Python.exe opens the file with utf-8 correctly.

I think the problem is in Python32\Lib\idlelib\PyShell.py line 585:
In class ModifiedInterpreter:

    def execfile(self, filename, source=None):
        "Execute an existing file"
        if source is None:
            source = open(filename, "r").read() # this is the bug IMHO

----------
components: IDLE
messages: 141081
nosy: ledave123
priority: normal
severity: normal
status: open
title: IDLE ignores -*- coding -*- with -r option
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Jul 25 13:04:21 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 25 Jul 2011 11:04:21 +0000
Subject: [New-bugs-announce] [issue12637] logging lastResort handler not
	ignoring messages less	than WARNING
In-Reply-To: <1311591861.64.0.698091326071.issue12637@psf.upfronthosting.co.za>
Message-ID: <1311591861.64.0.698091326071.issue12637@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

The 'Advanced Logging Tutorial' states about the lastResort handler:
"The handler?s level is set to WARNING, so all events at this and
greater severities will be output."

Python 3.2 does not follow this behavior:

Python 3.2 (r32:88445, Jun 18 2011, 20:30:18)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> root = logging.getLogger()
>>> root.setLevel('DEBUG')
>>> root.warning('warning msg')
warning msg
>>> root.debug('debug msg')
debug msg
>>> 

This is fixed with the attached patch:

Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> root = logging.getLogger()
>>> root.setLevel('DEBUG')
>>> root.warning('warning msg')
warning msg
>>> root.debug('debug msg')
>>>

----------
components: Library (Lib)
files: logging_lastResort.patch
keywords: patch
messages: 141085
nosy: xdegaye
priority: normal
severity: normal
status: open
title: logging lastResort handler not ignoring messages less than WARNING
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22748/logging_lastResort.patch

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

From report at bugs.python.org  Mon Jul 25 17:34:58 2011
From: report at bugs.python.org (Carl)
Date: Mon, 25 Jul 2011 15:34:58 +0000
Subject: [New-bugs-announce] [issue12638] urllib.URLopener prematurely
	deletes files on cleanup
In-Reply-To: <1311608098.49.0.512505187556.issue12638@psf.upfronthosting.co.za>
Message-ID: <1311608098.49.0.512505187556.issue12638@psf.upfronthosting.co.za>


New submission from Carl <carl at carlbook.com>:

urllib.URLopener (or urllib.request.URLopener for Python 3) and user defined classes that inherit from these prematurely delete files upon cleanup.  Any temporary files downloaded using the .retrieve() method are deleted when an instance of a URLopener is garbage collected.

I feel this is a violation since the filename is returned to the caller and then silently deleted.  It is possible to simply override the .cleanup() method, but I feel this is not a good solution.

----------
components: None
files: bug2.py
messages: 141094
nosy: carlbook
priority: normal
severity: normal
status: open
title: urllib.URLopener prematurely deletes files on cleanup
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22750/bug2.py

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

From report at bugs.python.org  Mon Jul 25 18:23:27 2011
From: report at bugs.python.org (John Keeping)
Date: Mon, 25 Jul 2011 16:23:27 +0000
Subject: [New-bugs-announce] [issue12639] msilib Directory.start_component()
	fails if keyfile is	not None
In-Reply-To: <1311611007.28.0.321431208072.issue12639@psf.upfronthosting.co.za>
Message-ID: <1311611007.28.0.321431208072.issue12639@psf.upfronthosting.co.za>


New submission from John Keeping <john.keeping at lineone.net>:

If msilib.Directory.start_component() is called with the keyfile argument not None then it attempts to call self.cab.gen_id(self.absolute, keyfile) but the msilib.CAB.gen_id() method takes only two arguments (not three).

----------
components: Windows
files: msilib.gen_id.patch
keywords: patch
messages: 141098
nosy: john.keeping
priority: normal
severity: normal
status: open
title: msilib Directory.start_component() fails if keyfile is not None
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file22751/msilib.gen_id.patch

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

From report at bugs.python.org  Tue Jul 26 01:37:51 2011
From: report at bugs.python.org (python272)
Date: Mon, 25 Jul 2011 23:37:51 +0000
Subject: [New-bugs-announce] [issue12640] test_ctypes seg fault
	(test_callback_register_double); armv7; gcc 4.5.1
In-Reply-To: <1311637071.74.0.758300374846.issue12640@psf.upfronthosting.co.za>
Message-ID: <1311637071.74.0.758300374846.issue12640@psf.upfronthosting.co.za>


New submission from python272 <letters.random13 at gmail.com>:

[meego]$/opt/org.python.python-2.7.2/bin/python -m test.regrtest ...
...
test_callback_register_double (ctypes.test.test_callbacks.SampleCallbacksTestCase) ... Segmentation fault

this is after a native (not cross-compile) configure; make; make install on armv7:
== CPython 2.7.2 (default, Jul 25 2011, 11:06:06) [GCC 4.5.1 20100731 (MeeGo 4.5.1-1) [release 4.5-2010.09-1]]
==   Linux-2.6.37-24.5.CE-adaptation-n900-armv7l-with-glibc2.4 little-endian
==   /tmp/test_python_6700
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)

that is the only regrtest seg fault, but there are several worrisome(?) failures in test_ctypes:
...
======================================================================
FAIL: test_longlongresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/org.python.python-2.7.2/lib/python2.7/ctypes/test/test_functions.py", line 167, in test_longlongresult
    self.assertEqual(result, 21)
AssertionError: 10L != 21
...
Ran 335 tests in 3.949s

FAILED (failures=17, errors=1, skipped=1)
test test_ctypes failed -- multiple errors occurred
1 test failed:
    test_ctypes
============

a few other test modules have failures, they appear to be less severe:
test_cmath 
test_float 
#http://bugs.python.org/issue12331
test_lib2to3 
test_math 
test_pyexpat 
test_strtod


=================
note: the arm systems i have access to (meego armv7 & android sl4a/py4a) both natively use python < 2.6.7; forgive my ignorance if 2.7 series is not expected to be mature on arm. please also forgive if i should have just disabled ctypes in setup.py as many of the online (cross-compile) instructions suggest:
disabled_module_list.append('_ctypes')
===============

test_ctypes for a native build of 2.6.7 does not seg fault, but does have the same test failures:
========
...
Ran 327 tests in 3.025s

FAILED (failures=17)
test test_ctypes failed -- multiple errors occurred
1 test failed:
    test_ctypes

----------
components: Tests
messages: 141131
nosy: python272
priority: normal
severity: normal
status: open
title: test_ctypes seg fault (test_callback_register_double); armv7; gcc 4.5.1
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul 26 19:02:31 2011
From: report at bugs.python.org (Jon)
Date: Tue, 26 Jul 2011 17:02:31 +0000
Subject: [New-bugs-announce] [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>


New submission from Jon <jon.forums at gmail.com>:

The use of -mno-cygwin at http://bit.ly/qAIsZV causes build failures with versions of MinGW GCC. For example http://bit.ly/llK3f3

I recently ran into it trying to build a Mercurial snapshot using a MinGW GCC v4.6.2 flavor http://pastie.org/2274486

Why is -mno-cygwin still be used, and is there any reason why it can't be removed?

Thanks, Jon

----------
assignee: tarek
components: Distutils
messages: 141172
nosy: eric.araujo, jonforums, tarek
priority: normal
severity: normal
status: open
title: Remove -mno-cygwin from distutils
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul 26 23:20:19 2011
From: report at bugs.python.org (Jann Eike Kruse)
Date: Tue, 26 Jul 2011 21:20:19 +0000
Subject: [New-bugs-announce] [issue12642] 2.6.6 documentation of the open()
	built-in function
In-Reply-To: <1311715219.77.0.164344328426.issue12642@psf.upfronthosting.co.za>
Message-ID: <1311715219.77.0.164344328426.issue12642@psf.upfronthosting.co.za>


New submission from Jann Eike Kruse <python at jannkruse.de>:

The documentation page 

http://docs.python.org/release/2.6.6/library/functions.html?highlight=open#open

describes the  open()  built-in function as

  open(filename[, mode[, bufsize]])

but the Python interpreter complains:

  Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40) 
  [GCC 4.4.5] on linux2 
  Type "help", "copyright", "credits" or "license" for more information.
  >>> 
  >>> 
  >>> file_descriptor = open(filename='/spam')
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: Required argument 'name' (pos 1) not found
  >>> 
  >>> 
  >>> file_descriptor = open(name='/spam', bufsize=-1)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: 'bufsize' is an invalid keyword argument for this function
  >>> 
  >>> 
  >>> file_descriptor = open(name='/spam', buffering=-1)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  IOError: [Errno 2] No such file or directory: '/spam'
  >>> _
  

So the documentation page should read

  open(name[, mode[, buffering]])
       ----          ---------

instead, note 'name' not 'filename' and 'buffering' not 'bufsize'.

Maybe it's relevant, because Debian/stable still ships with
Python 2.6.6 and I guess the Python 2.7.x documentation has 
the same bug.

The """docstring""" does already reflect that correctly.


PS:
This is my first bug report. I hope I did this right. 
Mercy, please! ;)

----------
assignee: docs at python
components: Documentation
messages: 141183
nosy: docs at python, jannkruse
priority: normal
severity: normal
status: open
title: 2.6.6 documentation of the  open()  built-in function
versions: Python 2.6

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

From report at bugs.python.org  Wed Jul 27 14:10:07 2011
From: report at bugs.python.org (aliles)
Date: Wed, 27 Jul 2011 12:10:07 +0000
Subject: [New-bugs-announce] [issue12643] code.InteractiveConsole ignores
	sys.excepthook
In-Reply-To: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za>
Message-ID: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za>


New submission from aliles <aaron.iles at gmail.com>:

code.InteractiveConsole doesn't match the CPython interactive interpreter with respect to allowing sys.excepthook to handle exceptions. Unlike the interactive interpreter, replacing sys.excepthook with an alternate function will not change exception handling behaviour from inside a code.InteractiveConole

This affects downstream interpreters such as PyPy.
https://bugs.pypy.org/issue811

----------
components: Library (Lib)
files: console.py
messages: 141222
nosy: aliles
priority: normal
severity: normal
status: open
title: code.InteractiveConsole ignores sys.excepthook
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22771/console.py

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

From report at bugs.python.org  Wed Jul 27 16:29:14 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 27 Jul 2011 14:29:14 +0000
Subject: [New-bugs-announce] [issue12644] document the "%a" conversion in
	the old string	formatting operations
In-Reply-To: <1311776954.08.0.677656936944.issue12644@psf.upfronthosting.co.za>
Message-ID: <1311776954.08.0.677656936944.issue12644@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The 'a' conversion type isn't documented in library/stdtypes.rst

----------
assignee: eli.bendersky
components: Documentation
keywords: gsoc
messages: 141228
nosy: eli.bendersky
priority: low
severity: normal
status: open
title: document the "%a" conversion in the old string formatting operations
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jul 27 20:03:35 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 27 Jul 2011 18:03:35 +0000
Subject: [New-bugs-announce] [issue12645] test.support. import_fresh_module
	- incorrect doc
In-Reply-To: <1311789815.76.0.639942891335.issue12645@psf.upfronthosting.co.za>
Message-ID: <1311789815.76.0.639942891335.issue12645@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

>From Ezio Melotti's email to python-dev:


    diff --git a/Doc/library/test.rst b/Doc/library/test.rst
    --- a/Doc/library/test.rst
    +++ b/Doc/library/test.rst
    @@ -447,7 +447,7 @@
        Module and package deprecation messages are suppressed during this import
        if *deprecated* is ``True``.

    -   This function will raise :exc:`unittest.SkipTest` is the named module
    +   This function will raise :exc:`unittest.SkipTest` if the named module


Actually I think this is no longer true.  import_fresh_module raises an ImportError if *name* can't be imported, or returns None if the fresh module is not found.

Its use case is to enable or block accelerations for modules that optionally provide one.  All the modules that currently use import_fresh_module are (afaik) always available (json, warnings, heapq), so raising SkipTest when the module is missing is not useful now.
It returns None in the case an acceleration is missing, so e.g. in "cjson = import_fresh_module('json', fresh=['_json'])" cjson will be None and it will be possible to do things like @skipUnless(cjson, 'requires _json').  Here raising an ImportError will defeat (part of) the purpose of the function, i.e. avoiding:
try:
 import _json
except ImportError:
 _json = None

and raising a SkipTest when the accelerations are missing is not an option if there are other tests (e.g. the tests for the Python implementation).

These changes come from http://hg.python.org/cpython/rev/c1a12a308c5b .  Before the change import_fresh_module was still returning the module (e.g. json) even when the acceleration (fresh=['_json']) was missing, and the C tests were run twice using the same pure-python module used for the Py ones.

The typo and the wrong doc is also on 2.7.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 141255
nosy: docs at python, eli.bendersky, ezio.melotti
priority: normal
severity: normal
status: open
title: test.support. import_fresh_module - incorrect doc
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Jul 27 20:29:22 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Wed, 27 Jul 2011 18:29:22 +0000
Subject: [New-bugs-announce] [issue12646] zlib.Decompress.decompress/flush
	do not raise any	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>


New submission from Oleg Oshmyan <chortos at inbox.lv>:

If a truncated input stream is given to the zlib.decompress function, it raises a zlib.error. However, if the same stream is fed to a zlib.Decompress object, no exception is raised during the entire lifetime of the object. Attached is an example demonstrating the discrepancy.

zlib.decompress raises this exception when it gets a Z_BUF_ERROR from zlib, while the implementation of zlib.Decompress.decompress just skips every Z_BUF_ERROR it gets as described in this (apparently inaccurate) comment:
        /* We will only get Z_BUF_ERROR if the output buffer was full
           but there wasn't more output when we tried again, so it is
           not an error condition.
        */

----------
components: Extension Modules
files: zlib-fail.py
messages: 141257
nosy: chortos
priority: normal
severity: normal
status: open
title: zlib.Decompress.decompress/flush do not raise any exceptions when given truncated input streams
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22777/zlib-fail.py

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

From report at bugs.python.org  Wed Jul 27 21:26:16 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Jul 2011 19:26:16 +0000
Subject: [New-bugs-announce] [issue12647] Add __bool__ to None
In-Reply-To: <1311794776.71.0.254853675833.issue12647@psf.upfronthosting.co.za>
Message-ID: <1311794776.71.0.254853675833.issue12647@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Currently bool(None) returns False only because it has a special case in PyObject_IsTrue().   All other types can become False only if they implement __bool__() or __len__().

I propose removing the special case branch and instead adding __bool__ to None.  This will simplify the explanation of what bool() does to:  "bool(x) always returns True unless the object defines __bool__() to return False or defines __len__() to return a non-zero value".

The removal of the special case will slightly slow down tests for "if None", and it will slightly speed-up tests for "if x" where x is something other than True, False, or None.

----------
assignee: rhettinger
components: Interpreter Core
messages: 141269
nosy: rhettinger
priority: low
severity: normal
status: open
title: Add __bool__ to None
versions: Python 3.3

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

From report at bugs.python.org  Thu Jul 28 11:40:03 2011
From: report at bugs.python.org (kota)
Date: Thu, 28 Jul 2011 09:40:03 +0000
Subject: [New-bugs-announce] [issue12648] Wrong import module search order
	on Windows
In-Reply-To: <1311846003.79.0.904743673634.issue12648@psf.upfronthosting.co.za>
Message-ID: <1311846003.79.0.904743673634.issue12648@psf.upfronthosting.co.za>


New submission from kota <nospam.kotarou.dono at gmail.com>:

There seems to be a wrong import module search order (http://docs.python.org/tutorial/modules.html#the-module-search-path) on Windows. Python seems to be loading the built-in module instead of the python code with the same name as the module in the current directory. This only happens on Windows as I tested on Linux and it loaded the module properly.

Steps to reproduce:
1. Create a file named `parser.py' containing `print "test"'
2. Open a console window to the directory you created the file in and run `python2.7 -v' or `python -v'
3. Type `import parser'

On Windows, I get this output:
import encodings.cp437 # from c:\Python27\lib\encodings\cp437.py
# wrote c:\Python27\lib\encodings\cp437.pyc
import parser # builtin

On Linux, I get this:
import parser # from parser.py
# wrote parser.pyc
test

`sys.path' on Windows:
['', 'C:\\WINDOWS\\system32\\python27.zip', 'c:\\Python27\\DLLs', 'c:\\Python27\\lib', 'c:\\Python27\\lib\\plat-win', 'c:\\Python27\\lib\\lib-tk', 'c:\\Python27', 'c:\\Python27\
\lib\\site-packages']

`sys.path' on Linux:
['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PIL', '/usr/lib/pymodules/python2.7/gtk-2.0', '/usr/lib/python2.7/dist-packages/gst-0.10', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7']

----------
components: None
messages: 141288
nosy: kota
priority: normal
severity: normal
status: open
title: Wrong import module search order on Windows
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 28 15:15:06 2011
From: report at bugs.python.org (dandre)
Date: Thu, 28 Jul 2011 13:15:06 +0000
Subject: [New-bugs-announce] [issue12649] email.Header corupts international
	email header and	ignores maxlinelen in some cases
In-Reply-To: <1311858906.9.0.41182214935.issue12649@psf.upfronthosting.co.za>
Message-ID: <1311858906.9.0.41182214935.issue12649@psf.upfronthosting.co.za>


New submission from dandre <andre.d at gmx.net>:

Hello there, first of all, thank you all for Python. I didn't know it was so great; otherwise I'd have checked it out before.

Using 2.7.2 MSC v.1500 32 Intel bit for now.

Playing with email.header, I came across an odd behaviour.

Attached please find a script which demonstrates that
1) maxlinelen is ignored and
2) header fields are split in a manner not suitable for all systems involved in email processing.

The script will print the headers. They're all the same and extend over two lines; both should probably not be the case, although it dosn't hurt in itself.

If you uncomment the SMTP part of the script and send that email to yourself, you'll probably see that the From: and To: header will be misinterpreted by your email client; I tested this with two different email providers. Looking at the raw data which are received, it appears that at least in one case, a system along the way added a comma between the two "To:" lines. This is something which one should easily be able to avoid, if only the maxlinelen would be obeyed...

Having taken a look at email.header.py, it appears to me that the semantics of _encode_chunks() does not exactly match its documentation due to the results of (at least some) charset.header_encode() calls. What seems to happen is that charset.header_encode() can return several lines already, and it will apparently split the line without any deeper knowledge. As a result, the Header module will not apply its sophisticated maxlinelen/splitchars logic. The header is split at some pretty arbitrary point and not all systems appear to be happy with that, although the relevant RFC apparently only reads "SHOULD" in this regard.

----------
components: Library (Lib)
files: email_header_bug.py
messages: 141290
nosy: dandre
priority: normal
severity: normal
status: open
title: email.Header corupts international email header and ignores maxlinelen in some cases
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file22783/email_header_bug.py

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

From report at bugs.python.org  Thu Jul 28 15:59:00 2011
From: report at bugs.python.org (gabriele.trombetti)
Date: Thu, 28 Jul 2011 13:59:00 +0000
Subject: [New-bugs-announce] [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>


New submission from gabriele.trombetti <g.trombetti at plasmacore.com>:

There seems to be a file descriptor (fd) leak in subprocess upon call to kill() and then destroying the current subprocess object (e.g. by scope exit) if the pipe functionality is being used.

This is a reproducer:

(Linux 2.6.25, Python 2.7.1 (r271:86832))

import subprocess, time
def leaktest():
    subp = subprocess.Popen("echo hi; sleep 200; echo bye", shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    #you can do something here
    subp.terminate()
    #subp.wait() #Fixes the bug
    #time.sleep(0.001) #fixes the bug
    #time.sleep(0.0000001) #doesn't fix the bug
    return True

Launch the function multiple times interactively, each time the number of open file descriptors for the python process will increase by 2. You can see that by "ls -l /proc/<pid>/fd"
This seems to be a race condition because adding a time.sleep(0.001) before the return fixes the problem. Probably some kernel delay is responsible for the race. 

This bug is significant for daemons because the daemon will die once the number of open file descriptors hits the ulimit, usually 1024, so please fix. 

Note: until the bug is fixed, a simple workaround (not documented in module docs though) is to call Popen.wait() after Popen.kill()

Thank you

----------
components: Library (Lib)
messages: 141295
nosy: gabriele.trombetti
priority: normal
severity: normal
status: open
title: Subprocess leaks fd upon kill()
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 29 00:09:12 2011
From: report at bugs.python.org (Pedro Larroy)
Date: Thu, 28 Jul 2011 22:09:12 +0000
Subject: [New-bugs-announce] [issue12651] -O2 or -O3? this brings excitement
	to computing!
In-Reply-To: <1311890952.9.0.743029237922.issue12651@psf.upfronthosting.co.za>
Message-ID: <1311890952.9.0.743029237922.issue12651@psf.upfronthosting.co.za>


New submission from Pedro Larroy <pedro.larroy at gmail.com>:

When I build it compiles with both -O2 and -O3...

this is debian testing on amd64.

gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Python/getcompiler.o Python/getcompiler.c

----------
components: Build
messages: 141318
nosy: Pedro.Larroy
priority: normal
severity: normal
status: open
title: -O2 or -O3? this brings excitement to computing!
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 29 09:45:25 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 29 Jul 2011 07:45:25 +0000
Subject: [New-bugs-announce] [issue12652] Move documentation of test.support
	into the devguide
In-Reply-To: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>
Message-ID: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

First step in transition:

Attaching a patch to devguide's runtests.rst to incorporate existing test.support documentation from 3.3 head, with some small markup changes suitable for the devguide.

----------
components: Devguide
files: devguide_test_support.1.patch
keywords: patch
messages: 141337
nosy: brett.cannon, docs at python, eli.bendersky, ncoghlan
priority: low
severity: normal
stage: patch review
status: open
title: Move documentation of test.support into the devguide
type: behavior
Added file: http://bugs.python.org/file22790/devguide_test_support.1.patch

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

From report at bugs.python.org  Fri Jul 29 12:36:23 2011
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 29 Jul 2011 10:36:23 +0000
Subject: [New-bugs-announce] [issue12653] Provide accelerators for all
	buttons in Windows	installers
In-Reply-To: <1311935783.8.0.769443256699.issue12653@psf.upfronthosting.co.za>
Message-ID: <1311935783.8.0.769443256699.issue12653@psf.upfronthosting.co.za>


New submission from Ram Rachum <ram at rachum.com>:

I was installing Python 3.2.1 on my laptop today, and was unable to efficiently use the keyboard in order to navigate the installation dialogs. Every button should have an accelerator, e.g. "Next" should be "&Next" so Alt-N will press it. (I don't know whether you use the ampersand notation or something else.)

----------
messages: 141340
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Provide accelerators for all buttons in Windows installers
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jul 29 14:45:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jul 2011 12:45:31 +0000
Subject: [New-bugs-announce] [issue12654] sum() works with bytes objects
In-Reply-To: <1311943531.95.0.378108563398.issue12654@psf.upfronthosting.co.za>
Message-ID: <1311943531.95.0.378108563398.issue12654@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

... while it apparently shouldn't:

>>> sum([b'', b''], b'')
b''
>>> sum([b'', b''], bytearray())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sum() can't sum bytes [use b''.join(seq) instead]


In 2.7, the situation is the reverse:

>>> sum([b'', b''], b'')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sum() can't sum strings [use ''.join(seq) instead]
>>> sum([b'', b''], bytearray())
bytearray(b'')

----------
components: Interpreter Core
messages: 141363
nosy: mark.dickinson, pitrou, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: sum() works with bytes objects
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 29 19:09:55 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 Jul 2011 17:09:55 +0000
Subject: [New-bugs-announce] [issue12655] Expose sched.h functions
In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za>
Message-ID: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

For fun and profit. :)

----------
components: Extension Modules
files: sched_stuff.patch
keywords: patch
messages: 141401
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: Expose sched.h functions
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22794/sched_stuff.patch

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

From report at bugs.python.org  Fri Jul 29 20:00:09 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 29 Jul 2011 18:00:09 +0000
Subject: [New-bugs-announce] [issue12656] test.test_asyncore: add tests for
	AF_INET6 and AF_UNIX	sockets
In-Reply-To: <1311962409.81.0.679396198329.issue12656@psf.upfronthosting.co.za>
Message-ID: <1311962409.81.0.679396198329.issue12656@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

As noted in issue #12502, test_asyncore only tests AF_INET sockets.
With the patch attached, the vast majority of the tests will also be run with AF_UNIX and AF_INET6 sockets (if supported by the host OS).

----------
components: Tests
files: test_ayncore.diff
keywords: needs review, patch
messages: 141404
nosy: giampaolo.rodola, neologix
priority: low
severity: normal
stage: patch review
status: open
title: test.test_asyncore: add tests for AF_INET6 and AF_UNIX sockets
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22795/test_ayncore.diff

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

From report at bugs.python.org  Fri Jul 29 20:28:08 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 29 Jul 2011 18:28:08 +0000
Subject: [New-bugs-announce] [issue12657] Cannot override JSON encoding of
	basic type subclasses
In-Reply-To: <1311964088.32.0.0267577465373.issue12657@psf.upfronthosting.co.za>
Message-ID: <1311964088.32.0.0267577465373.issue12657@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

I found this out while experimenting with enum types that inherit from int.  The json library provides for extending the encoder to handle non-basic types; in those cases, your class's .default() method is called.  However, it is impossible to override how basic types are encoded.

Worse, if you subclass int, you cannot override how instances of your subclass get encoded, because _iterencode() does isinstance() checks.  So enum values which subclass int cannot be properly encoded.

I think the isinstance checks should be changed to explicit type equality tests, e.g. `type(o) is int`.

----------
components: Library (Lib)
messages: 141406
nosy: barry
priority: normal
severity: normal
status: open
title: Cannot override JSON encoding of basic type subclasses
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul 30 10:50:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Jul 2011 08:50:55 +0000
Subject: [New-bugs-announce] [issue12658] Build fails in a non-checkout
	directory
Message-ID: <1312015855.7.0.362481082531.issue12658@psf.upfronthosting.co.za>


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


----------
nosy: pitrou
priority: normal
severity: normal
status: open
title: Build fails in a non-checkout directory

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

From report at bugs.python.org  Sat Jul 30 15:51:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Jul 2011 13:51:24 +0000
Subject: [New-bugs-announce] [issue12659] Add tests for
	packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Packaging?s test support module should have tests.

Using the ?easy? keyword because I?m willing to review and commit partial patches by new contributors instead of waiting for one complete patch.

----------
assignee: tarek
components: Distutils2
keywords: easy
messages: 141441
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Add tests for packaging.tests.support
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul 30 17:06:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Jul 2011 15:06:49 +0000
Subject: [New-bugs-announce] [issue12660] test_gdb fails when installed
In-Reply-To: <1312038409.05.0.274432685937.issue12660@psf.upfronthosting.co.za>
Message-ID: <1312038409.05.0.274432685937.issue12660@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_gdb doesn't work from an installed Python 3.3. I suppose gdb fails finding the plugin file for the Python executable, although it manifests in quite mysterious ways. The log is rather large, I'm attaching it just in case.

----------
assignee: dmalcolm
components: Tests
files: test_gdb.log
messages: 141443
nosy: dmalcolm, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: test_gdb fails when installed
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file22803/test_gdb.log

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

From report at bugs.python.org  Sat Jul 30 19:52:52 2011
From: report at bugs.python.org (Leonid Vasilev)
Date: Sat, 30 Jul 2011 17:52:52 +0000
Subject: [New-bugs-announce] [issue12661] [new function] shutil.cleartree
In-Reply-To: <1312048372.59.0.959522450911.issue12661@psf.upfronthosting.co.za>
Message-ID: <1312048372.59.0.959522450911.issue12661@psf.upfronthosting.co.za>


New submission from Leonid Vasilev <vsleonid at gmail.com>:

Hello,

This patch adds new function to shutil.
I think it's quite generic, and it fits shutil purpose.

Sample usage:
shutil.cleartree(path='/home/chin/Dev/python-hg-dev', ignore=shutil.ignore_pattterns('*.py'))

removes all files from path, except *.py files. 

and

shutil.cleartree(path='/home/chin/Dev/python-hg-dev', ignore=shutil.ignore_pattterns('*.pyc'), invert=True)

is equivalent to `find /home/chin/Dev/python-hg-dev -name "*.pyc" -delete`

----------
components: Library (Lib)
files: shutil.cleartree.patch
keywords: patch
messages: 141450
nosy: chin
priority: normal
severity: normal
status: open
title: [new function] shutil.cleartree
type: feature request
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file22804/shutil.cleartree.patch

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

From report at bugs.python.org  Sun Jul 31 15:09:12 2011
From: report at bugs.python.org (ojab)
Date: Sun, 31 Jul 2011 13:09:12 +0000
Subject: [New-bugs-announce] [issue12662] Allow configparser to process
	suplicate options
In-Reply-To: <1312117752.5.0.933932400203.issue12662@psf.upfronthosting.co.za>
Message-ID: <1312117752.5.0.933932400203.issue12662@psf.upfronthosting.co.za>


New submission from ojab <ojab at ojab.ru>:

Allow configparser to process duplicate options, just concatenating it's values, so using file

[sect1]
opt1=asd;
opt2=qwe
opt1=fgs

we will have config['sect1']['opt1'] == 'asd;fgs'

----------
components: Library (Lib)
messages: 141463
nosy: ojab
priority: normal
severity: normal
status: open
title: Allow configparser to process suplicate options
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul 31 16:33:57 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 31 Jul 2011 14:33:57 +0000
Subject: [New-bugs-announce] [issue12663] ArgumentParser.error writes to
	stderr not to stdout
In-Reply-To: <1312122837.61.0.0244813637126.issue12663@psf.upfronthosting.co.za>
Message-ID: <1312122837.61.0.0244813637126.issue12663@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, following up http://mail.python.org/pipermail/docs/2011-July/005210.html , here's a patch to fix it. It applies to all the relevant branches.

----------
assignee: docs at python
components: Documentation
files: ArgumentParser.error_stderr-default.patch
keywords: patch
messages: 141467
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: ArgumentParser.error writes to stderr not to stdout
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22808/ArgumentParser.error_stderr-default.patch

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

From report at bugs.python.org  Sun Jul 31 16:59:09 2011
From: report at bugs.python.org (Aaron Robson)
Date: Sun, 31 Jul 2011 14:59:09 +0000
Subject: [New-bugs-announce] [issue12664] Path variable - Windows installer
In-Reply-To: <1312124349.72.0.418795016594.issue12664@psf.upfronthosting.co.za>
Message-ID: <1312124349.72.0.418795016594.issue12664@psf.upfronthosting.co.za>


New submission from Aaron Robson <shiny.magnum at googlemail.com>:

One of the main barriers to getting a working development environment for me was having to discover that I needed, learn about and find out how to set up the Path variable in Windows.

I propose an option in the installer (perhaps even set to be on by default) to allow the user to choose if they want it to be added to the list or not.

My apologies if this has been raised before (my searches in the tracker didn't turn up any similar problems), I am quite new to the issue tracker however.

----------
components: Installation
messages: 141468
nosy: AaronR
priority: normal
severity: normal
status: open
title: Path variable - Windows installer
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jul 31 17:08:32 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 31 Jul 2011 15:08:32 +0000
Subject: [New-bugs-announce] [issue12665] Dictionary view example has error
	in set ops
In-Reply-To: <1312124912.45.0.454246287313.issue12665@psf.upfronthosting.co.za>
Message-ID: <1312124912.45.0.454246287313.issue12665@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, following up http://mail.python.org/pipermail/docs/2011-July/005209.html here's a patch to fix the example error on active 3.x branches.

----------
assignee: docs at python
components: Documentation
files: dict_view_examples-default.patch
keywords: patch
messages: 141469
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Dictionary view example has error in set ops
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22809/dict_view_examples-default.patch

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

From report at bugs.python.org  Sun Jul 31 17:28:13 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 31 Jul 2011 15:28:13 +0000
Subject: [New-bugs-announce] [issue12666] map semantic change not documented
	in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In `whatsnew/3.0.html`, there is little said about the map builtin:

map() and filter() return iterators. If you really need a list, a quick fix is e.g. list(map(...)), but a better fix is often to use a list comprehension (especially when the original code uses lambda), or rewriting the code so it doesn?t need a list at all. Particularly tricky is map() invoked for the side effects of the function; the correct transformation is to use a regular for loop (since creating a list would just be wasteful).

This suggests that all one must do to port to Python 3 is wrap map in list, and in fact this is what the 2to3 fixers do, when in fact, map is semantically different in how it handles arguments of different lengths. Consider the following.

    def to_tuple(*args):
        return args

    print(list(map(to_tuple, [1,2,3], [4,5,6,7])))

On Python 2, this code outputs:

[(1, 4), (2, 5), (3, 6), (None, 7)]

On Python 3, this code outputs:

[(1, 4), (2, 5), (3, 6)]

I suggest three fixes (in order of importance):

1) Document the difference in whatsnew/3.0.html.
2) Describe how one should port code of this usage to 3.0.
3) Incorporate the porting in the 2to3 fixer (if possible).

If no one objects, I'll begin on (1). Does anyone have any suggestions for a clean approach to (2)?

----------
assignee: docs at python
components: 2to3 (2.x to 3.0 conversion tool), Documentation
keywords: easy
messages: 141470
nosy: docs at python, jason.coombs
priority: normal
severity: normal
status: open
title: map semantic change not documented in What's New
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul 31 20:01:18 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 31 Jul 2011 18:01:18 +0000
Subject: [New-bugs-announce] [issue12667] Better logging.handler.SMTPHandler
	doc for 'secure'	argument
In-Reply-To: <1312135278.74.0.984312174238.issue12667@psf.upfronthosting.co.za>
Message-ID: <1312135278.74.0.984312174238.issue12667@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, following up http://mail.python.org/pipermail/docs/2011-July/005207.html here are 2 patches to correct the documentation for 'secure' argument of SMTPHandler:

- the one for default (applicable also on 3.2) adds completely the 'secure' arg (missing)
- the one for 2.7 corrects the wrong information.

Both are taken from the docstring, that seems perfectly usable for the doc.

----------
assignee: docs at python
components: Documentation
files: logging_smtphandler_secure-default.patch
keywords: patch
messages: 141473
nosy: docs at python, sandro.tosi, vinay.sajip
priority: normal
severity: normal
stage: patch review
status: open
title: Better logging.handler.SMTPHandler doc for 'secure' argument
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22810/logging_smtphandler_secure-default.patch

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

From report at bugs.python.org  Sun Jul 31 23:19:39 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 31 Jul 2011 21:19:39 +0000
Subject: [New-bugs-announce] [issue12668] 3.2 What's New: it's
	integer->string, not the opposite
In-Reply-To: <1312147179.72.0.252519921224.issue12668@psf.upfronthosting.co.za>
Message-ID: <1312147179.72.0.252519921224.issue12668@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, following up http://mail.python.org/pipermail/docs/2011-July/005087.html, here's a patch to fix the 3.2 What's New section.

----------
assignee: docs at python
components: Documentation
files: whatsnew_3.2_int2str-default.patch
keywords: patch
messages: 141476
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: 3.2 What's New: it's integer->string, not the opposite
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22813/whatsnew_3.2_int2str-default.patch

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

From report at bugs.python.org  Sun Jul 31 23:52:15 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 31 Jul 2011 21:52:15 +0000
Subject: [New-bugs-announce] [issue12669] test_curses skipped on buildbots
In-Reply-To: <1312149135.76.0.0319517534091.issue12669@psf.upfronthosting.co.za>
Message-ID: <1312149135.76.0.0319517534091.issue12669@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

When running regrtest with the -j and/or -w options, test_curses gets skipped,
complaining that stdout is not a tty. This means that the buildbots never run
this test, which is obviously a Bad Thing.

For the -w case (which applies to the buildbots), this is caused by sys.stdout
(and sys.stderr) being replaced with a StringIO instance. We can work around
this in the test by using sys.__stdout__ instead. This is perhaps ugly, but it
seems to work, and is much better than doing nothing. For the record, this has
already been proposed in issue7096 (now dead).

For the -j case things aren't quite so straightforward - each test is run in a
subprocess, with stdout and stderr redirected to pipes, so there isn't an easy
way to access the terminal the process is associated with. Off the top of my
head, the only way I can think of to work around this is to special-case
test_curses so that it runs in the main process, and I'd really much rather not
do that. Thankfully this case doesn't apply to the buildbots at present, but it
is still bothersome when running tests locally.

TLDR:
1. Is there any reason for test_curses not to use sys.__stdout__?
2. Any ideas on how to get test_curses working with regrtest.py -j?

----------
components: Tests
messages: 141477
nosy: ezio.melotti, haypo, michael.foord, nadeem.vawda, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: test_curses skipped on buildbots
type: behavior
versions: Python 3.3

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