From report at bugs.python.org  Sun Apr  1 10:07:51 2012
From: report at bugs.python.org (py.user)
Date: Sun, 01 Apr 2012 08:07:51 +0000
Subject: [New-bugs-announce] [issue14460] In re's positive lookbehind
	assertion repetition works
Message-ID: <1333267671.53.0.559378302882.issue14460@psf.upfronthosting.co.za>


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

>>> import re
>>> re.search(r'(?<=a){100,200}bc', 'abc', re.DEBUG)
max_repeat 100 200 
  assert -1 
    literal 97 
literal 98 
literal 99 
<_sre.SRE_Match object at 0xb7429f38>
>>> re.search(r'(?<=a){100,200}bc', 'abc', re.DEBUG).group()
'bc'
>>>


I expected "nothing to repeat"

----------
components: Regular Expressions
messages: 157264
nosy: ezio.melotti, mrabarnett, py.user
priority: normal
severity: normal
status: open
title: In re's positive lookbehind assertion repetition works
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Apr  1 10:12:00 2012
From: report at bugs.python.org (py.user)
Date: Sun, 01 Apr 2012 08:12:00 +0000
Subject: [New-bugs-announce] [issue14461] In re's positive lookbehind
	assertion documentation	match() cannot match
Message-ID: <1333267920.68.0.0890741084259.issue14461@psf.upfronthosting.co.za>


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

http://docs.python.org/py3k/library/re.html
"Note that patterns which start with positive lookbehind assertions will never match at the beginning of the string being searched; you will most likely want to use the search() function rather than the match() function:"

>>> re.match(r'(?<=^)abc', 'abc').group()
'abc'
>>> re.match(r'(?<=\b)abc', 'abc').group()
'abc'
>>> re.match(r'(?<=\A)abc', 'abc').group()
'abc'
>>> re.match(r'(?<=\A)abc', 'abc', re.DEBUG).group()
assert -1 
  at at_beginning_string 
literal 97 
literal 98 
literal 99 
'abc'
>>>


in some cases match() can match

----------
assignee: docs at python
components: Documentation, Regular Expressions
messages: 157265
nosy: docs at python, ezio.melotti, mrabarnett, py.user
priority: normal
severity: normal
status: open
title: In re's positive lookbehind assertion documentation match() cannot match
versions: Python 3.2

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

From report at bugs.python.org  Sun Apr  1 10:16:48 2012
From: report at bugs.python.org (py.user)
Date: Sun, 01 Apr 2012 08:16:48 +0000
Subject: [New-bugs-announce] [issue14462] In re's named group the name
	cannot contain unicode	characters
Message-ID: <1333268208.65.0.802050679023.issue14462@psf.upfronthosting.co.za>


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

http://docs.python.org/py3k/library/re.html
"(?P<name>...)

    Similar to regular parentheses, but the substring matched by the group is accessible within the rest of the regular expression via the symbolic group name name. Group names must be valid Python identifiers, and each group name must be defined only once within a regular expression."


>>> chr(255)
'?'
>>> '?'.isidentifier()
True
>>> import re
>>> re.search(r'(?P<?>a)', 'abc')
Traceback (most recent call last):
  File "/usr/local/lib/python3.2/functools.py", line 176, in wrapper
    result = cache[key]
KeyError: (<class 'str'>, '(?P<?>a)', 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/re.py", line 158, in search
    return _compile(pattern, flags).search(string)
  File "/usr/local/lib/python3.2/re.py", line 255, in _compile
    return _compile_typed(type(pattern), pattern, flags)
  File "/usr/local/lib/python3.2/functools.py", line 180, in wrapper
    result = user_function(*args, **kwds)
  File "/usr/local/lib/python3.2/re.py", line 267, in _compile_typed
    return sre_compile.compile(pattern, flags)
  File "/usr/local/lib/python3.2/sre_compile.py", line 491, in compile
    p = sre_parse.parse(p, flags)
  File "/usr/local/lib/python3.2/sre_parse.py", line 692, in parse
    p = _parse_sub(source, pattern, 0)
  File "/usr/local/lib/python3.2/sre_parse.py", line 315, in _parse_sub
    itemsappend(_parse(source, state))
  File "/usr/local/lib/python3.2/sre_parse.py", line 552, in _parse
    raise error("bad character in group name")
sre_constants.error: bad character in group name
>>>


also:
(?P=name)
(?(name)yes|no)
\g<name>

----------
assignee: docs at python
components: Documentation, Regular Expressions
messages: 157266
nosy: docs at python, ezio.melotti, mrabarnett, py.user
priority: normal
severity: normal
status: open
title: In re's named group the name cannot contain unicode characters
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Apr  1 11:27:52 2012
From: report at bugs.python.org (Ned Deily)
Date: Sun, 01 Apr 2012 09:27:52 +0000
Subject: [New-bugs-announce] [issue14463] _decimal.so compile fails in OS X
	installer builds
Message-ID: <1333272472.49.0.502934035814.issue14463@psf.upfronthosting.co.za>


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

It may also fail in other builds where the build directory is not the same as the source directory.  The problem is in setup.py function _decimal_ext which fails to create an absolute path for the libmpdec include source directory.  Patch follows.

----------
assignee: ned.deily
components: Build
messages: 157267
nosy: ned.deily, skrah
priority: normal
severity: normal
status: open
title: _decimal.so compile fails in OS X installer builds
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr  1 14:16:35 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Apr 2012 12:16:35 +0000
Subject: [New-bugs-announce] [issue14464] reference loss in test_xml_etree_c
Message-ID: <1333282595.42.0.638497827613.issue14464@psf.upfronthosting.co.za>


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

This is quite recent.

$ ./python -m test -R 3:2 test_xml_etree_c
[1/1] test_xml_etree_c
beginning 5 repetitions
12345
.....
test_xml_etree_c leaked [-2, -2] references, sum=-4

----------
assignee: eli.bendersky
components: Library (Lib)
messages: 157279
nosy: eli.bendersky, flox, pitrou
priority: critical
severity: normal
stage: needs patch
status: open
title: reference loss in test_xml_etree_c
type: resource usage
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr  1 17:28:04 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 01 Apr 2012 15:28:04 +0000
Subject: [New-bugs-announce] [issue14465] add feature to prettify XML output
Message-ID: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

I often miss lxml's "pretty_print=True" functionality. Can you implement something similar.

----------
components: Library (Lib)
messages: 157299
nosy: eli.bendersky, tshepang
priority: normal
severity: normal
status: open
title: add feature to prettify XML output
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr  1 17:33:51 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Apr 2012 15:33:51 +0000
Subject: [New-bugs-announce] [issue14466] Rip out mq instructions
Message-ID: <1333294431.46.0.420841825384.issue14466@psf.upfronthosting.co.za>


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

The devguide describes a mq-based approach (*) for generating patches, but it seems nobody (almost) uses it. We should therefore replace that description with a more traditional one ("hg diff").

(*) http://docs.python.org/devguide/patch.html#tool-usage

----------
components: Devguide
messages: 157302
nosy: ezio.melotti, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Rip out mq instructions

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

From report at bugs.python.org  Sun Apr  1 17:35:04 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Apr 2012 15:35:04 +0000
Subject: [New-bugs-announce] [issue14467] Avoid exotic documentation in the
	devguide
Message-ID: <1333294504.16.0.644587677187.issue14467@psf.upfronthosting.co.za>


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

The devguide is growing exotic documentation about e.g. how to install GNU autoconf. I think this should be avoided, or relegated to the FAQ.

----------
components: Devguide
messages: 157303
nosy: dmalcolm, eric.araujo, ezio.melotti, pitrou, rosslagerwall
priority: normal
severity: normal
status: open
title: Avoid exotic documentation in the devguide

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

From report at bugs.python.org  Sun Apr  1 18:07:47 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 01 Apr 2012 16:07:47 +0000
Subject: [New-bugs-announce] [issue14468] Update cloning guidelines in
	devguide
Message-ID: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>


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

The devguide recommends using hg update to switch between branches in one repository.  This is only practical if you build Python in a custom (sub)directory, otherwise you?d need to either do the configure-make-test dance when merging/porting patches, or skip testing.  I?ve always used one clone per Python version, where I can keep the compiled artifacts; it makes it easy to see what a file looks like in any of the three versions, easy to work on different things in the different repos (like fixing something in 3.2 that you noticed while you were adding something to 3.3), it is cheap thanks to hardlinks, fast because you run hg pull instead of hg update to merge a patch from 3.2, and is just the simplest thing that works.  I don?t think anyone uses the one-clone-with-update approach, so I think we should rewrite the instructions to talk about one clone per version.

----------
components: Devguide
messages: 157311
nosy: eric.araujo, ezio.melotti, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: Update cloning guidelines in devguide

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

From report at bugs.python.org  Sun Apr  1 18:43:00 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Apr 2012 16:43:00 +0000
Subject: [New-bugs-announce] [issue14469] Python 3 documentation links
Message-ID: <1333298580.51.0.119482106967.issue14469@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

"Other resources" links in the Python 3 documentation refer to the Python 2.7 online documentation. It is also strange that http://python.org/doc (for example from issue tracker sidebar) refer to the Python 2.7 documentation.

----------
assignee: docs at python
components: Documentation
messages: 157316
nosy: docs at python, storchaka
priority: normal
severity: normal
status: open
title: Python 3 documentation links
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Apr  1 20:06:27 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 01 Apr 2012 18:06:27 +0000
Subject: [New-bugs-announce] [issue14470] Remove use of w9xopen in
	subporcess module
Message-ID: <1333303587.03.0.401233973218.issue14470@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

As Python 3.3 declare:
Windows 2000 and Windows platforms which set COMSPEC to command.com are no longer supported due to maintenance burden.

We need to drop corresponding code from subprocess.

----------
keywords: easy
messages: 157321
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Remove use of w9xopen in subporcess module
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr  1 22:24:32 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 01 Apr 2012 20:24:32 +0000
Subject: [New-bugs-announce] [issue14471] Buffer oferrun in winreg.c
Message-ID: <1333311872.78.0.659875130211.issue14471@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

I found this issue with code analyzer in VS2010.
The problem applies to all 3.x versions, but there is no corresponding winreg.c file in 2.x.
Since I'm not sure of the maintenance state of the individual branches, I'm creating this defect hoping for guidance. Which branches should be fixed?

----------
components: Interpreter Core
files: winreg.patch
keywords: patch
messages: 157329
nosy: krisvale
priority: normal
severity: normal
status: open
title: Buffer oferrun in winreg.c
type: crash
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file25092/winreg.patch

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

From report at bugs.python.org  Mon Apr  2 12:20:42 2012
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 02 Apr 2012 10:20:42 +0000
Subject: [New-bugs-announce] [issue14472] .gitignore is outdated
Message-ID: <1333362042.78.0.183970961684.issue14472@psf.upfronthosting.co.za>


New submission from Matej Cepl <mcepl at redhat.com>:

Patch for the port of .hgignore to .gitignore is attached

----------
components: Build
files: _gitignore.patch
keywords: patch
messages: 157346
nosy: mcepl
priority: normal
severity: normal
status: open
title: .gitignore is outdated
Added file: http://bugs.python.org/file25095/_gitignore.patch

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

From report at bugs.python.org  Mon Apr  2 13:51:32 2012
From: report at bugs.python.org (Federico Reghenzani)
Date: Mon, 02 Apr 2012 11:51:32 +0000
Subject: [New-bugs-announce] [issue14473] Regex Howto error
Message-ID: <1333367492.14.0.400451963757.issue14473@psf.upfronthosting.co.za>


New submission from Federico Reghenzani <federico at reghe.net>:

There's an error in Regex Howto, when explain the operator '?', I attached the patch.

----------
assignee: docs at python
components: Documentation
files: regex_doc.diff
keywords: patch
messages: 157348
nosy: docs at python, federico.reghenzani
priority: normal
severity: normal
status: open
title: Regex Howto error
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25097/regex_doc.diff

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

From report at bugs.python.org  Mon Apr  2 14:08:20 2012
From: report at bugs.python.org (Pierre Ossman)
Date: Mon, 02 Apr 2012 12:08:20 +0000
Subject: [New-bugs-announce] [issue14474] mishandling of AttributeError in
	threads
Message-ID: <1333368500.29.0.652267156106.issue14474@psf.upfronthosting.co.za>


New submission from Pierre Ossman <ossman at cendio.se>:

These three things do not mix:

 - AttributeError
 - Threads
 - Object methods

An unhandled AttributeError thrown in a thread will not call sys.excepthook if the thread's start function is a class/object method.

Test case:


import sys
import thread

class Dummy:
	def worker(self):
		raise AttributeError

thread.start_new_thread(Dummy().worker, ())

sys.stdin.readline()


Note that you do not get a traceback here. Throwing any other exception type works fine, as does having worker() be a simple function.

I think I've traced the issue to Objects/classobject.c:instance_repr(). It tries to look up the method, making sure to handle any AttributeError this might cause. But it fails to save and restore and Exception currently already active, effectively clearing out the current exception.

----------
components: Interpreter Core
messages: 157350
nosy: ossman
priority: normal
severity: normal
status: open
title: mishandling of AttributeError in threads
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr  2 15:13:34 2012
From: report at bugs.python.org (Mikko Rasa)
Date: Mon, 02 Apr 2012 13:13:34 +0000
Subject: [New-bugs-announce] [issue14475] codecs.StreamReader.read behaves
	differently from	regular files
Message-ID: <1333372414.16.0.496350307965.issue14475@psf.upfronthosting.co.za>


New submission from Mikko Rasa <tdb at tdb.fi>:

For regular files, a read() call without arguments will read until EOF.  codecs.StreamReader does its own buffering, and if there are characters in the buffer, a read() call will be satisfied from the buffer without an attempt to read the rest of the file.  This discrepancy causes certain code that worked with regular open() fail if codecs.open() is substituted.

The easiest way to reproduce this is to first call readline() and then read().  Since readline() can't know how many characters are on the line, it will almost always leave some characters in the buffer, triggering the problem with read().

----------
messages: 157355
nosy: tdb
priority: normal
severity: normal
status: open
title: codecs.StreamReader.read behaves differently from regular files
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Apr  2 16:57:06 2012
From: report at bugs.python.org (Pierre Ossman)
Date: Mon, 02 Apr 2012 14:57:06 +0000
Subject: [New-bugs-announce] [issue14476] sudo breaks python
Message-ID: <1333378626.33.0.624726791004.issue14476@psf.upfronthosting.co.za>


New submission from Pierre Ossman <ossman at cendio.se>:

sudo breaks exception handling in Python in some subtle way. The following test program works fine when run directly, but breaks when run through sudo:


#!/usr/bin/python

import time

def a():
	try:
		while True:
			time.sleep(0.001)
	except KeyboardInterrupt:
		print "a"

def b():
	try:
		a()
	except KeyboardInterrupt:
		print "b"

b()


This is expected:

pierre at pangolin:~$ ./test.py
^Ca

But through sudo you get random behaviour:

pierre at pangolin:~$ sudo ./test.py
^Ca b
pierre at pangolin:~$ sudo ./test.py
^Ca b
pierre at pangolin:~$ sudo ./test.py
^Ca
b
pierre at pangolin:~$ sudo ./test.py
^Ca
pierre at pangolin:~$ sudo ./test.py
^Ca
pierre at pangolin:~$ sudo ./test.py
^Cb


Seen on Ubuntu 12.04 (alpha/beta) and on Fedora 16. Happens more often on Ubuntu though.

----------
components: Interpreter Core
messages: 157358
nosy: ossman
priority: normal
severity: normal
status: open
title: sudo breaks python
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr  2 18:04:49 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 02 Apr 2012 16:04:49 +0000
Subject: [New-bugs-announce] [issue14477] Rietveld test issue
Message-ID: <1333382689.52.0.891466185612.issue14477@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

This is to test issues with the Rietveld integration.

----------
messages: 157368
nosy: dmalcolm, loewis
priority: normal
severity: normal
status: open
title: Rietveld test issue

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

From report at bugs.python.org  Mon Apr  2 19:16:26 2012
From: report at bugs.python.org (James Hutchison)
Date: Mon, 02 Apr 2012 17:16:26 +0000
Subject: [New-bugs-announce] [issue14478] Decimal hashing very slow,
	could be cached
Message-ID: <1333386986.79.0.369810234487.issue14478@psf.upfronthosting.co.za>


New submission from James Hutchison <jamesghutchison at gmail.com>:

Tested on 3.2

Note that I noticed that Decimal is supposed to be faster in 3.3 but I thought I would bring this to light just in case its still relevant

Decimal hashing is very slow, even for simple numbers. I found by caching the hash result, there is significant speed up whenever a Decimal value is reused.

I created a class that inherits from Decimal and changed the __hash__ function to try/except a stored hash value as such:

    def __hash__(self):
        try: return self.myHash;
        except:
            self.myHash = super().__hash__();
            return self.myHash;

Example code:

d = dict();
start = time.time();
i = int(1);
j = int(2);
k = int(3);
for i in range(100000):
    d[i,j,k] = 5;
print(time.time() - start);

d = dict();
start = time.time();
i = Decimal(1);
j = Decimal(2);
k = Decimal(3);
for i in range(100000):
    d[i,j,k] = 5;
print(time.time() - start);

d = dict();
start = time.time();
i = CachingDecimal(1);
j = CachingDecimal(2);
k = CachingDecimal(3);
for i in range(100000):
    d[i,j,k] = 5;
print(time.time() - start);

Output
int:  0.04699993133544922
Decimal:  2.312999963760376
CachingDecimal:  0.1100001335144043

In a real life example, I changed some of the values in my code from int to Decimal because non-whole numbers needed to be supported (and this seemed like the easiest way to do so without having to worry about my == comparisons breaking) and it slowed my code down massively. Changing to a CachingDecimal type sped up one code block from 92 seconds with Decimal to 7 seconds, which was much closer to the original int speed.

Note that all of the relevant operations have to be overloaded to return the CachingDecimal type, which is a pain, so this makes a lot of sense to implement into the Decimal module. My understanding is that altering a Decimal value will always create a new Decimal object, so there shouldn't be any issues with the cached hash desyncing with the correct hash. Someone may want to check that though.

Thanks,

James

----------
components: Library (Lib)
messages: 157369
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: Decimal hashing very slow, could be cached
type: performance
versions: Python 3.2

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

From report at bugs.python.org  Mon Apr  2 22:33:45 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Apr 2012 20:33:45 +0000
Subject: [New-bugs-announce] [issue14479] Replace transplant with graft in
	devguide
Message-ID: <1333398825.72.0.80965455601.issue14479@psf.upfronthosting.co.za>


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

hg has a new "graft" command that replaces and obsoletes the transplant extension. The devguide should be changed in that regard.

----------
components: Devguide
messages: 157385
nosy: eric.araujo, ezio.melotti, pitrou, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Replace transplant with graft in devguide

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

From report at bugs.python.org  Tue Apr  3 09:23:14 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 03 Apr 2012 07:23:14 +0000
Subject: [New-bugs-announce] [issue14480] os.kill on Windows should accept
	zero as signal
Message-ID: <1333437794.42.0.926195578505.issue14480@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Starting from 3.2 Python supports os.kill for Windows.
It process signal.CTRL_C_EVENT and signal.CTRL_BREAK_EVENT, and kills pid for all other signals.

Posix allows to pass zero signal to check pid for existing.
It will be nice to keep that behavior for Windows also.
The patch should be trivial: just don't call TerminateProcess in Modules/posixmodule.c:win32_kill if sig is zero.

----------
components: Library (Lib), Windows
keywords: easy
messages: 157398
nosy: asvetlov
priority: normal
severity: normal
status: open
title: os.kill on Windows should accept zero as signal
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr  3 10:12:24 2012
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 03 Apr 2012 08:12:24 +0000
Subject: [New-bugs-announce] [issue14481] trivial formatting error in
	subprocess docs
Message-ID: <1333440744.26.0.476663601501.issue14481@psf.upfronthosting.co.za>


New submission from Chris Rebert <pybugs at rebertia.com>:

The final line under "17.1.4.2. Replacing shell pipeline" (http://docs.python.org/dev/library/subprocess.html#replacing-shell-pipeline ) isn't formatted as code (e.g. monospaced); it should be.

----------
assignee: docs at python
components: Documentation
messages: 157401
nosy: cvrebert, docs at python
priority: normal
severity: normal
status: open
title: trivial formatting error in subprocess docs
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr  3 11:28:42 2012
From: report at bugs.python.org (Popa Claudiu)
Date: Tue, 03 Apr 2012 09:28:42 +0000
Subject: [New-bugs-announce] [issue14482]
	multiprocessing.connection.Listener fails with
	invalid	address on Windows
Message-ID: <1333445322.44.0.595815869021.issue14482@psf.upfronthosting.co.za>


New submission from Popa Claudiu <pcmanticore at gmail.com>:

This is related to http://bugs.python.org/issue14151. 
When using an AF_UNIX address with multiprocessing.connection.Listener or Client, the following error will occur, due to the fact that AF_UNIX is not present in socket module.

>>> import multiprocessing.connection as con
>>> con.Listener('/var/a.pipe')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python31\lib\multiprocessing\connection.py", line 97, in __init__
    self._listener = SocketListener(address, family, backlog)
  File "C:\Python31\lib\multiprocessing\connection.py", line 216, in __init__
    self._socket = socket.socket(getattr(socket, family))
AttributeError: 'module' object has no attribute 'AF_UNIX'


The attached patch fixes this issue, the check is done in the newly added _validate_family, where a similar check is done for AF_PIPE on Unix systems.

----------
components: Library (Lib)
files: multiprocessing.patch
keywords: patch
messages: 157404
nosy: Popa.Claudiu, pitrou
priority: normal
severity: normal
status: open
title: multiprocessing.connection.Listener fails with invalid address on Windows
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25107/multiprocessing.patch

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

From report at bugs.python.org  Tue Apr  3 15:51:54 2012
From: report at bugs.python.org (Sean Grider)
Date: Tue, 03 Apr 2012 13:51:54 +0000
Subject: [New-bugs-announce] [issue14483] inspect.getsource fails to read a
	file of only comments
Message-ID: <1333461114.24.0.345526771392.issue14483@psf.upfronthosting.co.za>


New submission from Sean Grider <sean.grider at gmail.com>:

I have a custom parser that generates html files to describe what python scripts do depending on their source comments. I use inspect.getsourcelines to parse out different comments styles (I use #@, #@@ and #$ to signal custom comments)

I recently found that getsource and getsourcelines return nothing if the file contains nothing other than a def main and it's comments.

It seems that getsource stops reading after the last non-comment line. For example:

def main():
  """ description """
  #comment1
  #comment2
  #comment3

getsource on the above file will return def main and the doc_string but nothing else.

if however I change it to:
def main():
  """ description """
  #comment1
  #comment2
  #comment3
  return

I now get the entire file, but just doing the following:
def main():
  """ description """
  #comment1
  my_var = 123
  #comment2
  #comment3

will now give me def main, the doc_string and comment1, but nothing else.

Is this expected behavior? I would think that the parser should not care if the source is comments or code, I just want to read whatever is in the file.

This behavior is present on 2.7.2 on both Windows 7x64 and RedHat 2.6.39.4-2.fc12.x86_64

----------
messages: 157417
nosy: Sean.Grider
priority: normal
severity: normal
status: open
title: inspect.getsource fails to read a file of only comments
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr  3 16:10:26 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Apr 2012 14:10:26 +0000
Subject: [New-bugs-announce] [issue14484] missing return in win32_kill?
Message-ID: <1333462226.23.0.725280599354.issue14484@psf.upfronthosting.co.za>


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

Here is an excerpt from the os.kill implementation under Windows (in win32_kill(), posixmodule.c):

    if (sig == CTRL_C_EVENT || sig == CTRL_BREAK_EVENT) {
        if (GenerateConsoleCtrlEvent(sig, pid) == 0) {
            err = GetLastError();
            PyErr_SetFromWindowsErr(err);
        }
        else
            Py_RETURN_NONE;
    }

It seems there is a missing return in the first branch, when GenerateConsoleCtrlEvent() fails.

----------
components: Windows
messages: 157419
nosy: asvetlov, brian.curtin, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: missing return in win32_kill?
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Apr  3 18:28:25 2012
From: report at bugs.python.org (junyan)
Date: Tue, 03 Apr 2012 16:28:25 +0000
Subject: [New-bugs-announce] [issue14485] hi, thanks, nice to learn from you
Message-ID: <1333470442.82661.YahooMailClassic@web114201.mail.gq1.yahoo.com>


New submission from junyan <junyantao2010 at yahoo.com>:

Thank you very much, thanks for your job of the free software opening to us, and I am a primary worker on this aspect research.

best.

Yours
Junyan

----------
messages: 157431
nosy: james tao
priority: normal
severity: normal
status: open
title: hi, thanks,  nice to learn from you

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

From report at bugs.python.org  Wed Apr  4 03:05:22 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 04 Apr 2012 01:05:22 +0000
Subject: [New-bugs-announce] [issue14486] Add some versionchanged notes in
	threading docs
Message-ID: <1333501522.24.0.791616845298.issue14486@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

A (very) minor irritation discovered today - the PEP 8 style names were added to the threading.Thread API in 2.6, but the only notice of this is up at the top of the module docs.

Some embedded notices like:

  ..versionchanged:: 2.6
     Added PEP 8 compliant interfaces. See note at top of page.

might be helpful.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 157451
nosy: docs at python, ncoghlan
priority: low
severity: normal
stage: needs patch
status: open
title: Add some versionchanged notes in threading docs
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  4 04:23:39 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 04 Apr 2012 02:23:39 +0000
Subject: [New-bugs-announce] [issue14487] Add pending() query method to
	Queue.Queue
Message-ID: <1333506219.01.0.716621518629.issue14487@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The task management API in the Queue module doesn't let you check to see if there are any pending tasks still being processed.

A pending() query API (analagous to empty() and full()) would resolve that problem.

The use case is for a process that terminates when all current jobs are complete, but should immediately start processing any *new* jobs that arrive while waiting for the old ones. Using the current Queue.join() method would fail the second requirement (since the blocking calls means that no new jobs could be added while waiting for the old ones to finish).

----------
messages: 157453
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add pending() query method to Queue.Queue

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

From report at bugs.python.org  Wed Apr  4 05:22:37 2012
From: report at bugs.python.org (Janice)
Date: Wed, 04 Apr 2012 03:22:37 +0000
Subject: [New-bugs-announce] [issue14488] Can
Message-ID: <1333509757.11.0.987059185448.issue14488@psf.upfronthosting.co.za>


Changes by Janice <kiwii128 at naver.com>:


----------
nosy: kiwii128
priority: normal
severity: normal
status: open
title: Can

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

From report at bugs.python.org  Wed Apr  4 08:24:39 2012
From: report at bugs.python.org (H Xu)
Date: Wed, 04 Apr 2012 06:24:39 +0000
Subject: [New-bugs-announce] [issue14489] repr() function link on the
	built-in function	documentation is incorrect
Message-ID: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za>


New submission from H Xu <xuhdev at gmail.com>:

The `repr()` built-in function link  in this page [ http://docs.python.org/library/functions.html ] should link to the built-in version of `repr()`.
It should link to: http://docs.python.org/library/functions.html#repr

However, it links to here: http://docs.python.org/library/repr.html#module-repr

----------
assignee: docs at python
components: Documentation
messages: 157462
nosy: H.Xu, docs at python
priority: normal
severity: normal
status: open
title: repr() function link on the built-in function documentation is incorrect
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  4 13:45:22 2012
From: report at bugs.python.org (Popa Claudiu)
Date: Wed, 04 Apr 2012 11:45:22 +0000
Subject: [New-bugs-announce] [issue14490] abitype.py wrong raise format
Message-ID: <1333539922.74.0.14982794149.issue14490@psf.upfronthosting.co.za>


New submission from Popa Claudiu <pcmanticore at gmail.com>:

In Tools/abitype.py an exception is raised using the old format:

raise Exception, '%s has no PyVarObject_HEAD_INIT' % name

The attached patch fixes this problem.

----------
components: Demos and Tools
files: abitype.patch
keywords: patch
messages: 157467
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: abitype.py wrong raise format
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25114/abitype.patch

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

From report at bugs.python.org  Wed Apr  4 13:58:26 2012
From: report at bugs.python.org (Popa Claudiu)
Date: Wed, 04 Apr 2012 11:58:26 +0000
Subject: [New-bugs-announce] [issue14491] fixcid.py is using <> instead of !=
Message-ID: <1333540706.17.0.957403109352.issue14491@psf.upfronthosting.co.za>


New submission from Popa Claudiu <pcmanticore at gmail.com>:

Tools/fixcid.py uses <> instead of !=. The attached patched fixes this issue.

----------
components: Demos and Tools
files: fixcid.patch
keywords: patch
messages: 157470
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: fixcid.py is using <> instead of !=
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25116/fixcid.patch

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

From report at bugs.python.org  Wed Apr  4 14:10:22 2012
From: report at bugs.python.org (Popa Claudiu)
Date: Wed, 04 Apr 2012 12:10:22 +0000
Subject: [New-bugs-announce] [issue14492] pdeps.py has_key
Message-ID: <1333541422.42.0.575169190211.issue14492@psf.upfronthosting.co.za>


New submission from Popa Claudiu <pcmanticore at gmail.com>:

Tools/pdeps.py is using has_key for a dictionary. The attached patch fixes this issue.

----------
files: pdeps.patch
keywords: patch
messages: 157471
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: pdeps.py has_key
Added file: http://bugs.python.org/file25117/pdeps.patch

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

From report at bugs.python.org  Wed Apr  4 14:17:20 2012
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 04 Apr 2012 12:17:20 +0000
Subject: [New-bugs-announce] [issue14493] use gvfs-open/xdg-open in
	Lib/webbrowser.py
Message-ID: <1333541840.96.0.231691916093.issue14493@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

[forwarded from https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/971311]

The webbrowser.py is using gnome-open. This is no longer supported by gnome, instead they use gvfs-open. The attached patch adds support for this and will also use xdg-open if available as this is meant to be the 
cross desktop tool to use for this kind of task, see http://portland.freedesktop.org/wiki/

----------
assignee: doko
components: Library (Lib)
keywords: patch
messages: 157472
nosy: doko
priority: normal
severity: normal
status: open
title: use gvfs-open/xdg-open in Lib/webbrowser.py
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr  4 14:53:06 2012
From: report at bugs.python.org (Sven Marnach)
Date: Wed, 04 Apr 2012 12:53:06 +0000
Subject: [New-bugs-announce] [issue14494] __future__.py and its
	documentation claim absolute	imports became mandatory in 2.7,
	but they didn't
Message-ID: <1333543986.45.0.920300905324.issue14494@psf.upfronthosting.co.za>


New submission from Sven Marnach <sven at marnach.net>:

As has been pointed out before on python-dev [1], the mandatory version of '__future__.absolute_import' does not match reality.  In Python 2.7, absolute imports are not the default.

[1]: http://article.gmane.org/gmane.comp.python.devel/125446

The attached patch should fix the documentation and Lib/__future__.py.  I set the mandatory version to (3, 0, 0, "alpha", 0), in accordance with other features that became mandatory in Py3k, though there never was a 3.0a0 release.  I double-checked that absolute imports already were the default in 3.0a1.

The patch should probably be applied to all branches.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: absolute_import.patch
keywords: patch
messages: 157474
nosy: docs at python, smarnach
priority: normal
severity: normal
status: open
title: __future__.py and its documentation claim absolute imports became mandatory in 2.7, but they didn't
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25118/absolute_import.patch

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

From report at bugs.python.org  Wed Apr  4 16:59:24 2012
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 04 Apr 2012 14:59:24 +0000
Subject: [New-bugs-announce] [issue14495] Minor typo in
	tkinter.ttk.Treeview.exists docstring
Message-ID: <1333551564.21.0.378637170829.issue14495@psf.upfronthosting.co.za>


New submission from Zachary Ware <zachary.ware at gmail.com>:

I found a very very minor typo in the docstring of tkinter.ttk.Treeview.exists: "Returns True if the specified item is present in the *three*"

I assume that should be "tree".  The attached patch removes the "h".

Thanks!

--Note: This is the first time I've done anything on bugs.python.org, so if there's anything I've done wrong or could do better, please let me know!
Thanks, 
Zach

----------
assignee: docs at python
components: Documentation
files: Treeview.exists docstring.diff
keywords: patch
messages: 157483
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, gpolo, zach.ware
priority: normal
severity: normal
status: open
title: Minor typo in tkinter.ttk.Treeview.exists docstring
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25119/Treeview.exists docstring.diff

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

From report at bugs.python.org  Wed Apr  4 19:33:00 2012
From: report at bugs.python.org (Popa Claudiu)
Date: Wed, 04 Apr 2012 17:33:00 +0000
Subject: [New-bugs-announce] [issue14496] Wrong name in
	idlelib/tabbedpages.py
Message-ID: <1333560780.31.0.2464741525.issue14496@psf.upfronthosting.co.za>


New submission from Popa Claudiu <pcmanticore at gmail.com>:

In the file from the subject, page_name was used instead of tab_name, increasing the chances of a NameError exception.
I didn't find any tests for IDLE, so there are no tests attached.

----------
components: IDLE
files: idlelib.patch
keywords: patch
messages: 157494
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: Wrong name in idlelib/tabbedpages.py
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25122/idlelib.patch

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

From report at bugs.python.org  Wed Apr  4 22:30:36 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Apr 2012 20:30:36 +0000
Subject: [New-bugs-announce] [issue14497] Invalid syntax Python files in
	Python sources tree
Message-ID: <1333571436.48.0.541559960271.issue14497@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

I was very surprised to find in Python source code files that are not compatible with Python3. It turns out that this is not an exception, such files very much (see scanner script in attachment). Surely for many years no one had reached his hands run 2to3? These files need to be or to correct, or throw (when nobody needs them).

Python 3.2 detects significantly less invalid syntax files. But Python 3.3 has become more severe.

----------
assignee: ronaldoussoren
components: 2to3 (2.x to 3.x conversion tool), Demos and Tools, Library (Lib), Macintosh, Tests, Tkinter, Windows
files: scanpy.py
messages: 157501
nosy: ronaldoussoren, storchaka
priority: normal
severity: normal
status: open
title: Invalid syntax Python files in Python sources tree
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file25124/scanpy.py

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

From report at bugs.python.org  Wed Apr  4 22:49:28 2012
From: report at bugs.python.org (Matthew Scott)
Date: Wed, 04 Apr 2012 20:49:28 +0000
Subject: [New-bugs-announce] [issue14498] Python 3.x
	distutils.util.get_platform returns incorrect	value using Mac
	OSX 10.7
Message-ID: <1333572568.76.0.187073077098.issue14498@psf.upfronthosting.co.za>


New submission from Matthew Scott <matt at 11craft.com>:

Using Python 3.2.2 and Python 3.3.0a2 (installed via 64-bit installers in official DMGs on python.org), 'distutils.util.get_platform()' returns an incorrect OS version when running on Mac OSX 10.7.

Using Python 2.6.7, and Python 2.7.1 (the versions included with Mac OSX), the output indicates 'macosx-10.7' correctly.

> for version in 2.6 2.7 3.2 3.3; do python${version} -c "from __future__ import print_function;import distutils.util,sys;print(sys.version.split()[0],distutils.util.get_platform())"; done 2.6.7 macosx-10.7-intel
2.7.1 macosx-10.7-intel
3.2.2 macosx-10.6-intel
3.3.0a2 macosx-10.6-intel

Some packages make use of this in their setup.py to determine the proper location of libraries.

For example, the 'readline' distribution's setup.py does so here: https://github.com/ludwigschwardt/python-readline/blob/6f0e801fa1632fcbb0e005eb9709aaa6051a0f28/setup.py#L33

It fails due to the incorrect assumption that it's running on 10.6 instead of 10.7.  Excerpt from "python setup.py bdist_egg":

building 'readline' extension
Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/MacOSX10.6.sdk
Please check your Xcode installation
gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -isysroot /Developer/SDKs/MacOSX10.6.sdk -DHAVE_RL_CALLBACK -DHAVE_RL_CATCH_SIGNAL -DHAVE_RL_COMPLETION_APPEND_CHARACTER -DHAVE_RL_COMPLETION_DISPLAY_MATCHES_HOOK -DHAVE_RL_COMPLETION_MATCHES -DHAVE_RL_COMPLETION_SUPPRESS_APPEND -DHAVE_RL_PRE_INPUT_HOOK -I. -I/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m -c Modules/3.x/readline.c -o build/temp.macosx-10.6-intel-3.2/Modules/3.x/readline.o -Wno-strict-prototypes -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch x86_64
In file included from Modules/3.x/readline.c:8:
/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/Python.h:11:20: error: limits.h: No such file or directory

----------
assignee: eric.araujo
components: Distutils, Library (Lib), Macintosh
messages: 157504
nosy: Matthew.Scott, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Python 3.x distutils.util.get_platform returns incorrect value using Mac OSX 10.7
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Apr  5 00:01:40 2012
From: report at bugs.python.org (Ned Deily)
Date: Wed, 04 Apr 2012 22:01:40 +0000
Subject: [New-bugs-announce] [issue14499] Extension module builds fail with
	Xcode 4.3 on OS X 10.7	due to SDK move
Message-ID: <1333576900.91.0.0583021085072.issue14499@psf.upfronthosting.co.za>


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

With the release of Xcode 4.3 for OS X 10.7, Apple has moved the location of the OS X SDKs from their long-time path of /Developer to within the new Xcode.app bundle itself.  This breaks the building of extension modules with any of Distutils or packaging/Distutils2 when Python was built as as universal build with an SDK in the former location, as is the case with the python.org installers.

A workaround is to either leave the old /Developer directory in place when upgrading to Xcode 4.3 or to install a symlink to the new location:

sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer /Developer

----------
assignee: ned.deily
components: Distutils, Macintosh
messages: 157511
nosy: ned.deily, tarek
priority: critical
severity: normal
stage: needs patch
status: open
title: Extension module builds fail with Xcode 4.3 on OS X 10.7 due to SDK move
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Apr  5 00:13:14 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Apr 2012 22:13:14 +0000
Subject: [New-bugs-announce] [issue14500] test_importlib fails in refleak
	mode
Message-ID: <1333577594.41.0.849099540387.issue14500@psf.upfronthosting.co.za>


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

$ ./python -m test -R 3:2 test_importlib 
[1/1] test_importlib
beginning 5 repetitions
12345
test test_importlib failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/importlib/test/import_/test_packages.py", line 41, in test_module_not_package_but_side_effects
    submodule = import_util.import_(subname)
  File "/home/antoine/cpython/default/Lib/importlib/test/import_/util.py", line 15, in import_
    return importlib.__import__(*args, **kwargs)
  File "/home/antoine/cpython/default/Lib/importlib/_bootstrap.py", line 1046, in __import__
    return sys.modules[name.partition('.')[0]]
KeyError: 'mod'

----------
assignee: brett.cannon
components: Library (Lib), Tests
messages: 157514
nosy: brett.cannon, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_importlib fails in refleak mode
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Apr  5 08:45:55 2012
From: report at bugs.python.org (=?utf-8?b?0JzQsNC60YHQuNC8INCm0YvQv9C60LjQvQ==?=)
Date: Thu, 05 Apr 2012 06:45:55 +0000
Subject: [New-bugs-announce] [issue14501] Error initialising BaseManager
	class with 'authkey'	argument of string type.
Message-ID: <1333608355.05.0.964001699487.issue14501@psf.upfronthosting.co.za>


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

The following code:

    class TestServer(BaseManager):pass
    Server_1=TestServer(address=("127.0.0.1",55555),authkey="passkey")

produces following error in python 3.2 :

"TypeError: string argument without an encoding"

The cause is in BaseManager constructor implementation (Python32\Lib\multiprocessing\managers.py):

self._authkey = AuthenticationString(authkey)

The "AuthenticationString" class is a substitute of "bytes" class, and 
"bytes" class requires second encoding argument, if first argument is a string.

I've solved this problem, changing the code in "Python32\Lib\multiprocessing\managers.py" to following:

        if isinstance(authkey,str):
            self._authkey = AuthenticationString(authkey,'utf-8')
        else:
            self._authkey = AuthenticationString(authkey)

This works for me. Please consider to fix this issue in release.

----------
components: Extension Modules
messages: 157539
nosy: Drauger
priority: normal
severity: normal
status: open
title: Error initialising BaseManager class with 'authkey' argument of string type.
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Thu Apr  5 09:06:56 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 05 Apr 2012 07:06:56 +0000
Subject: [New-bugs-announce] [issue14502] Document better what happens on
	releasing an unacquired	lock
Message-ID: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za>


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

>From docs at python.org:

"""
I recently ran into a situation where I could not be certain that a lock 
was currently in the acquired state. I checked the documentation to 
determine what would happen if I attempted to release a lock that was 
already released, and saw an ominous warning of "Do not call this method 
when the lock is unlocked."

Needing to know what would happen, I cautiously tested it out. I half 
expected my computer to explode as I released a lock for the second 
time, but was pleased to see it raise a 'thread.error' exception which 
could be caught and handled.

I generally expect the documentation to tell me what will happen if I do 
something invalid. In this case the documentation should indicate that a 
thread.error will be raised if you release an unlocked lock.
"""


I agree: if we know that a ThreadError will always be raised in this instance, we should document it as such.

----------
assignee: docs at python
components: Documentation
messages: 157544
nosy: docs at python, georg.brandl, pitrou
priority: normal
severity: normal
status: open
title: Document better what happens on releasing an unacquired lock
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Apr  5 10:04:13 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Thu, 05 Apr 2012 08:04:13 +0000
Subject: [New-bugs-announce] [issue14503] docs:Code not highlighted
Message-ID: <1333613053.66.0.675522025893.issue14503@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

In http://docs.python.org/dev/whatsnew/3.3.html#pep-380-syntax-for-delegating-to-a-subgenerator , two code samples

----------
assignee: docs at python
components: Documentation
messages: 157551
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: docs:Code not highlighted

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

From report at bugs.python.org  Thu Apr  5 10:34:12 2012
From: report at bugs.python.org (Amnon Harel)
Date: Thu, 05 Apr 2012 08:34:12 +0000
Subject: [New-bugs-announce] [issue14504] Suggestion to improve argparse's
	help messages for	"store_const"
Message-ID: <1333614852.3.0.346870129538.issue14504@psf.upfronthosting.co.za>


New submission from Amnon Harel <amnon.harel at cern.ch>:

argparse's help messages for variables that use "store_const" can probably be improved:
- propagate the default to all the options
- mark the default option as such explicitly
- group the keywords that have the same destination together (?)
- place the default option first (?)

For example, wouldn't the attached .py be better served with a help message that looks like:
...
optional arguments:
  -h, --help         show this help message and exit
  -w, --wrench       use a wrench (default)
  -H, --hammer       use a hammer (default: wrench)
  -s, --screwdriver  use a screwdriver (default: wrench)
  -T, --tnt          just blow the whole thing up (default: wrench)
  --foo FOO          foo bar (default: None)

?

----------
components: Library (Lib)
files: demo.py
messages: 157554
nosy: Amnon.Harel
priority: normal
severity: normal
status: open
title: Suggestion to improve argparse's help messages for "store_const"
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file25129/demo.py

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

From report at bugs.python.org  Thu Apr  5 11:01:23 2012
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 05 Apr 2012 09:01:23 +0000
Subject: [New-bugs-announce] [issue14505] PyFile_FromString leaks file
	descriptors in python 2.7
Message-ID: <1333616483.39.0.0432953809764.issue14505@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

[forwarded from http://bugs.debian.org/664529]

seen with 2.7.3 rc2

File descriptors opened by PyFile_FromString don't get closed when the
reference count is decreased.

Here's my test program, pythony.c:

#include <Python.h>

int main()
{
  int i = 0;
  PyObject *obj;

  Py_Initialize();
  while (i++ < 5) {
    obj = PyFile_FromString("hello.py", "r");
    assert(obj);
    Py_DECREF(obj);
  }
  Py_Finalize();
}

hello.py is 'print("hello world")'.

I'm compiling it with both Python 2.6 and 2.7.
$ gcc pythony.c -lpython2.6 -L/usr/lib/python2.6/config -I/usr/include/python2.6/ -o pythony-2.6
$ gcc pythony.c -lpython2.7 -L/usr/lib/python2.7/config -I/usr/include/python2.7/ -o pythony-2.7

$ strace ./pythony-2.6 2>&1 | tail -n 20
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb1d097b0) = -1 EINVAL (Invalid argument)
ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb1d097b0) = -1 EINVAL (Invalid argument)
open("hello.py", O_RDONLY)              = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
close(3)                                = 0
open("hello.py", O_RDONLY)              = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
close(3)                                = 0
open("hello.py", O_RDONLY)              = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
close(3)                                = 0
open("hello.py", O_RDONLY)              = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
close(3)                                = 0
open("hello.py", O_RDONLY)              = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
close(3)                                = 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f1e1a0224f0}, {0x7f1e1a49a160, [], SA_RESTORER, 0x7f1e1a0224f0}, 8) = 0
exit_group(0)                           = ?


$ strace ./pythony-2.7 2>&1 | tail -n 20
fstat(4, {st_mode=S_IFREG|0644, st_size=1950, ...}) = 0
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0x7fa41f10f000, 4096)            = 0
close(3)                                = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ffff7bd33f0) = -1 EINVAL (Invalid argument)
ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ffff7bd33f0) = -1 EINVAL (Invalid argument)
open("hello.py", O_RDONLY)              = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
open("hello.py", O_RDONLY)              = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
open("hello.py", O_RDONLY)              = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
open("hello.py", O_RDONLY)              = 6
fstat(6, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
open("hello.py", O_RDONLY)              = 7
fstat(7, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7fa4206e24f0}, {0x7fa420b8dd50, [], SA_RESTORER, 0x7fa4206e24f0}, 8) = 0
exit_group(0)                           = ?


The Python 2.7 version never calls close, not even at Py_Finalize().

On #d-d, jwilk suspected that this change might be the cause:
http://hg.python.org/cpython/rev/0f5b64630fda/#l4.46

----------
components: Interpreter Core
messages: 157555
nosy: doko
priority: high
severity: normal
status: open
title: PyFile_FromString leaks file descriptors in python 2.7
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr  5 13:51:41 2012
From: report at bugs.python.org (Olaf Tomalka)
Date: Thu, 05 Apr 2012 11:51:41 +0000
Subject: [New-bugs-announce] [issue14506] HTMLParser can't handle erronous
	end tags with	additional tags in it
Message-ID: <1333626701.6.0.661176415375.issue14506@psf.upfronthosting.co.za>


New submission from Olaf Tomalka <olaf.tomalka at gmail.com>:

While this is wrongly formated html, I've spotted such an example on real website on the web, and all browsers handle the bad tag gracefully, while the python html parser throws an exception with "bad end tag", I think additional info in end tag should be ignored, no exception thrown and rest of the page parsed.
I'm including minimal example.

----------
components: Library (Lib)
files: minimal.py
messages: 157570
nosy: ritave
priority: normal
severity: normal
status: open
title: HTMLParser can't handle erronous end tags with additional tags in it
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file25130/minimal.py

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

From report at bugs.python.org  Thu Apr  5 14:28:38 2012
From: report at bugs.python.org (Per Myren)
Date: Thu, 05 Apr 2012 12:28:38 +0000
Subject: [New-bugs-announce] [issue14507] Segfault with starmap and izip
	combo
Message-ID: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za>


New submission from Per Myren <progrper at gmail.com>:

The following code crashes with a segfault on Python 2.7.2:

from operator import add
from itertools import izip, starmap

a = b = [1]
for i in xrange(100000):
    a = starmap(add, izip(a, b))

list(a)


It also crashes with Python 3.2.2:

from operator import add
from itertools import starmap

a = b = [1]
for i in range(100000):
    a = starmap(add, zip(a, b))

list(a)

----------
components: Library (Lib)
messages: 157576
nosy: progrper
priority: normal
severity: normal
status: open
title: Segfault with starmap and izip combo
type: crash
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Apr  5 15:01:08 2012
From: report at bugs.python.org (Popa Claudiu)
Date: Thu, 05 Apr 2012 13:01:08 +0000
Subject: [New-bugs-announce] [issue14508] gprof2html is broken
Message-ID: <1333630868.14.0.473747405241.issue14508@psf.upfronthosting.co.za>


New submission from Popa Claudiu <pcmanticore at gmail.com>:

Tools/gprof2html.py uses "file" to open a file. Also, the opened file passed to add_escapes was never closed. There's a test included in the patch.

----------
components: Demos and Tools
files: gprof.patch
keywords: patch
messages: 157580
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: gprof2html is broken
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25133/gprof.patch

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

From report at bugs.python.org  Thu Apr  5 15:42:51 2012
From: report at bugs.python.org (Thomas Wouters)
Date: Thu, 05 Apr 2012 13:42:51 +0000
Subject: [New-bugs-announce] [issue14509] Build failures in non-pydebug
	builds without NDEBUG.
Message-ID: <1333633371.25.0.0777678806587.issue14509@psf.upfronthosting.co.za>


New submission from Thomas Wouters <thomas at python.org>:

The hash randomization change conflates 'pydebug' builds (which define the 'Py_DEBUG' preprocessor symbol) and asserts (which use 'NDEBUG' instead.) While Py_DEBUG automatically unsets NDEBUG, the inverse is not true (and should not be true.)

In random.c (and Include/object.h), _Py_HashSecret_Initialized is defined as static or global depending on the value of Py_DEBUG. But in (at least) Objects/stringobject.c and Objects/unicodeobject.c, unguarded asserts are used that check the value of _Py_HashSecret_Initialized. This causes builds that define neither NDEBUG nor Py_DEBUG to fail. Either the guard used around the declaration and definition should be '#ifndef NDEBUG' instead of '#ifdef Py_DEBUG', or there should be a Py_DEBUG guard around the two assert statements.

(I would submit a patch but my development environment died during a nasty power outage yesterday.)

----------
components: Interpreter Core
messages: 157586
nosy: benjamin.peterson, twouters
priority: release blocker
severity: normal
status: open
title: Build failures in non-pydebug builds without NDEBUG.
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr  5 15:47:47 2012
From: report at bugs.python.org (YunJian)
Date: Thu, 05 Apr 2012 13:47:47 +0000
Subject: [New-bugs-announce] [issue14510] Regular Expression "+" perform
	wrong repeat
Message-ID: <1333633667.39.0.742877689343.issue14510@psf.upfronthosting.co.za>


New submission from YunJian <tld5yj at yahoo.com.cn>:

Regular expression perform wrong result, I use regular expression r'(\$.)+' try to match "$B$b" or something like that, but the script only give back "$b", r'(\$.){1,}', r'(\$.){2}' performed the same, you can take the file I attached for reference and run it, I try to solve it myself but failed, now I must use other ways to realize my aim, so appreciate for you help, thank you!

----------
components: Regular Expressions
files: CheckInconsistency.py
messages: 157588
nosy: ezio.melotti, mrabarnett, tld5yj
priority: normal
severity: normal
status: open
title: Regular Expression "+" perform wrong repeat
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file25136/CheckInconsistency.py

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

From report at bugs.python.org  Thu Apr  5 17:33:55 2012
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 05 Apr 2012 15:33:55 +0000
Subject: [New-bugs-announce] [issue14511] _static/opensearch.xml for Python
	3.2 docs directs	searches to 3.3 docs
Message-ID: <1333640035.04.0.466278675781.issue14511@psf.upfronthosting.co.za>


New submission from Zachary Ware <zachary.ware at gmail.com>:

Adding the search plugin for the 3.2 docs to Firefox and then searching from it returns results from the 3.3 dev docs, despite everything saying it should be for searching "Python v3.2.2 documentation".

If my understanding of how it all works is correct, the attached patch should fix the issue.  It simply removes 'dev/' from the html_use_opensearch assignment in Doc\conf.py in the 3.2 branch.

Thanks,

Zach

----------
assignee: docs at python
components: Documentation
files: 3.2 conf.py opensearch.diff
keywords: patch
messages: 157599
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, zach.ware
priority: normal
severity: normal
status: open
title: _static/opensearch.xml for Python 3.2 docs directs searches to 3.3 docs
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file25137/3.2 conf.py opensearch.diff

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

From report at bugs.python.org  Thu Apr  5 19:07:05 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 05 Apr 2012 17:07:05 +0000
Subject: [New-bugs-announce] [issue14512] Pydocs module docs server not
	working on Windows.
Message-ID: <1333645625.74.0.578211515784.issue14512@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

3.2.3rc2 and 3.3.0a2, freshly downloaded and installed, Win7, 64 bit
Start Menue/Pythonxx/Module Docs
Brings up tkinter pydoc box.
[open browser] brings up *empty* localhost:7464 window.
Search 'tkinter' and double-click tkinter entry or select and [go to selected] opens empty localhost:7464/tkinter.html window.

This worked sometime last year on earlier 3.2, maybe on xp box.

I thought there might be an issue already, but I searched for 'pydoc' and 'modole docs' and found nothing.

----------
assignee: docs at python
components: Documentation, Installation, Library (Lib)
messages: 157606
nosy: docs at python, georg.brandl, loewis, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Pydocs module docs server not working on Windows.
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Apr  5 21:34:52 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 05 Apr 2012 19:34:52 +0000
Subject: [New-bugs-announce] [issue14513] IDLE icon switched and switches on
	Windows taskbar
Message-ID: <1333654492.57.0.20461784389.issue14513@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

IDLE has an icon that is, appropriately, a white page with text overlaid with the Python logo on lower right. (Module docs uses the same icon.) For a long time, this has been used everywhere for IDLE -- start menu, desktop, taskbar.
 
In the latest 3.2.3rc2 and 3.3.0a2 releases, the Windows 7 taskbar icon for IDLE is the red Tk icon. If IDLE is pinned to the taskbar, the icon changes to the command-prompt + logo python-pythonw icon. This seems to be new in these releases and is confusing and annoying. Otherwise, the IDLE icon is as it was.

----------
components: Installation, Windows
messages: 157611
nosy: georg.brandl, loewis, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE icon switched and switches on Windows taskbar
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Apr  6 04:00:29 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Apr 2012 02:00:29 +0000
Subject: [New-bugs-announce] [issue14514] Equivalent to
	tempfile.NamedTemporaryFile that deletes	file at context exit
Message-ID: <1333677629.14.0.589008132421.issue14514@psf.upfronthosting.co.za>


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

A common pattern (especially in writing tests) is to create a named temporary file, operate on it with tools that take the filename, and then delete the file.  This pattern would be facilitated by a version of NamedTemporaryFile that deleted the named file at the end of the context, but allowed the file to continue to exist when closed.  This latter requirement arises because the file cannot be opened a second time on Windows, and so needs to be closed before other operations that open it can be performed in order for the code to work cross platform.

It's tempting just to change delete=True to mean delete on exit (not close) if and only if NamedTemporaryFile is being used as a context manager, but there might be backward compatibility issues with that.  It might be acceptable as a feature change, though, since the likelyhood of someone closing such a tempfile inside the context and then depending on it *not* existing between then and the end of the context seems low.

If that it deemed unacceptable, this could be implemented as a new flag on NamedTemporaryFile, or by changing the delete flag to take additional values (True/False == current behavior, but add delete='onclose', delete='onexit', delete='no', and document True/False as deprecated.)

----------
components: Library (Lib)
messages: 157634
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: Equivalent to tempfile.NamedTemporaryFile that deletes file at context exit
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr  6 04:07:48 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Apr 2012 02:07:48 +0000
Subject: [New-bugs-announce] [issue14515] tempfile.TemporaryDirectory
	documented as returning	object but returns name
Message-ID: <1333678068.19.0.790451967958.issue14515@psf.upfronthosting.co.za>


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

The title pretty much says it all.  I believe the behavior is correct (more useful than returning an object that is only useful for obtaining the name) even though it is unusual for context managers.  In any case there is plenty of code using the existing behavior, so I think this is a doc bug.

----------
assignee: docs at python
components: Documentation
messages: 157635
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: tempfile.TemporaryDirectory documented as returning object but returns name
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Apr  6 12:22:10 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 Apr 2012 10:22:10 +0000
Subject: [New-bugs-announce] [issue14516] test_tools assumes BUILDDIR=SRCDIR
Message-ID: <1333707730.38.0.628831175594.issue14516@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

When I run "make tests" I get (amongst others) the following test failure:

======================================================================
FAIL: test_noargs (test.test_tools.ReindentTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ronald/Projects/python/rw/default/Lib/test/test_tools.py", line 30, in test_noargs
    assert_python_ok(self.script)
  File "/Users/ronald/Projects/python/rw/default/Lib/test/script_helper.py", line 53, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/Users/ronald/Projects/python/rw/default/Lib/test/script_helper.py", line 45, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 2, stderr follows:
/Users/ronald/Projects/python/rw/default/build/python.exe: can't open file '/Users/ronald/Projects/python/rw/default/build/Tools/scripts/reindent.py': [Errno 2] No such file or directory


This is because the script is actually "/Users/ronald/Projects/python/rw/default/Tools/scripts/reindent.py".

The attached patch fixes the issue.

(assigned to eric because he introduced these tests, unless there are objections I'll commit during the weekend)

----------
assignee: eric.araujo
components: Tests
files: test_tools.patch
keywords: easy, needs review, patch
messages: 157655
nosy: eric.araujo, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: test_tools assumes BUILDDIR=SRCDIR
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25140/test_tools.patch

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

From report at bugs.python.org  Fri Apr  6 13:24:57 2012
From: report at bugs.python.org (Christophe Benoit)
Date: Fri, 06 Apr 2012 11:24:57 +0000
Subject: [New-bugs-announce] [issue14517] Recompilation of sources with
	Distutils
Message-ID: <1333711497.18.0.995661570344.issue14517@psf.upfronthosting.co.za>


New submission from Christophe Benoit <cca.benoit at gmail.com>:

When using distutils to build a C-extension, I have noticed that 
my C-sources were recompiled as soon as one source file has been touched;
from python 2.6. This was not the case with previous python versions.

----------
assignee: eric.araujo
components: Distutils
messages: 157659
nosy: cbenoit, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Recompilation of sources with Distutils
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr  6 21:42:27 2012
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 06 Apr 2012 19:42:27 +0000
Subject: [New-bugs-announce] [issue14518] Add bcrypt $2a$ to crypt.py
Message-ID: <1333741347.69.0.597224923936.issue14518@psf.upfronthosting.co.za>


New submission from Daniel Holth <dholth at fastmail.fm>:

The prefix for bcrypt '$2a$' is supported on many systems and could be added to crypt.py

Could the documentation mention the available rounds parameter for most of these newer hashes? And that Unicode strings are automatically converted to utf-8 before being passed into the OS crypt() function, or is that just assumed to be common knowledge?

----------
messages: 157679
nosy: dholth
priority: normal
severity: normal
status: open
title: Add bcrypt $2a$ to crypt.py

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

From report at bugs.python.org  Sat Apr  7 02:19:56 2012
From: report at bugs.python.org (py.user)
Date: Sat, 07 Apr 2012 00:19:56 +0000
Subject: [New-bugs-announce] [issue14519] In re's examples the example with
	scanf() contains wrong	analog for %x, %X specifiers
Message-ID: <1333757996.58.0.360922081437.issue14519@psf.upfronthosting.co.za>


New submission from py.user <bugzilla-mail-box at yandex.ru>:

http://docs.python.org/py3k/library/re.html#simulating-scanf

0[xX][\dA-Fa-f]+   ->   (0[xX])?[\dA-Fa-f]+

----------
assignee: docs at python
components: Documentation, Regular Expressions
messages: 157711
nosy: docs at python, ezio.melotti, mrabarnett, py.user
priority: normal
severity: normal
status: open
title: In re's examples the example with scanf() contains wrong analog for %x, %X specifiers
versions: Python 3.2

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

From report at bugs.python.org  Sat Apr  7 12:55:39 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Apr 2012 10:55:39 +0000
Subject: [New-bugs-announce] [issue14520] Buggy Decimal.__sizeof__
Message-ID: <1333796139.51.0.465726080972.issue14520@psf.upfronthosting.co.za>


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

I'm not sure __sizeof__ is implemented correctly:

>>> from decimal import Decimal
>>> import sys
>>> d = Decimal(123456789123456798123456789123456798123456789123456798)
>>> d
Decimal('123456789123456798123456789123456798123456789123456798')
>>> sys.getsizeof(d)
24

... looks too small.

----------
assignee: skrah
messages: 157726
nosy: pitrou, skrah
priority: normal
severity: normal
status: open
title: Buggy Decimal.__sizeof__
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr  7 20:43:06 2012
From: report at bugs.python.org (mattip)
Date: Sat, 07 Apr 2012 18:43:06 +0000
Subject: [New-bugs-announce] [issue14521] math.copysign(1.,
	float('nan')) returns -1.
Message-ID: <1333824186.8.0.672108286036.issue14521@psf.upfronthosting.co.za>


New submission from mattip <matti.picus at gmail.com>:

Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.copysign(1., float('inf'))
1.0
>>> math.copysign(1., float('-inf'))
-1.0
>>> math.copysign(1., float('nan'))
-1.0
>>> math.copysign(1., float('-nan'))
1.0
>>>

----------
components: None
messages: 157746
nosy: mattip
priority: normal
severity: normal
status: open
title: math.copysign(1., float('nan')) returns -1.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr  7 21:02:43 2012
From: report at bugs.python.org (sbt)
Date: Sat, 07 Apr 2012 19:02:43 +0000
Subject: [New-bugs-announce] [issue14522] Avoid using DuplicateHandle() on
	sockets in	multiprocessing.connection
Message-ID: <1333825363.09.0.353081584992.issue14522@psf.upfronthosting.co.za>


New submission from sbt <shibturn at gmail.com>:

In multiprocessing.connection on Windows, socket handles are indirectly duplicated using DuplicateHandle() instead the WSADuplicateSocket().  According to Microsoft's documentation this is not supported.

This is easily avoided by using socket.detach() instead of duplicating the handle.

----------
files: mp_socket_dup.patch
keywords: patch
messages: 157747
nosy: sbt
priority: normal
severity: normal
status: open
title: Avoid using DuplicateHandle() on sockets in multiprocessing.connection
Added file: http://bugs.python.org/file25153/mp_socket_dup.patch

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

From report at bugs.python.org  Sun Apr  8 01:15:46 2012
From: report at bugs.python.org (Arcangeltj)
Date: Sat, 07 Apr 2012 23:15:46 +0000
Subject: [New-bugs-announce] [issue14523] IDLE's subprocess startup error
Message-ID: <1333840546.69.0.270630772659.issue14523@psf.upfronthosting.co.za>


New submission from Arcangeltj <arcangeltj at gmail.com>:

"IDLE's subprocess didn't make connection. Either IDLE can't start a subprocess or personal firewall software is blocking the connection." 

What or why is this happening? Is there something that can fix this issue?

----------
components: IDLE
messages: 157764
nosy: arcangeltj
priority: normal
severity: normal
status: open
title: IDLE's subprocess startup error
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Sun Apr  8 03:50:18 2012
From: report at bugs.python.org (Paul A.)
Date: Sun, 08 Apr 2012 01:50:18 +0000
Subject: [New-bugs-announce] [issue14524]
	Python-2.7.3rc2/Modules/_ctypes/libffi/src/dlmalloc.c	won't
	compile on ia64-hp-hpux11.31 without -DHAVE_USR_INCLUDE_MALLOC_H
Message-ID: <1333849818.58.0.912863620165.issue14524@psf.upfronthosting.co.za>


New submission from Paul A. <pda at freeshell.org>:

Shouldn't configure be able to arrive at that without me adding manually?

Anyway, after the build finishes thing soon come crashing down; my stack trace is at the end...

running build_scripts
creating build/scripts-2.7
copying and adjusting /usr/local/src/Python-2.7.3rc2/Tools/scripts/pydoc -> build/scripts-2.7
copying and adjusting /usr/local/src/Python-2.7.3rc2/Tools/scripts/idle -> build/scripts-2.7
copying and adjusting /usr/local/src/Python-2.7.3rc2/Tools/scripts/2to3 -> build/scripts-2.7
copying and adjusting /usr/local/src/Python-2.7.3rc2/Lib/smtpd.py -> build/scripts-2.7
changing mode of build/scripts-2.7/pydoc from 644 to 755
changing mode of build/scripts-2.7/idle from 644 to 755
changing mode of build/scripts-2.7/2to3 from 644 to 755
changing mode of build/scripts-2.7/smtpd.py from 644 to 755
sh[3]: 1340 Abort(coredump)

(gdb) bt
#0  0xc0000000004395d0:0 in kill+0x30 () from /usr/lib/hpux64/libc.so.1
#1  0xc0000000002e8180:0 in raise+0x120 () from /usr/lib/hpux64/libc.so.1
#2  0xc0000000003f8c50:0 in abort+0x170 () from /usr/lib/hpux64/libc.so.1
#3  0xc000000010f0c7f0:0 in free (mem=0x60000000000053d0)
    at /usr/local/src/Python-2.7.3rc2/Modules/_ctypes/libffi/src/dlmalloc.c:4288
#4  0xc000000000bfcde0:0 in _UNW_free_mpool()+0xc0 ()
   from /usr/lib/hpux64/libunwind.so.1
#5  0xc00000000004cb50:0 in EM_mark_BOS+0x50 () from /usr/lib/hpux64/dld.so

----------
components: Build
messages: 157768
nosy: pda
priority: normal
severity: normal
status: open
title: Python-2.7.3rc2/Modules/_ctypes/libffi/src/dlmalloc.c won't compile on ia64-hp-hpux11.31 without -DHAVE_USR_INCLUDE_MALLOC_H
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr  8 03:54:35 2012
From: report at bugs.python.org (Paul A.)
Date: Sun, 08 Apr 2012 01:54:35 +0000
Subject: [New-bugs-announce] [issue14525] ia64-hp-hpux11.31 won't compile
	Python-2.6.8rc2 without	-D_TERMIOS_INCLUDED
Message-ID: <1333850075.77.0.408518012212.issue14525@psf.upfronthosting.co.za>


New submission from Paul A. <pda at freeshell.org>:

I can't help thinking that configure should be able to figure out the need for this -- Modules/termios.c won't compile without adding -D_TERMIOS_INCLUDED by hand. This is far from new, all 2.5+ versions I've tried to compile are like that on this platform.

----------
components: Build
messages: 157769
nosy: pda
priority: normal
severity: normal
status: open
title: ia64-hp-hpux11.31 won't compile Python-2.6.8rc2 without -D_TERMIOS_INCLUDED
type: enhancement
versions: Python 2.6

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

From report at bugs.python.org  Sun Apr  8 04:06:36 2012
From: report at bugs.python.org (Paul A.)
Date: Sun, 08 Apr 2012 02:06:36 +0000
Subject: [New-bugs-announce] [issue14526] Python-2.6.8rc2 test never
	finishes ia64-hp-hpux11.31
Message-ID: <1333850796.49.0.00984513973581.issue14526@psf.upfronthosting.co.za>


New submission from Paul A. <pda at freeshell.org>:

Perhaps I'm not interpreting something happening earlier, but `make test' here  only seems to run a short time but doesn't actually finish.  It appears not to be using any cpu, or waiting for input, so I'm not sure what's happening.
...
test_grammar
test_opcodes
test_dict
test_builtin
test_exceptions
test_types
test_unittest
test_doctest
test_doctest2
test_py3kwarn
test_py3kwarn skipped -- test.test_py3kwarn must be run with the -3 flag
test_MimeWriter
test_SimpleHTTPServer
test_StringIO
test___all__
test test___all__ failed -- Traceback (most recent call last):
  File "/usr/local/src/Python-2.6.8rc2/Lib/test/test___all__.py", line 103, in test_all
    self.check_all(modname)
  File "/usr/local/src/Python-2.6.8rc2/Lib/test/test___all__.py", line 39, in check_all
    modname, e.__class__.__name__, e))

AssertionError: __all__ failure in distutils.command: ImportError: No module named _sha256

test___future__
test__locale
test_abc
test_abstract_numbers
test_aepack
test_aepack skipped -- No module named aepack
test_aifc
test_al
test_al skipped -- No module named al
test_anydbm
test_applesingle
test_applesingle skipped -- No module named macostools
test_array
test_ast
test_asynchat
test test_asynchat failed -- multiple errors occurred; run in verbose mode for details
test_asyncore
test test_asyncore failed -- multiple errors occurred; run in verbose mode for details
test_atexit
test_audioop
test_augassign
test_base64
test_bastion
test_bigaddrspace
test_bigmem
test_binascii
test_binhex
test_binop
test_bisect
test_bool
test_bsddb
test_bsddb skipped -- No module named _bsddb
test_bsddb185
test_bsddb185 skipped -- No module named bsddb185
test_bsddb3
test_bsddb3 skipped -- No module named _bsddb
test_buffer
test_bufio
test_bytes
test_bz2
test_bz2 skipped -- No module named bz2
test_calendar
test_call
test_capi

----------
components: Tests
messages: 157771
nosy: pda
priority: normal
severity: normal
status: open
title: Python-2.6.8rc2 test never finishes ia64-hp-hpux11.31
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Apr  8 04:25:35 2012
From: report at bugs.python.org (Paul A.)
Date: Sun, 08 Apr 2012 02:25:35 +0000
Subject: [New-bugs-announce] [issue14527] How to link with an external
	libffi?
Message-ID: <1333851935.11.0.629390980004.issue14527@psf.upfronthosting.co.za>


New submission from Paul A. <pda at freeshell.org>:

I trying to build python using an external libffi package I have installed -- is there some trick in directing --with-system-ffi to the path where it's located.  I don't see clues in config.log or anywhere to help.

----------
messages: 157776
nosy: pda
priority: normal
severity: normal
status: open
title: How to link with an external libffi?
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr  8 12:05:38 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 08 Apr 2012 10:05:38 +0000
Subject: [New-bugs-announce] [issue14528] Document whether strings implement
	__iter__
Message-ID: <1333879538.06.0.592518387164.issue14528@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

While converting code from Python 2 to Python 3, I came across the "gotcha" that strings implement __iter__ in Python 3 but not in Python 2.

Looking through the documentation, I don't seem to see anything like this mentioned in the library portion of either Python 2 or 3's documentation:

http://docs.python.org/library/stdtypes.html#iterator-types
http://docs.python.org/py3k/library/stdtypes.html#iterator-types

Or in the documentation describing differences between 2 and 3:

http://docs.python.org/release/3.0.1/whatsnew/3.0.html

In fact, the Python 2 and 3 sections on iterator types seem largely the same.  Python 2's documentation even seems a bit misleading in this regard.  At the beginning of this section, it says, "Sequences, described below in more detail, always support the iteration methods [of which __iter__() is the main one]."  And str and unicode are the first two types mentioned in that next section on sequence types.

Here is a blog post I came across about this issue:

http://plope.com/Members/chrism/python_2_vs_python_3_str_iter

I think it would be worth highlighting this issue somewhere in the Python documentation, or at least acknowledging the change (unless I'm simply looking in the wrong place, in which case maybe it should be made more visible).

----------
assignee: docs at python
components: Documentation
messages: 157783
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: Document whether strings implement __iter__
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Apr  8 19:49:19 2012
From: report at bugs.python.org (Mario Vilas)
Date: Sun, 08 Apr 2012 17:49:19 +0000
Subject: [New-bugs-announce] [issue14529] distutils's build_msi command
	ignores the data_files	argument
Message-ID: <1333907359.21.0.0116056941941.issue14529@psf.upfronthosting.co.za>


New submission from Mario Vilas <mvilas at gmail.com>:

When creating an MSI installer on Python 2.7 (Windows, both in 32 and 64 bits) the data_files argument of the setup function is completely ignored. This results in broken installations.

----------
assignee: eric.araujo
components: Distutils
messages: 157799
nosy: Mario.Vilas, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils's build_msi command ignores the data_files argument
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr  8 19:58:20 2012
From: report at bugs.python.org (Mario Vilas)
Date: Sun, 08 Apr 2012 17:58:20 +0000
Subject: [New-bugs-announce] [issue14530] distutils's build_wininst command
	fails to correctly	interpret the data_files argument
Message-ID: <1333907900.33.0.191070589139.issue14530@psf.upfronthosting.co.za>


New submission from Mario Vilas <mvilas at gmail.com>:

I tried the following:

setup(

    data_files = [(sys.prefix_exec, os.path.join('Win32', 'BeaEngine.dll'))]

  # (... rest of the setup call here...)

)

This works perfectly when running the "python setup.py install". But when generating an installer (not MSI but the exe file), the installer places the 'BeaEngine.dll' in a subdirectory called 'python27'. For 64 bit builds, the subdirectory is called 'Python27-x64' instead.

The paths to my python installations are "C:\Python27" and "C:\Python27-x64" respectively. The target folders should have been those, not "C:\Python27-x64\Python27-x64" which is clearly wrong.

So far my workaround was this:

    data_files = [(os.path.join(sys.prefix_exec,'..'), os.path.join('Win32', 'BeaEngine.dll'))]

But of course, now my setup.py script only works for generating the installer, not for installing the module from sources.

----------
assignee: eric.araujo
components: Distutils
messages: 157801
nosy: Mario.Vilas, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils's build_wininst command fails to correctly interpret the data_files argument
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr  8 21:01:23 2012
From: report at bugs.python.org (Edward Yang)
Date: Sun, 08 Apr 2012 19:01:23 +0000
Subject: [New-bugs-announce] [issue14531] Backtrace should not attempt to
	open <stdin> file
Message-ID: <1333911683.02.0.244330903259.issue14531@psf.upfronthosting.co.za>


New submission from Edward Yang <ezyang at mit.edu>:

When generating a backtrace from an interactive Python session (e.g. the input is from <stdin>, Python attempts to actually find a file named <stdin>, to somewhat hilarious consequences.

See the strace'd Python session below:

>>> foo
open("/etc/default/apport", O_RDONLY|O_LARGEFILE) = 3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
open("<stdin>", O_RDONLY|O_LARGEFILE)   = -1 ENOENT (No such file or directory)
open("<stdin>", O_RDONLY|O_LARGEFILE)   = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/pylint-0.24.0-py2.7.egg/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/logilab_astng-0.22.0-py2.7.egg/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/logilab_common-0.56.1-py2.7.egg/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/unittest2-0.5.1-py2.7.egg/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/GitPython-0.3.2.RC1-py2.7.egg/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/gitdb-0.5.4-py2.7-linux-i686.egg/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/smmap-0.8.1-py2.7.egg/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/async-0.6.1-py2.7-linux-i686.egg/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/decorator-3.3.1-py2.7.egg/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.2-py2.7-linux-i686.egg/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/Sphinx-1.0.7-py2.7.egg/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/docutils-0.8.1-py2.7.egg/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/Jinja2-2.6-py2.7.egg/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/Pygments-1.4-py2.7.egg/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/nose-1.1.2-py2.7.egg/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/ezyang/Dev/6.02/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/ezyang/Dev/pyafs/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/ezyang/Dev/wizard/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/ezyang/Dev/twisted/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.6/site-packages/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/ezyang/Work/shared-python/build/lib.linux-i686-2.6/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/ezyang/Work/snarfs/python/coil/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/ezyang/Dev/py-github/src/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/plat-linux2/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/lib-tk/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/lib-old/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/lib-dynload/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.7/dist-packages/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/dist-packages/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/dist-packages/Numeric/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/dist-packages/PIL/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/dist-packages/gst-0.10/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/dist-packages/gtk-2.0/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/pymodules/python2.7/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/pymodules/python2.7/libubuntuone/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/dist-packages/ubuntu-sso-client/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/dist-packages/ubuntuone-client/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/dist-packages/ubuntuone-control-panel/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/dist-packages/ubuntuone-couch/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/dist-packages/ubuntuone-installer/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/<stdin>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
NameError: name 'foo' is not defined
>>>

----------
components: Library (Lib)
messages: 157805
nosy: ezyang
priority: normal
severity: normal
status: open
title: Backtrace should not attempt to open <stdin> file
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Sun Apr  8 22:27:43 2012
From: report at bugs.python.org (Jon Oberheide)
Date: Sun, 08 Apr 2012 20:27:43 +0000
Subject: [New-bugs-announce] [issue14532] multiprocessing module performs a
	time-dependent hmac	comparison
Message-ID: <1333916863.07.0.388274376094.issue14532@psf.upfronthosting.co.za>


New submission from Jon Oberheide <jon at oberheide.org>:

The multiprocessing module performs a time-dependent comparison of the HMAC digest used for authentication:

def deliver_challenge(connection, authkey):
    import hmac
    assert isinstance(authkey, bytes)
    message = os.urandom(MESSAGE_LENGTH)
    connection.send_bytes(CHALLENGE + message)
    digest = hmac.new(authkey, message).digest()
    response = connection.recv_bytes(256)        # reject large message
    if response == digest:
        connection.send_bytes(WELCOME)
    else:
        connection.send_bytes(FAILURE)
        raise AuthenticationError('digest received was wrong')

This comparison should be made time-independent as to not leak information about the expected digest and allow an attacker to derive the full digest.

More info on such timing attacks:

http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/
http://rdist.root.org/2010/07/19/exploiting-remote-timing-attacks/

----------
components: Library (Lib)
messages: 157809
nosy: Jon.Oberheide
priority: normal
severity: normal
status: open
title: multiprocessing module performs a time-dependent hmac comparison

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

From report at bugs.python.org  Mon Apr  9 01:16:47 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 08 Apr 2012 23:16:47 +0000
Subject: [New-bugs-announce] [issue14533] Modify regrtest to make test_main
	optional
Message-ID: <1333927007.96.0.584520357529.issue14533@psf.upfronthosting.co.za>


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

The attached patch makes 'test_main' optional for stdlib tests.  If a test module does not have a 'test_main', regrtest will use the unittest loadTestsFromModule loader to load the tests.

This moves us further in the direction of using normal unittest facilities instead of specialized regrtest ones.  Any test module that can be correctly run currently using python unittest -m test.test_xxx could be converted to use this by simply deleting its test_main, thus no longer requiring manual maintenance of the list of tests to run.  Not all tests can be converted that easily, however, since test_main sometimes does some additional things (such as reap_children or reap_threads).

----------
files: dont_require_test_main.patch
keywords: patch
messages: 157816
nosy: michael.foord, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: Modify regrtest to make test_main optional
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25159/dont_require_test_main.patch

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

From report at bugs.python.org  Mon Apr  9 15:10:53 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Apr 2012 13:10:53 +0000
Subject: [New-bugs-announce] [issue14534] Add method to mark
	unittest.TestCases as "do not run".
Message-ID: <1333977053.0.0.776415854805.issue14534@psf.upfronthosting.co.za>


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

A common pattern in testing is to have a base test class that implements test methods, and subclasses that provide various data that drives the tests to be run in different ways.  It is convenient for the base class to inherit from TestCase, but this causes the normal test loader to load it as a test to be run, when most times it can't run by itself.

My proposed solution is to make test case loading depend on an attribute of the class rather than the fact that it subclasses TestCase.  TestCase would then have the attribute set to True by default.  A decorator would be provided that sets the attribute to False, since that would make it visually obvious which TestCases are base classes and not to be loaded.

(Note: once this is available the 'best practices' description of test file construction in the documentation for the stdlib 'test' module should be updated to use it.)

----------
assignee: michael.foord
components: Library (Lib)
keywords: easy
messages: 157842
nosy: michael.foord, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Add method to mark unittest.TestCases as "do not run".
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr  9 16:27:45 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 09 Apr 2012 14:27:45 +0000
Subject: [New-bugs-announce] [issue14535] three code examples in docs are
	not syntax highlighted
Message-ID: <1333981665.2.0.806826898617.issue14535@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

Three code examples in http://docs.python.org/py3k/library/multiprocessing.html#examples are not syntax highlighted.

----------
assignee: docs at python
components: Documentation
messages: 157845
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: three code examples in docs are not syntax highlighted
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr  9 17:40:53 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Apr 2012 15:40:53 +0000
Subject: [New-bugs-announce] [issue14536] Invalid links in svn.python.org
Message-ID: <1333986053.37.0.658488076066.issue14536@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Links "Subversion instructions" and "Developer FAQ" on http://svn.python.org/ are invalid.

----------
components: Devguide
messages: 157851
nosy: ezio.melotti, storchaka
priority: normal
severity: normal
status: open
title: Invalid links in svn.python.org

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

From report at bugs.python.org  Mon Apr  9 20:48:33 2012
From: report at bugs.python.org (Aaron Meurer)
Date: Mon, 09 Apr 2012 18:48:33 +0000
Subject: [New-bugs-announce] [issue14537] "Fatal Python error: Cannot
	recover from stack	overflow." with SymPy test suite
Message-ID: <1333997313.25.0.0460793555995.issue14537@psf.upfronthosting.co.za>


New submission from Aaron Meurer <asmeurer at gmail.com>:

Recently, after a small seemingly unrelated refactoring, the SymPy test suite in Python 3 started dying with "Fatal Python error: Cannot recover from stack overflow."  

Here's how to reproduce the error

git clone git://github.com/sympy/sympy.git # Clone the development version of SymPy
cd sympy
git checkout 0856119bd7399a416c21e1692855a1077164f21c # This is the first commit to exhibit the problem. Do this in case we make an unrelated change that removes the problem.
./bin/use2to3 # Convert the codebase to Python 3
python3 py3k-sympy/setup.py test # Run the tests

The issue is described in more detail at http://groups.google.com/group/sympy/browse_thread/thread/f664fe88e6b4f29d/3a44691c945695db#3a44691c945695db.  Some key points:

- The test that triggers the error is an XFAIL test (test that is expected to fail) that raises RuntimeError: maximum recursion depth exceeded.

- The change that caused the error, 0856119bd7399a416c21e1692855a1077164f21c (see https://github.com/sympy/sympy/commit/0856119bd7399a416c21e1692855a1077164f21c), is seemingly unrelated.  The only thing that I can think of is that it has added another call to the stack.

- This kills Python with Abort Trap: 6 in Mac OS X, which generates a problem report to be sent to Apple.  I have included a copy of it here: https://gist.github.com/2317869.

- Others have reproduced this error as well, as can be seen by our test reporter tool.  See the mailing list thread for more info.

- I tested this in 3.2.3r2, and the error still occurred.  I tried testing in the 3.3 alpha, but I could not get it to compile.

----------
messages: 157876
nosy: Aaron.Meurer
priority: normal
severity: normal
status: open
title: "Fatal Python error: Cannot recover from stack overflow."  with SymPy test suite
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Mon Apr  9 22:01:56 2012
From: report at bugs.python.org (Michel Leunen)
Date: Mon, 09 Apr 2012 20:01:56 +0000
Subject: [New-bugs-announce] [issue14538] HTMLParser
Message-ID: <1334001716.14.0.206404588397.issue14538@psf.upfronthosting.co.za>


New submission from Michel Leunen <michel.leunen at gmail.com>:

HTMLParser fails to parse this structure of tags: 

'<a></a><script></script><meta><meta / ><body></body>'

Parsing stops after the first meta tag ignoring the remainers

from HTMLParser import HTMLParser
parser = process_html()
parser.feed('<a></a><script></script><meta><meta / ><body></body>')

Python 2.7.2+ Ubuntu 11.10

----------
components: Library (Lib)
messages: 157890
nosy: Michel.Leunen
priority: normal
severity: normal
status: open
title: HTMLParser
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr  9 23:51:15 2012
From: report at bugs.python.org (zodalahtathi)
Date: Mon, 09 Apr 2012 21:51:15 +0000
Subject: [New-bugs-announce] [issue14539] logging module: logger does not
	print log message with	logging.INFO level
Message-ID: <1334008275.31.0.522161663981.issue14539@psf.upfronthosting.co.za>


New submission from zodalahtathi <M8R-a7044e at mailinator.com>:

The logging module does not print logging message when the logging level is set to a level inferior to the default level.
I can reproduce it using the Python3 (3.2.2) package from Ubuntu 12.04 beta2, or using a hand compiled Python 3.2.2. The bug is NOT present in Python 3.2.1.

~ $ python3
Python 3.2.3rc2 (default, Mar 21 2012, 16:59:51) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> logger = logging.getLogger()
>>> logger.getEffectiveLevel() <= logging.WARN
True
>>> logger.warn("warning message")
warning message
>>> logger.setLevel(logging.INFO)
>>> logger.getEffectiveLevel() <= logging.INFO
True
>>> logger.info("info message")
>>>

----------
messages: 157908
nosy: zodalahtathi
priority: normal
severity: normal
status: open
title: logging module: logger does not print log message with logging.INFO level
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Apr 10 04:11:16 2012
From: report at bugs.python.org (Paul A.)
Date: Tue, 10 Apr 2012 02:11:16 +0000
Subject: [New-bugs-announce] [issue14540] Crash in
	Modules/_ctypes/libffi/src/dlmalloc.c on	ia64-hp-hpux11.31
Message-ID: <1334023876.29.0.692126392594.issue14540@psf.upfronthosting.co.za>


New submission from Paul A. <pda at freeshell.org>:

The following stack trace happened towards the end of a Python-2.7.3rc2 build, but I also get much the same results with 2.7.2; one difference I noticed was I didn't think I needed to add -DHAVE_USR_INCLUDE_MALLOC_H there.

running build_scripts
creating build/scripts-2.7
copying and adjusting /usr/local/src/Python-2.7.3rc2/Tools/scripts/pydoc -> build/scripts-2.7
copying and adjusting /usr/local/src/Python-2.7.3rc2/Tools/scripts/idle -> build/scripts-2.7
copying and adjusting /usr/local/src/Python-2.7.3rc2/Tools/scripts/2to3 -> build/scripts-2.7
copying and adjusting /usr/local/src/Python-2.7.3rc2/Lib/smtpd.py -> build/scripts-2.7
changing mode of build/scripts-2.7/pydoc from 644 to 755
changing mode of build/scripts-2.7/idle from 644 to 755
changing mode of build/scripts-2.7/2to3 from 644 to 755
changing mode of build/scripts-2.7/smtpd.py from 644 to 755
sh[3]: 1340 Abort(coredump)

(gdb) bt
#0  0xc0000000004395d0:0 in kill+0x30 () from /usr/lib/hpux64/libc.so.1
#1  0xc0000000002e8180:0 in raise+0x120 () from /usr/lib/hpux64/libc.so.1
#2  0xc0000000003f8c50:0 in abort+0x170 () from /usr/lib/hpux64/libc.so.1
#3  0xc000000010f0c7f0:0 in free (mem=0x60000000000053d0)
    at /usr/local/src/Python-2.7.3rc2/Modules/_ctypes/libffi/src/dlmalloc.c:4288
#4  0xc000000000bfcde0:0 in _UNW_free_mpool()+0xc0 ()
   from /usr/lib/hpux64/libunwind.so.1
#5  0xc00000000004cb50:0 in EM_mark_BOS+0x50 () from /usr/lib/hpux64/dld.so

----------
components: ctypes
messages: 157928
nosy: pda
priority: normal
severity: normal
status: open
title: Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux11.31
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 10 15:55:38 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 10 Apr 2012 13:55:38 +0000
Subject: [New-bugs-announce] [issue14541] test_sndhdr fails when run from an
	installation
Message-ID: <1334066138.27.0.944851053898.issue14541@psf.upfronthosting.co.za>


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

test_sndhdr fails when run from an installed Python, due to a missing directory in the installation.

The attached patch should rectify this.

----------
components: Library (Lib)
files: Makefile.pre.in.diff
keywords: easy, patch
messages: 157953
nosy: georg.brandl, vinay.sajip
priority: normal
severity: normal
status: open
title: test_sndhdr fails when run from an installation
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25168/Makefile.pre.in.diff

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

From report at bugs.python.org  Tue Apr 10 23:22:28 2012
From: report at bugs.python.org (Bill Jefferson)
Date: Tue, 10 Apr 2012 21:22:28 +0000
Subject: [New-bugs-announce] [issue14542] reverse() doesn't reverse sort
	correctly
Message-ID: <1334092948.92.0.355966941096.issue14542@psf.upfronthosting.co.za>


New submission from Bill Jefferson <shaggers3 at yahoo.com>:

reverse() doesn't reverse sort correctly in Python 25 and 27. sort() works correctly, but reverse doesn't. The following uses reverse(). Incorrect. Even though the date comes first, reverse() sorts on the file name, "B57IBMCD_T.....zip"

2012-04-05 B57IBMCD_T7.2.3.1.zip
2012-03-23 B57IBMCD_T7.2.2.3.zip
2012-02-22 B57IBMCD_T7.2.2.2.zip
2012-02-13 B57IBMCD_T7.2.2.1.zip
2012-01-23 B57IBMCD_T7.2.1.1.zip
2012-03-28 B57IBMCD_T7.0.4.6.zip
2012-03-08 B57IBMCD_T7.0.4.5.zip
2012-03-03 B57IBMCD_T7.0.4.4.zip
2012-02-29 B57IBMCD_T7.0.4.3.zip
2012-01-06 B57IBMCD_T7.0.4.2.zip
2011-12-08 B57IBMCD_T7.0.4.1.zip
2012-01-06 B57IBMCD_T7.0.3.1.zip
2012-01-06 B57IBMCD_T7.0.2.2.zip
2012-01-06 B57IBMCD_T7.0.2.1.zip
2012-01-06 B57IBMCD_T6.2.4.9.zip
2011-12-07 B57IBMCD_T6.2.4.9-r1.zip
2011-09-13 B57IBMCD_T6.2.4.8.zip
2012-03-28 B57IBMCD_T6.2.4.12.zip
2012-02-15 B57IBMCD_T6.2.4.11.zip
2011-12-06 B57IBMCD_T6.2.4.10.zip

----------
components: Demos and Tools, IDLE, Windows
files: EX38.PY
messages: 157988
nosy: billje
priority: normal
severity: normal
status: open
title: reverse() doesn't reverse sort correctly
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file25172/EX38.PY

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

From report at bugs.python.org  Wed Apr 11 01:17:49 2012
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 10 Apr 2012 23:17:49 +0000
Subject: [New-bugs-announce] [issue14543] Upgrade OpenSSL on Windows to
	0.9.8u
Message-ID: <1334099869.05.0.692647995835.issue14543@psf.upfronthosting.co.za>


New submission from Dino Viehland <dinov at microsoft.com>:

OpenSSL has had many fixes since the 0.9.8l version, and in particular there is one issue which prevents it from connecting with SSL with a client certificate: the end result is the SSL connection hangs or times out.

Updating the OpenSSL version will fix this and enable better compatibility across platforms.

I've attached my repro but if you want to try it you'll need a different server + private key pair to authenticate with.  I've also confirmed re-building Python with 0.9.8m fixes the problem and Python currently ships with 0.9.8l.

----------
components: Extension Modules
files: repro.py
messages: 157995
nosy: benjamin.peterson, dino.viehland
priority: release blocker
severity: normal
status: open
title: Upgrade OpenSSL on Windows to 0.9.8u
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file25174/repro.py

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

From report at bugs.python.org  Wed Apr 11 06:46:31 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 11 Apr 2012 04:46:31 +0000
Subject: [New-bugs-announce] [issue14544] Limit "global" keyword name
	conflicts in language spec	to those enforced by CPython
Message-ID: <1334119591.44.0.0449104949206.issue14544@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The language spec currently includes the following paragraph [1]:

   Names listed in a global statement must not be defined as
   formal parameters or in a for loop control target, class
   definition, function definition, or import statement.

While the first restriction is real (and enforced by CPython), since formal parameters are explicitly defined as local variables, there's no obvious rationale for the last 4 restrictions (and CPython doesn't enforce any of them).

The proposal is that the paragraph be simplified to:

   Names listed in a global statement must not also be defined as
   formal function parameters. Attempting to do so raises SyntaxError.

The current (incorrect!) CPython implementation detail note will be removed.

A similar clarification will also be made in the "nonlocal" statement documentation.

[1] http://docs.python.org/dev/reference/simple_stmts.html#the-global-statement

----------
messages: 158005
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Limit "global" keyword name conflicts in language spec to those enforced by CPython
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 11 07:26:11 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Apr 2012 05:26:11 +0000
Subject: [New-bugs-announce] [issue14545] html module should not be
	available in Python 3.1
Message-ID: <1334121971.71.0.628267633735.issue14545@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The Python documentation says that the html module (defining html.escape()) is new in Python 3.2:

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

However, it's importable in Python 3.1, but without the escape() function.   See below for evidence.

This prevents the usual EAFP code from not working:

try:
    # Python 3.2 deprecates cgi.escape() and adds the html module as a replacement.
    import html
except ImportError:
    import cgi as html


> python
Python 3.1.4 (default, Apr 10 2012, 21:58:25) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import html
>>> html.escape
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'escape'
>>> dir(html)
['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__path__']
>>> html.__file__
'/opt/local/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/html/__init__.py'

----------
components: None
messages: 158008
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: html module should not be available in Python 3.1
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Wed Apr 11 16:29:36 2012
From: report at bugs.python.org (Carton He)
Date: Wed, 11 Apr 2012 14:29:36 +0000
Subject: [New-bugs-announce] [issue14546] lll.py can't handle multiple
	parameters correctly
Message-ID: <1334154576.79.0.440664410533.issue14546@psf.upfronthosting.co.za>


New submission from Carton He <cartonhe at gmail.com>:

Space errors in calling of lll(arg) of main() cause it only applies to the last parameter instead of all parameters.

Patch attached for Python 3.1

----------
components: Demos and Tools
files: lll.py.patch
keywords: patch
messages: 158036
nosy: carton
priority: normal
severity: normal
status: open
title: lll.py can't handle multiple parameters correctly
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file25178/lll.py.patch

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

From report at bugs.python.org  Wed Apr 11 16:42:49 2012
From: report at bugs.python.org (Johannes Buchner)
Date: Wed, 11 Apr 2012 14:42:49 +0000
Subject: [New-bugs-announce] [issue14547] Python symlink to script behaves
	unexpectedly
Message-ID: <1334155369.29.0.554259242167.issue14547@psf.upfronthosting.co.za>


New submission from Johannes Buchner <buchner.johannes at gmx.at>:

If I have a script 
foo/bar.py
  import baz

and create a symlink to it, called barhere.py
ln -s foo/bar.py barhere.py

when I run it, it behaves unexpectedly, specifically it behaves differently than if I had copied it here. It prefers to import baz from foo/baz, not from the current folder.

Apparently Python (2.7.2-r3) handles symlinks differently than just looking at the content (everything is a file philosophy in UNIX).

----------
messages: 158039
nosy: j13r
priority: normal
severity: normal
status: open
title: Python symlink to script behaves unexpectedly

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

From report at bugs.python.org  Wed Apr 11 18:32:32 2012
From: report at bugs.python.org (sbt)
Date: Wed, 11 Apr 2012 16:32:32 +0000
Subject: [New-bugs-announce] [issue14548] garbage collection just after
	multiprocessing's fork	causes exceptions
Message-ID: <1334161952.16.0.996503370024.issue14548@psf.upfronthosting.co.za>


New submission from sbt <shibturn at gmail.com>:

When running test_multiprocessing on Linux I occasionally see a stream of errors caused by ignored weakref callbacks:

  Exception AssertionError: AssertionError() in <Finalize object, dead> ignored

These do not cause the unittests to fail.

Finalizers from the parent process are supposed to be cleared after the fork.  But if a garbage collection before that then Finalizer callbacks can be run in the "wrong" process.

Disabling gc during fork seems to prevent the errors.  Or maybe the Finalizer should record the pid of the process which created it and only invoke the callback if it matches the current pid.

(Compare Issure 1336 conscerning subprocess.)

----------
messages: 158049
nosy: sbt
priority: normal
severity: normal
status: open
title: garbage collection just after multiprocessing's fork causes exceptions

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

From report at bugs.python.org  Wed Apr 11 18:42:42 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 11 Apr 2012 16:42:42 +0000
Subject: [New-bugs-announce] [issue14549] Recursive inclusion of packages
Message-ID: <1334162562.68.0.805161870888.issue14549@psf.upfronthosting.co.za>


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

For projects with more than a few packages, it is tedious to list all subpackages manually in setup.cfg.  There was once a find_packages in distutils2.util (copied from distribute), but when we moved away from setup.py it was removed (I don?t remember all the details).

A new field would be best if we could find a good name, or we could have special syntax in the existing packages field (like ?packages = distutils2.*?).

----------
assignee: eric.araujo
components: Distutils2
messages: 158053
nosy: alexis, eric.araujo, erik.bray, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Recursive inclusion of packages
type: enhancement
versions: 3rd party, Python 3.3

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

From report at bugs.python.org  Wed Apr 11 19:17:50 2012
From: report at bugs.python.org (Craig Sawyer)
Date: Wed, 11 Apr 2012 17:17:50 +0000
Subject: [New-bugs-announce] [issue14550] os.path.abspath() returns physical
	path, not logical path.
Message-ID: <1334164670.66.0.0156847857752.issue14550@psf.upfronthosting.co.za>


New submission from Craig Sawyer <csawyer at yumaed.org>:

we have os.path.abspath() and os.path.realpath().  the difference according to the documentation is realpath() returns the physical path (i.e. no symlinks in the path).  while abspath() uses getcwd() but because of POSIX.1-2008 (IEEE Std 1003.1-2008) says os.getcwd() returns without symbolic links as well, so os.path.abspath() == os.path.realpath() near as I can tell.

I think os.path.abspath() should return a logical path(i.e. one with symlinks).  The only solution I know of is to getenv('PWD') except that is not guaranteed to be around in POSIX (some BSD's don't offer PWD I understand).  The other option is to ask /bin/pwd which is part of the POSIX standard.

Anyways, I couldn't find a previous bug around this issue, but I think there should be a way in the standard library to get a logical path, as well as a realpath().

----------
components: None
messages: 158056
nosy: csawyer-yumaed
priority: normal
severity: normal
status: open
title: os.path.abspath() returns physical path, not logical path.
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Apr 11 20:28:31 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Apr 2012 18:28:31 +0000
Subject: [New-bugs-announce] [issue14551] imp.load_source docs removed from
	python3 docs...is this	correct?
Message-ID: <1334168911.32.0.490760920072.issue14551@psf.upfronthosting.co.za>


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

This was removed in 2cf7bb2bbfb8 along with a bunch of other functions.  Yet in issue 13959 Brett mentions needing to implement it.  I don't see any replacement for its functionality in importlib, so I would think it would be a function we would want to keep.  It certainly still exists, and I'm sure many people are using it.

----------
messages: 158066
nosy: brett.cannon, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: imp.load_source docs removed from python3 docs...is this correct?
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Apr 11 23:35:55 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 11 Apr 2012 21:35:55 +0000
Subject: [New-bugs-announce] [issue14552] test module: remove repetition
Message-ID: <1334180155.46.0.58029796452.issue14552@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: repetition.diff
keywords: patch
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: test module: remove repetition
Added file: http://bugs.python.org/file25182/repetition.diff

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

From report at bugs.python.org  Wed Apr 11 23:38:40 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 11 Apr 2012 21:38:40 +0000
Subject: [New-bugs-announce] [issue14553] http.server module: grammar fix
Message-ID: <1334180320.01.0.771394900512.issue14553@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: grammar.diff
keywords: patch
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: http.server module: grammar fix
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25183/grammar.diff

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

From report at bugs.python.org  Thu Apr 12 00:02:35 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 11 Apr 2012 22:02:35 +0000
Subject: [New-bugs-announce] [issue14554] test module: correction
Message-ID: <1334181755.32.0.776262768406.issue14554@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

add missing '\n'

----------
assignee: docs at python
components: Documentation
messages: 158082
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: test module: correction
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Apr 12 00:29:18 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Apr 2012 22:29:18 +0000
Subject: [New-bugs-announce] [issue14555] clock_gettime/settime/getres: Add
	more clock identifiers
Message-ID: <1334183358.11.0.0329195703165.issue14555@psf.upfronthosting.co.za>


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

Python 3.3 supports the following clock identifiers:

 * CLOCK_REALTIME
 * CLOCK_MONOTONIC
 * CLOCK_MONOTONIC_RAW
 * CLOCK_HIGHRES
 * CLOCK_PROCESS_CPUTIME_ID
 * CLOCK_THREAD_CPUTIME_ID

Linux has more clocks:

 * CLOCK_BOOTTIME
 * CLOCK_REALTIME_COARSE
 * CLOCK_MONOTONIC_COARSE
 * CLOCK_BOOTTIME_ALARM
 * CLOCK_REALTIME_ALARM

FreeBSD has more clocks:

 * CLOCK_VIRTUAL
 * CLOCK_UPTIME, CLOCK_UPTIME_FAST, CLOCK_UPTIME_PRECISE
 * CLOCK_MONOTONIC_FAST, CLOCK_MONOTONIC_PRECISE
 * CLOCK_REALTIME_FAST, CLOCK_REALTIME_PRECISE
 * CLOCK_SECOND
 * CLOCK_PROF

CLOCK_BOOTTIME is useful is you would like to handle system suspend for example.

----------
components: Library (Lib)
messages: 158084
nosy: haypo
priority: normal
severity: normal
status: open
title: clock_gettime/settime/getres: Add more clock identifiers
versions: Python 3.3

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

From report at bugs.python.org  Thu Apr 12 03:20:17 2012
From: report at bugs.python.org (Joel Lovinger)
Date: Thu, 12 Apr 2012 01:20:17 +0000
Subject: [New-bugs-announce] [issue14556] telnetlib Telnet.expect fails with
	timeout=0
Message-ID: <1334193617.55.0.736160184516.issue14556@psf.upfronthosting.co.za>


New submission from Joel Lovinger <jlovinger at gmail.com>:

In Python 2.4.3 a Telnet.expect with timeout=0 would always make at least one call to Telnet.fill_rawq if a match couldn't be found and the connection was open.

In Python 2.7.1/2.7.3 Telnet.expect with timeout=0 breaks before any call to Telnet.fill_rawq if a match isn't found in already read raw/cooked data. Expected behavior is that on timeout=0 at least one non-blocking attempt should be made to read from the connection when necessary to fulfill a match.

>From code inspection (including Python 2.7.3) timeout behavior was modified to provide an overall elapsed timeout instead of passing unmodified timeout to each select resulting in the failure.


Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from telnetlib import Telnet
>>> import time
>>> tn = Telnet("scn.org", 23)
>>> time.sleep(5) # short wait for data to be available
>>> tn.expect(['.{16}'], 0)
(-1, None, '')
>>>

Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from telnetlib import Telnet
>>> import time
>>> tn = Telnet("scn.org", 23)
>>> time.sleep(5) # short wait for data to be available
>>> tn.expect(['.{16}'], 0)
(0, <_sre.SRE_Match object at 0x01752410>, '\r\nSeattle Communit')
>>>

----------
components: Library (Lib)
messages: 158096
nosy: Joel.Lovinger
priority: normal
severity: normal
status: open
title: telnetlib Telnet.expect fails with timeout=0
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 12 04:07:29 2012
From: report at bugs.python.org (Adi Roiban)
Date: Thu, 12 Apr 2012 02:07:29 +0000
Subject: [New-bugs-announce] [issue14557] HP-UX libraries not included
Message-ID: <1334196449.83.0.830418461799.issue14557@psf.upfronthosting.co.za>


New submission from Adi Roiban <adi at roiban.ro>:

Hi,

I am trying to build Python on HP-UXiv3.

HP-UX also keeps libs in /usr/lib/hpux64 and /usr/lib/hpux32.

I have attached a patch for searching these folders.

----

The patch is against the latest version of cpython.

I have tests the change on Python 2.5.6.

Cheers,
Adi

----------
files: hpux-libs.diff
keywords: patch
messages: 158099
nosy: adiroiban
priority: normal
severity: normal
status: open
title: HP-UX libraries not included
Added file: http://bugs.python.org/file25184/hpux-libs.diff

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

From report at bugs.python.org  Thu Apr 12 07:26:15 2012
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Thu, 12 Apr 2012 05:26:15 +0000
Subject: [New-bugs-announce] [issue14558] Documentation for unittest.main
	does not describe some	keyword arguments.
Message-ID: <1334208375.3.0.0230518732022.issue14558@psf.upfronthosting.co.za>


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

Documentation for unittest.main, at <http://docs.python.org/dev/library/unittest.html#unittest.main>, does not describe the keyword arguments 'module', 'argv', or 'testLoader'.

----------
assignee: docs at python
components: Documentation
messages: 158104
nosy: docs at python, jfinkels
priority: normal
severity: normal
status: open
title: Documentation for unittest.main does not describe some keyword arguments.
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Apr 12 09:24:23 2012
From: report at bugs.python.org (Mitchell Blank Jr)
Date: Thu, 12 Apr 2012 07:24:23 +0000
Subject: [New-bugs-announce] [issue14559] (2.7.3 Regression) PC\8.0
	directory can no longer be	used to build on windows
Message-ID: <1334215463.37.0.843460683269.issue14559@psf.upfronthosting.co.za>


New submission from Mitchell Blank Jr <m-python at bodyfour.com>:

In the diff between 2.7.2 and 2.7.3, we see:

--- Python-2.7.2/PCbuild/pythoncore.vcproj      2011-06-11 08:46:27.000000000 -0700
+++ Python-2.7.3/PCbuild/pythoncore.vcproj      2012-04-09 16:07:35.000000000 -0700
@@ -1835,6 +1835,10 @@
                                >
                        </File>
                        <File
+                               RelativePath="..\Python\random.c"
+                               >
+                       </File>
+                       <File
                                RelativePath="..\Python\structmember.c"
                                >
                        </File>

...however there isn't any similar change to PC\VS8.0\pythoncore.vcproj , PC\VS7.1\pythoncore.vcproj, nor PC\VC6\pythoncore.dsp

I don't know if any of those are deprecated, but the VS8.0 .vcproj's definitely worked in 2.7.2.  In 2.7.3 the missing random.obj file causes python27.dll to fail to link and everything goes downhill from there.

Hand-applying the same change to the PC\VS8.0 directory fixed the problem for me.

----------
components: Build
messages: 158110
nosy: mitchblank
priority: normal
severity: normal
status: open
title: (2.7.3 Regression)  PC\8.0 directory can no longer be used to build on windows
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 12 10:11:59 2012
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCg?=)
Date: Thu, 12 Apr 2012 08:11:59 +0000
Subject: [New-bugs-announce] [issue14560] urllib2 cannot make POST with
	utf-8 content
Message-ID: <1334218319.63.0.453561175662.issue14560@psf.upfronthosting.co.za>


New submission from ?????? ? <lans.rf at gmail.com>:

Issue can be found only in 2.7, in 2.6.6 it works

System:
    Linux strix 3.2.14-1-ARCH x86_64
Python information:
    Python 2.7.2 (default, Jan 31 2012, 13:19:49) [GCC 4.6.2 20120120 (prerelease)] on linux2

Snippet to reproduce error:

# -*- encoding: utf-8 -*-
import urllib2

request = urllib2.Request('http://google.com', u'???????', {'Content-Type': 'text/plain; charset=utf-8'})
urllib2.urlopen(request).read()

Stacktrace:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 394, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 412, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 372, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1199, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1168, in do_open
    h.request(req.get_method(), req.get_selector(), req.data, headers)
  File "/usr/lib/python2.7/httplib.py", line 955, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python2.7/httplib.py", line 989, in _send_request
    self.endheaders(body)
  File "/usr/lib/python2.7/httplib.py", line 951, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python2.7/httplib.py", line 815, in _send_output
    self.send(message_body)
  File "/usr/lib/python2.7/httplib.py", line 787, in send
    self.sock.sendall(data)
  File "/usr/lib/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)

----------
components: Unicode
messages: 158114
nosy: ezio.melotti, ??????.?
priority: normal
severity: normal
status: open
title: urllib2 cannot make POST with utf-8 content
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 12 12:14:41 2012
From: report at bugs.python.org (Ian Delaney)
Date: Thu, 12 Apr 2012 10:14:41 +0000
Subject: [New-bugs-announce] [issue14561] python-2.7.2-r3 suffers test
	failure at test_mhlib
Message-ID: <1334225681.36.0.37712291947.issue14561@psf.upfronthosting.co.za>


New submission from Ian Delaney <della5 at iinet.com.au>:

Testing test suite of pyth-2.7.
Re-running failed tests in verbose mode
Re-running test 'test_mhlib' in verbose mode
test_basic (test.test_mhlib.MhlibTests) ... ok
test_listfolders (test.test_mhlib.MhlibTests) ... FAIL

It seems to be pinned down to this one line in test that failed.

ok, it comes down to this.  From test_mhlib.py

    def test_listfolders(self):
        mh = getMH()
        eq = self.assertEqual

#        tfolders.sort()                    \\ Line 184
#        eq(folders, tfolders)              \\ Line 185

Commenting them out removes the source of error. The lines that trips up include at least 185, 189, 193.  The 'folders' are not equal.

Bug filed in gentoo bugzilla; Bug 387967; 21-10-2011.

The build log from that bug in Comment 2

https://bugs.gentoo.org/attachment.cgi?id=290409

----------
components: Tests
messages: 158119
nosy: idella5
priority: normal
severity: normal
status: open
title: python-2.7.2-r3 suffers test failure at test_mhlib
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 12 14:23:10 2012
From: report at bugs.python.org (Anrs Hu)
Date: Thu, 12 Apr 2012 12:23:10 +0000
Subject: [New-bugs-announce] [issue14562] urllib2 maybe blocks too long
Message-ID: <1334233390.52.0.591380103695.issue14562@psf.upfronthosting.co.za>


New submission from Anrs Hu <anders.x.hu at gmail.com>:

If HTTP URL response's Transfer-Encoding is 'Chunked', then the urllib2.urlopen(URL).readline() will block until there're enough 8192 bytes, even though the first chunk is just a line. 

Every chunks should be processed as soon as posible, so the readline() behavior should read a line and return immediately, rather than read 8K data to buffer and look up a line from the buffer.

----------
components: Library (Lib)
messages: 158124
nosy: Anrs.Hu
priority: normal
severity: normal
status: open
title: urllib2 maybe blocks too long
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 12 15:11:02 2012
From: report at bugs.python.org (aliles)
Date: Thu, 12 Apr 2012 13:11:02 +0000
Subject: [New-bugs-announce] [issue14563] Segmentation fault on
	ctypes.Structure subclass with	byte string field names
Message-ID: <1334236262.62.0.0349212060005.issue14563@psf.upfronthosting.co.za>


New submission from aliles <aaron.iles at gmail.com>:

Python 3.2 will exit with a segmentation fault if a byte string is used as a field name in a subclass of ctypes.Structure.

Python 3.2.2 (default, Dec 18 2011, 18:56:20) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> class Point(ctypes.Structure):
...     _fields_ = ((b'x', ctypes.c_int), (b'y', ctypes.c_int))
... 
Segmentation fault: 11

This also occurs if None or an int is used as the field name.

I would expect that a TypeError exception would be raised if an attempt is made to use an invalid type for the field name.

----------
components: ctypes
files: segfault.py
messages: 158127
nosy: aliles
priority: normal
severity: normal
status: open
title: Segmentation fault on ctypes.Structure subclass with byte string field names
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file25189/segfault.py

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

From report at bugs.python.org  Thu Apr 12 19:27:25 2012
From: report at bugs.python.org (Peng Yu)
Date: Thu, 12 Apr 2012 17:27:25 +0000
Subject: [New-bugs-announce] [issue14564] Error running: ( echo 'import os';
	echo 'help(os)'; )| python |head
Message-ID: <1334251645.47.0.0743579426512.issue14564@psf.upfronthosting.co.za>


New submission from Peng Yu <pengyu.ut at gmail.com>:

I get the following error when I run the following command. I think that help may use something that don't work well with pipe. Could anybody take a look?

~/linux/bin/xplat/src/pymisc/pyhelp/main$ ( echo 'import os'; echo 'help(os)'; )| python |head
Help on module os:

NAME
    os - OS routines for Mac, NT, or Posix depending on what system we're on.

FILE
    /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py

MODULE DOCS
    http://docs.python.org/library/os
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 467, in __call__
    return pydoc.help(*args, **kwds)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1727, in __call__
    self.help(request)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1774, in help
    else: doc(request, 'Help on %s:')
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1511, in doc
    pager(render_doc(thing, title, forceload))
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1318, in pager
    pager(text)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1416, in plainpager
    sys.stdout.write(plain(text))
IOError: [Errno 32] Broken pipe
~/linux/bin/xplat/src/pymisc/pyhelp/main$ ( echo 'import os'; echo 'help(os)'; )| python
Help on module os:

NAME
    os - OS routines for Mac, NT, or Posix depending on what system we're on.

FILE
    /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py

MODULE DOCS
    http://docs.python.org/library/os

DESCRIPTION

----------
messages: 158154
nosy: Peng.Yu
priority: normal
severity: normal
status: open
title: Error running: ( echo 'import os'; echo 'help(os)'; )| python |head
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 12 20:21:06 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 12 Apr 2012 18:21:06 +0000
Subject: [New-bugs-announce] [issue14565] is_cgi doesn't function as
	documented for cgi_directories
Message-ID: <1334254866.64.0.659489278184.issue14565@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

I notice a deficiency in is_cgi: there is no documentation requiring cgi_directories to be a single part, only that the initial value happens to be a list of two directories, each of which have only a single part or level.  The description of is_cgi, however, only requires that the strings in self.cgi_directories be prefixes of self.path, followed by "/" or end of string. While it is not at all clear that being followed by end of string would produce useful results, the description does allow for multiple parts in the directory, but the implementation does not.

Consider a potential value in an overridden or augmented cgi_directories such as '/subdomain/cgi-bin'.  The current is_cgi wouldn't handle that.

Solution: replace the following is_cgi code (from current trunk):

        collapsed_path = _url_collapse_path(self.path)
        dir_sep = collapsed_path.find('/', 1)
        head, tail = collapsed_path[:dir_sep], collapsed_path[dir_sep+1:]
        if head in self.cgi_directories:
            self.cgi_info = head, tail
            return True
        return False

with:

        cln = len( collapsed_path )
        found = False
        for ix in self.cgi_directories:
            ln = len( ix )
            print('is_cgi: %d %d - %s - %s'
                  % ( ln, cln, ix, collapsed_path ))
            if ln == cln  and  ix == collapsed_path:
                self.cgi_info = ( ix, '')
                found = True
                break
            elif ( ln < cln  and  collapsed_path[ ln ] == '/'
                   and  collapsed_path.startswith( ix )):
                self.cgi_info = ( ix, collapsed_path[ ln+1: ])
                found = True
                break
        return found

----------
messages: 158158
nosy: v+python
priority: normal
severity: normal
status: open
title: is_cgi doesn't function as documented for cgi_directories

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

From report at bugs.python.org  Thu Apr 12 21:01:11 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 12 Apr 2012 19:01:11 +0000
Subject: [New-bugs-announce] [issue14566] run_cgi reverts to using
	unnormalized path
Message-ID: <1334257271.24.0.449019497726.issue14566@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

While is_cgi carefully normalizes the path using _url_collapse_path, if it returns True, then run_cgi is called... which sort of starts out using the cgi_info created by is_cgi, but then compares and searches using the original self.path value instead.  This effectively bypasses both the normalization done by _url_collapse_path and the bugs and potential security problems that the normalization was intended to fix!

A simple cure is to replace the first two lines of run_cgi:

        path = self.path
        dir, rest = self.cgi_info

with:

        dir, rest = self.cgi_info
        path = '/'.join([ dir, rest ])

While this works, one might wonder why is_cgi splits the normalized path into two pieces to start with, if it gets recombined, and generally, dir and rest, although initialized from cgi_info, often get recalculated in the loop which immediately follows in run_cgi... more often than you might expect, if an unnormalized path is in the original request, but if the path comes in normalized (or the above fix is applied), and the CGI program actually resides directly in one of the cgi_directories directories (rather than below it), then the dir and rest calculated by is_cgi are actually used, and the loop performs only one half iteration.

----------
components: Library (Lib)
messages: 158162
nosy: orsenthil, v+python
priority: normal
severity: normal
status: open
title: run_cgi reverts to using unnormalized path
type: security
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/issue14566>
_______________________________________

From report at bugs.python.org  Thu Apr 12 21:53:07 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 12 Apr 2012 19:53:07 +0000
Subject: [New-bugs-announce] [issue14567] http/server.py query string
	handling incorrect, inefficient
Message-ID: <1334260387.16.0.632012029633.issue14567@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

A URL potentially consists of four parts: path, PATH_INFO, anchor, QUERY_STRING.  The syntax is roughly:

/path/parts/cgi-script/path/info/parts#anchor?query-string

where # and ? characters play key roles.

is_cgi not-so-cleverly passes the whole request to _url_collapse_path for normalization, resulting in inappropriately normalizing the anchor and query-string as well as appropriately normalizing the path and path info parts.  Consider that there is no syntax restrictions preventing a query string or anchor from containing / and characters. I contrived such strings, and observed that they were passed to _url_collapse_path and were inappropriately "normalized".

Now for non-CGI usage, both the anchor and query-string are ignored by server.py (see translate_path which has code to chop them off). For non-CGI usage, translate_path is called just once, so this isn't particularly inefficient nor is it incorrect. However, for CGI usage it can be both.

It is not clear to me why browsers even send the anchor to the server, but they do. Perhaps there are servers that process it, but this one doesn't, in any case I can find, and I'm unaware of semantics applied by any server.  Therefore, parsing and ignoring it seems appropriate.

Presently, inappropriate normalization of the query-string causes no correctness problem for CGI requests because of issue 14566 which reverts back to the original path.  Should issue 14566 be fixed as recommended, certain query-strings will be mangled by the inappropriate normalization. However, even though there is not presently a correctness problem, there is an efficiency problem for CGI requests: the anchor and query-string are both needlessly processed by _url_collapse_path, and potentially repeatedly processed by translate_path in the loop at the top of run_cgi. In fact, it is not exactly clear whether anchors and query-strings containing cleverly crafted / and . and .. combinations might be able to confuse that loop... because translate_path chops them off, but the loop does not!

It seems to me that the appropriate place to separate the anchor and query string would be in parse_request.  Instead of creating self.command, self.path, self.request_version there, I think it would be better to divide the current content of self.path into three parts: self.path, self.anchor, and self.query_string.

self.path, then, would unambiguously contain only path parts, and would be appropriately passed through _url_collapse_path... perhaps even right there in parse_request ... it seems appropriate to normalize the path for reqular files as well as CGI files for all the same reasons.

Reasons:
1) no ability to access files outside the configured realm due to malicious use of .. as a path component -- although it seems translate_path prevents this anyway, in a complex manner.
2) proper application of unquote, to allow # and ? characters to exist in path parts, and may also legally be applied to other characters by browser code

Neither of these actions are presently performed for regular files, only for CGI files.

If the processing happens in parse_request, then other code would be affected:

is_cgi would no longer need to call _url_collapse_path, as it would already be done

translate_path would no longer need to parse off query strings or anchors, as it would already be done

translate_path would no longer need to call urllib.parse.unquote, as it would already be done.

run_cgi would no longer need to parse anchor or query, but instead could reference query as self.query_string

----------
components: Library (Lib)
messages: 158166
nosy: orsenthil, v+python
priority: normal
severity: normal
status: open
title: http/server.py query string handling incorrect, inefficient
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/issue14567>
_______________________________________

From report at bugs.python.org  Thu Apr 12 23:24:05 2012
From: report at bugs.python.org (Adi Roiban)
Date: Thu, 12 Apr 2012 21:24:05 +0000
Subject: [New-bugs-announce] [issue14568] HP-UX local libraries not included
Message-ID: <1334265845.44.0.154291439069.issue14568@psf.upfronthosting.co.za>


New submission from Adi Roiban <adi at roiban.ro>:

Hi,

Sorry for bothering you.

In my initial report, I did not added /usr/local/lib paths , since I was thinking that Python should only work with the default library location.
Now I see that /usr/local is added just at the beginning of module building.

The default HPUX system comes with openssl, but for example there is no zlib.

Now, on HPUX one can use the Connect archives from  http://hpux.connect.org.uk/

They come with a nice tool for providing similar functionality like apt-get or yum.

zlib is included in HPUX Connect archive.

HPUX Connect packages are installed in /usr/local

With the initial code I was able to build hashlib and other extensions using libraries from /usr/local

To include /usr/local/lib/hpux* in the path, I also had to add them to self.compiler.library_dirs as otherwise they were not added in LD.

I am not sure how it did work in the first place, since on HPUX openssl is in /usr/lib/hpux* and not in /usr/lib/

Here is the code

        # HP-UX keeps files in lib/hpux folders.
        if platform == 'hp-ux11':
            for hpux_path in [
                    '/usr/lib/hpux64', '/usr/lib/hpux32',
                    '/usr/local/lib/hpux64', '/usr/local/lib/hpux32',
                ]:
                lib_dirs += hpux_path
                add_dir_to_list(self.compiler.library_dirs, hpux_path)

With the following code I was able to also build the extensions using libraries from /usr/local on HPUX.

I am new to python build system and I am not sure if this is the right way to do it.

I am also new to 'hg'. I have pulled the latest changed for cpython but I can not see the previous changes in 'default' branch.

I have attached a patch based on 76268:3df2f4a83816

Thanks!
Adi

----------
components: Extension Modules
files: hpux_local_lib.diff
keywords: patch
messages: 158171
nosy: adiroiban
priority: normal
severity: normal
status: open
title: HP-UX local libraries not included
Added file: http://bugs.python.org/file25198/hpux_local_lib.diff

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

From report at bugs.python.org  Thu Apr 12 23:49:07 2012
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 12 Apr 2012 21:49:07 +0000
Subject: [New-bugs-announce] [issue14569] pystate.c #ifdef ordering problem
Message-ID: <1334267347.56.0.554739208984.issue14569@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

The C linkage is guarded by WITH_THREAD.  The 'extern "C" {' and '}' declarations should be in effect regardless of threading.

Note that the bug can only be triggered by compiling without threads, but with a C++ compiler; this is obscure enough that I don't feel strongly about backporting.

----------
components: Interpreter Core
keywords: easy
messages: 158174
nosy: Jim.Jewett
priority: normal
severity: normal
status: open
title: pystate.c #ifdef ordering problem
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Apr 13 04:42:27 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 13 Apr 2012 02:42:27 +0000
Subject: [New-bugs-announce] [issue14570] Document json "sort_keys"
	parameter properly
Message-ID: <1334284947.71.0.88941407788.issue14570@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The json "sort_keys" parameter is actually supported as an argument to dump() and dumps() (and is used that way in the examples), but is only documented as an argument to the JSONEncoder constructor.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 158194
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Document json "sort_keys" parameter properly
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Apr 13 21:49:08 2012
From: report at bugs.python.org (Jonathan Finlay)
Date: Fri, 13 Apr 2012 19:49:08 +0000
Subject: [New-bugs-announce] [issue14571] float argument required,
	not NoneType
Message-ID: <1334346548.9.0.537593280574.issue14571@psf.upfronthosting.co.za>


New submission from Jonathan Finlay <jfinlay at riseup.net>:

File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/main.py", line 1194, in _sig_remove_book
    res = page.sig_close()

  File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/form.py", line 492, in sig_close
    dialog.destroy()

  File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/win_form.py", line 396, in destroy
    self.screen.switch_view(view_type=self.prev_view.view_type)

  File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/screen/screen.py", line 320, in switch_view
    self.display()

  File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/screen/screen.py", line 657, in display
    view.display()

  File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/view/form.py", line 126, in display
    record[field].get(record, check_load=False)

  File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/model/record.py", line 124, in __getitem__
    self.set(value, signal=False)

  File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/model/record.py", line 421, in set
    self.group.fields[fieldname].set(self, value, modified=False)

  File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/model/field.py", line 757, in set
    group.destroy()

  File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/model/group.py", line 390, in destroy
    self.clear()

  File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/model/group.py", line 107, in clear
    self.signal('group-list-changed', ('record-removed', record))

  File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/signal_event.py", line 14, in signal
    fnct(self, signal_data, *data)

  File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/screen/screen.py", line 219, in _group_list_changed
    view.group_list_changed(group, signal)

  File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/view/list.py", line 627, in group_list_changed
    self.display()

  File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/view/list.py", line 747, in display
    self.update_children()

  File "/home/jonathan/Desarrollo/Tryton/2.3/tryton/tryton/gui/window/view_form/view/list.py", line 783, in update_children
    True)

  File "/usr/lib/python2.6/locale.py", line 182, in format
    formatted = percent % value

----------
components: Library (Lib)
files: locale.patch
keywords: patch
messages: 158229
nosy: jonathanf
priority: normal
severity: normal
status: open
title: float argument required, not NoneType
type: compile error
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/file25206/locale.patch

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

From report at bugs.python.org  Sat Apr 14 00:09:12 2012
From: report at bugs.python.org (Joakim Sernbrant)
Date: Fri, 13 Apr 2012 22:09:12 +0000
Subject: [New-bugs-announce] [issue14572] 2.7.3: sqlite module does not
	build on centos 5
Message-ID: <1334354952.88.0.487562486207.issue14572@psf.upfronthosting.co.za>


New submission from Joakim Sernbrant <serbaut at gmail.com>:

Python-2.7.3/Modules/_sqlite/connection.c: In function ?_pysqlite_set_result?:
Python-2.7.3/Modules/_sqlite/connection.c:552: error: ?sqlite3_int64? undeclared (first use in this function)

The centos 5 version of sqlite3 (sqlite-devel-3.3.6-5) does not export the type sqlite3_int64. 2.7.0 did build without problems.

Newer versions declare both sqlite3_int64 and sqlite_int64: http://www.sqlite.org/c3ref/int64.html

Patch:

diff --git a/Modules/_sqlite/connection.c b/Modules/_sqlite/connection.c
index 26678c7..a646513 100644
--- a/Modules/_sqlite/connection.c
+++ b/Modules/_sqlite/connection.c
@@ -549,7 +549,7 @@ void _pysqlite_set_result(sqlite3_context* context, PyObject* py_val)
     } else if (py_val == Py_None) {
         sqlite3_result_null(context);
     } else if (PyInt_Check(py_val)) {
-        sqlite3_result_int64(context, (sqlite3_int64)PyInt_AsLong(py_val));
+        sqlite3_result_int64(context, (sqlite_int64)PyInt_AsLong(py_val));
     } else if (PyLong_Check(py_val)) {
         sqlite3_result_int64(context, PyLong_AsLongLong(py_val));
     } else if (PyFloat_Check(py_val)) {
@@ -580,7 +580,7 @@ PyObject* _pysqlite_build_py_params(sqlite3_context *context, int argc, sqlite3_
     sqlite3_value* cur_value;
     PyObject* cur_py_value;
     const char* val_str;
-    sqlite3_int64 val_int;
+    sqlite_int64 val_int;
     Py_ssize_t buflen;
     void* raw_buffer;

----------
components: Build
messages: 158238
nosy: Joakim.Sernbrant
priority: normal
severity: normal
status: open
title: 2.7.3: sqlite module does not build on centos 5
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 14 00:10:33 2012
From: report at bugs.python.org (Aaron Staley)
Date: Fri, 13 Apr 2012 22:10:33 +0000
Subject: [New-bugs-announce] [issue14573] json iterencode can not handle
	general iterators
Message-ID: <1334355033.57.0.314676653112.issue14573@psf.upfronthosting.co.za>


New submission from Aaron Staley <usaar33 at gmail.com>:

The json library's encoder includes a function called 'iterencode'.  iterencode allows for encoding to be streamed; as tokens are produced they are yielded. This allows for the encoded object to be streamed to a file, over a socket, etc. without being placed all into memory.

Unfortunately, iterencode cannot encode general iterators.  This significantly limits the usefulness of the function.  For my use case I wish to convert a large stream (iterator) of objects into json.  Unfortunately, I currently have to:

A. Bring all the objects into memory by encasing the iterator in a list()
B. Make a hack where I subclass list and making that object's __iter__ function return my desired iterator.

The problem is that the json library explicitly checks for something being a list:

                if isinstance(value, (list, tuple)):
                    chunks = _iterencode_list(value, _current_indent_level)

It would work just as well (and be more pythonic) to see if the value supports the iterator protocol:
                if isinstance(value, collections.Iterable):
                    chunks = _iterencode_list(value, _current_indent_level)


Erroring example:

>>> import json
>>> e = json.JSONEncoder()
>>> r = xrange(20)
>>> gen = e.iterencode(r)
<generator object _iterencode at 0x14a5460>
>>> next(gen)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/json/encoder.py", line 419, in _iterencode
    o = _default(o)
  File "/usr/lib/python3.2/json/encoder.py", line 170, in default
    raise TypeError(repr(o) + " is not JSON serializable")
TypeError: xrange(0, 20) is not JSON serializable

----------
components: Library (Lib)
messages: 158239
nosy: Aaron.Staley
priority: normal
severity: normal
status: open
title: json iterencode can not handle general iterators
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Apr 14 01:07:42 2012
From: report at bugs.python.org (Vlad)
Date: Fri, 13 Apr 2012 23:07:42 +0000
Subject: [New-bugs-announce] [issue14574] SocketServer doesn't handle client
	disconnects properly
Message-ID: <1334358462.67.0.980544384901.issue14574@psf.upfronthosting.co.za>


New submission from Vlad <vladandjeric at gmail.com>:

When dealing with a new connection, SocketServer.BaseRequestHandler.__init__ first calls the request handler (self.handle below) and then calls cleanup code which closes the connection (self.finish below).

class BaseRequestHandler:
    def __init__(self, request, client_address, server):
        < ... snip ... >
        try:
            self.handle()
        finally:
            self.finish()

The issue arises when a client disconnects suddenly during the self.handle() call. The handler may attempt to write data to the disconnected socket.  This will cause an exception (which is correct), but somehow data will still be added to the connection's buffer and self.wfile.closed will be False! As a result, BaseRequestHandler.finish() will attempt to flush the connection's buffer and this will raise another exception which can't be handled without modifying the library code.

----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 62718)
Traceback (most recent call last):
  File "C:\Python27\lib\SocketServer.py", line 284, in _handle_request_noblock
    self.process_request(request, client_address)
  File "C:\Python27\lib\SocketServer.py", line 310, in process_request
    self.finish_request(request, client_address)
  File "C:\Python27\lib\SocketServer.py", line 323, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "C:\Python27\lib\SocketServer.py", line 641, in __init__
    self.finish()
  File "C:\Python27\lib\SocketServer.py", line 694, in finish
    self.wfile.flush()
  File "C:\Python27\lib\socket.py", line 303, in flush
    self._sock.sendall(view[write_offset:write_offset+buffer_size])
error: [Errno 10053] An established connection was aborted by the software in your host machine
----------------------------------------

I've provided a toy server below, you can reproduce the issue by submitting a request to it with curl and then immediately killing curl:

 curl -d "test"  http://127.0.0.1:8000/

Toy server code:
===========================

import BaseHTTPServer
import SocketServer
import time

class ThreadedHTTPServer(BaseHTTPServer.HTTPServer):
  pass

class RequestHandler(BaseHTTPServer.BaseHTTPRequestHandler):
  def do_POST(self):
    try:
      length = int(self.headers["Content-Length"])
      request = self.rfile.read(length)

      print "Sleeping. Kill the 'curl' command now."
      time.sleep(10)
      print "Woke up. You should see a stack trace from the problematic exception below."

      print "Received POST: " + request
      self.send_response(200) # <------- This somehow adds to the connection's buffer!
      self.end_headers()
    except Exception as e:
      print "Exception: " + str(e)  # <----- This exception is expected

httpd = ThreadedHTTPServer(("127.0.0.1", 8000), RequestHandler)
httpd.serve_forever()
httpd.server_close()

----------
components: Library (Lib)
messages: 158240
nosy: vdjeric
priority: normal
severity: normal
status: open
title: SocketServer doesn't handle client disconnects properly
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 14 06:34:52 2012
From: report at bugs.python.org (Hugh Gibbons)
Date: Sat, 14 Apr 2012 04:34:52 +0000
Subject: [New-bugs-announce] [issue14575] IDLE crashes after file open in OS
	X
Message-ID: <1334378092.39.0.081519751274.issue14575@psf.upfronthosting.co.za>


New submission from Hugh Gibbons <hg13004 at gmail.com>:

IDLE crashes shortly after I open a any file with IDLE, using the file browser.  If I open a file from the File->Recent Files list, it does not crash.

OS X version 10.6.8.

----------
components: IDLE
messages: 158249
nosy: hgibbons
priority: normal
severity: normal
status: open
title: IDLE crashes after file open in OS X
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 14 12:41:05 2012
From: report at bugs.python.org (clikkeb)
Date: Sat, 14 Apr 2012 10:41:05 +0000
Subject: [New-bugs-announce] [issue14576] IDLE cannot connect to subprocess
	- New solution
Message-ID: <1334400065.92.0.605072928338.issue14576@psf.upfronthosting.co.za>


New submission from clikkeb <clikkeb at gmail.com>:

It's a common issue that IDLE cannot start on Windows because

"IDLE's subprocess didn't make connection.Either IDLE can't start a subprocess or personal firewall software is blocking the connection."

Everyone claim that the user should set the firewal so that IDLE can connect to subprocess via loopback. I found, instead, that this issue is often caused by an incorrect or missing setting of one the following variables: HOME, USERPROFILE or the combination of HOMEPATH and HOMEDRIVE; if these variables don't represent an existent and writable directory, the error occurs.
Try setting HOMEPATH to an unexistent  or unwritable directory just before launching idle.bat script.
Check IdleConf.GetUserCfgDir() in module configHandler.py, where the function os.path.expanduser is called to get the user home directory. You might also temporarly patch GetUserCfgDir, setting the userDir variable to an unexistent path just after it has been initialized via os.path.expanduser (line 202).
Should be considered a check on expanduser behaviour?

OS: Windows XP
Python version: 3.2.2

clikkeb

----------
components: IDLE
messages: 158253
nosy: clikkeb
priority: normal
severity: normal
status: open
title: IDLE cannot connect to subprocess - New solution
versions: Python 3.2

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

From report at bugs.python.org  Sat Apr 14 13:16:54 2012
From: report at bugs.python.org (Michael Foord)
Date: Sat, 14 Apr 2012 11:16:54 +0000
Subject: [New-bugs-announce] [issue14577] pickling uses __class__ so you
	can't pickle proxy/mock	objects that pretend to be other objects
Message-ID: <1334402214.26.0.28776275463.issue14577@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Pickling uses __class__ instead of type(obj) to determine the type to pickle. This means that objects which pretend to be other objects (like proxy and mock objects) can't be pickled correctly:

>>> class Foo(object):
...  __class__ = property(lambda *a, **k: int)
...  
... 
>>> from pickle import dumps
>>> dumps(Foo())
b'\x80\x03cbuiltins\nint\nq\x00)\x81q\x01}q\x02b.'

Here Foo() is pickled as an int. In Python 2 using type(obj) wouldn't work for old style classes, but I don't see a reason not to use type(obj) in Python 3.

Note that also, the pickle protocol methods like __getstate__ etc are looked up on the object instance (using getattr) rather than on the object type. This means that __getattr__ is invoked to look them up - requiring special casing in objects that provide __getattr__ to avoid them (raise  an AttributeError if they don't provide these methods). This affects three object types in the unittest.mock namespace (_Call, sentinel and the Mock variants).

----------
messages: 158254
nosy: michael.foord
priority: normal
severity: normal
status: open
title: pickling uses __class__ so you can't pickle proxy/mock objects that pretend to be other objects

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

From report at bugs.python.org  Sat Apr 14 19:07:07 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 14 Apr 2012 17:07:07 +0000
Subject: [New-bugs-announce] [issue14578] importlib doesn't check Windows
	registry for paths
Message-ID: <1334423227.55.0.616430347505.issue14578@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Because I don't have access to Windows, importlib doesn't check the Windows registry for paths to search (see the use of _PyWin_FindRegisteredModule() in Python/import.c and its definition in PC/import_nt.c).

I am considering this a release blocker as once importlib is bootstrapped in this will be a regression that Windows users may not be happy with.

----------
components: Windows
messages: 158265
nosy: brett.cannon
priority: release blocker
severity: normal
stage: test needed
status: open
title: importlib doesn't check Windows registry for paths
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 14 20:46:03 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Apr 2012 18:46:03 +0000
Subject: [New-bugs-announce] [issue14579] Possible vulnerability in the
	utf-16 decoder after error	handling
Message-ID: <1334429163.6.0.999765397067.issue14579@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

In the utf-16 decoder after calling unicode_decode_call_errorhandler aligned_end is not updated. This may potentially cause data leaks, memory damage, and crash. The bug introduced by implementation of the issue #4868. In a similar situation in the utf-8 decoder aligned_end is updated.

----------
files: utf16_update_after_error.patch
keywords: patch
messages: 158272
nosy: storchaka
priority: normal
severity: normal
status: open
title: Possible vulnerability in the utf-16 decoder after error handling
type: security
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25213/utf16_update_after_error.patch

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

From report at bugs.python.org  Sat Apr 14 20:55:43 2012
From: report at bugs.python.org (Paul Ollis)
Date: Sat, 14 Apr 2012 18:55:43 +0000
Subject: [New-bugs-announce] [issue14580] imp.reload can fail for sub-modules
Message-ID: <1334429743.69.0.840922249937.issue14580@psf.upfronthosting.co.za>


New submission from Paul Ollis <python at ollis.me.uk>:

Code like this::

    import collections.abc
    imp.reload(collections.abc)

Raises the following exception:

    SystemError: Negative size passed to PyUnicode_New

This occurs on the latest mercurial checkout (76302).

----------
components: Interpreter Core
messages: 158273
nosy: paul_ollis
priority: normal
severity: normal
status: open
title: imp.reload can fail for sub-modules
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 14 22:10:21 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 14 Apr 2012 20:10:21 +0000
Subject: [New-bugs-announce] [issue14581] Support case-insensitive file
	extensions on Windows in	importlib
Message-ID: <1334434221.26.0.706558952592.issue14581@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Importlib doesn't cover case-insensitivity on file extensions under Windows (see test.test_import.test_import: http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/41/steps/test/logs/stdio). Should add a test to test_importlib and then fix (but only for Windows; apparently this isn't honoured under OS X even though it is case-insensitive).

----------
components: Windows
messages: 158279
nosy: brett.cannon
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Support case-insensitive file extensions on Windows in importlib
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 14 22:31:41 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 14 Apr 2012 20:31:41 +0000
Subject: [New-bugs-announce] [issue14582] Have importlib use return value
	from a loader's	load_module()
Message-ID: <1334435501.08.0.930274319662.issue14582@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Right now importlib doesn't use what loader.load_module() returns as that was what import.c did. But PEP 302 explicitly states that load_module() is expected to return the module that was loaded. So to save a dict lookup I want to rely on the return value of load_module().

----------
assignee: brett.cannon
components: Interpreter Core
messages: 158280
nosy: brett.cannon
priority: low
severity: normal
stage: test needed
status: open
title: Have importlib use return value from a loader's load_module()
type: performance
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 14 22:45:31 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 14 Apr 2012 20:45:31 +0000
Subject: [New-bugs-announce] [issue14583] try/except import fails
	--without-threads
Message-ID: <1334436331.01.0.461185960127.issue14583@psf.upfronthosting.co.za>


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

In the build --without-threads, catching an ImportError in support.py
fails. Fedora buildbot:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/1986/steps/test/logs/stdio

./python  ./Tools/scripts/run_tests.py -j 1 -u all -W --timeout=3600 
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/__main__.py", line 1, in <module>
    from test import regrtest, support
  File "<frozen importlib._bootstrap>", line 1038, in _handle_fromlist
  File "<frozen importlib._bootstrap>", line 977, in _find_and_load
  File "<frozen importlib._bootstrap>", line 561, in load_module
  File "<frozen importlib._bootstrap>", line 218, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 446, in _load_module
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/regrtest.py", line 243, in <module>
    from test import support
  File "<frozen importlib._bootstrap>", line 1038, in _handle_fromlist
  File "<frozen importlib._bootstrap>", line 977, in _find_and_load
  File "<frozen importlib._bootstrap>", line 561, in load_module
  File "<frozen importlib._bootstrap>", line 218, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 446, in _load_module
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/support.py", line 34, in <module>
    import multiprocessing.process
SystemError: NULL result without error in PyObject_Call
[110893 refs]
make: *** [buildbottest] Error 255

----------
components: Tests
messages: 158281
nosy: brett.cannon, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: try/except import fails --without-threads
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 14 22:48:16 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Apr 2012 20:48:16 +0000
Subject: [New-bugs-announce] [issue14584] Add gzip support the XMLRPC Server
Message-ID: <1334436496.76.0.995633405639.issue14584@psf.upfronthosting.co.za>


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

The xmlrpclib client already supports gzipped data and say so in the HTTP header: "Accept-Encoding: gzip".

Our XMLRPC Server ignores this header and always sends uncompressed data.

----------
messages: 158282
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add gzip support the XMLRPC Server
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr 15 03:27:25 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 15 Apr 2012 01:27:25 +0000
Subject: [New-bugs-announce] [issue14585] Have test_import run more
	importlib tests
Message-ID: <1334453245.9.0.0799360762368.issue14585@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

As it stands, test_import runs importlib.test.import_.test_relative_imports. It would probably be better to have test_import run all importlib tests using __import__(), especially since it is already coded up in importlib.test.__main__ to do so.

In all honesty I'm willing to bet there is some duplication in test_import that can just go away if someone put the time in to try to prune the file down.

----------
messages: 158306
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Have test_import run more importlib tests

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

From report at bugs.python.org  Sun Apr 15 04:04:33 2012
From: report at bugs.python.org (Guy Taylor)
Date: Sun, 15 Apr 2012 02:04:33 +0000
Subject: [New-bugs-announce] [issue14586] TypeError: truncate() takes no
	keyword arguments
Message-ID: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za>


New submission from Guy Taylor <thebigguy.co.uk at gmail.com>:

The Python docs suggest that io.IOBase.truncate' should take a keyword argument of 'size'.
However this causes a 'TypeError':
  TypeError: truncate() takes no keyword arguments

Suggest that the docs are changed to 'truncate(size)' or CPython is changed to allow the keyword.

http://docs.python.org/py3k/library/io.html?highlight=truncate#io.IOBase.truncate
http://docs.python.org/library/io.html?highlight=truncate#io.IOBase.truncate

----------
assignee: docs at python
components: Documentation, Interpreter Core
files: test.py
messages: 158308
nosy: TheBiggerGuy, docs at python
priority: normal
severity: normal
status: open
title: TypeError: truncate() takes no keyword arguments
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file25219/test.py

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

From report at bugs.python.org  Sun Apr 15 16:17:28 2012
From: report at bugs.python.org (Christian Clauss)
Date: Sun, 15 Apr 2012 14:17:28 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue14587=5D_Certain_diacritica?=
 =?utf-8?q?l_marks_can_and_should_be_capitalized=2E=2E=2E_e=2Eg=2E_=C3=BC_?=
 =?utf-8?b?LS0+IMOc?=
Message-ID: <1334499448.33.0.168656695712.issue14587@psf.upfronthosting.co.za>


New submission from Christian Clauss <cclauss at bluewin.ch>:

BUGS: certain diacritical marks can and should be capitalized...
    str.upper() does not .replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?'), etc.
    str.lower() does not .replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?'), etc.
    str.title() has the same problems plus it capitalizes the letter _after_ a diacritic. e.g. 'l?sai'.title() --> 'L?Sai' with a capitol 'S'
    myUpper(), myLower(), myTitle() exhibit the correct behavior with a handful of diacritic marks.

def myUpper(inString):
    return inString.upper().replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?')

def myLower(inString):
    return inString.lower().replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?').replace('?', '?')

def myTitle(inString): # WARNING: converts all whitespace to a single space
    returnValue = []
    for theWord in inString.split():
        returnValue.append(myUpper(theWord[:1]) + myLower(theWord[1:]))
    return ' '.join(returnValue)

----------
components: Unicode
messages: 158332
nosy: Christian.Clauss, ezio.melotti
priority: normal
severity: normal
status: open
title: Certain diacritical marks can and should be capitalized... e.g. ? --> ?
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr 16 02:23:18 2012
From: report at bugs.python.org (Daniel Urban)
Date: Mon, 16 Apr 2012 00:23:18 +0000
Subject: [New-bugs-announce] [issue14588] PEP 3115 compliant dynamic class
	creation
Message-ID: <1334535798.87.0.826104374353.issue14588@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

As Nick Coghlan proposed [1, 2], there should be a way to dynamically create classes, which handles metaclasses correctly (see also issue1294232).

Here is my first attempt at creating an operator.build_class method. It only includes very simple tests and no documentation, but I will write them if needed.

With this patch there are two functions for creating a class object:
1. __build_class__ (no change)
2. operator.build_class(name, bases=(), kwds=None, eval_body=None): finds the correct metaclass and calls its __prepare__. If eval_body is given, calls it with the namespace returned by __prepare__. Then calls the correct metaclass, and returns the created class object.

Both of these functions (after parsing their arguments) call _PyType_BuildClass, a new C API function. The first argument of this function is a callable, that will be called with the namespace returned by __prepare__ (it also can be NULL, in that case nothing will be called). __build_class__ passes the function that is the body of the class statement. operator.build_class passes the callable given by the user (or NULL, if the user didn't pass the eval_body argument). The implementation of _PyType_BuildClass is approximately the following:

def _PyType_BuildClass(func=None, name, bases, kwds={}):
    meta = kwds.pop('metaclass', None)
    if meta is None:
        if not bases:
            meta = type
        else:
            meta = type(bases[0])
    ns, meta = prepare_namespace(name, meta, bases, kwds)
    if func is not None:
        func(ns)
    return meta(name, bases, ns, kwds)

(Actually the return value of the func is used if it's a cell object. I'm not sure, why and when this is needed, this code comes from __build_class__.)

The changes are in the following files:

1. object.h: the exported function is _PyType_BuildClass instead of _PyType_CalculateMetaclass (that doesn't need to be in the include file anymore).

2. operator.c: the build_class method checks its arguments, then calls _PyType_BuildClass.

3. typeobject.c:

_PyType_CalculateMetaclass is renamed to calculate_metaclass, because now it is only called from this file.

prepare_namespace calls calculate_metaclass to determine the correct metaclass, then calls its __prepare__ method. (This code is moved here mostly from __build_class__). It also passes back the correct metaclass to its caller.

_PyType_BuildClass gets the starting metaclass from its arguments. Then it calls prepare_namespace to get the namespace and the correct metaclass. If it received a non-NULL first argument (the function that is the class body or the eval_body argument of operator.build_class), then calls it, passing the namespace. Then it calls the correct metaclass. (Most of this code is also from __build_class__.)

4. bltinmodule.c: builtin___build_class__ now only parses its arguments, and simply calls _PyType_BuildClass.

5. test_operator.py: a simple test for operator.build_class


[1] http://mail.python.org/pipermail/python-dev/2011-April/110874.html
[2] http://mail.python.org/pipermail/python-dev/2012-April/118732.html

----------
components: Extension Modules, Interpreter Core
files: operator_build_class.patch
keywords: patch
messages: 158382
nosy: durban, ncoghlan
priority: normal
severity: normal
status: open
title: PEP 3115 compliant dynamic class creation
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25231/operator_build_class.patch

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

From report at bugs.python.org  Mon Apr 16 02:49:51 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Apr 2012 00:49:51 +0000
Subject: [New-bugs-announce] [issue14589] test_algorithms() of test_ssl
	fails: certificate of	sha256.tbs-internet.com changed
Message-ID: <1334537391.58.0.830155937634.issue14589@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/3677/steps/test/logs/stdio
======================================================================
ERROR: test_algorithms (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_ssl.py", line 841, in test_algorithms
    s.connect(remote)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/ssl.py", line 543, in connect
    self._real_connect(addr, False)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/ssl.py", line 533, in _real_connect
    self.do_handshake()
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/ssl.py", line 513, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [Errno 1] _ssl.c:435: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

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

It looks like https://sha256.tbs-internet.com/ certificate changed: the serial number of the current certificate is 00:AA:55:98:78:20:F6:77:C2:A1:D0:15:C1:C3:F8:B2:2C.

The serial number of Lib/test/sha256.pem is c9:9a:83:ec:a0:48:07:71:66:c6:f2:cd:88:e1:b9:6d (try "openssl x509 -in Lib/test/sha256.pem  -text -noout" command).

I don't know how to download the new certificate.

----------
messages: 158386
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: test_algorithms() of test_ssl fails: certificate of sha256.tbs-internet.com changed
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr 16 03:57:48 2012
From: report at bugs.python.org (Graham Dumpleton)
Date: Mon, 16 Apr 2012 01:57:48 +0000
Subject: [New-bugs-announce] [issue14590] ConfigParser doesn't strip inline
	comment when delimiter	occurs earlier without preceding space.
Message-ID: <1334541468.07.0.833607995836.issue14590@psf.upfronthosting.co.za>


New submission from Graham Dumpleton <Graham.Dumpleton at gmail.com>:

When parsing for inline comments, ConfigParser will only check the first occurrence of the delimiter in the line. If that instance of the delimiter isn't preceded with a space, it then assumes no comment. This ignores the fact that there could be a second instance of the delimiter which does have a preceding space. The result is that inline comments can be left as part of the value.

So, a config file of:

[section]
value1 = a;b
value2 = a ; comment
value3 = a; b ; comment

after parsing actually results in:

[section]
value1 = a;b
value2 = a
value3 = a; b ; comment

That is, 'value3' is incorrect as still embeds the inline comment.

Test script attached for Python 2.X.

Not tested on Python 3.X but code appears to do the same thing, except that on Python 3.X inline comments are disabled by default.

----------
components: Library (Lib)
files: test_config.py
messages: 158397
nosy: grahamd
priority: normal
severity: normal
status: open
title: ConfigParser doesn't strip inline comment when delimiter occurs earlier without preceding space.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25233/test_config.py

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

From report at bugs.python.org  Mon Apr 16 11:09:52 2012
From: report at bugs.python.org (Dave Reid)
Date: Mon, 16 Apr 2012 09:09:52 +0000
Subject: [New-bugs-announce] [issue14591] Value returned by random.random()
	out of valid range
Message-ID: <1334567392.82.0.521028461876.issue14591@psf.upfronthosting.co.za>


New submission from Dave Reid <seabass666 at gmail.com>:

A particular combination of seed and jumpahead calls seems to force the MT generator into a state where it produces a random variate that is outside the range 0-1. Problem looks like it might be in _randommodule.c:genrand_int32, which produces a value > 0xffffffff for the given state, but I don't understand the generator well enough to debug any further.

The attached test case produces 1.58809998297 as the 2nd variate in Python 2.7 and 1.35540900431 as the 23rd variate in Python 2.7.3. The problem occurs on both Linux (CentOS 6) and Mac OSX (10.6.8), both 64-bit.

----------
components: Interpreter Core
files: badrand.py
messages: 158406
nosy: Dave.Reid
priority: normal
severity: normal
status: open
title: Value returned by random.random() out of valid range
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file25235/badrand.py

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

From report at bugs.python.org  Mon Apr 16 13:33:01 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 16 Apr 2012 11:33:01 +0000
Subject: [New-bugs-announce] [issue14592] old-style (level=-1) importing
	broken after importlib	changes
Message-ID: <1334575981.92.0.820846886591.issue14592@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

Up to the early Py3.3 developer versions, calling __import__() with a level of -1 worked as in Python 2, i.e. it tried a relative import first and then a global import.

This no longer seems to be available after the importlib rewrite (e.g. as of rev f341b99bb370).

----------
components: Interpreter Core
messages: 158409
nosy: scoder
priority: normal
severity: normal
status: open
title: old-style (level=-1) importing broken after importlib changes
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 16 13:38:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Apr 2012 11:38:44 +0000
Subject: [New-bugs-announce] [issue14593]
	PyErr_SetFromImportErrorWithNameAndPath lacks error	checking
Message-ID: <1334576324.57.0.944762137092.issue14593@psf.upfronthosting.co.za>


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

The PyErr_SetFromImportErrorWithNameAndPath implementation never checks for the various results returned by the C API functions it invokes.

(also, it needs documenting, see python-dev)

As for PyErr_SetExcWithArgsKwargs, there's a potential refleak when args is NULL.

----------
components: Interpreter Core
messages: 158411
nosy: brett.cannon, brian.curtin, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: PyErr_SetFromImportErrorWithNameAndPath lacks error checking
type: resource usage
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 16 13:44:44 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 16 Apr 2012 11:44:44 +0000
Subject: [New-bugs-announce] [issue14594] document imp.load_dynamic()
Message-ID: <1334576684.12.0.825511182603.issue14594@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

The imp.load_dynamic() function is used by third party code (e.g. Cython's pyximport) but is not currently documented.

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

The latest changes to the import mechanism suggest that it should better be documented to give a hint that users can rely on it.

----------
assignee: docs at python
components: Documentation
messages: 158412
nosy: docs at python, scoder
priority: normal
severity: normal
status: open
title: document imp.load_dynamic()
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/issue14594>
_______________________________________

From report at bugs.python.org  Mon Apr 16 13:50:58 2012
From: report at bugs.python.org (Robert E.)
Date: Mon, 16 Apr 2012 11:50:58 +0000
Subject: [New-bugs-announce] [issue14595] Complete your registration to
	Python tracker --	key	25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG
In-Reply-To: <20120416114931.F347A1C830@psf.upfronthosting.co.za>
Message-ID: <4F8C07A0.20108@re-factory.de>


New submission from Robert E. <robert at re-factory.de>:

Am 16.04.2012 13:49, schrieb Python tracker:
> To complete your registration of the user "roberte" with
> Python tracker, please do one of the following:
> 
> - send a reply to report at bugs.python.org and maintain the subject line as is (the
> reply's additional "Re:" is ok),
> 
> - or visit the following URL:
> 
> http://bugs.python.org/?@action=confrego&otk=25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG

----------
messages: 158413
nosy: roberte
priority: normal
severity: normal
status: open
title: Complete your registration to Python tracker -- key	25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG

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

From report at bugs.python.org  Mon Apr 16 14:10:12 2012
From: report at bugs.python.org (Robert Elsner)
Date: Mon, 16 Apr 2012 12:10:12 +0000
Subject: [New-bugs-announce] [issue14596] struct.unpack memory leak
Message-ID: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za>


New submission from Robert Elsner <robert.elsner2 at googlemail.com>:

When unpacking multiple files with _variable_ length, struct unpack leaks massive amounts of memory. The corresponding functions from numpy (fromfile) or the array (fromfile) standard lib module behave as expected.

I prepared a minimal testcase illustrating the problem on 

Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) 
[GCC 4.4.5] on linux2

This is a severe limitation when reading big files where performance is critical. The struct.Struct class does not display this behavior. Note that the variable length of the buffer is necessary to reproduce the problem (as is usually the case with real data files).
I suspect this is due to some internal buffer in the struct module not being freed after use.
I did not test on later Python versions, but could not find a related bug in the tracker.

----------
components: Library (Lib)
files: unpack_memory_leak.py
messages: 158418
nosy: Robert.Elsner
priority: normal
severity: normal
status: open
title: struct.unpack memory leak
versions: Python 2.6
Added file: http://bugs.python.org/file25238/unpack_memory_leak.py

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

From report at bugs.python.org  Mon Apr 16 15:09:33 2012
From: report at bugs.python.org (Pat Lynch)
Date: Mon, 16 Apr 2012 13:09:33 +0000
Subject: [New-bugs-announce] [issue14597] Cannot unload dll in ctypes until
	script exits
Message-ID: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za>


New submission from Pat Lynch <plynch76 at gmail.com>:

If I load a dll in ctypes, then delete that loaded DLL instance, the DLL is not unloaded until the script finishes and exits.

I'm trying to write some unit tests in python to exercise that DLL where each test case loads a DLL, does some work, then unloads the DLL.  Unfortunately the DLL only gets unloaded when the unit tests finish.

I've tried forcing the garbage collector to run to get the DLL to unload.  It did nothing...

# load the DLL
parser_dll = CDLL(dllpath)

# do some work here

# 'unload' the dll (or as close as I can get it to it)
if (parser_dll):
    del parser_dll

----------
components: ctypes
messages: 158433
nosy: plynch76
priority: normal
severity: normal
status: open
title: Cannot unload dll in ctypes until script exits
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr 16 18:30:53 2012
From: report at bugs.python.org (=?utf-8?q?Peter_H=C3=A4ring?=)
Date: Mon, 16 Apr 2012 16:30:53 +0000
Subject: [New-bugs-announce] [issue14598] _cursesmodule.c fails with
	ncurses-5.9 on Linux
Message-ID: <1334593853.62.0.710921461264.issue14598@psf.upfronthosting.co.za>


New submission from Peter H?ring <p.haering at gmx.net>:

I need to define NCURSES_INTERNALS in py_curses.h before ncurses.h is included, even on my Linux system with ncurses-5.9.

See the same issue for cygwin: 14438

----------
components: Extension Modules
messages: 158481
nosy: phaering
priority: normal
severity: normal
status: open
title: _cursesmodule.c fails with ncurses-5.9 on Linux
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr 16 19:52:21 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Apr 2012 17:52:21 +0000
Subject: [New-bugs-announce] [issue14599] Windows test_import failure
Message-ID: <1334598741.01.0.455782214389.issue14599@psf.upfronthosting.co.za>


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

Not sure which revision triggered this, so opening a new bug:

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

There's also a test_reprlib failure, no idea if it is related.

----------
keywords: buildbot
messages: 158489
nosy: brett.cannon, pitrou, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Windows test_import failure
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 16 23:14:29 2012
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 16 Apr 2012 21:14:29 +0000
Subject: [New-bugs-announce] [issue14600] Change ImportError reference
	handling, naming
Message-ID: <1334610869.36.0.563738930515.issue14600@psf.upfronthosting.co.za>


New submission from Brian Curtin <brian at python.org>:

Antoine mentioned in email that the reference handling should be changed, so here's a shot at it. I also condensed and renamed the convenience functions - I was paying too much attention to the surrounding conventions and made this harder than it had to be.

----------
assignee: brian.curtin
files: ImportError_changes.diff
keywords: patch
messages: 158499
nosy: brian.curtin, pitrou
priority: high
severity: normal
stage: patch review
status: open
title: Change ImportError reference handling, naming
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25245/ImportError_changes.diff

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

From report at bugs.python.org  Mon Apr 16 23:41:06 2012
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 16 Apr 2012 21:41:06 +0000
Subject: [New-bugs-announce] [issue14601] PEP sources not available as
	documented
Message-ID: <1334612466.63.0.59561167474.issue14601@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

PEP 12 states:

"""
To get the source this (or any) PEP, look at the top of the HTML page and click on the date & time on the "Last-Modified" line. It is a link to the source text in the Python repository.
"""

Unfortunately, the link actually goes to SVN, which only works for (older copies of) older PEPs.

Following that link in a newer PEP returns a 404.

http://www.python.org/dev/peps/pep-0418/  
==>
http://svn.python.org/view/*checkout*/peps/trunk/pep-0418.txt

----------
assignee: docs at python
components: Documentation
messages: 158506
nosy: Jim.Jewett, docs at python
priority: normal
severity: normal
status: open
title: PEP sources not available as documented
type: behavior

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

From report at bugs.python.org  Tue Apr 17 00:36:13 2012
From: report at bugs.python.org (Andrew Thompson)
Date: Mon, 16 Apr 2012 22:36:13 +0000
Subject: [New-bugs-announce] [issue14602] OSX Build Target
Message-ID: <1334615773.44.0.468426555931.issue14602@psf.upfronthosting.co.za>


New submission from Andrew Thompson <draft1967 at gmail.com>:

I could not get Python3 to build on my OSX 10.6.8 box as per the instructions on the website (or those in the README).  It "configures" , but does not "make" :
    
<snip>
IOError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.4" but "10.5" during configure
make: *** [Include/Python-ast.h] Error 1
</snip>

I can fix this by issuing

export MACOSX_DEPLOYMENT_TARGET=10.6

EXTRA WRINKLE:
It then configures and makes. But if I select a new terminal  (i.e. without the exported env variable, and "make clean ; configure ; make" it continues to make perfectly.    Not sure what is going on here.

IMPORTANT:
**** To replicate this bug I had to get a fresh mercurial clone ****


Q: Is this the correct setting for the TARGET ?
Q: Does this happen for other OSX users (specifically !=10.6 users) ?

Q: Should this be documented to save grief for other newbie OSX devs ?



Full Stack Dump of error :

gcc -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -I. -I./Include    -DPy_BUILD_CORE -o Python/_warnings.o Python/_warnings.c
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site.py", line 553, in <module>
    main()
  File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site.py", line 535, in main
    known_paths = addusersitepackages(known_paths)
  File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site.py", line 268, in addusersitepackages
    user_site = getusersitepackages()
  File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site.py", line 243, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site.py", line 233, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/sysconfig.py", line 535, in get_config_var
    return get_config_vars().get(name)
  File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/sysconfig.py", line 434, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/sysconfig.py", line 313, in _init_posix
    raise IOError(msg)
IOError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.4" but "10.5" during configure
make: *** [Include/Python-ast.h] Error 1

----------
components: Build, Devguide
messages: 158511
nosy: aft, ezio.melotti
priority: normal
severity: normal
status: open
title: OSX Build Target

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

From report at bugs.python.org  Tue Apr 17 05:18:02 2012
From: report at bugs.python.org (Dum Dum)
Date: Tue, 17 Apr 2012 03:18:02 +0000
Subject: [New-bugs-announce] [issue14603] List comprehension in
	zipfile.namelist
Message-ID: <1334632682.19.0.839389777617.issue14603@psf.upfronthosting.co.za>


New submission from Dum Dum <xlr3204s.ipod at googlemail.com>:

Use list comprehension in namelist() method of zipfile module.

----------
components: Library (Lib)
files: zipfile.patch
keywords: patch
messages: 158524
nosy: Dum.Dum
priority: normal
severity: normal
status: open
title: List comprehension in zipfile.namelist
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25249/zipfile.patch

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

From report at bugs.python.org  Tue Apr 17 13:58:51 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Apr 2012 11:58:51 +0000
Subject: [New-bugs-announce] [issue14604] spurious stat() calls in importlib
Message-ID: <1334663931.89.0.459058246046.issue14604@psf.upfronthosting.co.za>


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

It seems importlib does multiple stat() calls on py files:

stat("/home/antoine/cpython/opt/Lib", {st_mode=S_IFDIR|0775, st_size=12288, ...}) = 0
stat("/home/antoine/cpython/opt/Lib/_sysconfigdata.py", {st_mode=S_IFREG|0664, st_size=16032, ...}) = 0
stat("/home/antoine/cpython/opt/Lib/_sysconfigdata.py", {st_mode=S_IFREG|0664, st_size=16032, ...}) = 0
open("/home/antoine/cpython/opt/Lib/__pycache__/_sysconfigdata.cpython-33.pyc", O_RDONLY) = 3


It also does multiple stat() calls on some directories:

stat("/home/antoine/cpython/opt/build/lib.linux-x86_64-3.3", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
stat("/home/antoine/.local/lib/python3.3/site-packages", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
stat("/home/antoine/.local/lib/python3.3/site-packages", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
stat("/home/antoine/.local/lib/python3.3/site-packages", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
open("/home/antoine/.local/lib/python3.3/site-packages", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3


That said, the number of system calls issued by 3.3 at startup is now much lower than with 3.2:

$ strace ./python -Sc pass 2>&1 | wc -l
512
$ strace python3.2 -Sc pass 2>&1 | wc -l
1018

----------
components: Library (Lib)
messages: 158546
nosy: brett.cannon, neologix, pitrou
priority: low
severity: normal
status: open
title: spurious stat() calls in importlib
type: performance
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr 17 17:58:05 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 17 Apr 2012 15:58:05 +0000
Subject: [New-bugs-announce] [issue14605] Make import machinery explicit
Message-ID: <1334678285.31.0.589963804213.issue14605@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

There should no longer be any implicit part of import when there doesn't have to be. To make import fully explicit, some things need to happen (in context to importlib):

* Expose FileLoader
* Expose SourceFileLoader
* Expose PathFinder
* Expose the extension loader
* Expose the default path hook
* Explicitly set sys.meta_path with PathFinder
* Explicitly set sys.path_hooks with the default path hook and zipimport
* Make sys.path_importer_cache view None as no finder discovered
* Insert None into sys.path_importer_cache instead of NullImporter

I am not exposing SourcelessFileLoader because importlib publicly tries to discourage the shipping of .pyc files w/o their corresponding source files. Otherwise all objects as used by importlib for performing imports will become public.

----------
assignee: brett.cannon
components: Interpreter Core
messages: 158552
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Make import machinery explicit
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr 17 20:56:02 2012
From: report at bugs.python.org (Roland)
Date: Tue, 17 Apr 2012 18:56:02 +0000
Subject: [New-bugs-announce] [issue14606] Memory leak subprocess
Message-ID: <1334688962.0.0.912468236102.issue14606@psf.upfronthosting.co.za>


Changes by Roland <rfs at ebi.ac.uk>:


----------
nosy: rfs
priority: normal
severity: normal
status: open
title: Memory leak subprocess
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 17 23:28:16 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 17 Apr 2012 21:28:16 +0000
Subject: [New-bugs-announce] [issue14607] method with special keyword-only
	argument gives error
Message-ID: <1334698096.33.0.253940616413.issue14607@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

This is probably a bug.


>>> class A:
...   def f(self, __a=42):
...     pass
... 
>>> A().f()
>>> class A:
...   def f(self, *, __a=42):
...     pass
... 
>>> A().f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() needs keyword-only argument _A__a

----------
components: Interpreter Core
messages: 158568
nosy: flox
priority: normal
severity: normal
status: open
title: method with special keyword-only argument gives error
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Apr 17 23:31:27 2012
From: report at bugs.python.org (Eduard)
Date: Tue, 17 Apr 2012 21:31:27 +0000
Subject: [New-bugs-announce] [issue14608] Python 2.7.3 x86 msi - msvcr90.dll
	version mismatch
Message-ID: <1334698287.56.0.0123105112026.issue14608@psf.upfronthosting.co.za>


New submission from Eduard <alexandrul.ct at gmail.com>:

After installing Python 2.7.3, inside the Python folder I have version 9.0.30729.1 of msvcr90.dll, but it seems that the embeded redistributable package contains the 9.0.21022.8 version of msvcm90.dll, msvcp90.dll, and msvcr90.dll

Is this the intended behavior?

----------
components: Installation
messages: 158569
nosy: alexandrul
priority: normal
severity: normal
status: open
title: Python 2.7.3 x86 msi - msvcr90.dll version mismatch
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr 18 05:58:37 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 18 Apr 2012 03:58:37 +0000
Subject: [New-bugs-announce] [issue14609] can't modify sys.modules during
	import with importlib
Message-ID: <1334721517.01.0.954208594605.issue14609@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

$ cat > x.py
import sys
sys.modules["x"] = 42

benjamin at localhost ~/dev/python/py3k $ python3
Python 3.2.2 (default, Feb 18 2012, 09:16:28) 
[GCC 4.5.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import x
>>> x
42

$ ./python 
Python 3.3.0a2+ (default:6762b943ee59, Apr 17 2012, 23:57:13) 
[GCC 4.5.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import x
>>> x
<module 'x' from './x.py'>

It's not clear to me whether it's the loader's responsibilty to handle this or __import__.

----------
assignee: brett.cannon
components: Interpreter Core
messages: 158587
nosy: benjamin.peterson, brett.cannon
priority: high
severity: normal
status: open
title: can't modify sys.modules during import with importlib
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 18 09:40:10 2012
From: report at bugs.python.org (Raphael Cruzeiro)
Date: Wed, 18 Apr 2012 07:40:10 +0000
Subject: [New-bugs-announce] [issue14610] configure script hangs on pthread
	verification and	PTHREAD_SCOPE_SYSTEM verification on Ubuntu
Message-ID: <1334734810.54.0.87567518387.issue14610@psf.upfronthosting.co.za>


New submission from Raphael Cruzeiro <raphaelcruzeiro at raphaelcruzeiro.com>:

While installing Python 2.7.3 on my Ubuntu server the configure script hanged on the verification for pthread, I then proceded to alter the script to aways return true for pthread and it hanged again checking for PTHREAD_SCOPE_SYSTEM, which I also bypassed by altering the script and only then was I able to successfully install Python 2.7.3

----------
components: Installation
messages: 158597
nosy: Raphael.Cruzeiro
priority: normal
severity: normal
status: open
title: configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr 18 10:35:09 2012
From: report at bugs.python.org (Stefano Taschini)
Date: Wed, 18 Apr 2012 08:35:09 +0000
Subject: [New-bugs-announce] [issue14611] inspect.getargs fails on some
	anonymous tuples
Message-ID: <1334738109.2.0.700206080535.issue14611@psf.upfronthosting.co.za>


New submission from Stefano Taschini <taschini at ieee.org>:

How to reproduce
----------------

Take the following two functions:

    >>> def f(l, (x, y)):
    ...    sup = max(u*x + v*y for u, v in l)
    ...    return ((u, v) for u, v in l if u*x + v*y == sup)

    >>> def g((x, y)):
    ...    def h():
    ...        return x + y
    ...    return h

Inspect.getargs will throw an exception on the former and return a wrong
result on the latter::

    >>> import inspect
    >>> inspect.getargs(f.__code__)
    Traceback (most recent call last):
    ...
    IndexError: list index out of range

    >>> inspect.getargs(g.__code__)
    Arguments(args=['h'], varargs=None, keywords=None)

    # h is most definitely not an argument of g!

Analysis
--------

If you disassemble the two functions, you'll see that in both cases
the anonymous tuples are unpacked using STORE_DEREF::

    >>> import dis
    >>> dis.disassemble(f.__code__)
      1           0 LOAD_FAST                1 (.1)
                  3 UNPACK_SEQUENCE          2
                  6 STORE_DEREF              0 (x)
                  9 STORE_DEREF              2 (y)
    <BLANKLINE>
      2          12 LOAD_GLOBAL              0 (max)
    ...

    >>> dis.disassemble(g.__code__)
      1           0 LOAD_FAST                0 (.0)
                  3 UNPACK_SEQUENCE          2
                  6 STORE_DEREF              0 (x)
                  9 STORE_DEREF              1 (y)
    <BLANKLINE>
      2          12 LOAD_CLOSURE             1 (y)
                 15 LOAD_CLOSURE             0 (x)
                 18 BUILD_TUPLE              2
                 21 LOAD_CONST               1 (<code object h ...>)
                 24 MAKE_CLOSURE             0
                 27 STORE_FAST               3 (h)
    <BLANKLINE>
      4          30 LOAD_FAST                3 (h)
                 33 RETURN_VALUE        \


However, the implementation of inspect.getargs only looks for
UNPACK_TUPLE, UNPACK_SEQUENCE, STORE_FAST.

Notes
-----

The version of Python used is::

    >>> import sys
    >>> sys.version_info[:3]
    (2, 7, 3)

----------
components: Library (Lib)
messages: 158599
nosy: taschini
priority: normal
severity: normal
status: open
title: inspect.getargs fails on some anonymous tuples
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr 18 13:20:32 2012
From: report at bugs.python.org (Massimiliano Tomassoli)
Date: Wed, 18 Apr 2012 11:20:32 +0000
Subject: [New-bugs-announce] [issue14612] Crash after modifying f_lineno
Message-ID: <1334748032.28.0.116760449462.issue14612@psf.upfronthosting.co.za>


New submission from Massimiliano Tomassoli <kiuhnm03 at yahoo.it>:

Debugging script.py and jumping to line 3 makes Python crash.
For instance:

python -m pdb script.py
(Pdb) j 3

----------
components: Interpreter Core
files: script.py
messages: 158603
nosy: mtomassoli
priority: normal
severity: normal
status: open
title: Crash after modifying f_lineno
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file25256/script.py

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

From report at bugs.python.org  Wed Apr 18 14:26:28 2012
From: report at bugs.python.org (Michael Foord)
Date: Wed, 18 Apr 2012 12:26:28 +0000
Subject: [New-bugs-announce] [issue14613] time.time can return None or NaN
Message-ID: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

time.time() can return None, or sometimes NaN. If it can't get a "proper" value from the OS then I would expect it to throw an exception. The docs don't mention anything about error conditions.

This was originally reported to Ubuntu One and there has been discussion / attempts to reproduce (it affects several people and so wasn't an isolated case):

https://bugs.launchpad.net/ubuntu/+source/ubuntuone-control-panel/+bug/844435

The issue is that with the unexpected response from time.time(), a ValueError was caused later when converting the time:

https://launchpadlibrarian.net/79283418/Traceback.txt

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/ubuntuone-control-panel/ubuntuone/controlpanel/web_client/libsoup.py", line 55, in _handler
    msg.status_code, msg.get_uri().to_string(False))
  File "/usr/lib/python2.7/logging/__init__.py", line 1120, in debug
    self._log(DEBUG, msg, args, **kwargs)
  File "/usr/lib/python2.7/logging/__init__.py", line 1249, in _log
    record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info, func, extra)
  File "/usr/lib/python2.7/logging/__init__.py", line 1223, in makeRecord
    rv = LogRecord(name, level, fn, lno, msg, args, exc_info, func)
  File "/usr/lib/python2.7/logging/__init__.py", line 280, in __init__
    self.msecs = (ct - long(ct)) * 1000
ValueError: cannot convert float NaN to integer

----------
assignee: haypo
messages: 158608
nosy: haypo, michael.foord
priority: normal
severity: normal
status: open
title: time.time can return None or NaN

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

From report at bugs.python.org  Wed Apr 18 17:03:34 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Apr 2012 15:03:34 +0000
Subject: [New-bugs-announce] [issue14614] PyTuple_SET_ITEM could check
	bounds in debug mode
Message-ID: <1334761414.21.0.756614621806.issue14614@psf.upfronthosting.co.za>


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

Which it doesn't, as exemplified in e8c87226bcb3 :-)

----------
components: Interpreter Core
messages: 158632
nosy: benjamin.peterson, ncoghlan, pitrou
priority: low
severity: normal
status: open
title: PyTuple_SET_ITEM could check bounds in debug mode
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 18 18:32:42 2012
From: report at bugs.python.org (Eric Snow)
Date: Wed, 18 Apr 2012 16:32:42 +0000
Subject: [New-bugs-announce] [issue14615] pull some import state out of the
	interpreter state
Message-ID: <1334766762.33.0.320325938554.issue14615@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

Once the dust clears from the issue 2377 and issue 13959, we should consider what import-state-related members of PyInterpreterState (Include/pystate.h) can be removed.  This is in the interest of simplifying the interpreter state.

The most straightforward candidate is 'modules_reloading' (since reload() will likely become pure python), but we'll have to make sure we do not introduce any race conditions.

Another candidate that could probably go away, regardless of the import work, is 'modules_by_index'.  As far as I can see, there is only one use of    interp->modules_by_index in the cpython code-base: PyState_FindModule() in Python/pystate.c.  Likewise there is only one use of PyState_FindModule(): atexit_callfuncs() in Modules/atexitmodule.c.

Ultimately I'd love it if modules were also removed from the interpreter state, but doing that is not so cut-and-dry.

----------
components: Interpreter Core
messages: 158638
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
status: open
title: pull some import state out of the interpreter state
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 18 19:12:37 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 18 Apr 2012 17:12:37 +0000
Subject: [New-bugs-announce] [issue14616] subprocess docs should mention
	pipes.quote/shlex.quote
Message-ID: <1334769157.78.0.557014485739.issue14616@psf.upfronthosting.co.za>


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

The warning at http://docs.python.org/library/subprocess#frequently-used-arguments should IMO recommend using shlex.quote.  Even if it strongly advises against using shell=True, there are people who need or want to use it, so let?s give them a pointer to the quote function.

For older versions, I think we should talk about pipes.quote; even if it?s not documented in library/pipes, it is there, it is known and it is used, so I see no harm in mentioning it (with due mention that it?s only semi-official and that it becomes public in 3.3).

----------
assignee: docs at python
components: Documentation
messages: 158641
nosy: docs at python, eric.araujo
priority: normal
severity: normal
status: open
title: subprocess docs should mention pipes.quote/shlex.quote
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Apr 18 19:55:28 2012
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 18 Apr 2012 17:55:28 +0000
Subject: [New-bugs-announce] [issue14617] confusing docs with regard to
	__hash__
Message-ID: <1334771728.14.0.513778784524.issue14617@psf.upfronthosting.co.za>


New submission from Ethan Furman <ethan at stoneleaf.us>:

>From http://docs.python.org/py3k/reference/datamodel.html#object.__hash__
-----------------------------------------------------------------------
Classes which inherit a __hash__() method from a parent class but change the meaning of __eq__() such that the hash value returned is no longer appropriate (e.g. by switching to a value-based concept of equality instead of the default identity based equality) can explicitly flag themselves as being unhashable by setting __hash__ = None in the class definition. Doing so means that not only will instances of the class raise an appropriate TypeError when a program attempts to retrieve their hash value, but they will also be correctly identified as unhashable when checking isinstance(obj, collections.Hashable) (unlike classes which define their own __hash__() to explicitly raise TypeError).

If a class that overrides __eq__() needs to retain the implementation of __hash__() from a parent class, the interpreter must be told this explicitly by setting __hash__ = <ParentClass>.__hash__. Otherwise the inheritance of __hash__() will be blocked, just as if __hash__ had been explicitly set to None.
-----------------------------------------------------------------------

The first paragraph says the user has to change __hash__ if it's different because of changes to __eq__, the second paragraph says __hash__ is automatically removed if __eq__ is changed;  the second paragraph reflects reality.

Proposed change:
-----------------------------------------------------------------------
Classes which change the meaning of __eq__() (thus losing automatic delegation to the parent class' __hash__) can explicitly flag themselves as being unhashable by setting __hash__ = None in the class definition (which is otherwise done implicity). Having __hash__ set to None, either explicitly or implicitly, means that not only will instances of the class raise an appropriate TypeError when a program attempts to retrieve their hash value, but they will also be correctly identified as unhashable when checking isinstance(obj, collections.Hashable) (unlike classes which define their own __hash__() to explicitly raise TypeError).

If a class that overrides __eq__() needs to retain the implementation of __hash__() from a parent class, the interpreter must be told this explicitly by setting __hash__ = <ParentClass>.__hash__.
-----------------------------------------------------------------------

Patch attached.

----------
assignee: docs at python
components: Documentation, Interpreter Core
files: __hash__.diff
keywords: patch
messages: 158644
nosy: docs at python, stoneleaf
priority: normal
severity: normal
status: open
title: confusing docs with regard to __hash__
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25261/__hash__.diff

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

From martin at v.loewis.de  Wed Apr 18 21:32:27 2012
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 18 Apr 2012 21:32:27 +0200
Subject: [New-bugs-announce] [issue14615] pull some import state out of
 the	interpreter state
In-Reply-To: <1334766762.33.0.320325938554.issue14615@psf.upfronthosting.co.za>
References: <1334766762.33.0.320325938554.issue14615@psf.upfronthosting.co.za>
Message-ID: <4F8F16CB.5040204@v.loewis.de>

> Another candidate that could probably go away, regardless of the
> import work, is 'modules_by_index'.  As far as I can see, there is
> only one use of    interp->modules_by_index in the cpython code-base:
> PyState_FindModule() in Python/pystate.c.  Likewise there is only one
> use of PyState_FindModule(): atexit_callfuncs() in
> Modules/atexitmodule.c.

There will be certainly many more uses of PySteate_FindModule in the
future. I fail to see what is gained by this kind of change, and am
firmly -1 on removing variables arbitrarily.

From report at bugs.python.org  Thu Apr 19 03:32:27 2012
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Apr 2012 01:32:27 +0000
Subject: [New-bugs-announce] [issue14618] remove modules_reloading from the
	interpreter state
Message-ID: <1334799147.41.0.250628519615.issue14618@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

Once imp.reload() is moved to imp.py, and the code is stripped from Python/import.c, we can see where modules_reloading stands.  I expect that it will have become entirely superfluous at that point.

----------
components: Interpreter Core
messages: 158691
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
status: open
title: remove modules_reloading from the interpreter state
versions: Python 3.3

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

From report at bugs.python.org  Thu Apr 19 07:14:55 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Apr 2012 05:14:55 +0000
Subject: [New-bugs-announce] [issue14619] Enhanced variable substitution for
	databases
Message-ID: <1334812495.3.0.737876206598.issue14619@psf.upfronthosting.co.za>


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

I suggest adding a ?? placeholder for variable length substitutions in SQL statements:

vars = 'Knight', ('Gwain', 'Gallahad', 'Lancelot'), 30
c.execute('''SELECT * FROM loyalsubjects
             WHERE rank = ? 
             AND name IN (??)
             AND age >= ?
          ''', vars)

----------
components: Extension Modules
messages: 158698
nosy: rhettinger
priority: low
severity: normal
status: open
title: Enhanced variable substitution for databases
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr 19 10:51:39 2012
From: report at bugs.python.org (Florian Bruhin)
Date: Thu, 19 Apr 2012 08:51:39 +0000
Subject: [New-bugs-announce] [issue14620] Fatal Python error: Cannot recover
	from stack overflow.
Message-ID: <1334825499.76.0.44489005416.issue14620@psf.upfronthosting.co.za>


New submission from Florian Bruhin <python.org at the-compiler.org>:

Hey,

I just got the error message in the title when trying to run a script with python.

You can find the coredump, stacktrace, and the scripts I ran at http://the-compiler.org/tmp/pythoncrash/

The command line I ran:
python -u pythonomegle.py

Running Python 3.2.2 on Archlinux.

----------
components: None
messages: 158706
nosy: The-Compiler
priority: normal
severity: normal
status: open
title: Fatal Python error: Cannot recover from stack overflow.
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Thu Apr 19 19:58:09 2012
From: report at bugs.python.org (Vlado Boza)
Date: Thu, 19 Apr 2012 17:58:09 +0000
Subject: [New-bugs-announce] [issue14621] Hash function is not randomized
	properly
Message-ID: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za>


New submission from Vlado Boza <usama at ksp.sk>:

Fix of this http://bugs.python.org/issue13703 is broken.

tl;dr: There only 256 different hash functions (compare it to size of _Py_HashSecret prefix and suffix). And whether keys collide or not depends only on the last 8 bits of prefix. 

Problem with current randomization of hash function is following:
Suffix does not influence whether two keys have some hash or not (it is xor-ed after everything). 
Everything except last 8 bits in prefix does not influence it also. Try adding 0x474200 to prefix and see what happens (it will add 0x474200 to resulting hash). 

To make a DoS attack, attacker must do the following:
Generate sets of colliding keys for every 256 possible combinations of last 8 bits. Try each one of these sets - one will have significantly bigger response time, and then repeat this one.

----------
messages: 158736
nosy: Vlado.Boza
priority: normal
severity: normal
status: open
title: Hash function is not randomized properly
type: security

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

From report at bugs.python.org  Thu Apr 19 19:59:09 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Thu, 19 Apr 2012 17:59:09 +0000
Subject: [New-bugs-announce] [issue14622] Python http.server is dead slow
	using	gethostbyaddr/getfqdn for each request
Message-ID: <1334858349.45.0.662214350668.issue14622@psf.upfronthosting.co.za>


New submission from Yuval Greenfield <ubershmekel at gmail.com>:

This is the line in question: http://hg.python.org/cpython/file/293180d199f2/Lib/http/server.py#l527

I was trying to test out a few html files using "python -m http.server" and it took 4 seconds for each request, it was completely unusable. I had to do hula hoops to find out that it was Python's fault. The function self.address_string is used in every log, meaning every request makes a reverse DNS query before responding. This function failed for every request. Now I know this may be my network's fault but that doesn't mean the server has to die with it. I think the better solution would be to just print out the ip address like other popular servers do. There's no need to be fancy with server names in the log of our toy server, especially when it may come at such a high price.

----------
components: Library (Lib)
messages: 158737
nosy: ubershmekel
priority: normal
severity: normal
status: open
title: Python http.server is dead slow using gethostbyaddr/getfqdn for each request
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr 19 22:49:29 2012
From: report at bugs.python.org (Mike Hobbs)
Date: Thu, 19 Apr 2012 20:49:29 +0000
Subject: [New-bugs-announce] [issue14623] Shutdown exception in daemon thread
Message-ID: <1334868569.61.0.545748058978.issue14623@psf.upfronthosting.co.za>


New submission from Mike Hobbs <mhobbs at 8thbridge.com>:

This issue is very similar to the issue original reported in issue1722344, except that it occurs in daemon threads. Here's a sample exception:

Exception in thread Thread-1 (most likely raised during interpreter shutdown):
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/threading.py", line 552, in __bootstrap_inner
  File "/usr/local/lib/python2.7/threading.py", line 505, in run
  File "/opt/8b/libr8/eb/util/graphite.py", line 86, in run
  File "/usr/local/lib/python2.7/Queue.py", line 168, in get
  File "/usr/local/lib/python2.7/threading.py", line 237, in wait
<type 'exceptions.TypeError'>: 'NoneType' object is not callable

Investigating line 237 in threading.py shows that RuntimeError must have been set to None. The issue appears to be that Py_Finalize wipes all globals while there are still daemon threads running. Would it be correct to terminate daemon threads prior to wiping the globals, since the threads won't be able to accomplish much anyway?

----------
components: Interpreter Core
messages: 158746
nosy: mhobbs
priority: normal
severity: normal
status: open
title: Shutdown exception in daemon thread
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 19 22:59:01 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Apr 2012 20:59:01 +0000
Subject: [New-bugs-announce] [issue14624] Faster utf-16 decoder
Message-ID: <1334869141.17.0.802149162715.issue14624@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

I propose a patch, which accelerates the utf-16 decoder. With PEP 393 utf-16 decoder slowed down a few times (3-4x), this patch returns the performance at the level of Python 3.2 and even higher (+10-30% over 3.2).

In addition, it fixes a few bugs in the utf-16 decoder. Also as a side effect is possible acceleration of other decoders.

----------
components: Interpreter Core
files: decode_utf16.patch
keywords: patch
messages: 158748
nosy: storchaka
priority: normal
severity: normal
status: open
title: Faster utf-16 decoder
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file25277/decode_utf16.patch

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

From report at bugs.python.org  Thu Apr 19 22:59:57 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Apr 2012 20:59:57 +0000
Subject: [New-bugs-announce] [issue14625] Faster utf-32 decoder
Message-ID: <1334869197.32.0.159275934867.issue14625@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

I suggest two variants of patch, accelerating the utf-32 decoder. With PEP 393 utf-32 decoder slowed down up to 2x, these patches returns a performance at the level of Python 3.2 and even much higher (2-3x over 3.2). The variant A is simpler, but the variant B is a little faster (+8-15%).

----------
components: Interpreter Core
files: decode_utf32_a.patch
keywords: patch
messages: 158749
nosy: storchaka
priority: normal
severity: normal
status: open
title: Faster utf-32 decoder
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file25278/decode_utf32_a.patch

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

From report at bugs.python.org  Fri Apr 20 01:52:39 2012
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 19 Apr 2012 23:52:39 +0000
Subject: [New-bugs-announce] [issue14626] os module: use keyword-only
	arguments for dir_fd and	nofollow to reduce function count
Message-ID: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

There are some functions in the os module that do much the same thing but differ only in minor ways, like

* whether or not they follow symbolic links (stat vs lstat)
* taking an extra "dir_fd" parameter (chmod vs fchmodat(3.3))

It would be better if we consolidated these variations into one function which took keyword-only parameters that allow access to the alternate functionality.

Here is a sample of the new possible function signatures, as originally proposed by Serhiy Storchaka:

access(path, mode, *, followlinks=True, dirfd=None, eaccess=False)
chmod(path, mode, *, followlinks=True, dirfd=None)
chown(path, uid, gid, *, followlinks=True, dirfd=None)
link(srcpath, dstpath, *, followlinks=True, srcdirfd=None, dstdirfd=None)
mkdir(path, mode=0o777, *, dirfd=None)
mknod(path, mode=0o600, device=0, *, dirfd=None)
open(path, flag, mode=0o777, *, dirfd=None)
readlink(path, *, dirfd=None)
rename(oldpath, newpath, *, olddirfd=None, newdirfd=None)
stat(path, *, followlinks=True, dirfd=None)
symlink(src, dst, *, dirfd=None)
unlink(path, *, removedir=False, dirfd=None)
utimes(path[, (atime, mtime)], *, ns=False, dirfd=None)
mkfifoat(path, mode=0o666, *, followlinks=True, dirfd=None)

My opinion about naming: PEP 8 suggests underscores to separate words in non-class identifiers.  So I'd spell those "dir_fd", "src_dir_fd" (etc), "remove_dir", and "follow_symlinks".

(While thinking about this, I remembered the infrequently-cited maxim "no boolean parameters".  But that's more a guideline than a rule, and it tends to be a complaint about how the meaning of the parameter is unclear at a call site.  As these will be keyword-only parameters I think their meanings will be perfectly clear, so I shan't worry about it.)

----------
messages: 158777
nosy: larry
priority: normal
severity: normal
status: open
title: os module: use keyword-only arguments for dir_fd and nofollow to reduce function count

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

From report at bugs.python.org  Fri Apr 20 02:01:22 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Apr 2012 00:01:22 +0000
Subject: [New-bugs-announce] [issue14627] Fatal Python Error when Python
	startup is interrupted by	CTRL+c
Message-ID: <1334880082.24.0.373368528623.issue14627@psf.upfronthosting.co.za>


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

If you press CTRL+c while Python is starting, you may get such error:

^CFatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 990, in _find_and_load
  File "<frozen importlib._bootstrap>", line 571, in load_module
  File "<frozen importlib._bootstrap>", line 228, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 456, in _load_module
  File "/home/haypo/prog/python/default/Lib/io.py", line 90, in <module>
    RawIOBase.register(FileIO)
  File "/home/haypo/prog/python/default/Lib/abc.py", line 155, in register
    if issubclass(subclass, cls):
  File "/home/haypo/prog/python/default/Lib/abc.py", line 201, in __subclasscheck__
    elif subclass in cls._abc_negative_cache:
KeyboardInterrupt
Abandon

----------
messages: 158782
nosy: brett.cannon, haypo
priority: normal
severity: normal
status: open
title: Fatal Python Error when Python startup is interrupted by CTRL+c
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr 20 06:31:07 2012
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Apr 2012 04:31:07 +0000
Subject: [New-bugs-announce] [issue14628] Clarify import statement
	documentation regarding what	gets bound
Message-ID: <1334896267.8.0.0783452284973.issue14628@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

(see #14609 and #14582)

http://docs.python.org/dev/reference/simple_stmts.html#the-import-statement

The specification for the import statement says the following:

"The first form of import statement binds the module name in the local namespace to the module object".

This is not the case and has not been the case perhaps ever.  Instead of getting bound to the module (returned by loader.load_module() during import), the name is bound to the value at sys.modules[module_name].

Normally two approaches yield the same result.  However, if during import the sys.modules value for the module is assigned to something else, the behavior deviates from the specfication.  See #14609 for an example.

Considering the backwards-compatibility issues, the language reference should be updated to reflect the actual behavior.

----------
assignee: docs at python
components: Documentation
messages: 158793
nosy: benjamin.peterson, brett.cannon, docs at python, eric.snow
priority: normal
severity: normal
status: open
title: Clarify import statement documentation regarding what gets bound
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Apr 20 07:17:18 2012
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Apr 2012 05:17:18 +0000
Subject: [New-bugs-announce] [issue14629] discrepency between
	tokenize.detect_encoding() and	PyTokenizer_FindEncodingFilename()
Message-ID: <1334899038.03.0.61083358932.issue14629@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

(see http://mail.python.org/pipermail/python-dev/2012-April/118889.html)

The behavior of tokenize.detect_encoding() and PyTokenizer_FindEncodingFilename() is unexpectedly different and this has bearing on the current work on imports.

When a file has no encoding indicator (see PEP 263) it falls back to UTF8 (see PEP 3120).  The tokenize module (Lib/tokenize.py) facilitates this through "detect_encoding()".  The CPython internal tokenizer (Python/tokenizer.c) does so through "PyTokenizer_FindEncodingFilename()".  Both check the first two lines of the file, per PEP 263.

When faced with an unparsable file (per the encoding), tokenize.detect_encoding() will gladly give you the encoding without any fuss.  However, PyTokenizer_FindEncodingFilename() will raise a SyntaxError in that situation.

The 'badsyntax_pep3120' test (Lib/test/badsyntax_pep3120.py) is one module that demonstrates this discrepency.  I'll use it in the following example.

 ---

For tokenize.detect_encoding():

  import tokenize
  enc = tokenize.detect_encoding(open("cpython/Lib/test/badsyntax_pep3120.py").readline)
  print(enc)  # "utf-8" (no SyntaxError)

For PyTokenizer_FindEncodingFilename():

I've attached the source for a C extension module ('_tokenizer') that wraps PyTokenizer_FindEncodingFilename().

  import _tokenizer
  enc = _tokenizer.detect_encoding("cpython/Lib/test/badsyntax_pep3120.py")
  print(enc)  # raises SyntaxError

 ---

Some relevant, related notes:

The discrepencies extend further too.  The following code returns a UnicodeDecodeError, rather than a SyntaxError:

  tokenize.tokenize(open("/home/esnow/projects/import_cleanup/Lib/test/badsyntax_pep3120.py").readline)

In 3.1 (C-based import machinery, Python/import.c), the following results in a SyntaxError, during encoding detection.  In the current repo tip (importlib-based import machinery, Lib/importlib/_bootstrap.py), the following results in a SyntaxError much later, during compilation.

  import test.badsyntax_pep3120

importlib uses tokenize.detect_encoding() and import.c uses PyTokenizer_FindEncodingFilename()...

----------
components: Library (Lib)
files: _tokenizer.c
messages: 158797
nosy: brett.cannon, eric.snow, loewis
priority: normal
severity: normal
status: open
title: discrepency between tokenize.detect_encoding() and PyTokenizer_FindEncodingFilename()
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25283/_tokenizer.c

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

From report at bugs.python.org  Fri Apr 20 09:51:22 2012
From: report at bugs.python.org (Brecht Machiels)
Date: Fri, 20 Apr 2012 07:51:22 +0000
Subject: [New-bugs-announce] [issue14630] non-deterministic behavior of int
	subclass
Message-ID: <1334908282.98.0.497797235147.issue14630@psf.upfronthosting.co.za>


New submission from Brecht Machiels <brecht at mos6581.org>:

I have subclassed int to add an extra attribute:

class Integer(int):
    def __new__(cls, value, base=10, indirect=False):
        try:
            obj = int.__new__(cls, value, base)
        except TypeError:
            obj = int.__new__(cls, value)
        return obj

    def __init__(self, value, base=10, indirect=False):
        self.indirect = indirect

Using this class in my application, int(Integer(b'0')) sometimes returns a value of 48 (= ord('0')!) or 192, instead of the correct value 0. str(Integer(b'0')) always returns '0'. This seems to only occur for the value 0. First decoding b'0' to a string, or passing int(b'0') to Integer makes no difference. The problem lies with converting an Integer(0) to an int with int().

Furthermore, this occurs in a random way. Subsequent runs will produce 48 or 192 at different points in the application (a parser). Both Python 3.2.2 and 3.2.3 behave the same (32-bit, Windows XP). Apparently, the 64-bit Windows Python 3.2.3 does not show this behavior [2]. I haven't tested on other operating systems.

I cannot seem to reproduce this in a simple test program. The following produces no output:

for i in range(100000):
    integer = int(Integer(b'0'))
    if integer > 0:
        print(integer)

Checking for the condition int(Integer()) > 0 in my application (when I know the argument to Integer is b'0') and conditionally printing int(Integer(b'0')) a number of times, the results 48 and 192 do show up now and then.

As I can't reproduce the problem in a short test program, I have attached the relevant code. It is basically a PDF parser. The output for this [2] PDF file is, for example:

b'0' 0 Integer(0) 192 0 b'0' 16853712
b'0' 0 Integer(0) 48 0 b'0' 16938088
b'0' 0 Integer(0) 192 0 b'0' 17421696
b'0' 0 Integer(0) 48 0 b'0' 23144888
b'0' 0 Integer(0) 48 0 b'0' 23185408
b'0' 0 Integer(0) 48 0 b'0' 23323272

Search for print function calls in the code to see what this represents.

[1] http://stackoverflow.com/questions/10230604/non-deterministic-behavior-of-int-subclass#comment13156508_10230604
[2] http://www.gust.org.pl/projects/e-foundry/math-support/vieth2008.pdf

----------
components: None
files: pdf.py
messages: 158803
nosy: brechtm
priority: normal
severity: normal
status: open
title: non-deterministic behavior of int subclass
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file25286/pdf.py

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

From report at bugs.python.org  Fri Apr 20 15:49:42 2012
From: report at bugs.python.org (Sundance)
Date: Fri, 20 Apr 2012 13:49:42 +0000
Subject: [New-bugs-announce] [issue14631] Instance methods and WeakRefs
	don't mix.
Message-ID: <1334929782.59.0.560223623807.issue14631@psf.upfronthosting.co.za>


New submission from Sundance <sundance at ierne.eu.org>:

SUMMARY
=======

The behavior of instance methods makes it impossible to keep a weakref on them. The reference dies instantly even if the instance and the method still exist.


EXAMPLE
=======

>>> import weakref

>>> callbacks = weakref.WeakSet()

>>> def callback1():
...   print "In callback1."

>>> class SomeClass:
...   def callback2(self):
...     print "In callback2."

>>> some_instance = SomeClass()

>>> callbacks.add( callback1 )
>>> callbacks.add( some_instance.callback2 )

>>> for callback in callbacks:
...   callback()
In callback1.

>>> ## callback2 is never called!


ANALYSIS
========

The WeakSet in the example above, and the weakref.ref() it employs, actually behave as specified. It's the particular nature of bound methods that causes the unexpected behavior.

>From what I understand, instance methods are bound dynamically when looked up on the instance. A new object of type instancemethod is created each time:

>>> t1 = some_instance.callback
>>> t2 = some_instance.callback
>>> t1 is t2
False

So when a program calls weakref.ref(some_instance.callback), a new instancemethod object is created on the fly, a weakref to that object is created... and the instancemethod object dies, because its refcount is 0.

This fundamental difference between instance methods and other callables makes it painful to implement weakly referencing callback registries.


PROPOSED SOLUTION
=================

Changing the fundamental nature of instance methods to accommodate one single corner case doesn't seem worthwhile.

Similarly, changing the behavior of weakref.ref(), which does work as specified, is probably not a good idea.

My approach is thus to provide a new helper, WeakCallableRef, that behaves like weakref.ref(), but is safe to use on callables and does what you would naturally expect with instance methods.

It works by binding the lifetime of the ref to that of 1/ the instance bearing the method, and 2/ the unbound method itself. It is also safe to use on other function types beside instance methods, so implementations of callback registries don't have to special case depending on the callable type.

The unexpected behavior should also be mentioned somewhere in the weakref documentation, by the way.

See attached file for a proposed implementation.

----------
components: Library (Lib)
files: WeakCallableRef.py
messages: 158828
nosy: Sundance
priority: normal
severity: normal
status: open
title: Instance methods and WeakRefs don't mix.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file25288/WeakCallableRef.py

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

From report at bugs.python.org  Fri Apr 20 15:57:08 2012
From: report at bugs.python.org (JohnM)
Date: Fri, 20 Apr 2012 13:57:08 +0000
Subject: [New-bugs-announce] [issue14632] Race condition in
	WatchedFileHandler leads to unhandled	exception
Message-ID: <1334930228.42.0.0482247289102.issue14632@psf.upfronthosting.co.za>


New submission from JohnM <phlogistonjohn at asynchrono.us>:

The (very handy) logging.handlers.WatchedFileHandler appears to be  susceptible to a race condition that causes occasional OSErrors during the normal course of operations:


Traceback (most recent call last):
  File "test.py", line 58, in test_race
    log.warning('Foo bar %d', ii)
  File "/usr/lib64/python2.7/logging/__init__.py", line 1144, in warning
    self._log(WARNING, msg, args, **kwargs)
  File "/usr/lib64/python2.7/logging/__init__.py", line 1250, in _log
    self.handle(record)
  File "/usr/lib64/python2.7/logging/__init__.py", line 1260, in handle
    self.callHandlers(record)
  File "/usr/lib64/python2.7/logging/__init__.py", line 1300, in callHandlers
    hdlr.handle(record)
  File "/usr/lib64/python2.7/logging/__init__.py", line 744, in handle
    self.emit(record)
  File "/usr/lib64/python2.7/logging/handlers.py", line 412, in emit
    stat = os.stat(self.baseFilename)
OSError: [Errno 2] No such file or directory: '/tmp/tmpG6_luRTestRaceWatchedFileHandler'

Looking at the implementation of the handler's emit function, I've commented on where I think the race can occur. Logrotate (or some similar application) is deleting/unlinking the logfile between the first os.path.exists and os.stat calls:

    def emit(self, record):
        """
        Emit a record.

        First check if the underlying file has changed, and if it
        has, close the old stream and reopen the file to get the
        current stream.
        """
        if not os.path.exists(self.baseFilename):
        #      ^^^ race occurs between here 
            stat = None
            changed = 1
        else:
            stat = os.stat(self.baseFilename)
            #      ^^^ and this stat call
            changed = (stat[ST_DEV] != self.dev) or (stat[ST_INO] != self.ino)
        if changed and self.stream is not None:
            self.stream.flush()
            self.stream.close()
            self.stream = self._open()
            if stat is None:
                stat = os.stat(self.baseFilename)
            self.dev, self.ino = stat[ST_DEV], stat[ST_INO]
        logging.FileHandler.emit(self, record)

I've attached a test script that attempts to recreate the issue. On my Linux system running the script is able to trigger the issue about every 7 of 10 runs.

----------
components: Library (Lib)
files: test.py
messages: 158829
nosy: phlogistonjohn
priority: normal
severity: normal
status: open
title: Race condition in WatchedFileHandler leads to unhandled exception
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file25289/test.py

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

From report at bugs.python.org  Fri Apr 20 17:18:59 2012
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Apr 2012 15:18:59 +0000
Subject: [New-bugs-announce] [issue14633] test_find_module_encoding should
	test for a less	specific message (or
Message-ID: <1334935139.39.0.293792224706.issue14633@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

test_find_module_encoding (in Lib/test/test_imp.py), has the following check:

    self.assertRaisesRegex(SyntaxError,
        r"Non-UTF-8 code starting with '\\xf6'"
        r" in file .*badsyntax_pep3120.py",
        imp.find_module, 'badsyntax_pep3120', path)

It may be worth changing to something like this (aligning with the changes in issue14629):

    self.assertRaisesRegex(SyntaxError,
        r"invalid or missing encoding declaration",
        imp.find_module, 'badsyntax_pep3120', path)

----------
messages: 158837
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
status: open
title: test_find_module_encoding should test for a less specific message (or

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

From report at bugs.python.org  Fri Apr 20 20:08:04 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Apr 2012 18:08:04 +0000
Subject: [New-bugs-announce] [issue14634] Mock cannot autospec functions
	with keyword-only	arguments.
Message-ID: <1334945284.24.0.289841146723.issue14634@psf.upfronthosting.co.za>


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

The following code:

  def foo(a, *, b=None):
    pass

  unittest.mock.create_autospec(foo)

fails with this traceback:

    Traceback (most recent call last):
      File "temp.py", line 6, in <module>
        unittest.mock.create_autospec(foo)
      File "/home/rdmurray/python/p33/Lib/unittest/mock.py", line 2026, in create_autospec
        mock = _set_signature(mock, spec)
      File "/home/rdmurray/python/p33/Lib/unittest/mock.py", line 162, in _set_signature
        result = _getsignature(original, skipfirst, instance)
      File "/home/rdmurray/python/p33/Lib/unittest/mock.py", line 81, in _getsignature
        regargs, varargs, varkwargs, defaults = inspect.getargspec(func)
      File "/home/rdmurray/python/p33/Lib/inspect.py", line 808, in getargspec
        raise ValueError("Function has keyword-only arguments or annotations"
    ValueError: Function has keyword-only arguments or annotations, use getfullargspec() API which can support them

----------
keywords: easy
messages: 158864
nosy: michael.foord, r.david.murray
priority: normal
severity: normal
status: open
title: Mock cannot autospec functions with keyword-only arguments.
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr 20 21:20:23 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 20 Apr 2012 19:20:23 +0000
Subject: [New-bugs-announce] [issue14635] telnetlib uses select instead of
	poll - limited to	FD_SETSIZE fds
Message-ID: <1334949623.77.0.295518189269.issue14635@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

telnetlib uses select.select.  This limits it to being able to work when file descriptors are still below FD_SETSIZE (often 1024) meaning it can't be used in some large programs today.

It should use poll.

(it is probably easy to fix this and the telnetlib EINTR issue1049450 at the same time)

----------
assignee: jackdied
components: Library (Lib)
messages: 158874
nosy: gregory.p.smith, jackdied
priority: normal
severity: normal
status: open
title: telnetlib uses select instead of poll - limited to FD_SETSIZE fds
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Apr 20 22:38:09 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Apr 2012 20:38:09 +0000
Subject: [New-bugs-announce] [issue14636] Mock could check for exceptions in
	side effect list
Message-ID: <1334954289.59.0.991318648825.issue14636@psf.upfronthosting.co.za>


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

I just spent an hour figuring out why my test was failing because I tried to do this:

   mymock.side_effect = (AuthenticationError, None)

expecting the first call to raise an auth error and the second time it was called to get a normal return.

Since there are almost zero circumstances in which one would really want to return an exception, is there any reason not to have mock check for exceptions and raise them in this circumstance?  (If one did need to return an exception one could write a function...which is what one has to do now for the above case, but the above case seems more commonly needed than returning an exception would be.)

----------
components: Library (Lib)
keywords: easy
messages: 158883
nosy: michael.foord, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Mock could check for exceptions in side effect list
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr 20 22:41:31 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Apr 2012 20:41:31 +0000
Subject: [New-bugs-announce] [issue14637]
	test.test_import.PathsTests.test_UNC_path is failing
Message-ID: <1334954491.9.0.0351086786979.issue14637@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

See http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/104/steps/test/logs/stdio for the failure, but basically:

======================================================================
ERROR: test_UNC_path (test.test_import.PathsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_import.py", line 469, in _test_UNC_path
    mod = __import__("test_trailing_slash")
  File "<frozen importlib._bootstrap>", line 1003, in _find_and_load
ImportError: No module named 'test_trailing_slash'

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


It seems spontaneous as the test succeeded previously and the commit it failed on didn't even touch code compiled by Windows.

----------
components: Windows
keywords: buildbot
messages: 158885
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test.test_import.PathsTests.test_UNC_path is failing

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

From report at bugs.python.org  Fri Apr 20 22:45:23 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 20 Apr 2012 20:45:23 +0000
Subject: [New-bugs-announce] [issue14638] pydoc error on instance of a
	custom class
Message-ID: <1334954723.85.0.214601064543.issue14638@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

pydoc fails on custom instances in specific cases. (When instance __name__ does not resolve to a str).

This is a small example:

>>> import pydoc
>>> class A:
...   def __getattr__(self, name):
...     return True
... 
>>> print(pydoc.render_doc(A))
Python Library Documentation: class A in module __main__
(...)
>>> print(pydoc.render_doc(A()))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "./Lib/pydoc.py", line 1534, in render_doc
    if name and '.' in name:
TypeError: argument of type 'bool' is not iterable

----------
components: Library (Lib)
messages: 158887
nosy: flox
priority: normal
severity: normal
status: open
title: pydoc error on instance of a custom class
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Apr 21 01:13:47 2012
From: report at bugs.python.org (Diego Manenti Martins)
Date: Fri, 20 Apr 2012 23:13:47 +0000
Subject: [New-bugs-announce] [issue14639] Different behavior for urllib2 in
	Python 2.7
Message-ID: <1334963627.5.0.25860672306.issue14639@psf.upfronthosting.co.za>


New submission from Diego Manenti Martins <dmmartins at gmail.com>:

this code sends data in a different way if using python 2.6 or python 2.7

>>> import urllib2
>>> url = 'http://server.com/post_image?tid=zoV6LJ'
>>> f = open('test.jpg')
>>> data = f.read()
>>> res = urllib2.urlopen(url, data)

I checked it with wireshark and the data is sent in a different way when using python 2.7

The code works for python2.5 and python2.6

----------
components: Library (Lib)
messages: 158897
nosy: Diego.Manenti.Martins
priority: normal
severity: normal
status: open
title: Different behavior for urllib2 in Python 2.7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 21 11:52:55 2012
From: report at bugs.python.org (Dionysios Kalofonos)
Date: Sat, 21 Apr 2012 09:52:55 +0000
Subject: [New-bugs-announce] [issue14640] Typos in pyporting.rst
Message-ID: <1335001975.37.0.452902157881.issue14640@psf.upfronthosting.co.za>


New submission from Dionysios Kalofonos <peitemou at gmail.com>:

See attached file.

----------
assignee: docs at python
components: Documentation
files: pyporting.diff
keywords: patch
messages: 158913
nosy: dk, docs at python
priority: normal
severity: normal
status: open
title: Typos in pyporting.rst
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file25299/pyporting.diff

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

From report at bugs.python.org  Sat Apr 21 15:49:17 2012
From: report at bugs.python.org (Dionysios Kalofonos)
Date: Sat, 21 Apr 2012 13:49:17 +0000
Subject: [New-bugs-announce] [issue14641] Minor fixes in sockets.rst
Message-ID: <1335016157.05.0.701229655848.issue14641@psf.upfronthosting.co.za>


New submission from Dionysios Kalofonos <peitemou at gmail.com>:

See attached file.

----------
assignee: docs at python
components: Documentation
files: sockets.diff
keywords: patch
messages: 158919
nosy: dk, docs at python
priority: normal
severity: normal
status: open
title: Minor fixes in sockets.rst
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file25300/sockets.diff

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

From report at bugs.python.org  Sun Apr 22 03:52:48 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 22 Apr 2012 01:52:48 +0000
Subject: [New-bugs-announce] [issue14642] Fix imoprtlib.h build rule to not
	depend on hg
Message-ID: <1335059568.53.0.0474586650503.issue14642@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

A shell or Python script should be used to verify that importlib.h actually needs to be rebuilt, and if so make sure that it's even possible (since it depends on a locally built ./python).

----------
components: Build
messages: 158944
nosy: brett.cannon, georg.brandl, loewis
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Fix imoprtlib.h build rule to not depend on hg
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr 22 11:28:12 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Apr 2012 09:28:12 +0000
Subject: [New-bugs-announce] [issue14643] Security page out of date
Message-ID: <1335086892.52.0.709735016989.issue14643@psf.upfronthosting.co.za>


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

http://www.python.org/news/security/ is completely out of date.
Also, the release pages (e.g. http://www.python.org/download/releases/2.7.3/) don't make it clear which versions are affected by the security issues.

----------
components: None
messages: 158954
nosy: barry, benjamin.peterson, georg.brandl, loewis, pitrou
priority: normal
severity: normal
status: open
title: Security page out of date

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

From report at bugs.python.org  Sun Apr 22 14:29:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Apr 2012 12:29:44 +0000
Subject: [New-bugs-announce] [issue14644] test_logging failure on OS X Tiger
Message-ID: <1335097784.55.0.606093462856.issue14644@psf.upfronthosting.co.za>


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

test_logging always fails on the OS X Tiger buildbot:

http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x

Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/smtplib.py", line 365, in getreply
    line = self.file.readline()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/socket.py", line 297, in readinto
    return self._sock.recv_into(b)
socket.timeout: timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/logging/handlers.py", line 930, in emit
    smtp = smtplib.SMTP(self.mailhost, port, timeout=self.timeout)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/smtplib.py", line 238, in __init__
    (code, msg) = self.connect(host, port)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/smtplib.py", line 319, in connect
    (code, msg) = self.getreply()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/smtplib.py", line 369, in getreply
    + str(e))
smtplib.SMTPServerDisconnected: Connection unexpectedly closed: timed out
Logged from file , line 0
test test_logging failed
ok

======================================================================
FAIL: test_basic (test.test_logging.SMTPHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_logging.py", line 941, in test_basic
    self.assertTrue(self.handled.is_set())
AssertionError: False is not true

----------
assignee: vinay.sajip
components: Library (Lib), Tests
messages: 158957
nosy: pitrou, vinay.sajip
priority: normal
severity: normal
status: open
title: test_logging failure on OS X Tiger
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr 22 19:57:08 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Apr 2012 17:57:08 +0000
Subject: [New-bugs-announce] [issue14645] Generator does not translate
	linesep characters in	certain circumstances
Message-ID: <1335117428.2.0.322445942387.issue14645@psf.upfronthosting.co.za>


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

I ran into this while translating a test, but it turns out it is a long standing problem.  I presume it has not been an issue because in general in Python2 email messages are read as text with universal newline support, and thus the linesep characters get translated on *read*, and the problem in Generator never shows up.  In python3, however, we will often read messages as binary, which will preserve the existing linesep characters, and expose the Generator bug.  

This isn't a critical bug for Python3 only because if a message is read in binary it will likely be written in binary using \r\n linesep, in which case the right thing will be happening.  Likewise most messages read from disk will be written to disk.  But it should be fixed so that the cases where a message is read in binary and written to disk in text and vice versa are correctly formatted.  (In particular, uses of the new smtplib.send_message could theoretically run in to this, though I haven't tested to see if that is really a problem.)

To reproduce, read data/msg_26.txt from the email test suite in binary mode (or text mode using "linesep='\n'", which will preserve the crlf in that file), and run str on the resulting message.  You'll see that the MIME preamble and the base64 part both have \r\n linesep, instead of the default '\n' linesep used for the rest of the message.

----------
assignee: r.david.murray
messages: 158978
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Generator does not translate linesep characters in certain circumstances
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Apr 22 21:37:53 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 22 Apr 2012 19:37:53 +0000
Subject: [New-bugs-announce] [issue14646] Require loaders set __loader__ and
	__package__
Message-ID: <1335123473.69.0.487132909443.issue14646@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

As discussed and agreed to on python-dev, it makes sense to require loaders to set __loader__ and __package__ so that they can be relied upon by globally executed code in a module.

The following needs to happen to close this bug:

* Update PEP 302 to say __loader__ is required, not optional
* Update PEP 366 to say __package__ is required
* Update PEP 302 to point to PEP 366 and mention the requirement
* Update importlib.util.module_for_loader to set both __loader__ and __package__
* Update importlib.util.set_loader and importlib.util.set_package to point out that module_for_loader supercedes those decorators
* Update importlib._bootstrap to set __loader__ when it is absent

----------
assignee: brett.cannon
components: Interpreter Core
messages: 158983
nosy: brett.cannon
priority: release blocker
severity: normal
stage: test needed
status: open
title: Require loaders set __loader__ and __package__
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 23 01:17:57 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 22 Apr 2012 23:17:57 +0000
Subject: [New-bugs-announce] [issue14647] imp.reload() on a package leads to
	a GC assertion failure
Message-ID: <1335136677.5.0.49699953472.issue14647@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

> ./python.exe -c "import urllib.parse as x; import imp; imp.reload(x)"
Assertion failed: (gc->gc.gc_refs != 0), function visit_decref, file Modules/gcmodule.c, line 327.
zsh: abort      ./python.exe -c "import urllib.parse as x; import imp; imp.reload(x)"

I even triggered a segfault that I can't reproduce.

----------
components: Library (Lib)
messages: 158993
nosy: brett.cannon
priority: release blocker
severity: normal
stage: test needed
status: open
title: imp.reload() on a package leads to a GC assertion failure
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 23 15:18:07 2012
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Mon, 23 Apr 2012 13:18:07 +0000
Subject: [New-bugs-announce] [issue14648] Attempt to format ascii and
	non-ascii strings together	fails with "... UCS2 ..."
Message-ID: <1335187087.5.0.315362932474.issue14648@psf.upfronthosting.co.za>


New submission from Dmitry Dvoinikov <dmitry at targeted.org>:

Using Python 3.3.0a2 (default, Apr  1 2012, 19:34:58) [MSC v.1500 64 bit (AMD64)] on win32.

This line of code

"{0:s}{1:s}".format("ABC", "\u0410\u0411\u0412")

results in

SystemError: Cannot copy UCS2 characters into a string of ascii characters

----------
components: Interpreter Core
messages: 159014
nosy: ddvoinikov
priority: normal
severity: normal
status: open
title: Attempt to format ascii and non-ascii strings together fails with "... UCS2 ..."
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 23 16:54:21 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 23 Apr 2012 14:54:21 +0000
Subject: [New-bugs-announce] [issue14649] doctest.DocTestSuite error
	misleading when module has no	docstrings
Message-ID: <1335192861.9.0.305748973415.issue14649@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

When invoking doctest.DocTestSuite's constructor with a module that has no docstrings, doctest raises the following exception:

...
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/doctest.py", line 2280, in DocTestSuite
    raise ValueError(module, "has no tests")
ValueError: (<module '[snip]' from '[snip]'>, 'has no tests')

The error message is misleading because the exception is not raised for modules that have docstrings but no doctests, only for modules that have no docstrings.

To be accurate, the message should be something like 'has no docstrings'.

----------
components: Library (Lib)
messages: 159022
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: doctest.DocTestSuite error misleading when module has no docstrings
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Apr 23 17:54:28 2012
From: report at bugs.python.org (Hobs)
Date: Mon, 23 Apr 2012 15:54:28 +0000
Subject: [New-bugs-announce] [issue14650] 1-character typo in shutils doctext
Message-ID: <1335196468.35.0.0445432965745.issue14650@psf.upfronthosting.co.za>


New submission from Hobs <hobsonlane at gmail.com>:

This patch fixes a 1-character typo in the docstring for shutil.disk_usage().

----------
assignee: docs at python
components: Documentation
files: shutil_disk_usage_doc.patch
keywords: patch
messages: 159035
nosy: Hobson.Lane, docs at python, eric.araujo
priority: normal
severity: normal
status: open
title: 1-character typo in shutils doctext
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25314/shutil_disk_usage_doc.patch

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

From report at bugs.python.org  Mon Apr 23 18:19:44 2012
From: report at bugs.python.org (Takayuki SHIMIZUKAWA)
Date: Mon, 23 Apr 2012 16:19:44 +0000
Subject: [New-bugs-announce] [issue14651] `pysetup run [cmd]` can't handle
	option values in the	setup.cfg
Message-ID: <1335197984.07.0.198109730361.issue14651@psf.upfronthosting.co.za>


New submission from Takayuki SHIMIZUKAWA <shimizukawa at gmail.com>:

`pysetup run [cmd]` can't handle option values in the setup.cfg

setup.cfg::

  [sdist]
  formats = gztar
  dist-dir = _dist

run on windows::

  C:> pysetup run sdist

That command generate `dist/package-version.zip` instead of `_dist/packcage-version.tar.gz`.

attached patch will fix it.

----------
assignee: eric.araujo
components: Distutils2
files: use-setupcfg-options-r13146.patch
keywords: patch
messages: 159040
nosy: alexis, eric.araujo, shimizukawa, tarek
priority: normal
severity: normal
status: open
title: `pysetup run [cmd]` can't handle option values in the setup.cfg
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file25316/use-setupcfg-options-r13146.patch

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

From report at bugs.python.org  Mon Apr 23 19:48:03 2012
From: report at bugs.python.org (=?utf-8?q?Sidney_San_Mart=C3=ADn?=)
Date: Mon, 23 Apr 2012 17:48:03 +0000
Subject: [New-bugs-announce] [issue14652] Better error messages for wsgiref
	validator failures
Message-ID: <1335203283.28.0.579235394721.issue14652@psf.upfronthosting.co.za>


New submission from Sidney San Mart?n <s at sidneysm.com>:

wsgiref?s validation middleware is missing messages for many of its assertions, and its docstring doesn?t reflect read() now requiring an argument (said that it took an optional argument).

Here?s a patch to add some and update the comment.

----------
components: Library (Lib)
files: ssm_validate.patch
keywords: patch
messages: 159053
nosy: ssm
priority: normal
severity: normal
status: open
title: Better error messages for wsgiref validator failures
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25320/ssm_validate.patch

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

From report at bugs.python.org  Mon Apr 23 22:33:32 2012
From: report at bugs.python.org (Mitar)
Date: Mon, 23 Apr 2012 20:33:32 +0000
Subject: [New-bugs-announce] [issue14653] Improve mktime_tz to use
	calendar.timegm instead of	time.mktime
Message-ID: <1335213212.56.0.724242644314.issue14653@psf.upfronthosting.co.za>


New submission from Mitar <mmitar at gmail.com>:

I would suggest improvement of mktime_tz to use calendar.timegm internally instead of time.mktime. The problem is that on Windows mktime_tz fails with "mktime argument out of range" for this code:

mktime_tz(parsedate_tz('Thu, 1 Jan 1970 00:00:00 GMT'))

if user is in GMT+X timezone. Obviously, "Thu, 1 Jan 1970 00:00:00 GMT" is not out of range. But because mktime_tz uses internally time.mktime which takes into the account local time (and local timezone) and then compensate for the timeline, out of range condition happens. I would suggest such implementation:

def mktime_tz(data):
    """Turn a 10-tuple as returned by parsedate_tz() into a UTC timestamp."""
    if data[9] is None:
        # No zone info, so localtime is better assumption than GMT
        return time.mktime(data[:8] + (-1,))
    else:
        t = calendar.timegm(data[:8] + (0,))
        return t - data[9]

It does not raise and exception, and it is also much cleaner: directly using GMT function and not localtime with timezone compensation.

----------
components: Library (Lib)
messages: 159074
nosy: mitar
priority: normal
severity: normal
status: open
title: Improve mktime_tz to use calendar.timegm instead of time.mktime
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr 23 23:04:07 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Apr 2012 21:04:07 +0000
Subject: [New-bugs-announce] [issue14654] More fast utf-8 decoding
Message-ID: <1335215047.86.0.0172027590975.issue14654@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

The utf-8 decoder is already well optimized. I propose a patch, which accelerates the utf-8 decoder for some of the frequent cases even more (+10-30%). In particular, for 2-bites non-latin1 codes will get about +30%.

This is not the final result of optimization. It may be possible to optimize the decoding of the ascii and mostly-ascii text (up to the speed of memcpy), decoding of text with occasional errors, reduce code duplication. But I'm not sure of the success.

Related issues:
[issue4868] Faster utf-8 decoding
[issue13417] faster utf-8 decoding
[issue14419] Faster ascii decoding
[issue14624] Faster utf-16 decoder
[issue14625] Faster utf-32 decoder

----------
components: Interpreter Core
files: decode_utf8.patch
keywords: patch
messages: 159080
nosy: haypo, pitrou, storchaka
priority: normal
severity: normal
status: open
title: More fast utf-8 decoding
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file25326/decode_utf8.patch

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

From report at bugs.python.org  Mon Apr 23 23:22:52 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Apr 2012 21:22:52 +0000
Subject: [New-bugs-announce] [issue14655] traceback module docs should show
	how to print/fomat an	exception object
Message-ID: <1335216172.17.0.173976069373.issue14655@psf.upfronthosting.co.za>


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

Suppose you have an exception object acquired from somewhere.  The exception is no longer active on the stack.  Now you want to format the exception like format_exception would (to log it, perhaps).  To do this you apparently need to call:

  format_exception(type(exc), exc, exc.__traceback__)

This seems redundant, so it would be nice to have a simpler call.  Too bad the name format_exception is already taken.  But, leaving that aside, the above is not documented in the traceback module.  The last example shows the (type(exc), exc) call form for format_exception_only, but that's as close as it gets.

----------
messages: 159084
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: traceback module docs should show how to print/fomat an exception object
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr 23 23:52:11 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 23 Apr 2012 21:52:11 +0000
Subject: [New-bugs-announce] [issue14656] Add a macro for unreachable code
Message-ID: <1335217931.89.0.157136074708.issue14656@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

It would be nice to have a macro Py_UNREACHABLE to keep compiler warnings away in unreachable code. This is can call __builtin_unreachable on gcc and abort elsewhere.

----------
components: Interpreter Core
keywords: easy
messages: 159088
nosy: benjamin.peterson
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a macro for unreachable code
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr 24 00:34:04 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Apr 2012 22:34:04 +0000
Subject: [New-bugs-announce] [issue14657] Avoid two importlib copies
Message-ID: <1335220444.14.0.163321462904.issue14657@psf.upfronthosting.co.za>


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

This patch avoids creating a second copy of importlib._bootstrap when a first one exists as _frozen_importlib.
This isn't perfect as it mutates the module when importlib is imported for the first time, but I think it's better than the status quo.
Also, importlib itself could be imported somewhere along the startup phase, so that all this is invisible to the user.

I'm not sure how to test this, since _frozen_importlib is an implementation detail, and changing that module's name would probably defeat the test already.

----------
components: Interpreter Core, Library (Lib)
files: unique_importlib.patch
keywords: patch
messages: 159096
nosy: brett.cannon, ncoghlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Avoid two importlib copies
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25328/unique_importlib.patch

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

From report at bugs.python.org  Tue Apr 24 00:53:33 2012
From: report at bugs.python.org (Albert Zeyer)
Date: Mon, 23 Apr 2012 22:53:33 +0000
Subject: [New-bugs-announce] [issue14658] Overwriting dict.__getattr__ is
	inconsistent
Message-ID: <1335221613.52.0.779214050633.issue14658@psf.upfronthosting.co.za>


New submission from Albert Zeyer <albzey at googlemail.com>:

```
class Foo1(dict):
    def __getattr__(self, key): return self[key]
    def __setattr__(self, key, value): self[key] = value

class Foo2(dict):
    __getattr__ = dict.__getitem__
    __setattr__ = dict.__setitem__

o1 = Foo1()
o1.x = 42
print(o1, o1.x)

o2 = Foo2()
o2.x = 42
print(o2, o2.x)
```

With CPython 2.5, 2.6 (similarly in 3.2), I get:
({'x': 42}, 42)
({}, 42)

With PyPy 1.5.0, I get the expected output::
({'x': 42}, 42)
({'x': 42}, 42)

I asked this also on SO: http://stackoverflow.com/questions/6305267/python-inconsistence-in-the-way-you-define-the-function-setattr

>From the answers, I am not exactly sure wether this is considered as a bug in CPython or not. Anyway, I just wanted to post this here.

----------
components: None
messages: 159099
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: Overwriting dict.__getattr__ is inconsistent
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 24 08:37:16 2012
From: report at bugs.python.org (frank)
Date: Tue, 24 Apr 2012 06:37:16 +0000
Subject: [New-bugs-announce] [issue14659] HP multi-thread environment python
	core in	PyObject_GC_UnTrack
Message-ID: <1335249436.07.0.574545520744.issue14659@psf.upfronthosting.co.za>


New submission from frank <zhang.guochao at zte.com.cn>:

#0  0x1ffffffffdbaa480:0 in PyObject_GC_UnTrack () at Modules/gcmodule.c:1149
1149    Modules/gcmodule.c: No such file or directory.
        in Modules/gcmodule.c
(gdb) where
#0  0x1ffffffffdbaa480:0 in PyObject_GC_UnTrack () at Modules/gcmodule.c:1149
#1  0x1ffffffffdab7040:0 in tupledealloc () at Objects/tupleobject.c:137
#2  0x1ffffffffdb3c650:0 in code_dealloc () at Python/compile.c:169
#3  0x1ffffffffdc09e70:0 in func_dealloc () at Objects/funcobject.c:408
#4  0x1ffffffffda81390:0 in insertdict () at Objects/dictobject.c:390
#5  0x1ffffffffda82030:0 in PyDict_SetItem () at Objects/dictobject.c:533
#6  0x1ffffffffdb25cd0:0 in eval_frame () at Python/ceval.c:1681
#7  0x1ffffffffdb309d0:0 in PyEval_EvalCodeEx () at Python/ceval.c:2650
#8  0x1ffffffffdb2f9e0:0 in PyEval_EvalCode () at Python/ceval.c:537
#9  0x1ffffffffdb7aa10:0 in PyImport_ExecCodeModuleEx () at Python/import.c:621
#10 0x1ffffffffdb7a850:0 in PyImport_ExecCodeModule () at Python/import.c:588

who can help me, many thanks!

----------
components: Interpreter Core
files: P160254_R1699958_120413075145.txt
messages: 159120
nosy: njfrank
priority: normal
severity: normal
status: open
title: HP multi-thread environment python core in PyObject_GC_UnTrack
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file25337/P160254_R1699958_120413075145.txt

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

From report at bugs.python.org  Tue Apr 24 13:08:40 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 24 Apr 2012 11:08:40 +0000
Subject: [New-bugs-announce] [issue14660] Implement PEP 420: Implicit
	Namespace Packages
Message-ID: <1335265720.13.0.725647299701.issue14660@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

I have created a branch features/pep-420 where I'll be developing a proof of concept implementation of PEP 420.

I've checked in a basic version, but it has these issues:

- We need to decide how finders communicate that they've found part of
a namespace package. Per Brett's suggestion, I'm currently returning a
string that means "the returned path is part of a namespace package".
I think that's an okay design.

- I guess we need to create a "namespace loader", so we can initialize __loader__. It's a little odd because it would be a loader for which there's no need for a find_module method. I'm currently setting __loader__ to the finder, which is completely wrong, but keeps things working.

- test_import and test_importlib both fail because they're checking
that imports with no __init__.py fail. Those tests need to be removed.

- There are no tests yet.

----------
assignee: eric.smith
messages: 159131
nosy: barry, brett.cannon, eric.smith, jason.coombs
priority: normal
severity: normal
status: open
title: Implement PEP 420: Implicit Namespace Packages
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr 24 18:36:21 2012
From: report at bugs.python.org (Pino Toscano)
Date: Tue, 24 Apr 2012 16:36:21 +0000
Subject: [New-bugs-announce] [issue14661] posix module: add O_EXEC, O_SEARCH,
	O_TTY_INIT
Message-ID: <1335285381.34.0.139492231306.issue14661@psf.upfronthosting.co.za>


New submission from Pino Toscano <toscano.pino at tiscali.it>:

The posix module exposes already quite some O_* constants, but it misses few POSIX ones (see [1]), but it misses O_EXEC, O_SEARCH, and O_TTY_INIT.

The attached patch adds them.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fcntl.h.html

----------
files: fcntl_h_constants.diff
keywords: patch
messages: 159168
nosy: pino
priority: normal
severity: normal
status: open
title: posix module: add O_EXEC, O_SEARCH, O_TTY_INIT
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25341/fcntl_h_constants.diff

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

From report at bugs.python.org  Tue Apr 24 19:58:52 2012
From: report at bugs.python.org (Fabian Groffen)
Date: Tue, 24 Apr 2012 17:58:52 +0000
Subject: [New-bugs-announce] [issue14662] shutil.move broken in 2.7.3 on OSX
	(chflags fails)
Message-ID: <1335290332.17.0.906605532092.issue14662@psf.upfronthosting.co.za>


New submission from Fabian Groffen <grobian at gentoo.org>:

With current working dir an NFS-mounted ZFS share, and /var/tmp (OSX default) HFS+:

% echo "test" > /var/tmp/testfile
% python
Python 2.7.3 (default, Apr 24 2012, 19:33:45) 
[GCC 4.2.1 (Gentoo 4.2.1_p5666, Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.move("/var/tmp/testfile", "./testfile");
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 299, in move
    copy2(src, real_dst)
  File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 129, in copy2
    copystat(src, dst)
  File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 103, in copystat
    os.chflags(dst, st.st_flags)
OSError: [Errno 45] Operation not supported: './testfile'
>>> 
% ls /var/tmp/testfile ./testfile
./testfile  /var/tmp/testfile

The problem likely is that the flags stored on the HFS+ volume cannot be applied to the NFS-mounted ZFS volume.  This likely also occurs when doing a bit more regular things, like e.g. moving/copying to a mounted USB disk (with FAT32 filesystem).

I believe this is a "regression" introduced by http://bugs.python.org/issue8746.  Python-2.7.2 works fine.

While preserving flags is nice, it is questionable whether failure to do so in this case is worth dying for.  In particular, leaving behind both the original as well as the copy is a bit messy.

----------
components: None
messages: 159178
nosy: grobian
priority: normal
severity: normal
status: open
title: shutil.move broken in 2.7.3 on OSX (chflags fails)
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 24 20:07:13 2012
From: report at bugs.python.org (Nul Character)
Date: Tue, 24 Apr 2012 18:07:13 +0000
Subject: [New-bugs-announce] [issue14663] Cannot comment out comments
Message-ID: <1335290833.16.0.0579074367428.issue14663@psf.upfronthosting.co.za>


New submission from Nul Character <nulcharacter at gmail.com>:

When attempting to comment out a comment and thus nullifying it, the interpreter just double comments the line. This behavior works with multiline comments, however, the single line comments "double-comment" the line.

----------
components: Interpreter Core
files: comment.py
messages: 159180
nosy: nulchar
priority: normal
severity: normal
status: open
title: Cannot comment out comments
type: performance
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/file25344/comment.py

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

From report at bugs.python.org  Tue Apr 24 23:34:34 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Apr 2012 21:34:34 +0000
Subject: [New-bugs-announce] [issue14664] Skipping a test mixin gives
	metaclass error
Message-ID: <1335303274.85.0.323410405503.issue14664@psf.upfronthosting.co.za>


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

Seen on a buildbot:

test test_multiprocessing crashed -- Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/regrtest.py", line 1229, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "<frozen importlib._bootstrap>", line 1030, in _find_and_load
  File "<frozen importlib._bootstrap>", line 611, in load_module
  File "<frozen importlib._bootstrap>", line 271, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 499, in _load_module
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_multiprocessing.py", line 2430, in <module>
    testcases_processes = create_test_cases(ProcessesMixin, type='processes')
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_multiprocessing.py", line 2409, in create_test_cases
    class Temp(base, unittest.TestCase, Mixin):
TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases


Here is a patch.

----------
components: Library (Lib)
files: skip_mixin.patch
keywords: patch
messages: 159213
nosy: benjamin.peterson, michael.foord, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Skipping a test mixin gives metaclass error
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25353/skip_mixin.patch

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

From report at bugs.python.org  Wed Apr 25 00:17:15 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Apr 2012 22:17:15 +0000
Subject: [New-bugs-announce] [issue14665] faulthandler prints tracebacks in
	reverse order
Message-ID: <1335305835.2.0.186027990116.issue14665@psf.upfronthosting.co.za>


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

Python usually prints traceback from the outer to the inner function: the inner frame is printed last. But faulthandler prints the inner frame first and the outer frame last.

----------
components: Extension Modules
messages: 159223
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: faulthandler prints tracebacks in reverse order
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Apr 25 01:01:57 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Apr 2012 23:01:57 +0000
Subject: [New-bugs-announce] [issue14666] test_sendall_interrupted hangs on
	FreeBSD with a zombi	multiprocessing thread
Message-ID: <1335308517.69.0.701803893151.issue14666@psf.upfronthosting.co.za>


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

[233/364] test_multiprocessing
...
[265/364] test_typechecks
[266/364] test_socket
Timeout (1:00:00)!
Thread 0x0000000807235000:
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/socket.py", line 135 in accept
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/multiprocessing/connection.py", line 595 in accept
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/multiprocessing/connection.py", line 469 in accept
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/multiprocessing/reduction.py", line 256 in _serve
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 592 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 635 in _bootstrap_inner
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 612 in _bootstrap

Thread 0x0000000801407400:
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_socket.py", line 1208 in check_sendall_interrupted
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_socket.py", line 1219 in test_sendall_interrupted
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/case.py", line 385 in _executeTestPart
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/case.py", line 440 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/case.py", line 492 in __call__
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/runner.py", line 168 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/support.py", line 1333 in _run_suite
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/support.py", line 1367 in run_unittest
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_socket.py", line 4813 in test_main
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/regrtest.py", line 1237 in runtest_inner
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/regrtest.py", line 907 in runtest
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/regrtest.py", line 710 in main
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/__main__.py", line 13 in <module>
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/runpy.py", line 73 in _run_code
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/runpy.py", line 160 in _run_module_as_main
*** Error code 1

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

----------
messages: 159230
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: test_sendall_interrupted hangs on FreeBSD with a zombi multiprocessing thread
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 25 02:29:22 2012
From: report at bugs.python.org (James Lu)
Date: Wed, 25 Apr 2012 00:29:22 +0000
Subject: [New-bugs-announce] [issue14667] No IDLE
Message-ID: <1335313762.17.0.753940415621.issue14667@psf.upfronthosting.co.za>


New submission from James Lu <jamtlu at gmail.com>:

No IDLE 3.26
need badly!
High prriority

----------
components: IDLE
files: python.exe
messages: 159243
nosy: James.Lu
priority: normal
severity: normal
status: open
title: No IDLE
type: resource usage
versions: Python 3.2
Added file: http://bugs.python.org/file25358/python.exe

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

From report at bugs.python.org  Wed Apr 25 15:25:11 2012
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 25 Apr 2012 13:25:11 +0000
Subject: [New-bugs-announce] [issue14668] Document the path option in the
	Windows installer
Message-ID: <1335360311.11.0.51507359107.issue14668@psf.upfronthosting.co.za>


New submission from Brian Curtin <brian at python.org>:

Now that #3561 is in, it needs to be mentioned in at least the following places:
Doc\whatsnew\3.3.rst
Doc\faq\windows.rst

http://python.org/download/windows/ could use an update, but that's on a separate SVN repository

----------
assignee: brian.curtin
components: Documentation, Installation, Windows
messages: 159281
nosy: brian.curtin
priority: critical
severity: normal
stage: needs patch
status: open
title: Document the path option in the Windows installer
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 25 18:16:51 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Apr 2012 16:16:51 +0000
Subject: [New-bugs-announce] [issue14669] test_multiprocessing failure on OS
	X Tiger
Message-ID: <1335370611.47.0.977907847024.issue14669@psf.upfronthosting.co.za>


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

The OS X Tiger fails more or less intermittently on one of the new multiprocessing tests:

======================================================================
FAIL: test_pickling (test.test_multiprocessing.WithProcessesTestPicklingConnections)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_multiprocessing.py", line 2032, in test_pickling
    self.assertEqual(new_conn.recv(100), msg.upper())
AssertionError: b'' != b'THIS CONNECTION USES A NORMAL SOCKET'

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

----------
components: Library (Lib), Tests
messages: 159312
nosy: pitrou, sbt
priority: normal
severity: normal
status: open
title: test_multiprocessing failure on OS X Tiger
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 25 19:21:56 2012
From: report at bugs.python.org (Pedro Larroy)
Date: Wed, 25 Apr 2012 17:21:56 +0000
Subject: [New-bugs-announce] [issue14670] subprocess.call with pipe
	character in argument
Message-ID: <1335374516.95.0.470714396537.issue14670@psf.upfronthosting.co.za>


New submission from Pedro Larroy <pedro.larroy at gmail.com>:

When running a command with pipe character as argument the result is not the same as in commandline

For example:

>>> subprocess.call([r"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Commo
n7\IDE\devenv","/build",r"Debug|x64","gpc10.sln"], shell=False)

Chockes on Debug|x64 and just exits with 1.

Running python 2.7.1  r271:86832

----------
components: Windows
messages: 159322
nosy: Pedro.Larroy
priority: normal
severity: normal
status: open
title: subprocess.call with  pipe character in argument
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 26 04:53:36 2012
From: report at bugs.python.org (Q)
Date: Thu, 26 Apr 2012 02:53:36 +0000
Subject: [New-bugs-announce] [issue14671] isinstance(obj,
	object) returns True for _old style_ classes
Message-ID: <1335408816.14.0.0332999907924.issue14671@psf.upfronthosting.co.za>


New submission from Q <abonent at gmail.com>:

$python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
>>> class Old: pass
>>> class New(object): pass
>>> o = Old()
>>> n = New()
>>> isinstance(o, object)
True

This is it, basically. Is it a bug or a feature?

More tests :

>>> isinstance(o, Old)
True
>>> isinstance(o, New)
False
>>> isinstance(n, Old)
False
>>> isinstance(o, int)
False

Please note that some unimportant output was deleted from above.

PS. If this is a feature, how do I detect an old-style class then ?

----------
components: Interpreter Core
messages: 159351
nosy: thread13
priority: normal
severity: normal
status: open
title: isinstance(obj, object) returns True for _old style_ classes
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Apr 26 06:20:11 2012
From: report at bugs.python.org (Jeff Dean)
Date: Thu, 26 Apr 2012 04:20:11 +0000
Subject: [New-bugs-announce] [issue14672] Windows installer: add desktop
	shortcut(s)
Message-ID: <1335414011.97.0.984037154974.issue14672@psf.upfronthosting.co.za>


New submission from Jeff Dean <python.x.jsd at xoxy.net>:

Spun off from Issue3561:

I recently saw Brian Curtin's Pycon 2012 presentation.  If a goal is to make it easy for new Windows users to run python, consider (optionally) installing a desktop shortcut.  This would make it easy for new users to run python (easier than starting up a shell).  This does not require the path to be modified.  

The installer could also (optionally) add a shortcut for starting up a command interpreter with the path modified (for just that shortcut), in case command line access is needed.  This would not be necessary if the python being installed is added to the path.

The first shortcut would be enabled by default, to help truly novice users.  Other users could turn it off, or just delete the shortcut.

----------
components: Installation
messages: 159355
nosy: jdigital
priority: normal
severity: normal
status: open
title: Windows installer: add desktop shortcut(s)
type: enhancement

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

From report at bugs.python.org  Thu Apr 26 07:16:11 2012
From: report at bugs.python.org (Eric Snow)
Date: Thu, 26 Apr 2012 05:16:11 +0000
Subject: [New-bugs-announce] [issue14673] add sys.implementation
Message-ID: <1335417371.81.0.705378686686.issue14673@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

(see thread at http://mail.python.org/pipermail/python-ideas/2012-April/014878.html)

This is a patch to add sys.implementation to Python (with doc addition).  The main motivation is to have an explicit place to look for the name and version of the implementation for generating the import cache tag (a la PEP 3147).

----------
components: Interpreter Core
files: sys_implementation.diff
keywords: patch
messages: 159357
nosy: eric.snow
priority: normal
severity: normal
status: open
title: add sys.implementation
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25369/sys_implementation.diff

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

From report at bugs.python.org  Thu Apr 26 16:15:12 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Apr 2012 14:15:12 +0000
Subject: [New-bugs-announce] [issue14674] Add link to RFC 4627 from json
	documentation
Message-ID: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

The json module documentation should give a link to RFC 4627 and explain the current implementation is different from it. For example, according to RFC 4627 only an object or an array can be top-level JSON element.

----------
assignee: docs at python
components: Documentation
messages: 159367
nosy: docs at python, storchaka
priority: normal
severity: normal
status: open
title: Add link to RFC 4627 from json documentation
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Apr 26 16:37:45 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Thu, 26 Apr 2012 14:37:45 +0000
Subject: [New-bugs-announce] [issue14675] make distutils.ccompiler.CCompiler
	an abstract class
Message-ID: <1335451065.7.0.113076491662.issue14675@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

Make distutils.ccompiler.CCompiler an abstract class by making it inherit from abc.ABCMeta.
Thanks

----------
messages: 159369
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: make distutils.ccompiler.CCompiler an abstract class

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

From report at bugs.python.org  Thu Apr 26 18:49:12 2012
From: report at bugs.python.org (Peter Eisentraut)
Date: Thu, 26 Apr 2012 16:49:12 +0000
Subject: [New-bugs-announce] [issue14676] DeprecationWarning missing in
	default warning filters	documentation
Message-ID: <1335458952.26.0.88746757742.issue14676@psf.upfronthosting.co.za>


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

DeprecationWarning was disabled by default in Python 2.7, but the documentation section "Default Warning Filters" does not list it as ignored.  In the 3.x branches, this was already fixed.  Trivial patch attached.

----------
assignee: docs at python
components: Documentation
files: py27-default-warning-filters-doc.patch
keywords: patch
messages: 159398
nosy: docs at python, petere
priority: normal
severity: normal
status: open
title: DeprecationWarning missing in default warning filters documentation
versions: Python 2.7
Added file: http://bugs.python.org/file25373/py27-default-warning-filters-doc.patch

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

From report at bugs.python.org  Thu Apr 26 19:37:43 2012
From: report at bugs.python.org (mesheb82)
Date: Thu, 26 Apr 2012 17:37:43 +0000
Subject: [New-bugs-announce] [issue14677] Python 2.6 Printing Error
Message-ID: <1335461863.83.0.292616015938.issue14677@psf.upfronthosting.co.za>


New submission from mesheb82 <mesheb82 at gmail.com>:

I?m running:
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on win32

I was testing out some print functionality and I made an error in typing (I meant to use %8.8f), but is this behavior intentional or is it an error?
>> print '%8.8s' %(10000000001.)
>> '10000000'


I would expect this to return a TypeError.

I also tested this on Python 2.4 and Python 2.5 on linux and had the same behavior.

Steve

----------
components: IO
messages: 159403
nosy: mesheb82
priority: normal
severity: normal
status: open
title: Python 2.6 Printing Error
versions: Python 2.6

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

From report at bugs.python.org  Thu Apr 26 19:41:50 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 26 Apr 2012 17:41:50 +0000
Subject: [New-bugs-announce] [issue14678] Update zipimport to support
	importlib.invalidate_caches()
Message-ID: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

zipimport's finders that get cached in sys.path_importer_cache should probably be updated to support importlib.invalidate_caches() (else the module should get re-implemented in pure Python in importlib and then be tossed).

----------
components: Library (Lib)
messages: 159404
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Update zipimport to support importlib.invalidate_caches()
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Apr 26 22:06:13 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 26 Apr 2012 20:06:13 +0000
Subject: [New-bugs-announce] [issue14679] Changes to html.parser break
	third-party code
Message-ID: <1335470773.41.0.349037543033.issue14679@psf.upfronthosting.co.za>


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

The change to html.parser.tagfind in ba4baaddac8d is causing third-party code (Django) to fail. See

http://mail.python.org/pipermail/python-dev/2012-April/119074.html

for more information.

Other patterns which changed (e.g. attrfind_tolerant) might also lead to problems. As suggested in the python-dev thread, private versions of these patterns should be used and the existing public ones deprecated, where appropriate.

----------
keywords: 3.2regression
messages: 159421
nosy: ezio.melotti, vinay.sajip
priority: normal
severity: normal
status: open
title: Changes to html.parser break third-party code
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr 27 00:11:12 2012
From: report at bugs.python.org (Gregor)
Date: Thu, 26 Apr 2012 22:11:12 +0000
Subject: [New-bugs-announce] [issue14680] pydoc with -w option does not work
	for a lot of help	topics
Message-ID: <1335478272.08.0.215124599111.issue14680@psf.upfronthosting.co.za>


New submission from Gregor <gregor.hochschild at gmx.de>:

pydoc with pydoc with -w option (to write html files) does not work for a lot of help topics (e.g. EXPRESSIONS, FORMATTING, TUPLELITERALS, def, if, else...)
If you look at the source you can see that when using the switch '-w' (http://hg.python.org/cpython/file/2.7/Lib/pydoc.py#l2311) pydoc uses the function writedoc, otherwise to the class Helper (http://hg.python.org/cpython/file/2.7/Lib/pydoc.py#l2325). In the Helper-class EXPRESSIONS is defined under line 1666 (http://hg.python.org/cpython/file/2.7/Lib/pydoc.py#l1666). The function writedoc does not utilize this nor does it use the Helper class.

For dicussion see: http://stackoverflow.com/a/10333615/1318686

Example:
pydoc EXPRESSIONS 
works perfectly fine but 
pydoc -w EXPRESSIONS 
does not.

----------
assignee: docs at python
components: Documentation
messages: 159428
nosy: docs at python, gregor.hoch
priority: normal
severity: normal
status: open
title: pydoc with -w option does not work for a lot of help topics
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr 27 11:31:38 2012
From: report at bugs.python.org (rampythonnewbie)
Date: Fri, 27 Apr 2012 09:31:38 +0000
Subject: [New-bugs-announce] [issue14681] Problem in installation of version
	2.3.5 on mac OS X	10.5.8
Message-ID: <1335519098.21.0.990539777894.issue14681@psf.upfronthosting.co.za>


New submission from rampythonnewbie <ramumca7046 at gmail.com>:

Hello,

I am working on an application that runs only on Python version 2.3.5.  Presently i am using mac os x 10.5.8. It came with pre-installed python 2.5.1. Now, when i am running that application with existing version, it is showing the following error..

"RuntimeWarning: Python C API version mismatch for module _AE: This Python has API version 1013, module _AE has version 1012."

So, I want to install version 2.3.5 on my machine along with existing python 2.5.1 unchanged.

I tried the following procedure to install:

1. Downloaded  "Python-2.3.5.tgz" from www.python.org
2. Unpacked it with "tar -zxvf Python-2.3.5.tgz" command.
3. ./configure --prefix=/users/myhomedir/python23
4. make altinstall

But, I am getting following error:

"gcc  -u __dummy -u _PyMac_Error -framework System -framework CoreServices -framework Foundation -o python.exe \
			Modules/python.o \
			libpython2.3.a -ldl      
Undefined symbols:
  "__dummy", referenced from:
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [python.exe] Error 1"


Please help me to know how to install multiple versions of python on mac OS X 10.5 without using macports and virtualenv...

Thanks in advance

----------
messages: 159446
nosy: rampythonnewbie
priority: normal
severity: normal
status: open
title: Problem in installation of version 2.3.5 on mac OS X 10.5.8

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

From report at bugs.python.org  Fri Apr 27 16:13:02 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Fri, 27 Apr 2012 14:13:02 +0000
Subject: [New-bugs-announce] [issue14682] Backport missing errnos to 2.7
Message-ID: <1335535982.47.0.591124202563.issue14682@psf.upfronthosting.co.za>


New submission from Hynek Schlawack <hs at ox.cx>:

In order to fix issue14662, we need to back port at least ENOTSUP to 2.7 (presuming we don?t want to check for magic numbers).

The question is, whether we should back port all/most of them when we?re at it? There doesn?t seem to be much harm to it.

----------
assignee: ronaldoussoren
components: IO, Library (Lib), Macintosh
messages: 159458
nosy: benjamin.peterson, eric.araujo, hynek, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Backport missing errnos to 2.7
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr 27 16:33:05 2012
From: report at bugs.python.org (Luke McCarthy)
Date: Fri, 27 Apr 2012 14:33:05 +0000
Subject: [New-bugs-announce] [issue14683] os.path.isdir.__name__ is "_isdir"
	on Windows (2.7.3)
Message-ID: <1335537185.91.0.610172634713.issue14683@psf.upfronthosting.co.za>


New submission from Luke McCarthy <luke at iogopro.co.uk>:

This caused something to break in our code. I know, maybe it shouldn't rely on that.

----------
messages: 159460
nosy: shaurz
priority: normal
severity: normal
status: open
title: os.path.isdir.__name__ is "_isdir" on Windows (2.7.3)
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr 27 22:49:09 2012
From: report at bugs.python.org (Sam Rushing)
Date: Fri, 27 Apr 2012 20:49:09 +0000
Subject: [New-bugs-announce] [issue14684] zlib set dictionary support
	inflateSetDictionary
Message-ID: <1335559749.94.0.188559298614.issue14684@psf.upfronthosting.co.za>


New submission from Sam Rushing <rushing.sam at gmail.com>:

Google's SPDY protocol requires the use of a pre-defined compression dictionary.  The current zlib module doesn't expose the two functions for setting the dictionary.

This patch is minimal in the sense that it only exposes the two functions, but unfortunately the sequence of zlib calls required is clumsy: a call to inflate() must fail first (with an error of Z_NEED_DICT):


import zlib
zdict = b"thequickbrownfoxjumped\x00"
c = zlib.compressobj()
c.set_dictionary (zdict)
cd = c.compress (b"the quick brown fox jumped over the candlestick")
cd += c.flush()
d = zlib.decompressobj()
try:
    print (d.decompress (cd))
except zlib.error as what:
    if what.args[0].startswith ('Error 2 '):
        d.set_dictionary (zdict)
        print (d.flush())

Obviously a better way to catch/match Z_NEED_DICT would be nice.
A much nicer solution would allow you to associate the dictionary at creation time, rather than having to wait for an error condition.  I can only guess that the zlib authors designed it that way for a reason?

----------
components: Extension Modules
files: zlib_set_dictionary.patch
keywords: patch
messages: 159492
nosy: Sam.Rushing
priority: normal
severity: normal
status: open
title: zlib set dictionary support inflateSetDictionary
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file25387/zlib_set_dictionary.patch

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

From report at bugs.python.org  Fri Apr 27 23:43:47 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 27 Apr 2012 21:43:47 +0000
Subject: [New-bugs-announce] [issue14685] segfault in --without-threads build
Message-ID: <1335563027.12.0.967075753088.issue14685@psf.upfronthosting.co.za>


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

The build --without-threads segfaults in run_tests.py:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/2123/steps/test/logs/stdio

----------
components: Tests
messages: 159496
nosy: skrah
priority: release blocker
severity: normal
stage: needs patch
status: open
title: segfault in --without-threads build
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 28 00:16:33 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 27 Apr 2012 22:16:33 +0000
Subject: [New-bugs-announce] [issue14686] SystemError in unicodeobject.c
Message-ID: <1335564993.44.0.144159847253.issue14686@psf.upfronthosting.co.za>


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

Seen on the Gentoo buildbot:

http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/2154/steps/test/logs/stdio======================================================================
ERROR: test_format (test.test_bool.BoolTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_bool.py", line 167, in test_format
    self.assertEqual("%d" % False, "0")
SystemError: Objects/unicodeobject.c:13507: bad argument to internal function

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

----------
components: Tests
messages: 159502
nosy: haypo, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: SystemError in unicodeobject.c
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 28 02:47:58 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 28 Apr 2012 00:47:58 +0000
Subject: [New-bugs-announce] [issue14687] Optimize str%tuple for the PEP 393
Message-ID: <1335574078.74.0.597228078235.issue14687@psf.upfronthosting.co.za>


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

PyUnicode_Format() creates short temporary substrings. Attached patch tries to avoid substrings. For example, it avoids write of 1 character and repetition of 1 character like a space. PyUnicode_Format() now works in two steps:

 - computes the maximum character and the length of the output string
 - write characters into the output string

I'm not sure that my patch is correct, nor that the change does really speed-up Python.


Benchmark:

./python -m timeit \
  -s 's="x=%s, y=%u, z=%x"; args=(123, 456, 789)' \
  's%args'
./python -m timeit \
  -s 's="The %(k1)s is %(k2)s the %(k3)s."; args={"k1":"x","k2":"y","k3":"z",}' \
  's%args'

Python 3.2:

1000000 loops, best of 3: 0.482 usec per loop
1000000 loops, best of 3: 0.295 usec per loop

Python 3.3:

1000000 loops, best of 3: 0.653 usec per loop
1000000 loops, best of 3: 0.666 usec per loop

Python 3.3 + patch:

1000000 loops, best of 3: 0.596 usec per loop
1000000 loops, best of 3: 0.566 usec per loop

----------
files: pyunicode_format.patch
keywords: patch
messages: 159508
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: Optimize str%tuple for the PEP 393
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file25388/pyunicode_format.patch

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

From report at bugs.python.org  Sat Apr 28 11:28:31 2012
From: report at bugs.python.org (Dionysios Kalofonos)
Date: Sat, 28 Apr 2012 09:28:31 +0000
Subject: [New-bugs-announce] [issue14688] Typos in sorting.rst
Message-ID: <1335605311.94.0.280572266619.issue14688@psf.upfronthosting.co.za>


New submission from Dionysios Kalofonos <peitemou at gmail.com>:

Please see the file attached.

----------
assignee: docs at python
components: Documentation
files: sorting.diff
keywords: patch
messages: 159513
nosy: dk, docs at python
priority: normal
severity: normal
status: open
title: Typos in sorting.rst
versions: Python 3.3
Added file: http://bugs.python.org/file25389/sorting.diff

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

From report at bugs.python.org  Sat Apr 28 11:56:05 2012
From: report at bugs.python.org (Peter Eisentraut)
Date: Sat, 28 Apr 2012 09:56:05 +0000
Subject: [New-bugs-announce] [issue14689] make PYTHONWARNINGS variable work
	in libpython
Message-ID: <1335606965.58.0.412104204254.issue14689@psf.upfronthosting.co.za>


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

The environment variable PYTHONWARNINGS only works with the python interpreter binary, but not with programs embedding libpython.  This could be changed by moving the code from Modules/main.c to Python/pythonrun.c.  See attached patch (compiles cleanly, tests pass, not tested on Windows).

(I have checked all the other environment variables listed on the python man page for whether those that could be usable in the library are actually processed in the library, and all but PYTHONWARNINGS appear to behave reasonably.)

----------
components: Interpreter Core
files: py-pythonwarnings-envvar.patch
keywords: patch
messages: 159514
nosy: petere
priority: normal
severity: normal
status: open
title: make PYTHONWARNINGS variable work in libpython
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25390/py-pythonwarnings-envvar.patch

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

From report at bugs.python.org  Sun Apr 29 03:18:54 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 29 Apr 2012 01:18:54 +0000
Subject: [New-bugs-announce] [issue14690] Use monotonic time for sched,
	trace and subprocess modules
Message-ID: <1335662334.09.0.251528208694.issue14690@psf.upfronthosting.co.za>


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

The PEP 418 added a new time.monotonic() function. The sched, trace and subprocess modules should use it, if available, to avoid issues when the system time is changed.

Attached patch uses the time.monotonic() function when available.

See also the issue #14222 (same issue for queue and threading) and the PEP 418.

--

socket and ssl modules should also use a monotonic clock if available, but these modules are implemented in C. The C implementation of time.monotonic() requires the librt library and is written in the timemodule.c. It requires more work to reuse it in the socket and ssl modules.

----------
files: use_monotonic.patch
keywords: patch
messages: 159559
nosy: haypo, neologix, rhettinger
priority: normal
severity: normal
status: open
title: Use monotonic time for sched, trace and subprocess modules
Added file: http://bugs.python.org/file25400/use_monotonic.patch

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

From report at bugs.python.org  Sun Apr 29 10:57:30 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 29 Apr 2012 08:57:30 +0000
Subject: [New-bugs-announce] [issue14691] a code example not highlighted
	in	http://docs.python.org/dev/library/stdtypes.html#memoryview
Message-ID: <1335689850.36.0.828007836138.issue14691@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

A code example is not highlighted in the 3.3 docs for memoryview (http://docs.python.org/dev/library/stdtypes.html#memoryview)
Only 3.3 is affected by this bug as the code example is for a feature in 3.3.

----------
assignee: docs at python
components: Documentation
messages: 159590
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: a code example not highlighted in http://docs.python.org/dev/library/stdtypes.html#memoryview
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr 29 12:34:25 2012
From: report at bugs.python.org (Jakob Simon-Gaarde)
Date: Sun, 29 Apr 2012 10:34:25 +0000
Subject: [New-bugs-announce] [issue14692] json.joads parse_constant callback
	not working anymore
Message-ID: <1335695665.87.0.370023915793.issue14692@psf.upfronthosting.co.za>


New submission from Jakob Simon-Gaarde <jakobsg at gmail.com>:

Hi
It seems like the parse_constant keyword parameter for registering a callback function is no longer called in Python 2.7.

http://docs.python.org/library/json.html#json.load

I am using Python 2.7.3 on Ubuntu 12.04

I have created and attached a script that shows the problem.
Output in Python 2.6:
Met an int!
Met a constant!
{u'a': None, u'b': None}

Output in Python 2.7:
Met an int!
{u'a': None, u'b': False}

So parse_int callback still works btw.

Best Regards Jakob Simon-Gaarde

----------
components: Extension Modules
files: test_parse_constant.py
messages: 159596
nosy: Jakob.Simon-Gaarde
priority: normal
severity: normal
status: open
title: json.joads parse_constant callback not working anymore
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file25405/test_parse_constant.py

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

From report at bugs.python.org  Sun Apr 29 15:39:33 2012
From: report at bugs.python.org (Dov Feldstern)
Date: Sun, 29 Apr 2012 13:39:33 +0000
Subject: [New-bugs-announce] [issue14693] hashlib fallback modules should be
	built even if openssl	*is* available at build time
Message-ID: <1335706773.33.0.354595880346.issue14693@psf.upfronthosting.co.za>


New submission from Dov Feldstern <dfeldstern at nds.com>:

Python has its own implementations of various hash functions, that can be used as fallbacks when openssl is not available. However, if openssl *is* available at build time, then these fallbacks don't get built.

It would be nice if they would get built even if openssl *was* found at build time:

  (1) for (perceived?) licensing issues, one might choose to run without linking with openssl (see http://mail.python.org/pipermail/python-dev/2011-March/109053.html; that message requests that a bug be opened about this, but I wasn't able to find it?)

  (2) for "portable" builds: build onto portable or shared storage, and run on multiple machines, even if openssl happens not to be available on some of the machines.

----------
components: Build
messages: 159606
nosy: dov
priority: normal
severity: normal
status: open
title: hashlib fallback modules should be built even if openssl *is* available at build time
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr 29 18:12:15 2012
From: report at bugs.python.org (endolith)
Date: Sun, 29 Apr 2012 16:12:15 +0000
Subject: [New-bugs-announce] [issue14694] Option to show leading zeros for
	bin/hex/oct
Message-ID: <1335715935.12.0.0678651117983.issue14694@psf.upfronthosting.co.za>


New submission from endolith <endolith at gmail.com>:

Suggestion: Add an option to bin/hex/oct functions to format binary output with a minimum fixed width, including leading zeros.  Also might be useful for hex and oct.

Currently, bin(18) produces '0b10010'

with this change, something like bin(18, foo=8) would produce '0b00010010'


Examples of people wanting this:

http://stackoverflow.com/questions/3258330/converting-from-hex-to-binary-without-losing-leading-0s-python

http://stackoverflow.com/questions/1002116/can-bin-be-overloaded-like-oct-and-hex-in-python-2-6

http://stackoverflow.com/a/1425558/125507

https://www.linuxquestions.org/questions/programming-9/in-python-printing-leading-zero-for-hex-numbers-0-through-f-719426/

----------
components: Interpreter Core
messages: 159623
nosy: endolith
priority: normal
severity: normal
status: open
title: Option to show leading zeros for bin/hex/oct
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr 29 21:44:34 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 29 Apr 2012 19:44:34 +0000
Subject: [New-bugs-announce] [issue14695] Tools/parser/unparse.py is out of
	date.
Message-ID: <1335728674.11.0.179577366721.issue14695@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Here's a patch that makes all tests in Tools/parser/test_unparse.py pass on the default branch.  (The 'yield from' bits would have to be removed for 3.2.)

----------
components: Demos and Tools
files: unparse.patch
keywords: patch
messages: 159645
nosy: mark.dickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Tools/parser/unparse.py is out of date.
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25410/unparse.patch

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

From report at bugs.python.org  Sun Apr 29 22:58:50 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 29 Apr 2012 20:58:50 +0000
Subject: [New-bugs-announce] [issue14696] parser module doesn't support
	nonlocal statement
Message-ID: <1335733130.9.0.362918429472.issue14696@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Here's a patch.

----------
files: parser_nonlocal.patch
keywords: patch
messages: 159651
nosy: mark.dickinson
priority: normal
severity: normal
stage: patch review
status: open
title: parser module doesn't support nonlocal statement
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25411/parser_nonlocal.patch

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

From report at bugs.python.org  Sun Apr 29 23:44:58 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 29 Apr 2012 21:44:58 +0000
Subject: [New-bugs-announce] [issue14697] parser module doesn't support set
	displays or set	comprehensions
Message-ID: <1335735898.27.0.486602524616.issue14697@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

>>> parser.tuple2st(parser.expr('{2}').totuple())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
parser.ParserError: could not validate expression tuple
[70677 refs]
>>> parser.tuple2st(parser.expr('{x**2 for x in [1, 2, 3]}').totuple())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
parser.ParserError: could not validate expression tuple
[70677 refs]

This seems to be already fixed in Python 2.7.

----------
components: Library (Lib)
messages: 159656
nosy: mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: parser module doesn't support set displays or set comprehensions
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr 30 10:30:40 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 30 Apr 2012 08:30:40 +0000
Subject: [New-bugs-announce] [issue14698] test_posix failures
	-	getpwduid()/initgroups()/getgroups()
Message-ID: <1335774640.36.0.246153891142.issue14698@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

test_posix is consistently failing on the bigmem buildbot:

http://python.org/dev/buildbot/all/builders/AMD64 debian bigmem 3.x/builds/291/steps/test/logs/stdio

"""
======================================================================
ERROR: test_getgrouplist (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/test_posix.py", line 633, in test_getgrouplist
    set(posix.getgrouplist(pwd.getpwuid(os.getuid())[0],
KeyError: 'getpwuid(): uid not found: 5025'

======================================================================
ERROR: test_initgroups (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/test_posix.py", line 111, in test_initgroups
    name = pwd.getpwuid(posix.getuid()).pw_name
KeyError: 'getpwuid(): uid not found: 5025'
"""

I assume that's because the buildbot tests run with a UID without any corresponding pwd entry (which is legit).
The attached patch should fix thoe failures, by making the tests more robust.

----------
components: Tests
files: test_no_pwd.diff
keywords: buildbot, easy, needs review, patch
messages: 159677
nosy: neologix, pitrou
priority: normal
severity: normal
status: open
title: test_posix failures - getpwduid()/initgroups()/getgroups()
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25420/test_no_pwd.diff

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

From report at bugs.python.org  Mon Apr 30 12:11:22 2012
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 30 Apr 2012 10:11:22 +0000
Subject: [New-bugs-announce] [issue14699] Calling a classmethod_descriptor
	directly raises a	TypeError for wrong number of parameters.
Message-ID: <1335780682.19.0.434044540817.issue14699@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

classmethod_descriptor should either be uncallable or (better) accept the correct number of arguments.
The classmethod_descriptor can be regarded as the Python object corresponding directly to the underlying C function, as well as a descriptor object.
When called it should check that its first parameter is a subtype of the type in which it was declared, and then pass that as the 'self' parameter to the underlying C function. Currently it passes the type in which it was declared as its 'self' parameter, adding the remaining parameters.

This means that this fails:
float.__dict__['fromhex'](float, "1")
and this succeeds:
float.__dict__['fromhex']("1")
but it should be the other way around, otherwise it is impossible to pass a subtype as a parameter.

There is no tests for calling classmethod_descriptors in the test suite.

Attached patch includes tests and fixes the behaviour.

----------
components: Interpreter Core
files: classmethoddescr_call.patch
keywords: patch
messages: 159687
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Calling a classmethod_descriptor directly raises a TypeError for wrong number of parameters.
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25423/classmethoddescr_call.patch

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

From report at bugs.python.org  Mon Apr 30 18:55:26 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Apr 2012 16:55:26 +0000
Subject: [New-bugs-announce] [issue14700] Integer overflow in classic string
	formatting
Message-ID: <1335804926.58.0.135059540144.issue14700@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Check for integer overflow for width and precision is buggy.

Just a few examples (on platform with 32-bit int):

>>> '%.21d' % 123
'000000000000000000123'
>>> '%.2147483648d' % 123
'123'
>>> '%.2147483650d' % 123
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: prec too big

>>> '%.21f' % (1./7)
'0.142857142857142849213'
>>> '%.2147483648f' % (1./7)
'0.142857'
>>> '%.2147483650f' % (1./7)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: prec too big

----------
components: Interpreter Core
messages: 159707
nosy: storchaka
priority: normal
severity: normal
status: open
title: Integer overflow in classic string formatting
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/issue14700>
_______________________________________

From report at bugs.python.org  Mon Apr 30 20:55:23 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 30 Apr 2012 18:55:23 +0000
Subject: [New-bugs-announce] [issue14701] parser module doesn't support
	'raise ... from'
Message-ID: <1335812123.91.0.810471517196.issue14701@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

>>> import parser
>>> parser.tuple2st(parser.expr('raise exc from e'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    raise exc from e

----------
messages: 159724
nosy: mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: parser module doesn't support 'raise ... from'
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr 30 21:14:17 2012
From: report at bugs.python.org (Andrew McNabb)
Date: Mon, 30 Apr 2012 19:14:17 +0000
Subject: [New-bugs-announce] [issue14702] os.makedirs breaks under autofs
	directories
Message-ID: <1335813257.88.0.458381281199.issue14702@psf.upfronthosting.co.za>


New submission from Andrew McNabb <amcnabb at mcnabbs.org>:

When a os.makedirs is used under an autofs directory, it crashes. For example, on my machine, `os.makedirs('/net/prodigy/tmp')` crashes with the following traceback:

Traceback (most recent call last):
  ...
  File "/usr/lib64/python2.7/os.py", line 157, in makedirs
    mkdir(name, mode)
OSError: [Errno 13] Permission denied: '/net/prodigy/tmp'

In this case, '/net' is an autofs directory that automatically mounts the "prodigy" directory by connecting to a host called "prodigy" using NFS. The problem seems to be related to the fact that the "/net/prodigy" directory does not actually exist until it is first accessed.

I tried running `mkdir -p /net/prodigy/tmp`, and it succeeds even though the "/net/prodigy" directory did not exist before the "mkdir" command was run.

I'm not sure exactly how `mkdir -p` is implemented, but one potential workaround for Python's makedirs would be to add the following at the top of the function:

    os.stat(name)

This stat call really only needs to be run the first time makedirs is called (it does not need to be used for each recursive call).

----------
components: Library (Lib)
messages: 159728
nosy: amcnabb
priority: normal
severity: normal
status: open
title: os.makedirs breaks under autofs directories
versions: Python 2.7

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