From report at bugs.python.org  Sat May  1 00:57:29 2010
From: report at bugs.python.org (Dmitry Chichkov)
Date: Fri, 30 Apr 2010 22:57:29 +0000
Subject: [New-bugs-announce] [issue8583] Hardcoded namespace_separator in
	the	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>


New submission from Dmitry Chichkov <dchichkov at gmail.com>:

The namespace_separator parameter is hard coded in the cElementTree.XMLParser class disallowing the option of ignoring XML Namespaces with cElementTree library.

Here's the code example:
 from xml.etree.cElementTree import iterparse
 from StringIO import StringIO
 xml = """<root xmlns="http://www.very_long_url.com"><child/></root>"""
 for event, elem in iterparse(StringIO(xml)): print event, elem

It produces:
 end <Element '{http://www.very_long_url.com}child' at 0xb7ddfa58>
 end <Element '{http://www.very_long_url.com}root' at 0xb7ddfa40> 

In the current implementation local tags get forcibly concatenated with URIs often resulting in the ugly code on the user's side and performance degradation (at least due to extra concatenations and extra lengthy compare operations in the elements matching code).

Internally cElementTree uses EXPAT parser, which is doing namespace processing only optionally, enabled by providing a value for namespace_separator argument. This argument is hard-coded in the cElementTree: 
 self->parser = EXPAT(ParserCreate_MM)(encoding, &memory_handler, "}");

Well, attached is a patch exposing this parameter in the cElementTree.XMLParser() arguments. This parameter is optional and the default behavior should be unchanged.  Here's the test code:

import cElementTree

x = """<root xmlns="http://www.very_long_url.com"><child>text</child></root>"""

parser = cElementTree.XMLParser()
parser.feed(x)
elem = parser.close()
print elem

parser = cElementTree.XMLParser(namespace_separator="}")
parser.feed(x)
elem = parser.close()
print elem

parser = cElementTree.XMLParser(namespace_separator=None)
parser.feed(x)
elem = parser.close()
print elem

The resulting output:
<Element '{http://www.very_long_url.com}root' at 0xb7e885f0>
<Element '{http://www.very_long_url.com}root' at 0xb7e88608>
<Element 'root' at 0xb7e88458>

----------
components: Library (Lib)
messages: 104671
nosy: dmtr
priority: normal
severity: normal
status: open
title: Hardcoded namespace_separator in the cElementTree.XMLParser
type: performance
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat May  1 01:16:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Apr 2010 23:16:26 +0000
Subject: [New-bugs-announce] [issue8584] test_multiprocessing skips some
	tests
In-Reply-To: <1272669386.78.0.641016378449.issue8584@psf.upfronthosting.co.za>
Message-ID: <1272669386.78.0.641016378449.issue8584@psf.upfronthosting.co.za>


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

Some tests in test_multiprocessing (py3k) are skipped because they "require _ctypes", but I do have ctypes. Here are the skipped tests:

test_array (test.test_multiprocessing.WithProcessesTestArray) ... skipped 'requires _ctypes'
test_getobj_getlock_obj (test.test_multiprocessing.WithProcessesTestArray) ... skipped 'requires _ctypes'
test_rawarray (test.test_multiprocessing.WithProcessesTestArray) ... skipped 'requires _ctypes'

test_copy (test.test_multiprocessing.WithProcessesTestSharedCTypes) ... skipped 'requires _ctypes'
test_sharedctypes (test.test_multiprocessing.WithProcessesTestSharedCTypes) ... skipped 'requires _ctypes'
test_synchronize (test.test_multiprocessing.WithProcessesTestSharedCTypes) ... skipped 'requires _ctypes'

test_getobj_getlock (test.test_multiprocessing.WithProcessesTestValue) ... skipped 'requires _ctypes'
test_rawvalue (test.test_multiprocessing.WithProcessesTestValue) ... skipped 'requires _ctypes'
test_value (test.test_multiprocessing.WithProcessesTestValue) ... skipped 'requires _ctypes'

----------
assignee: jnoller
components: Tests
messages: 104675
nosy: jnoller, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_multiprocessing skips some tests
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat May  1 03:15:36 2010
From: report at bugs.python.org (Alex)
Date: Sat, 01 May 2010 01:15:36 +0000
Subject: [New-bugs-announce] [issue8585] zipimporter.find_module is untested
In-Reply-To: <1272676536.77.0.29287206537.issue8585@psf.upfronthosting.co.za>
Message-ID: <1272676536.77.0.29287206537.issue8585@psf.upfronthosting.co.za>


New submission from Alex <alex.gaynor at gmail.com>:

There are no tests for zipimporter.find_module in the success case, only tests that it handles invalid inputs ok.  I'll work up some tests for this tomorrow probably.

----------
components: Extension Modules
messages: 104684
nosy: alex
priority: normal
severity: normal
status: open
title: zipimporter.find_module is untested

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

From report at bugs.python.org  Sat May  1 12:38:15 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 10:38:15 +0000
Subject: [New-bugs-announce] [issue8586] test_imp.py test failures on Py3K
	Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

I get the following failure running test_imp on py3k, Mac OS X 10.6.3.


======================================================================
ERROR: test_package___file__ (__main__.PEP3147Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_imp.py", line 303, in test_package___file__
    support.forget('pep3147')
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/pep3147.pyc'

----------
messages: 104702
nosy: brett.cannon, michael.foord
priority: normal
severity: normal
stage: unit test needed
status: open
title: test_imp.py test failures on Py3K Mac OS X
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat May  1 12:44:56 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 10:44:56 +0000
Subject: [New-bugs-announce] [issue8587] test_import.py test failures on
	Py3K Mac OS X
In-Reply-To: <1272710696.01.0.527513394318.issue8587@psf.upfronthosting.co.za>
Message-ID: <1272710696.01.0.527513394318.issue8587@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

I get the following failures with test_import on Mac OS X 10.6.3:


======================================================================
ERROR: test_import (test.test_import.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 93, in test_import
    test_with_extension(".py")
  File "/compile/python-trunk3/Lib/test/test_import.py", line 86, in test_with_extension
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test___cached__ (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test___cached___legacy_pyc (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test_import_pyc_path (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test_missing_source (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test_missing_source_legacy (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test_package___cached__ (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test_package___cached___from_pyc (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test_unwritable_directory (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

----------
messages: 104703
nosy: brett.cannon, michael.foord
priority: normal
severity: normal
status: open
title: test_import.py test failures on Py3K Mac OS X
versions: Python 3.2

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

From report at bugs.python.org  Sat May  1 12:56:49 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 10:56:49 +0000
Subject: [New-bugs-announce] [issue8588] test_urllib2.py test failures on
	Py3K Mac OS X
In-Reply-To: <1272711409.24.0.121208244389.issue8588@psf.upfronthosting.co.za>
Message-ID: <1272711409.24.0.121208244389.issue8588@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Failures on py3k, Mac OS X 10.6.3.


======================================================================
ERROR: test_proxy_https (__main__.HandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_urllib2.py", line 1010, in test_proxy_https
    r = o.open(req)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 349, in open
    response = self._open(req, data)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 367, in _open
    '_open', req)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 327, in _call_chain
    result = func(*args)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 655, in <lambda>
    meth(r, proxy, type))
  File "/compile/python-trunk3/Lib/urllib/request.py", line 663, in proxy_open
    if req.host and proxy_bypass(req.host):
  File "/compile/python-trunk3/Lib/urllib/request.py", line 2214, in proxy_bypass
    return proxy_bypass_macosx_sysconf(host)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 2183, in proxy_bypass_macosx_sysconf
    hostIP = ip2num(hostIP)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 2161, in ip2num
    if len(parts) != 4:
TypeError: object of type 'map' has no len()

======================================================================
ERROR: test_proxy_https_proxy_authorization (__main__.HandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_urllib2.py", line 1026, in test_proxy_https_proxy_authorization
    r = o.open(req)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 349, in open
    response = self._open(req, data)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 367, in _open
    '_open', req)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 327, in _call_chain
    result = func(*args)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 655, in <lambda>
    meth(r, proxy, type))
  File "/compile/python-trunk3/Lib/urllib/request.py", line 663, in proxy_open
    if req.host and proxy_bypass(req.host):
  File "/compile/python-trunk3/Lib/urllib/request.py", line 2214, in proxy_bypass
    return proxy_bypass_macosx_sysconf(host)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 2183, in proxy_bypass_macosx_sysconf
    hostIP = ip2num(hostIP)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 2161, in ip2num
    if len(parts) != 4:
TypeError: object of type 'map' has no len()

----------
messages: 104708
nosy: michael.foord
priority: normal
severity: normal
status: open
title: test_urllib2.py test failures on Py3K Mac OS X
versions: Python 3.2

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

From report at bugs.python.org  Sat May  1 13:05:19 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 11:05:19 +0000
Subject: [New-bugs-announce] [issue8589]
	test_warnings.CEnvironmentVariableTests.test_nonascii	fails
	under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

If you run test_warnings.py under an ascii terminal (at least on Mac OS X) then test_warnings.CEnvironmentVariableTests.test_nonascii fails. Perhaps the test should be skipped? 

======================================================================
FAIL: test_nonascii (__main__.CEnvironmentVariableTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_warnings.py", line 758, in <module>
    test_main()
  File "Lib/test/test_warnings.py", line 753, in test_main
    PyEnvironmentVariableTests
  File "/compile/python-trunk3/Lib/test/support.py", line 1053, in run_unittest
    _run_suite(suite)
  File "/compile/python-trunk3/Lib/test/support.py", line 1027, in _run_suite
    result = runner.run(suite)
  File "/compile/python-trunk3/Lib/unittest/runner.py", line 158, in run
    result.printErrors()
  File "/compile/python-trunk3/Lib/unittest/runner.py", line 109, in printErrors
    self.printErrorList('FAIL', self.failures)
  File "/compile/python-trunk3/Lib/unittest/runner.py", line 116, in printErrorList
    self.stream.writeln("%s" % err)
  File "/compile/python-trunk3/Lib/unittest/runner.py", line 24, in writeln
    self.write(arg)
UnicodeEncodeError: 'ascii' codec can't encode character '\xf3' in position 121: ordinal not in range(128)


Looks like the traceback here actually comes from unittest trying to report the failure.

----------
messages: 104709
nosy: michael.foord
priority: normal
severity: normal
status: open
title: test_warnings.CEnvironmentVariableTests.test_nonascii fails under an ascii terminal
versions: Python 3.2

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

From report at bugs.python.org  Sat May  1 13:36:08 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 11:36:08 +0000
Subject: [New-bugs-announce] [issue8590]
	test_httpservers.CGIHTTPServerTestCase failure on	3.1-maint Mac OS X
In-Reply-To: <1272713768.56.0.588560261666.issue8590@psf.upfronthosting.co.za>
Message-ID: <1272713768.56.0.588560261666.issue8590@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

A failure in test_httpservers.py on 31-maint (not failing in py3k) on Mac OS X 10.6.3:

test_post (__main__.CGIHTTPServerTestCase) ... Traceback (most recent call last):
  File "/private/var/folders/WD/WDk8J3uFE7OM9tRer5Oy4E+++TI/-Tmp-/tmpv_ZniR/cgi-bin/file2.py", line 2, in <module>
    import cgi
  File "/compile/py-31-maint/Lib/cgi.py", line 34, in <module>
    from operator import attrgetter
ImportError: No module named operator
[28226 refs]
FAIL

======================================================================
FAIL: test_post (__main__.CGIHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_httpservers.py", line 379, in test_post
AssertionError: b'' != b'1, python, 123456\n'


Interesting to see the import error during the test. Running python and executing "import operator" works fine.

----------
messages: 104711
nosy: michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: test_httpservers.CGIHTTPServerTestCase failure on 3.1-maint Mac OS X
versions: Python 3.1

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

From report at bugs.python.org  Sat May  1 17:22:11 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 01 May 2010 15:22:11 +0000
Subject: [New-bugs-announce] [issue8591] update mkpkg to latest coding
	standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>


New submission from Dan Buch <daniel.buch at gmail.com>:

On first glance, `distutils2.mkpkg` does not reflect the latest and greatest in Python coding standards.  I'd like to take a stab at PEP-(7|8)'ing the whole thing, although I know there are other issues open to add features to the module, so I don't want to cause unnecessary merge pains.  Thoughts?

----------
assignee: tarek
components: Distutils2
messages: 104726
nosy: meatballhat, tarek
priority: normal
severity: normal
status: open
title: update mkpkg to latest coding standards
type: behavior
versions: 3rd party, Python 2.5, 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/issue8591>
_______________________________________

From report at bugs.python.org  Sat May  1 20:04:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 18:04:35 +0000
Subject: [New-bugs-announce] [issue8592] 'y' does not check for embedded NUL
	bytes
In-Reply-To: <1272737075.21.0.258918022173.issue8592@psf.upfronthosting.co.za>
Message-ID: <1272737075.21.0.258918022173.issue8592@psf.upfronthosting.co.za>


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

The documentation for the 'y' format (PyArg_ParseTuple and friends) states that:

? The bytes object must not contain embedded NUL bytes; if it does, a TypeError exception is raised. ?

But, reading Python/getargs.c, the strlen() check is actually missing in the code for 'y'.

----------
assignee: loewis
components: Interpreter Core
messages: 104734
nosy: loewis, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: 'y' does not check for embedded NUL bytes
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat May  1 20:25:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 18:25:02 +0000
Subject: [New-bugs-announce] [issue8593] Improve c-api/arg.rst
In-Reply-To: <1272738302.73.0.83180845409.issue8593@psf.upfronthosting.co.za>
Message-ID: <1272738302.73.0.83180845409.issue8593@psf.upfronthosting.co.za>


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

This patch fixes, reorders and improves c-api/arg.rst.

I would even suggest to go further and single out a couple of "most useful" formats ('s', 'y*', 'i', 'l'...) so that people don't get lost in all the possibilities.

----------
assignee: docs at python
components: Documentation
files: argdoc.patch
keywords: patch
messages: 104736
nosy: docs at python, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Improve c-api/arg.rst
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17168/argdoc.patch

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

From report at bugs.python.org  Sat May  1 22:33:02 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 01 May 2010 20:33:02 +0000
Subject: [New-bugs-announce] [issue8594] Add a "source_address" option to
	ftplib
In-Reply-To: <1272745982.51.0.743868524528.issue8594@psf.upfronthosting.co.za>
Message-ID: <1272745982.51.0.743868524528.issue8594@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

Similarly to issue 3972 the patch in attachment adds a new "source_address" option to FTP class to bind to a specific address when connecting to a remote FTP server.

It must be noted that this gets done for both control and passive data connections (client connecting to server). The latter one solves issue 1661754.

----------
components: Library (Lib)
files: ftplib_source_address.patch
keywords: needs review, patch
messages: 104749
nosy: giampaolo.rodola, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: Add a "source_address" option to ftplib
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17172/ftplib_source_address.patch

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

From report at bugs.python.org  Sun May  2 04:54:44 2010
From: report at bugs.python.org (Julian)
Date: Sun, 02 May 2010 02:54:44 +0000
Subject: [New-bugs-announce] [issue8595] Unexpected default timeout in
	http-client-related	libraries
In-Reply-To: <1272768884.43.0.28527344604.issue8595@psf.upfronthosting.co.za>
Message-ID: <1272768884.43.0.28527344604.issue8595@psf.upfronthosting.co.za>


New submission from Julian <python_org at somethinkodd.com>:

Since Python 2.6, httplib has offered a timeout parameter for fetches. As the documentation explains, if this parameter is not provided, it uses the global default.

What the document doesn't explain is httplib builds on top of the socket library. The socket library has a default timeout of None (i.e. forever). This may be an appropriate default for general sockets, but it is a poor default for httplib; typical http clients would use a timeout in the 2-10 second range.

This problem is propagated up to urllib2, which sits on httplib, and further obscures that the default might be unsuitable.

>From an inspection of the manuals, Python 3.0.1 suffers from the same problem except, the names have changed. urllib.response sits on http.client.

I, for one, made a brutal mistake of assuming that the "global default" would be some reasonable default for fetching web pages; I didn't have any specific timeout in mind, and was happy for the library to take care of it. Several million successful http downloads later, my server application thread froze waiting forever when talking to a recalcitrant web-server. I imagine others have fallen for the same trap.

While an ideal solution would be for httplib and http.client to use a more generally acceptable default, I can see it might be far too late to make such a change without breaking existing applications. Failing that, I would recommend that the documentation for httplib, urllib, urllib2, http.client and urllib.request (+ any other similar libraries sitting on socket? FTP, SMTP?) be changed to highlight that the default global timeout, sans deliberate override, is to wait a surprisingly long time.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 104763
nosy: docs at python, oddthinking
priority: normal
severity: normal
status: open
title: Unexpected default timeout in http-client-related libraries
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun May  2 06:04:10 2010
From: report at bugs.python.org (pvo)
Date: Sun, 02 May 2010 04:04:10 +0000
Subject: [New-bugs-announce] [issue8596] crypt blowfish 'ignores' salt
In-Reply-To: <1272773050.91.0.224780223694.issue8596@psf.upfronthosting.co.za>
Message-ID: <1272773050.91.0.224780223694.issue8596@psf.upfronthosting.co.za>


New submission from pvo <user+python at localhost.localdomain.org>:

Blowfish crypt uses a 128 bit salt, not only the letters [./a-zA-Z0-9]. Despite the different salts, crypt ignores the salt and produces identical encrypted passwords.
The problem occurs on FreeBSD 7.2 with Python 2.5.5 (r255:77872) and Python 2.6.4 (r264:7570) (both from the ports)

python2.6 crypt_blf.py 
 salt: '$2a$05$)O\x0e9\xb7\xb0\xc9\xd6)v.\xd3\x03\xea!\xc1$'
$2a$05$t59ktwmm7.WpI...../5uuAazXv5nUvrWyN1EzMcL6/EQ0HrNyJwq
 salt: '$2a$05$\x1ak\x0c\xfbF\xf5\xdf\xb4\x99\xa6\x12\x81\x8d\xce\xea\x19$'
$2a$05$COgstwmm........../5uuu63L/Vi1a/9FQpklC2BKZ74ai8JM2ey
 salt: '$2a$05$\x80:\x14\xbb\xc3R\x95\xb9\xcb\xf0#\x04\xbf"\xf7\xe9$'
$2a$05$COgstwmm........../5uuu63L/Vi1a/9FQpklC2BKZ74ai8JM2ey
 salt: '$2a$05$i\x01 \x10\x13#\xe3\xdc\x80\x90[3\xd5@(\x96$'
$2a$05$COgstwmm........../5uuu63L/Vi1a/9FQpklC2BKZ74ai8JM2ey
 salt: '$2a$05$<\xa8CY\xa6\x018\xe7\x0b}\x92\xd3\xa1L1\xfb$'
$2a$05$COgstwmm........../5uuu63L/Vi1a/9FQpklC2BKZ74ai8JM2ey

----------
components: Library (Lib)
files: crypt_blf.py
messages: 104768
nosy: pvo
priority: normal
severity: normal
status: open
title: crypt blowfish 'ignores' salt
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file17181/crypt_blf.py

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

From report at bugs.python.org  Sun May  2 07:45:31 2010
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Sun, 02 May 2010 05:45:31 +0000
Subject: [New-bugs-announce] [issue8597] build out-of-line asm on Windows
In-Reply-To: <1272779131.33.0.179650713526.issue8597@psf.upfronthosting.co.za>
Message-ID: <1272779131.33.0.179650713526.issue8597@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

I maintain a Python package which comes with assembly optimizations -- http://tahoe-lafs.org/trac/pycryptopp . Someone was porting this package to Win64 today and discovered that distutils couldn't build it because the Microsoft compiler on Win64 doesn't allow in-line assembly and distutils doesn't know how to build out-of-line assembly (see also http://stackoverflow.com/questions/1664812/can-pythons-distutils-compile-s-assembly which says that there isn't a known way to do this).

So the fellow who is porting pycryptopp to Win64 for me, Samuel Neves, found this hack in someone else's setup.py file: http://bitbucket.org/ambroff/greenlet/src/3ad4830aa109/setup.py

We're probably going to adapt that hack to the pycryptopp setup.py file in order to work around this problem.

But then another fellow named Josip Djolonga who is a GSoC student working on Distutils2 suggested that we could patch the compiler class to use assembly files and pass them to cl.exe. Samuel worked up a patch that does that and then he was able to build pycryptopp on Win64. Here is his patch attached as a file.

Note that we will still need to do some work-around in the pycryptopp setup.py file in order to make pycryptopp buildable on Win64 with older versions of Python that do not have this fix. Any suggestions on the best way to do that would be welcome.

Oops, I see that Samuel gave me the patch in traditional diff form instead of unified diff form. I hope you can accept it anyway since he has gone to bed.

----------
assignee: tarek
components: Distutils
files: patch.diff
keywords: patch
messages: 104770
nosy: tarek, zooko
priority: normal
severity: normal
status: open
title: build out-of-line asm on Windows
type: behavior
Added file: http://bugs.python.org/file17182/patch.diff

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

From report at bugs.python.org  Sun May  2 11:58:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 May 2010 09:58:08 +0000
Subject: [New-bugs-announce] [issue8598] test/support: don't use localhost
	as IPv6 host name
In-Reply-To: <1272794288.96.0.106540212417.issue8598@psf.upfronthosting.co.za>
Message-ID: <1272794288.96.0.106540212417.issue8598@psf.upfronthosting.co.za>


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

TestIPv6Environment testcase of test_ftplib uses support.HOST as hostname, and HOST=localhost. Usually, localhost is the name of 127.0.0.1, but not always ::1. On Linux, the usual names for ::1 are ip6-localhost or ip6-loopback. My internet server provider DNS resolver does not always resolv "localhost" as ::1, sometimes it answer 3(NXDOMAIN). Anyway, the name should be resolved by the local DNS resolver, not depend on an external (ISP) DNS server.

The simplest solution is to use "::1" instead of localhost ;-)

----------
components: Tests
messages: 104778
nosy: haypo
priority: normal
severity: normal
status: open
title: test/support: don't use localhost as IPv6 host name
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun May  2 17:03:46 2010
From: report at bugs.python.org (Oren Held)
Date: Sun, 02 May 2010 15:03:46 +0000
Subject: [New-bugs-announce] [issue8599] _execvpe should behaves
	inconsistently when PATH includes	a filename
In-Reply-To: <1272812626.29.0.414465850944.issue8599@psf.upfronthosting.co.za>
Message-ID: <1272812626.29.0.414465850944.issue8599@psf.upfronthosting.co.za>


New submission from Oren Held <oren at held.org.il>:

A. Description
When running os._execvpe with a relative pathname that does not exist, I'd expect to get ENOENT error. But there is an edge case in which Python throws ENOTDIR error - when the LAST element in PATH is a regular file (e.g. /bin/ls). This case is caused by a sysadmin mistake, but it may happen, as in the system on which I've encountered this bug.

B. Explanation + How to reproduce:
Consider the following case:
PATH="/bin:/bin/ls" # Last part is a filename instead of a directory
>>> import os; os.execvp("blabla", [""])
Throws: OSError: [Errno 20] Not a directory

Now, consider a similar but differently-ordered PATH:
PATH="/bin/ls:/bin" # *First* part is a filename instead of a directory
>>> import os; os.execvp("blabla", [""])
Throws: OSError: [Errno 2] No such file or directory


C. Why this behavior is not good:
First, IMO there is a certain problem here - differently ordered PATH shouldn't throw different exception. In both cases the executable was not found in PATH, both cases are the same for this matter.

Second, the unix shell (e.g. bash) faces the same issue, and behaves differently. It'll return "command not found" to stdout for both ENOENT and ENOTDIR cases, regardless of the element order in PATH.


D. My recommendation
I'd recommend throwing ENOENT even when ENODIR is thrown for some paths. I am not sure what's the least-evil way to do it, I've been thinking of the following patch, but it's not working because it depends on strerror. It also looks kinda ugly:

--- os.py.old	2010-05-02 17:41:21.481909804 +0300
+++ os.py	2010-05-02 18:03:11.261872651 +0300
@@ -386,7 +386,7 @@
                 saved_tb = tb
     if saved_exc:
         raise error, saved_exc, saved_tb
-    raise error, e, tb
+    raise error, error(errno.ENOENT, os.strerror(errno.ENOENT)), tb # DOESNT WORK, no access to os.strerror from here
 
 # Change environ to automatically call putenv() if it exists
 try:

----------
components: Library (Lib)
messages: 104788
nosy: Oren_Held
priority: normal
severity: normal
status: open
title: _execvpe should behaves inconsistently when PATH includes a filename
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon May  3 04:00:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 May 2010 02:00:25 +0000
Subject: [New-bugs-announce] [issue8600] test_gdb failures
In-Reply-To: <1272852025.2.0.622667060005.issue8600@psf.upfronthosting.co.za>
Message-ID: <1272852025.2.0.622667060005.issue8600@psf.upfronthosting.co.za>


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

All test_gdb tests fail here with both trunk and py3k. The failure is always the same so I'm just quoting one of them below:

======================================================================
FAIL: test_basic_command (test.test_gdb.PyBtTests)
Verify that the "py-bt" command works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_gdb.py", line 604, in test_basic_command
    cmds_after_breakpoint=['py-bt'])
  File "/home/antoine/py3k/__svn__/Lib/test/test_gdb.py", line 126, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: 
- warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
- warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
- warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
- warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
- warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.


This is with:

GNU gdb (GDB) 7.1-1mdv2010.1 (Mandriva Linux release 2010.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-mandriva-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

----------
assignee: dmalcolm
components: Tests
messages: 104810
nosy: dmalcolm, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gdb failures
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon May  3 08:54:29 2010
From: report at bugs.python.org (Matt Wartell)
Date: Mon, 03 May 2010 06:54:29 +0000
Subject: [New-bugs-announce] [issue8601] bz2.BZ2File should support "with"
	protocol per PEP 343
In-Reply-To: <1272869669.89.0.492897458524.issue8601@psf.upfronthosting.co.za>
Message-ID: <1272869669.89.0.492897458524.issue8601@psf.upfronthosting.co.za>


New submission from Matt Wartell <matt.wartell+pt at gmail.com>:

As the bz2.BZ2File object claims to be a file-like object it should conform to PEP 343 "The 'with' statement" by implementation of the __enter__ and __exit__ methods.


boring, substantiating detail follows:
$ uname -a
Linux tallguy 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 UTC 2010 i686 GNU/Linux
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
>>> with bz2.BZ2File('test.bz2') as infile:
...     pass
... 
AttributeError: 'bz2.BZ2File' object has no attribute '__exit__'

>>> getattr(bz2.BZ2File, '__enter__')
AttributeError: type object 'bz2.BZ2File' has no attribute '__enter__'
>>> getattr(bz2.BZ2File, '__exit__')
AttributeError: type object 'bz2.BZ2File' has no attribute '__exit__'


$ dpkg -l python2.6
ii  python2.6    2.6.5-1ubuntu6     An interactive hig...
$ dpkg -L python2.6 | grep bz2.so
/usr/lib/python2.6/lib-dynload/bz2.so

----------
components: Extension Modules
messages: 104817
nosy: Matt.Wartell
priority: normal
severity: normal
status: open
title: bz2.BZ2File should support "with" protocol per PEP 343
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon May  3 09:03:54 2010
From: report at bugs.python.org (Matt Wartell)
Date: Mon, 03 May 2010 07:03:54 +0000
Subject: [New-bugs-announce] [issue8602] documentation of bz2 module mildly
	erroneous
In-Reply-To: <1272870234.45.0.00658969889364.issue8602@psf.upfronthosting.co.za>
Message-ID: <1272870234.45.0.00658969889364.issue8602@psf.upfronthosting.co.za>


New submission from Matt Wartell <matt.wartell+pt at gmail.com>:

This is related to http://bugs.python.org/issue8601 "bz2.BZ2File should support "with" protocol per PEP 343"

The documentation at http://docs.python.org/library/bz2.html states:

   "This module provides a comprehensive interface for the bz2 compression library. It implements a complete file interface,..." 

although bz2.BZ2File does not support the __enter__ and __exit__ methods so arguably doesn't implement the "complete file interface". If issue8601 is declined then the documentation should probably note this exception.

----------
assignee: docs at python
components: Documentation
messages: 104818
nosy: Matt.Wartell, docs at python
priority: normal
severity: normal
status: open
title: documentation of bz2 module mildly erroneous
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon May  3 10:56:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 May 2010 08:56:26 +0000
Subject: [New-bugs-announce] [issue8603] Create a bytes version of
	os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>


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

As discussed in issue #8514, I propose a bytes version of os.envionb which would be synchronized with os.environ (which is possible thanks to surrogateescape error handler).

I also propose a os.getenvb()->bytes function.

I don't know yet if it's a good idea of not, but my patch accepts both bytes and str for os.environ(b).get() and os.getenv(b)().

antoine> In posixmodule.c, (...) if memory allocation of the bytes
antoine> object fails, we should error out.

I would require to change also the Windows version and the code specific to OS/2. Ok to do that, but after closing this issue ;-) I don't want to change to much things at the same time.

----------
components: Interpreter Core, Library (Lib), Unicode
files: os_environb.patch
keywords: patch
messages: 104825
nosy: Arfrever, ezio.melotti, gregory.p.smith, haypo, lemburg, loewis, pitrou
priority: normal
severity: normal
status: open
title: Create a bytes version of os.environ and getenvb()
versions: Python 3.2
Added file: http://bugs.python.org/file17191/os_environb.patch

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

From report at bugs.python.org  Mon May  3 14:43:59 2010
From: report at bugs.python.org (Olemis Lang)
Date: Mon, 03 May 2010 12:43:59 +0000
Subject: [New-bugs-announce] [issue8604] Alias for
	distutils.file_util.write_file in e.g. shutils
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>


New submission from Olemis Lang <olemis+py at gmail.com>:

Often I have the contents to be written in a file at a given path that
I know as well. I recently tried to find a function in stdlib to do
that and to my surprise this is what I found :

 - Such function exists
 - It's `distutils.file_util.write_file`

IMO the last place where people'd look for such a function is inside
`distutils` package. Besides I reviewed modules listed under `File and
directory access` category in `Library Reference` and found nothing
even similar.

The idea is to provide a a similar function in `shutils` module

----------
assignee: tarek
components: Distutils
messages: 104833
nosy: olemis, tarek
priority: normal
severity: normal
status: open
title: Alias for distutils.file_util.write_file in e.g. shutils
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Mon May  3 18:14:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 May 2010 16:14:53 +0000
Subject: [New-bugs-announce] [issue8605] gdb API issues
In-Reply-To: <1272903293.59.0.249639149559.issue8605@psf.upfronthosting.co.za>
Message-ID: <1272903293.59.0.249639149559.issue8605@psf.upfronthosting.co.za>


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

I now get the following failures in test_gdb:

======================================================================
FAIL: test_pyup_command (test.test_gdb.StackNavigationTests)
Verify that the "py-up" command works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 599, in test_pyup_command
    $''')
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 163, in assertMultilineMatches
    msg='%r did not match %r' % (actual, pattern))
AssertionError: 'Breakpoint 1 at 0x4508a0: file Objects/object.c, line 330.\n\nBreakpoint 1, PyObject_Print (op=42, fp=0x7ffff7535780, flags=1) at Objects/object.c:330\n330\t\treturn internal_print(op, fp, flags, 0);\n#7 (unable to read python frame information)\n' did not match '^.*\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 7, in bar \\(a=1, b=2, c=3\\)\n    baz\\(a, b, c\\)\n$'

======================================================================
FAIL: test_up_at_top (test.test_gdb.StackNavigationTests)
Verify handling of "py-up" at the top of the stack
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 613, in test_up_at_top
    cmds_after_breakpoint=['py-up'] * 4)
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 129, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: 'Error occurred in Python command.\nError occurred in Python command.\n' != ''

======================================================================
FAIL: test_up_then_down (test.test_gdb.StackNavigationTests)
Verify "py-up" followed by "py-down"
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 628, in test_up_then_down
    $''')
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 163, in assertMultilineMatches
    msg='%r did not match %r' % (actual, pattern))
AssertionError: 'Breakpoint 1 at 0x4508a0: file Objects/object.c, line 330.\n\nBreakpoint 1, PyObject_Print (op=42, fp=0x7ffff7535780, flags=1) at Objects/object.c:330\n330\t\treturn internal_print(op, fp, flags, 0);\n#7 (unable to read python frame information)\n#3 Frame 0x805700, for file /home/antoine/cpython/__svn__/Lib/test/gdb_sample.py, line 10, in baz (args=(1, 2, 3))\n    print(42)\n' did not match '^.*\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 7, in bar \\(a=1, b=2, c=3\\)\n    baz\\(a, b, c\\)\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 10, in baz \\(args=\\(1, 2, 3\\)\\)\n    print\\(42\\)\n$'

======================================================================
FAIL: test_basic_command (test.test_gdb.PyBtTests)
Verify that the "py-bt" command works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 634, in test_basic_command
    cmds_after_breakpoint=['py-bt'])
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 129, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: 'Error occurred in Python command.\n' != ''

======================================================================
FAIL: test_print_after_up (test.test_gdb.PyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 658, in test_print_after_up
    r".*\nlocal 'c' = 3\nlocal 'b' = 2\nlocal 'a' = 1\n.*")
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 163, in assertMultilineMatches
    msg='%r did not match %r' % (actual, pattern))
AssertionError: 'Breakpoint 1 at 0x4508a0: file Objects/object.c, line 330.\n\nBreakpoint 1, PyObject_Print (op=42, fp=0x7ffff7535780, flags=1) at Objects/object.c:330\n330\t\treturn internal_print(op, fp, flags, 0);\n#7 (unable to read python frame information)\nUnable to read information on python frame\nUnable to read information on python frame\nUnable to read information on python frame\n' did not match ".*\\nlocal 'c' = 3\\nlocal 'b' = 2\\nlocal 'a' = 1\\n.*"

======================================================================
FAIL: test_locals_after_up (test.test_gdb.PyLocalsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 684, in test_locals_after_up
    r".*\na = 1\nb = 2\nc = 3\n.*")
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 163, in assertMultilineMatches
    msg='%r did not match %r' % (actual, pattern))
AssertionError: 'Breakpoint 1 at 0x4508a0: file Objects/object.c, line 330.\n\nBreakpoint 1, PyObject_Print (op=42, fp=0x7ffff7535780, flags=1) at Objects/object.c:330\n330\t\treturn internal_print(op, fp, flags, 0);\n#7 (unable to read python frame information)\nUnable to read information on python frame\n' did not match '.*\\na = 1\\nb = 2\\nc = 3\\n.*'

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


Basically, it seems the Python API for gdb is a bit unstable or changing. Here is what manually trying the new commands produces:

(gdb) py-bt 
#4 (unable to read python frame information)
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 1341, in invoke
    frame.print_summary()
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 1195, in print_summary
    pyop = self.get_pyop()
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 1168, in get_pyop
    return PyFrameObjectPtr.from_pyobject_ptr(f)
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 349, in from_pyobject_ptr
    return cls(gdbval)
TypeError: __init__() takes exactly 3 arguments (2 given)
Error occurred in Python command.

(gdb) py-up 
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 1309, in invoke
    move_in_stack(move_up=True)
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 1289, in move_in_stack
    iter_frame.print_summary()
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 1195, in print_summary
    pyop = self.get_pyop()
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 1168, in get_pyop
    return PyFrameObjectPtr.from_pyobject_ptr(f)
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 349, in from_pyobject_ptr
    return cls(gdbval)
TypeError: __init__() takes exactly 3 arguments (2 given)
Error occurred in Python command.


$ gdb --version
GNU gdb (GDB) 7.1-1mdv2010.1 (Mandriva Linux release 2010.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-mandriva-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

----------
assignee: dmalcolm
components: Demos and Tools, Tests
messages: 104852
nosy: dmalcolm, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: gdb API issues
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon May  3 22:14:56 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 03 May 2010 20:14:56 +0000
Subject: [New-bugs-announce] [issue8606] OSF  is not supported anymore
In-Reply-To: <1272917696.34.0.331615225862.issue8606@psf.upfronthosting.co.za>
Message-ID: <1272917696.34.0.331615225862.issue8606@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

OSF* platform seems to be pretty dead. We are moving it to unsupported state, as documented in PEP11.

The first phase is Python 3.2: Configure will fail win OSF* platforms. This configuration failure will be trvivially reversible.

If nobody stands up to take care of OSF*, support will be removed in Python 3.3.

Discussion:

http://mail.python.org/pipermail/python-dev/2010-April/099718.html

http://mail.python.org/pipermail/python-dev/2010-May/099899.html

----------
assignee: jcea
messages: 104875
nosy: jcea
priority: normal
severity: normal
stage: committed/rejected
status: open
title: OSF  is not supported anymore
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue May  4 02:25:09 2010
From: report at bugs.python.org (Robin Dunn)
Date: Tue, 04 May 2010 00:25:09 +0000
Subject: [New-bugs-announce] [issue8607] OSX: duplicate -arch flags in
	CFLAGS breaks sysconfig
In-Reply-To: <1272932709.85.0.263067973339.issue8607@psf.upfronthosting.co.za>
Message-ID: <1272932709.85.0.263067973339.issue8607@psf.upfronthosting.co.za>


New submission from Robin Dunn <robin at alldunn.com>:

In Python 2.7b1, building on OSX 10.6 with this configure command:

export CC=gcc-4.0
export CXX=g++-4.0
export MACOSX_DEPLOYMENT_TARGET=10.4
../configure \
	--with-universal-archs=32-bit \
	--enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk \
	--enable-framework 


Results in these lines in Makefile:

BASECFLAGS=	-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -fno-common -dynamic
CFLAGS=		$(BASECFLAGS) -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  $(OPT) $(EXTRA_CFLAGS)


Then later on in the build the sysconfig module uses the -arch flags in CFLAGS but is not able to find a match because of the extra set of values, and the build fails with this exception:

Traceback (most recent call last):
  File "./../Lib/site.py", line 542, in <module>
    main()
  File "./../Lib/site.py", line 521, in main
    addbuilddir()
  File "./../Lib/site.py", line 118, in addbuilddir
    s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
  File "/projects/Python-2.7b1/Lib/sysconfig.py", line 646, in get_platform
    "Don't know machine value for archs=%r"%(archs,))
ValueError: Don't know machine value for archs=('i386', 'i386', 'ppc', 'ppc')
make: *** [sharedmods] Error 1

----------
components: Build
messages: 104905
nosy: robind
priority: normal
severity: normal
status: open
title: OSX: duplicate -arch flags in CFLAGS breaks sysconfig
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue May  4 10:58:07 2010
From: report at bugs.python.org (Torsten Marek)
Date: Tue, 04 May 2010 08:58:07 +0000
Subject: [New-bugs-announce] [issue8608] fix_import prefixes "." to already
	relative imports
In-Reply-To: <1272963487.39.0.595362588306.issue8608@psf.upfronthosting.co.za>
Message-ID: <1272963487.39.0.595362588306.issue8608@psf.upfronthosting.co.za>


New submission from Torsten Marek <shlomme at gmx.net>:

The fixer for absolute -> relative imports prefixes "." to already relative imports, i.e. 

    from . import something

will be converted into 

    from .. import something

if something.py exists. This of course will raise an exception on import or introduce subtle bugs if something exists in ..

I've attached a patch against 2to3 head which addresses this problem.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: fix-no-prefix-relative-import.diff
keywords: patch
messages: 104914
nosy: shlomme
priority: normal
severity: normal
status: open
title: fix_import prefixes "." to already relative imports
type: behavior
Added file: http://bugs.python.org/file17196/fix-no-prefix-relative-import.diff

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

From report at bugs.python.org  Tue May  4 11:47:22 2010
From: report at bugs.python.org (Nico)
Date: Tue, 04 May 2010 09:47:22 +0000
Subject: [New-bugs-announce] [issue8609] itertools: problem with nested
	groupby, list()
In-Reply-To: <1272966442.26.0.576520629253.issue8609@psf.upfronthosting.co.za>
Message-ID: <1272966442.26.0.576520629253.issue8609@psf.upfronthosting.co.za>


New submission from Nico <nico.schloemer at gmail.com>:

Hi,

I ran into a bit of an unexpected issue here with itertools.

I need to say that I discovered itertools only recently, and that maybe my way of approaching the problem is "not what I want to do". If you think this may be the case, please let me know.

Anyway, the problem is the following:
I have a list of dictionaries, something like

[ { "a": 1, "b": 1, "c": 3 },
  { "a": 1, "b": 1, "c": 4 },
  ...
]

and I'd like to iterate through all items with, e.g., "a":1. What I do is sort and then groupby,

my_list.sort( key=operator.itemgetter('a') )
my_list_grouped = itertools.groupby( my_list, operator.itemgetter('a') )

and then just very simply iterate over my_list_grouped,

for my_item in my_list_grouped:
    # do something with my_item[0], my_item[1]

Now, inside this loop I'd like to again iterate over all items with the same 'b'-value -- no problem, just do the above inside the loop:

for my_item in my_list_grouped:
        # group by keyword "b"
        my_list2 = list( my_item[1] )
        my_list2.sort( key=operator.itemgetter('b') )
        my_list_grouped = itertools.groupby( my_list2, operator.itemgetter('b') )
        for e in my_list_grouped:
            # do something with e[0], e[1]

That seems to work all right.

Now, the problem occurs when this all is wrapped into an outer loop, such as

for k in [ 'first pass', 'second pass' ]:
    for my_item in my_list_grouped:
    # bla, the above

To be able to iterate more than once through my_list_grouped, I have to convert it into a list first, so outside all loops, I go like

my_list.sort( key=operator.itemgetter('a') )
my_list_grouped = itertools.groupby( my_list, operator.itemgetter('a') )
my_list_grouped = list( my_list_grouped )

This, however, makes it impossible to do the inner sort and groupby-operation; you just get the very first element, and that's it.

An example file is attached.

Is there anything that I can do to debug?

Cheers,
Nico

----------
components: None
files: iterator-test.py
messages: 104917
nosy: nicki
priority: normal
severity: normal
status: open
title: itertools: problem with nested groupby, list()
versions: Python 2.6
Added file: http://bugs.python.org/file17198/iterator-test.py

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

From report at bugs.python.org  Tue May  4 13:58:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 May 2010 11:58:58 +0000
Subject: [New-bugs-announce] [issue8610] Python3/POSIX: errors if file
	system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>


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

On POSIX (but not on Mac OS X), Python3 calls get_codeset() to get the file system encoding. If this function fails, sys.getfilesystemencoding() returns None.  PyUnicode_DecodeFSDefaultAndSize() fallbacks to utf-8 whereas subprocess fail:

  ...
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 670, in __init__
    restore_signals, start_new_session)
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 1101, in _execute_child
    executable_list = (fs_encode(executable),)
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 1088, in fs_encode
    return s.encode(fs_encoding, 'surrogateescape')
TypeError: encode() argument 1 must be string, not None

We have two choices: raise a fatal error if get_codeset() failed, or fallback to utf-8.

On Windows and Mac OS X, get_codeset() shouldn't be called because the result is just dropped. We should call _PyCodec_Lookup(Py_FileSystemDefaultEncoding) instead to ensure that the file system encoding can be loaded.

----------
components: Interpreter Core, Unicode
messages: 104924
nosy: haypo
priority: normal
severity: normal
status: open
title: Python3/POSIX:  errors if file system encoding is None
versions: Python 3.2

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

From report at bugs.python.org  Tue May  4 15:30:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 May 2010 13:30:50 +0000
Subject: [New-bugs-announce] [issue8611] Python3 doesn't support locale
	different than utf8 and an	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>


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

Python3 is unable to start (bootstrap failure) on a POSIX system if the locale encoding is different than utf8 and the Python path (standard library path where the encoding module is stored) contains a non-ASCII character. (Windows and Mac OS X are not affected by this issue because the file system encoding is hardcoded.)

 - Py_FileSystemDefaultEncoding == NULL
 - calculate_path(): sys.path is filled with directory names decoded with the locale encoding
 - find_module() encodes each path using PyUnicode_AsEncodedString(..., Py_FileSystemDefaultEncoding, NULL): use "utf-8" encoding because Py_FileSystemDefaultEncoding is NULL

=> error because the path is not encoded and decoded with the same encoding

We cannot encodes a path with the locale encoding because we need find_module() to load the encoding codec, and loading the codec needs find_module()... (bootstrap error :-))

We should decodes the path using a fixed encoding (eg. ASCII or utf-8), use the same encoding to encodes paths in find_module(), and then reencode paths of all objects storing filenames:

 - sys.path list items
 - sys.modules dict keys
 - sys.modules values: each module have __file__ and/or __path__ attributes
 - all code objects (co_filename)
 - (maybe some other?)

The error occurs in an early stage of Py_InitializeEx(), so the object list is limited and we control this list (eg. site is not loaded yet).

Related issues:
 - #8610: "Python3/POSIX:  errors if file system encoding is None"
 - #8242: "Improve support of PEP 383 (surrogates) in Python3: meta-issue"

----------
components: Interpreter Core, Unicode
messages: 104932
nosy: haypo
priority: normal
severity: normal
status: open
title: Python3 doesn't support locale different than utf8 and an non-ASCII path (POSIX)
versions: Python 3.2

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

From report at bugs.python.org  Tue May  4 16:17:15 2010
From: report at bugs.python.org (Zaar Hai)
Date: Tue, 04 May 2010 14:17:15 +0000
Subject: [New-bugs-announce] [issue8612] multiprocessing Queue module failes
	to send INIConfig	objects
In-Reply-To: <1272982635.61.0.958839100699.issue8612@psf.upfronthosting.co.za>
Message-ID: <1272982635.61.0.958839100699.issue8612@psf.upfronthosting.co.za>


New submission from Zaar Hai <haizaar at gmail.com>:

I'm using INIConfig class from iniparse module(http://code.google.com/p/iniparse).
I've tried to use multiprocessing.Queue to propagate 
configuration changes between the processes. However, INIConfig instances 
have troubles being pushed through Queue objects.

I do not know whether this is a Queue or iniparse bug, so I've opened issued on both projects(http://code.google.com/p/iniparse/issues/detail?id=20). Even this is not a Queue bug, it would be great to have some advice on how this problem may be solved. Thanks.

Problem description:

Running this simple code:

from multiprocessing import Process
from multiprocessing import Queue
from iniparse import INIConfig
import time

def worker(queue):
    config = queue.get()
    print config.sec1.var1

def main():
    config = INIConfig(open("./my.conf"))
    queue = Queue()
    p = Process(target=worker, args=(queue,))
    p.start()
    queue.put(config)
    time.sleep(1)

if __name__ == "__main__":
    main()

Raised this error:
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.5/multiprocessing/queues.py", line 242, in _feed
    send(obj)
TypeError: 'Undefined' object is not callable

The contents of my.conf are like this:
[sec1]
var1 = test1
var2 = test2

I'm using python 2.5.2 on Debian Lenny amd64 with python-multiprocessing package (http://packages.debian.org/squeeze/python-multiprocessing).

----------
components: None
messages: 104942
nosy: Zaar.Hai
priority: normal
severity: normal
status: open
title: multiprocessing Queue module failes to send INIConfig objects
versions: Python 2.5

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

From report at bugs.python.org  Tue May  4 16:54:01 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 May 2010 14:54:01 +0000
Subject: [New-bugs-announce] [issue8613] Decimal module flags undetermined
	when a signal is	trapped.
In-Reply-To: <1272984841.0.0.906657038884.issue8613@psf.upfronthosting.co.za>
Message-ID: <1272984841.0.0.906657038884.issue8613@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

In an effort to keep to one issue per tracker item, I'm pulling this issue out of the comments on issue 8567.

Issue:  if a Decimal operation raises several signals, and one or more of those signals is trapped, how should that operation affect flags?

Decimal currently ends up setting some or none of those flags, depending on exactly which signal is trapped first.

Stefan points out that cdecimal and decnumber both treat all operations as atomic:  *all* flags relevant to that operation are set, and only then are any traps acted on.

The specification isn't clear on this.  At http://speleotrove.com/decimal/daexcep.html it says:

"""The value of the trap-enabler for each signal in the context determines whether an operation is completed after the condition is detected or whether the condition is trapped and hence not necessarily completed (see IEEE 754 ?7 and ?8)."""

There's also this (thanks, Stefan), in http://speleotrove.com/decimal/damodel.html

"""For each of the signals, the corresponding flag is set to 1 when the signal occurs. It is only reset to 0 by explicit user action."""

However, this doesn't really help: do we regard signals as being raised one-by-one during (or at the end of) an operation, or all at once?  And should a trap take effect the moment a signal is handled, or should all traps be delayed until the end of an operation?

----------
assignee: mark.dickinson
messages: 104945
nosy: facundobatista, mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
stage: unit test needed
status: open
title: Decimal module flags undetermined when a signal is trapped.
type: behavior

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

From report at bugs.python.org  Tue May  4 20:18:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 May 2010 18:18:04 +0000
Subject: [New-bugs-announce] [issue8614] test_gzip fails on OS X
In-Reply-To: <1272997084.97.0.485599300068.issue8614@psf.upfronthosting.co.za>
Message-ID: <1272997084.97.0.485599300068.issue8614@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

test_buffered_reader test_gzip is failing for me since r80720, on trunk on OS X 10.6.3:

======================================================================
ERROR: test_buffered_reader (__main__.TestGzip)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_gzip.py", line 91, in test_buffered_reader
    lines = [line for line in r]
  File "/Users/dickinsm/python/svn/trunk/Lib/gzip.py", line 365, in flush
    self.fileobj.flush()
IOError: [Errno 9] Bad file descriptor

----------------------------------------------------------------------
Ran 16 tests in 1.258s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_gzip.py", line 271, in <module>
    test_main(verbose=True)
  File "Lib/test/test_gzip.py", line 268, in test_main
    test_support.run_unittest(TestGzip)
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_support.py", line 1038, in run_unittest
    _run_suite(suite)
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_support.py", line 1021, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_gzip.py", line 91, in test_buffered_reader
    lines = [line for line in r]
  File "/Users/dickinsm/python/svn/trunk/Lib/gzip.py", line 365, in flush
    self.fileobj.flush()
IOError: [Errno 9] Bad file descriptor


Here's a minimal Python script that produces the failure:

import gzip
import io

f = gzip.GzipFile('hamster', 'wb')
f.write("some data")
f.close()

f = gzip.GzipFile('hamster', 'rb')
r = io.BufferedReader(f)
lines = [line for line in r]
r.close()

This gives the following output:

Traceback (most recent call last):
  File "test_gzip.py", line 11, in <module>
    r.close()
  File "/Users/dickinsm/python/svn/trunk/Lib/gzip.py", line 365, in flush
    self.fileobj.flush()
IOError: [Errno 9] Bad file descriptor
[20213 refs]

----------
components: Library (Lib)
messages: 104965
nosy: mark.dickinson, pitrou
priority: normal
severity: normal
status: open
title: test_gzip fails on OS X
versions: Python 2.7

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

From report at bugs.python.org  Tue May  4 23:14:59 2010
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 04 May 2010 21:14:59 +0000
Subject: [New-bugs-announce] [issue8615] turtle.py - backport of 3.1 features
In-Reply-To: <1273007699.22.0.180641297375.issue8615@psf.upfronthosting.co.za>
Message-ID: <1273007699.22.0.180641297375.issue8615@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

The file submitted, turtle.py, essentially contains a backport of the new features, which were added to the turtle module with Python 3.1.
Otherwise this versions is 100% compatible with the turtle module of Python 2.6. 
So scripts written with Python 3.1's turtle module will run unchanged with identical behaviour under Python 2.7. The same do - of course - scripts written with Python 2.6's version of the turtle module.

Remark: There were also some enhancements and cleanup in the code for Python 3.1, which I also did backport to this version. 

Inclusion of this version of turtle.py into Python 2.7 will need an update of the docs (essentially to those of Python 3.1). I'll be able to submit an appropriate *.rst file within a week or so.

----------
components: Library (Lib)
files: turtle.py
messages: 104975
nosy: georg.brandl, gregorlingl, loewis
priority: normal
severity: normal
status: open
title: turtle.py - backport of 3.1 features
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file17206/turtle.py

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

From report at bugs.python.org  Tue May  4 23:32:10 2010
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 04 May 2010 21:32:10 +0000
Subject: [New-bugs-announce] [issue8616] Changes to content of Demo/turtle
In-Reply-To: <1273008730.8.0.105084103886.issue8616@psf.upfronthosting.co.za>
Message-ID: <1273008730.8.0.105084103886.issue8616@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

turtleDemo.py contains a string referring to the outdated xturtle.
Should be replaced according to the submitted diff.

Moreover I'd like to propose to add to demo-scripts to the Demo-directory, namely tdemo_nim.py and tdemo_round_dance.py as well as to replace the old tdemo_paint.py by the enhanced version tdemo_scribble.py. I'll add those files subsequently.
Regards,
Gregor

----------
components: Demos and Tools
files: turtleDemo_27b1_to_turtleDemo.diff
keywords: patch
messages: 104977
nosy: georg.brandl, gregorlingl, loewis
priority: normal
severity: normal
status: open
title: Changes to content of Demo/turtle
versions: Python 2.7
Added file: http://bugs.python.org/file17208/turtleDemo_27b1_to_turtleDemo.diff

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

From report at bugs.python.org  Wed May  5 01:51:20 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Tue, 04 May 2010 23:51:20 +0000
Subject: [New-bugs-announce] [issue8617] Non-existent variables documented
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

http://docs.python.org/library/site.html#module-site mentions two variables that don't appear in my Python 2.6.5 installation's site module:

PYTHONNOUSERSITE
New in version 2.6.

PYTHONUSERBASE
New in version 2.6.

----------
assignee: docs at python
components: Documentation
messages: 104985
nosy: dabrahams, docs at python
priority: normal
severity: normal
status: open
title: Non-existent variables documented
versions: Python 2.6

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

From report at bugs.python.org  Wed May  5 02:23:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 05 May 2010 00:23:20 +0000
Subject: [New-bugs-announce] [issue8618] test_winsound failing on Windows
	Server 2008
In-Reply-To: <1273019000.91.0.843326391671.issue8618@psf.upfronthosting.co.za>
Message-ID: <1273019000.91.0.843326391671.issue8618@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

Some of the test_alias_* functions in test_winsound are failing with a RuntimeError "Failed to play sound" when run on Server 2008 R2. 

The sound from each test exists in the registry so the test doesn't end up getting skipped. I'm guessing there is some missing privilege, so it's possible we should additionally skip based on that.

----------
assignee: brian.curtin
components: Tests, Windows
messages: 104988
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: test_winsound failing on Windows Server 2008
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed May  5 05:43:03 2010
From: report at bugs.python.org (Sriram Thaiyar)
Date: Wed, 05 May 2010 03:43:03 +0000
Subject: [New-bugs-announce] [issue8619] Doc bug for
	urllib.request._urlopener in Python 3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>


New submission from Sriram Thaiyar <sriram.thaiyar at gmail.com>:

http://docs.python.org/dev/py3k/library/urllib.request.html#urllib.request._urlopener

[in the body]
urllib._urlopener should be urllib.request._urlopener

----------
assignee: docs at python
components: Documentation
messages: 104998
nosy: Sriram.Thaiyar, docs at python
priority: normal
severity: normal
status: open
title: Doc bug for urllib.request._urlopener in Python 3.1+
versions: Python 3.1

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

From report at bugs.python.org  Wed May  5 13:35:55 2010
From: report at bugs.python.org (Mattelaer)
Date: Wed, 05 May 2010 11:35:55 +0000
Subject: [New-bugs-announce] [issue8620] wrong truncation of line in Cmd.cmd
In-Reply-To: <1273059355.74.0.713627995995.issue8620@psf.upfronthosting.co.za>
Message-ID: <1273059355.74.0.713627995995.issue8620@psf.upfronthosting.co.za>


New submission from Mattelaer <olivier.mattelaer at uclouvain.be>:

When using the Cmd module on a file. 
it happens that the last line is truncated from the last caracther.

The problem is simply that it can happen that the last line doesn't finish by '\n' charcacter. In consequence the line which is suppose to suppress the '\n' suppress another character.

Cheers,

Olivier

----------
components: None
messages: 105012
nosy: omatt
priority: normal
severity: normal
status: open
title: wrong truncation of line in Cmd.cmd
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed May  5 14:00:58 2010
From: report at bugs.python.org (yig)
Date: Wed, 05 May 2010 12:00:58 +0000
Subject: [New-bugs-announce] [issue8621] Mac OS X
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>


New submission from yig <yotam at yotamgingold.com>:

Calling uuid.uuid4() while using the multiprocessing module leads to the same exact UUIDs being generating in each process.  It is an artifact resulting from the built-in uuid_generate_random() of my underlying platform, Mac OS X 10.6.3.  A Linux machine I have does not exhibit this problem.  I have tested it with both Python 2.5 and 2.6.

----------
assignee: ronaldoussoren
components: Macintosh
files: multiprocessing_uuid.py
messages: 105013
nosy: ronaldoussoren, yig
priority: normal
severity: normal
status: open
title: Mac OS X
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file17216/multiprocessing_uuid.py

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

From report at bugs.python.org  Wed May  5 15:55:25 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 05 May 2010 13:55:25 +0000
Subject: [New-bugs-announce] [issue8622] Add PYTHONFSENCODING environment
	variable
In-Reply-To: <1273067725.01.0.392024082724.issue8622@psf.upfronthosting.co.za>
Message-ID: <1273067725.01.0.392024082724.issue8622@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

As discussed on issue8610, we need a way to override the automatic detection of the file system encoding - for much the same reasons we also do for the I/O encoding: the detection mechanism isn't fail-safe.

We should add a new environment variable with the same functionality as PYTHONIOENCODING:

    PYTHONFSENCODING: Encoding[:errors] used for file system.

----------
components: Interpreter Core
messages: 105030
nosy: haypo, lemburg
priority: normal
severity: normal
status: open
title: Add PYTHONFSENCODING environment variable
versions: Python 3.2

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

From report at bugs.python.org  Wed May  5 15:57:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 13:57:36 +0000
Subject: [New-bugs-announce] [issue8623] Aliasing warnings in socketmodule.c
In-Reply-To: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za>
Message-ID: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za>


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

This is on py3k, with gcc 4.4.3:

/home/antoine/py3k/__svn__/Modules/socketmodule.c: In function 'socket_gethostbyaddr':
/home/antoine/py3k/__svn__/Modules/socketmodule.c:3238: warning: dereferencing pointer 'sa' does break strict-aliasing rules
/home/antoine/py3k/__svn__/Modules/socketmodule.c:3208: note: initialized from here
/home/antoine/py3k/__svn__/Modules/socketmodule.c: In function 'socket_gethostbyname_ex':
/home/antoine/py3k/__svn__/Modules/socketmodule.c:3183: warning: dereferencing pointer 'sa' does break strict-aliasing rules
/home/antoine/py3k/__svn__/Modules/socketmodule.c:3181: note: initialized from here

----------
components: Extension Modules
messages: 105033
nosy: brett.cannon, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Aliasing warnings in socketmodule.c
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed May  5 15:58:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 13:58:54 +0000
Subject: [New-bugs-announce] [issue8624] Aliasing warnings in
	multiprocessing.c
In-Reply-To: <1273067934.7.0.859212268784.issue8624@psf.upfronthosting.co.za>
Message-ID: <1273067934.7.0.859212268784.issue8624@psf.upfronthosting.co.za>


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

This is on py3k, with gcc 4.4.3:

/home/antoine/py3k/__svn__/Modules/_multiprocessing/multiprocessing.c: In function 'multiprocessing_sendfd':
/home/antoine/py3k/__svn__/Modules/_multiprocessing/multiprocessing.c:125: warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/antoine/py3k/__svn__/Modules/_multiprocessing/multiprocessing.c: In function 'multiprocessing_recvfd':
/home/antoine/py3k/__svn__/Modules/_multiprocessing/multiprocessing.c:168: warning: dereferencing type-punned pointer will break strict-aliasing rules

----------
assignee: jnoller
components: Extension Modules
messages: 105034
nosy: brett.cannon, jnoller, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Aliasing warnings in multiprocessing.c
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed May  5 16:03:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 14:03:49 +0000
Subject: [New-bugs-announce] [issue8625] --with-pydebug builds now include
	-O2 by default
In-Reply-To: <1273068229.98.0.576087123255.issue8625@psf.upfronthosting.co.za>
Message-ID: <1273068229.98.0.576087123255.issue8625@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

When doing a debug build of Python with gcc, without any previous setting of CFLAGS, the '-O2' flag is now automatically included.

This behaviour started in r79218.

It would be nice to restore the original behaviour, if possible, since the optimization causes difficulties when debugging.  One solution would be to add '-O0' to OPT for debug builds (on gcc), as in the attached patch.  You then get compiler flags including:

"-g -O2 -g -O0"

which is somewhat ugly, but the -O0 overrides the -O2 (I think).  Does this seem like a reasonable solution?

----------
components: Build
files: no_debug_optimization.patch
keywords: patch
messages: 105035
nosy: haypo, lemburg, mark.dickinson, pitrou
priority: normal
severity: normal
status: open
title: --with-pydebug builds now include -O2 by default
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17219/no_debug_optimization.patch

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

From report at bugs.python.org  Wed May  5 16:28:11 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Wed, 05 May 2010 14:28:11 +0000
Subject: [New-bugs-announce] [issue8626] TypeError: rsplit() takes no
	keyword arguments
In-Reply-To: <1273069691.09.0.629182954336.issue8626@psf.upfronthosting.co.za>
Message-ID: <1273069691.09.0.629182954336.issue8626@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

Based on the rsplit documentation, I'd expect

  'foo bar'.rsplit(maxsplit=1)

to work.  This is probably a much bigger problem than just rsplit, i.e. I doubt there is a policy about whether documented parameter names need to be usable as keywords, and if not, how one finds out which keywords are supported.

----------
messages: 105040
nosy: dabrahams
priority: normal
severity: normal
status: open
title: TypeError: rsplit() takes no keyword arguments

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

From report at bugs.python.org  Wed May  5 16:30:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 14:30:56 +0000
Subject: [New-bugs-announce] [issue8627] Unchecked PyErr_WarnPy3k return
	value in	Objects/typeobject.c
In-Reply-To: <1273069856.93.0.435136167669.issue8627@psf.upfronthosting.co.za>
Message-ID: <1273069856.93.0.435136167669.issue8627@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Lines 3884 and 3890 of Objects/typeobject.c (trunk, r80782), which check for a subclass overriding __eq__ (or __cmp__) but not __hash__, call PyErr_WarnPy3k but don't check the return value.  [This was reported when compiling Python with clang.] This can lead to an "XXX undetected error", if the warning actually raised an exception:

newton:trunk dickinsm$ ./python.exe -3
Python 2.7b1+ (trunk:80783, May  5 2010, 15:25:42) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
[35022 refs]
>>> warnings.filterwarnings("error")
[35046 refs]
>>> class A(object):
...     def __eq__(self, other):
...         return False
... 
XXX undetected error
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
DeprecationWarning: Overriding __eq__ blocks inheritance of __hash__ in 3.x
[35139 refs]

Nick, I think this came from a checkin of yours: r65642, related to issue 2235.  Any suggestions about how to fix it?  It's a bit tricky, since the function the check occurs in (inherit_slots) has return type 'void'.  Is it okay if I change inherit_slots to return an int here?  If so, I'll produce a patch.

Also, can we remove the check related to __hash__ and __cmp__?  With __cmp__ gone in 3.1, and 3.0 considered defunct, I don't think it's relevant any more.

----------
messages: 105041
nosy: mark.dickinson, ncoghlan
priority: normal
severity: normal
status: open
title: Unchecked PyErr_WarnPy3k return value in Objects/typeobject.c
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed May  5 17:11:51 2010
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 05 May 2010 15:11:51 +0000
Subject: [New-bugs-announce] [issue8628] Incorrect numbers.Complex.imag
	documentation
In-Reply-To: <1273072311.36.0.918807999354.issue8628@psf.upfronthosting.co.za>
Message-ID: <1273072311.36.0.918807999354.issue8628@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

The current documentation of the imag abstract property of numbers.Complex is this:
"Abstract. Retrieves the Real component of this number."
Of course the imag attribute is the imaginary component, not the real.

----------
assignee: docs at python
components: Documentation
messages: 105048
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: Incorrect numbers.Complex.imag documentation
versions: Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed May  5 18:20:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 16:20:39 +0000
Subject: [New-bugs-announce] [issue8629] Fix test_ssl failures under 2.6/3.1
	with OpenSSL 1.0.0
In-Reply-To: <1273076439.97.0.920291482414.issue8629@psf.upfronthosting.co.za>
Message-ID: <1273076439.97.0.920291482414.issue8629@psf.upfronthosting.co.za>


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

OpenSSL 1.0.0 needs to change the cipher list for some test_ssl tests to succeed, but the cipher list can't be changed in 2.6/3.1 (maintenance branches). The solution is to skip these tests with the newer OpenSSLs.

This patch uses the "openssl" executable to fetch the OpenSSL version, but we could instead backport OPENSSL_VERSION_* from trunk, at least as  undocumented attributes. What do you think?

----------
components: Tests
files: sslfix.patch
keywords: patch
messages: 105055
nosy: giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Fix test_ssl failures under 2.6/3.1 with OpenSSL 1.0.0
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file17224/sslfix.patch

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

From report at bugs.python.org  Wed May  5 18:38:15 2010
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_M=2E_C=2E_Campos?=)
Date: Wed, 05 May 2010 16:38:15 +0000
Subject: [New-bugs-announce] [issue8630] Keepends param in codec readline(s)
In-Reply-To: <1273077495.73.0.386813094956.issue8630@psf.upfronthosting.co.za>
Message-ID: <1273077495.73.0.386813094956.issue8630@psf.upfronthosting.co.za>


New submission from Andr? M. C. Campos <amccampos at gmail.com>:

Some methods in StreamReaderWriter class (codecs library) has different signatures from StreamReader methods. More precisely it's missing the keepends parameter in readline and readlines methods.

So, we cannot code:
fp = codecs.open(fileName, "r", "utf-8")
lines = fp.readlines(keepends=False)
or
line = fp.readline(keepends=False)

----------
components: Library (Lib)
messages: 105056
nosy: amccampos
priority: normal
severity: normal
status: open
title: Keepends param in codec readline(s)
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed May  5 23:45:06 2010
From: report at bugs.python.org (Alex Quinn)
Date: Wed, 05 May 2010 21:45:06 +0000
Subject: [New-bugs-announce] [issue8631] subprocess.Popen.communicate(...)
	hangs on Windows
In-Reply-To: <1273095906.37.0.582736332431.issue8631@psf.upfronthosting.co.za>
Message-ID: <1273095906.37.0.582736332431.issue8631@psf.upfronthosting.co.za>


New submission from Alex Quinn <aq2009 at alexquinn.org>:

After using subprocess.Popen(...).communicate(), the session hangs.

c:\>python31
Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from subprocess import Popen, PIPE
>>> Popen(["echo","Hello!"], stdout=PIPE).communicate()[0]
b'Hello!\n'
>>>

At this point, the session stops responding to keyboard input.



=========================================
MORE DETAILS:

Neither Ctrl-C, Ctrl-Z, nor Ctrl-D will break out of it, but Ctrl-Break does break out of it.

The task manager shows no CPU activity for the process.

I've seen problem with Python v3.1.2 and v2.6.1 on Windows 7.

It works fine under Linux:

$ python3.1
Python 3.1 (r31:73572, Mar 22 2010, 14:57:00)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-11)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from subprocess import Popen, PIPE
>>> Popen(["echo","Hello!"], stdout=PIPE).communicate()[0]
b'Hello!\n'
>>> print("No problems under Linux")
No problems under Linux
>>>

Is this bug type "crash" or "behavior"?  I went with the former, since it ends the usable Python session.

----------
components: IO, Library (Lib), Windows
messages: 105088
nosy: Alex Quinn
priority: normal
severity: normal
status: open
title: subprocess.Popen.communicate(...) hangs on Windows
type: crash
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Thu May  6 00:04:25 2010
From: report at bugs.python.org (Alex Quinn)
Date: Wed, 05 May 2010 22:04:25 +0000
Subject: [New-bugs-announce] [issue8632] subprocess doesn't handle Windows
	built-in commands as	os.system() does
In-Reply-To: <1273097065.69.0.229964904727.issue8632@psf.upfronthosting.co.za>
Message-ID: <1273097065.69.0.229964904727.issue8632@psf.upfronthosting.co.za>


New submission from Alex Quinn <aq2009 at alexquinn.org>:

The documentation says subprocess replaces os.system().  However, subprocess does not handle built-in Windows shell commands as os.system() does.

Works:
- os.system("dir /w")
- subprocess.Popen("cmd /c dir /w", stdout=subprocess.PIPE).communicate()[0]

Does NOT work:
- Popen("dir /w", stdout=PIPE).communicate()[0]
- Popen(["dir", "/w"], stdout=PIPE).communicate()[0]

Examples:
s:\d>python31
Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from subprocess import Popen, PIPE
>>> Popen(["cmd", "/c", "dir", "/w"], stdout=PIPE).communicate()[0]
   .....  (WORKED)
>>> Popen(["dir", "/w"], stdout=PIPE).communicate()[0]
dir: cannot access /w: No such file or directory
b''       (DIDN'T WORK)
>>>

----------
components: IO, Library (Lib), Windows
messages: 105091
nosy: Alex Quinn
priority: normal
severity: normal
status: open
title: subprocess doesn't handle Windows built-in commands as os.system() does
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu May  6 00:14:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 22:14:51 +0000
Subject: [New-bugs-announce] [issue8633] tarfile doesn't support undecodable
	filename in PAX format
In-Reply-To: <1273097691.15.0.651636064492.issue8633@psf.upfronthosting.co.za>
Message-ID: <1273097691.15.0.651636064492.issue8633@psf.upfronthosting.co.za>


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

tarfile is unable to open a TAR archive in PAX format embedding invalid filenames (filename not encoded in utf8, an undecodable filename). Attached file is an example (contain the file b'z/\xff', not decodable from utf8).

PAX specification has a "invalid" option with 4 values: bypass (default), rename, UTF-8, write.
http://www.opengroup.org/onlinepubs/009695399/utilities/pax.html

As it was done for other formats in issue #8390, PAX can use Python surrogateescape error handler to store undecodable bytes as unicode surrogates.

I think that PAX should be strict by default, but have an option to enable surrogateescape mode.

----------
components: Library (Lib)
files: z-pax.tar
messages: 105094
nosy: haypo, lars.gustaebel, loewis
priority: normal
severity: normal
status: open
title: tarfile doesn't support undecodable filename in PAX format
versions: Python 3.2
Added file: http://bugs.python.org/file17230/z-pax.tar

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

From report at bugs.python.org  Thu May  6 10:09:27 2010
From: report at bugs.python.org (Benjamin VENELLE)
Date: Thu, 06 May 2010 08:09:27 +0000
Subject: [New-bugs-announce] [issue8634] [PATCH] get method for dbm interface
In-Reply-To: <1273133367.38.0.142877532423.issue8634@psf.upfronthosting.co.za>
Message-ID: <1273133367.38.0.142877532423.issue8634@psf.upfronthosting.co.za>


New submission from Benjamin VENELLE <kain94 at gmail.com>:

I'm suggesting to add the dict's 'get' method to dbm interface. So that, it would be easier to manage 'key not found' issues.

B. Venelle.

----------
components: Library (Lib)
messages: 105130
nosy: Kain94
priority: normal
severity: normal
status: open
title: [PATCH] get method for dbm interface
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu May  6 15:16:04 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 06 May 2010 13:16:04 +0000
Subject: [New-bugs-announce] [issue8635] enumerate() docstring doesn't cover
	optional start	argument
In-Reply-To: <1273151764.64.0.669433681589.issue8635@psf.upfronthosting.co.za>
Message-ID: <1273151764.64.0.669433681589.issue8635@psf.upfronthosting.co.za>


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

As noted in the comments for issue 2831, the enumerate docstring doesn't cover the feature added by that patch.

----------
components: Interpreter Core
keywords: easy
messages: 105144
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: enumerate() docstring doesn't cover optional start argument
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu May  6 15:48:19 2010
From: report at bugs.python.org (Scott Dial)
Date: Thu, 06 May 2010 13:48:19 +0000
Subject: [New-bugs-announce] [issue8636] enumerate() test cases do not cover
	optional start	argument
In-Reply-To: <1273153699.94.0.112049339171.issue8636@psf.upfronthosting.co.za>
Message-ID: <1273153699.94.0.112049339171.issue8636@psf.upfronthosting.co.za>


New submission from Scott Dial <scott at scottdial.com>:

The issue2831 patch test cases are not actually being run by test_enumerate and they were broken tests anyways. This patch fixes the brokenness.

----------
components: Interpreter Core, Tests
files: test_enumerate.patch
keywords: patch
messages: 105147
nosy: scott.dial
priority: normal
severity: normal
status: open
title: enumerate() test cases do not cover optional start argument
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17237/test_enumerate.patch

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

From report at bugs.python.org  Thu May  6 17:33:46 2010
From: report at bugs.python.org (Justin Bronder)
Date: Thu, 06 May 2010 15:33:46 +0000
Subject: [New-bugs-announce] [issue8637] [PATCH] pydoc should respect
	MANPAGER over PAGER.
In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za>
Message-ID: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za>


New submission from Justin Bronder <jsbronder at gentoo.org>:

Similar to man(1), pydoc should respect the environment variable MANPAGER over PAGER.  The current behavior causes issues when using a PAGER that does not support man pages.

Patch based off of trunk, r80871

----------
components: Library (Lib)
files: python-2.7-pydoc-manpager.patch
keywords: patch
messages: 105151
nosy: jsbronder
priority: normal
severity: normal
status: open
title: [PATCH] pydoc should respect MANPAGER over PAGER.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17238/python-2.7-pydoc-manpager.patch

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

From report at bugs.python.org  Thu May  6 22:00:32 2010
From: report at bugs.python.org (Lucian Ursu)
Date: Thu, 06 May 2010 20:00:32 +0000
Subject: [New-bugs-announce] [issue8638] Remove suggestion for name mangling
	from the tutorial
In-Reply-To: <1273176032.85.0.0243971489868.issue8638@psf.upfronthosting.co.za>
Message-ID: <1273176032.85.0.0243971489868.issue8638@psf.upfronthosting.co.za>


New submission from Lucian Ursu <lucian_ursu at yahoo.com>:

I suggest that name mangling should not be recommended as a way of having private attributes. Instead, one underscore should be suggested as a signal that the attribute is private.
This suggestion comes after discussing with some of the helpers from #python. Basically, they said that name mangling should never be used, so it would be appropriate to remove this recommendation from the tutorial.

----------
assignee: docs at python
components: Documentation
messages: 105161
nosy: LucianU, docs at python
priority: normal
severity: normal
status: open
title: Remove suggestion for name mangling from the tutorial
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Thu May  6 23:58:30 2010
From: report at bugs.python.org (George Sakkis)
Date: Thu, 06 May 2010 21:58:30 +0000
Subject: [New-bugs-announce] [issue8639] Allow callable objects in
	inspect.getargspec
In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>
Message-ID: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>


New submission from George Sakkis <george.sakkis at gmail.com>:

Not sure if this has been brought before but how about extending  getargspec to work with callable instances, i.e. make it equivalent to getargspec(obj.__call__) ?

----------
components: Library (Lib)
messages: 105166
nosy: gsakkis
priority: normal
severity: normal
status: open
title: Allow callable objects in inspect.getargspec
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri May  7 00:45:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 22:45:17 +0000
Subject: [New-bugs-announce] [issue8640] subprocess: add envb argument to
	Popen constructor	(Python3, POSIX only)
In-Reply-To: <1273185917.08.0.761086865943.issue8640@psf.upfronthosting.co.za>
Message-ID: <1273185917.08.0.761086865943.issue8640@psf.upfronthosting.co.za>


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

Python 3.2 has now its os.environb, the bytes version of os.environ. subprocess should get a new envb argument to be able to use pure bytes environmental variables. Examples:

   subprocess.call([b'env], envb={b'PATH': b'/usr/bin'})

and

   envb = os.environb.copy()
   envb[b'PATH'] = b'/usr/bin'
   subprocess.call([b'env], envb=envb)

Specify both env and envb would raise an exception. envb should only be available on POSIX (as os.environb).

Related issues: #8513 (subprocess: support bytes program name) and #8603 (os.environb).

----------
components: Library (Lib), Unicode
messages: 105168
nosy: haypo
priority: normal
severity: normal
status: open
title: subprocess: add envb argument to Popen constructor (Python3, POSIX only)
versions: Python 3.2

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

From report at bugs.python.org  Fri May  7 08:16:34 2010
From: report at bugs.python.org (Puzzlet Chung)
Date: Fri, 07 May 2010 06:16:34 +0000
Subject: [New-bugs-announce] [issue8641] IDLE 3 doesn't highlights b"",
	but u""
In-Reply-To: <1273212994.94.0.428777321336.issue8641@psf.upfronthosting.co.za>
Message-ID: <1273212994.94.0.428777321336.issue8641@psf.upfronthosting.co.za>


New submission from Puzzlet Chung <puzzlet at gmail.com>:

IDLE 3.1.2 doesn't highlight b"" syntax, instead highlights u"".

Tested with IDLE (x86) 3.1.2 and Windows XP SP2.

----------
components: IDLE
messages: 105184
nosy: puzzlet
priority: normal
severity: normal
status: open
title: IDLE 3 doesn't highlights b"", but u""
versions: Python 3.1

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

From report at bugs.python.org  Fri May  7 11:05:33 2010
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Fri, 07 May 2010 09:05:33 +0000
Subject: [New-bugs-announce] [issue8642] json.loads description
In-Reply-To: <1273223133.88.0.532176627145.issue8642@psf.upfronthosting.co.za>
Message-ID: <1273223133.88.0.532176627145.issue8642@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi <mft at users.sourceforge.net>:

At the end of description of json.loads, dump() should be load().

----------
assignee: docs at python
components: Documentation
messages: 105187
nosy: docs at python, mft
priority: normal
severity: normal
status: open
title: json.loads description
versions: Python 2.6

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

From report at bugs.python.org  Fri May  7 13:11:18 2010
From: report at bugs.python.org (=?utf-8?b?TWljaGFsIEJvxb5vxYg=?=)
Date: Fri, 07 May 2010 11:11:18 +0000
Subject: [New-bugs-announce] [issue8643] incorrect timedelta yielded by two
	on-the-fly nows
In-Reply-To: <1273230678.16.0.688887441579.issue8643@psf.upfronthosting.co.za>
Message-ID: <1273230678.16.0.688887441579.issue8643@psf.upfronthosting.co.za>


New submission from Michal Bo?o? <michal.bozon at gmail.com>:

now() - now() from datetime.datetime produces not-nearly-zero timedelta:

>>> import datetime
>>> (datetime.datetime.now() - datetime.datetime.now()).seconds
86399

(i can't in the moment figure out why this is happening, sice the datetime library is written in C)

----------
components: Library (Lib)
messages: 105190
nosy: mykhal
priority: normal
severity: normal
status: open
title: incorrect timedelta yielded by two on-the-fly nows
type: behavior
versions: Python 2.5, Python 3.1

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

From report at bugs.python.org  Fri May  7 14:24:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 May 2010 12:24:55 +0000
Subject: [New-bugs-announce] [issue8644] timedelta.total_seconds needlessly
	inaccurate, especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

I just noticed (while responding to issue 8643) that timedelta.total_seconds() has some accuracy problems, especially for negative timedeltas:

Python 3.2a0 (py3k:80840:80842, May  7 2010, 12:29:35) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import timedelta
>>> td = timedelta(microseconds = -123)
>>> td.total_seconds() # expect -0.000123
-0.0001230000052601099

This could be easily fixed by using integer arithmetic internally instead of float arithmetic:

>>> 1e-6 * td.microseconds + td.seconds + 86400 * td.days
-0.0001230000052601099
>>> (td.microseconds + 1000000 * (td.seconds + 86400 * td.days)) / 1000000
-0.000123

This works especially nicely in combination with the new float repr and the improved accuracy of true division in 2.7 / 3.2, to give a total_seconds() whose repr is free of noise digits.  (Well, for small timedeltas, anyway.)

Since total_seconds is new in 2.7 and 3.2, I think it would be good to fix this before the 2.7 release.

----------
components: Extension Modules
messages: 105197
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: timedelta.total_seconds needlessly inaccurate, especially for negative timedeltas
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri May  7 17:55:35 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 15:55:35 +0000
Subject: [New-bugs-announce] [issue8645] PyUnicode_AsEncodedObject is
	undocumented
In-Reply-To: <1273247735.73.0.712345896243.issue8645@psf.upfronthosting.co.za>
Message-ID: <1273247735.73.0.712345896243.issue8645@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

PyUnicode_AsEncodedObject is undocumented.  It has the same signature as PyUnicode_AsEncodedString, although they do slightly different things based on a brief source code inspection (I'm not clear on what that difference is though).

----------
assignee: docs at python
components: Documentation
messages: 105203
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: PyUnicode_AsEncodedObject is undocumented
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri May  7 17:59:05 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 15:59:05 +0000
Subject: [New-bugs-announce] [issue8646] PyUnicode_EncodeDecimal is
	undocumented
In-Reply-To: <1273247945.7.0.702043835904.issue8646@psf.upfronthosting.co.za>
Message-ID: <1273247945.7.0.702043835904.issue8646@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

PyUnicode_EncodeDecimal is undocumented (although it's referenced in passing in the documentation for PyLong_FromUnicode).  There's a lengthy comment in unicodeobject.h describing PyUnicode_EncodeDecimal, which could be converted more or less directly into documentation.

----------
assignee: docs at python
components: Documentation
messages: 105205
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: PyUnicode_EncodeDecimal is undocumented
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri May  7 18:07:19 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 16:07:19 +0000
Subject: [New-bugs-announce] [issue8647] PyUnicode_GetMax is undocumented
In-Reply-To: <1273248439.66.0.594970239714.issue8647@psf.upfronthosting.co.za>
Message-ID: <1273248439.66.0.594970239714.issue8647@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Here's the relevant signature:

/* Get the maximum ordinal for a Unicode character. */
PyAPI_FUNC(Py_UNICODE) PyUnicode_GetMax(void);

----------
assignee: docs at python
components: Documentation
messages: 105206
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: PyUnicode_GetMax is undocumented
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri May  7 18:10:36 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 16:10:36 +0000
Subject: [New-bugs-announce] [issue8648] The UTF-7 codec functions are
	undocumented
In-Reply-To: <1273248636.7.0.217932609429.issue8648@psf.upfronthosting.co.za>
Message-ID: <1273248636.7.0.217932609429.issue8648@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The UTF-7 codec functions are undocumented:

PyUnicode_DecodeUTF7Stateful
PyUnicode_DecodeUTF7
PyUnicode_EncodeUTF7

----------
assignee: docs at python
components: Documentation
messages: 105207
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: The UTF-7 codec functions are undocumented
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri May  7 18:48:41 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 16:48:41 +0000
Subject: [New-bugs-announce] [issue8649] Py_UNICODE_* functions are
	undocumented
In-Reply-To: <1273250921.26.0.330435554177.issue8649@psf.upfronthosting.co.za>
Message-ID: <1273250921.26.0.330435554177.issue8649@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Python provides several functions for manipulating raw Py_UNICODE strings, but they aren't documented.  Below are their signatures.

PyAPI_FUNC(size_t) Py_UNICODE_strlen(const Py_UNICODE *u);

PyAPI_FUNC(Py_UNICODE*) Py_UNICODE_strcpy(
    Py_UNICODE *s1, const Py_UNICODE *s2);

PyAPI_FUNC(Py_UNICODE*) Py_UNICODE_strncpy(
    Py_UNICODE *s1, const Py_UNICODE *s2, size_t n);

PyAPI_FUNC(int) Py_UNICODE_strcmp(
    const Py_UNICODE *s1, const Py_UNICODE *s2);

PyAPI_FUNC(Py_UNICODE*) Py_UNICODE_strchr(
    const Py_UNICODE *s, Py_UNICODE c
    );

----------
assignee: docs at python
components: Documentation
messages: 105214
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Py_UNICODE_* functions are undocumented
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri May  7 19:21:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 17:21:01 +0000
Subject: [New-bugs-announce] [issue8650] zlibmodule.c isn't 64-bit clean
In-Reply-To: <1273252861.66.0.962857738541.issue8650@psf.upfronthosting.co.za>
Message-ID: <1273252861.66.0.962857738541.issue8650@psf.upfronthosting.co.za>


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

zlibmodule.c doesn't define PY_SSIZE_T_CLEAN, and uses lots of "int" variables for length values internally.
Besides, the zlib itself uses "uInt" and "uLong" variables in its z_stream structure (rather than something guaranteed to be at least the width of a pointer).

On large input data, this will conspire to produce bogus results or crashes. For example:

>>> s = 'x' * (4 * 1024**3 + 100)
>>> t = zlib.compress(s, 1)
>>> len(t)
12
>>> len(zlib.decompress(t))
100

----------
components: Extension Modules
messages: 105216
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: zlibmodule.c isn't 64-bit clean
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri May  7 19:24:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 17:24:56 +0000
Subject: [New-bugs-announce] [issue8651] "s#" and friends can silently
	truncate buffer length
In-Reply-To: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>
Message-ID: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>


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

When PY_SSIZE_T isn't defined and a format such as "s#" receives an object whose length fits in a Py_ssize_t but not in an int, the buffer length is silently truncated:

>>> s = 'x' * (4 * 1024**3 + 100)
>>> t = zlib.compress(s, 1)
>>> len(t)
12
>>> len(zlib.decompress(t))
100

(from issue8650)

----------
components: Interpreter Core
messages: 105217
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: "s#" and friends can silently truncate buffer length
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri May  7 19:25:34 2010
From: report at bugs.python.org (Marien Zwart)
Date: Fri, 07 May 2010 17:25:34 +0000
Subject: [New-bugs-announce] [issue8652] Minor improvements to the "Handling
	Exceptions" part of	the tutorial
In-Reply-To: <1273253134.08.0.147248211976.issue8652@psf.upfronthosting.co.za>
Message-ID: <1273253134.08.0.147248211976.issue8652@psf.upfronthosting.co.za>


New submission from Marien Zwart <m_zwart at 123mail.org>:

Based on questions asked on freenode's #python by people reading the tutorial I would like to suggest two improvements to http://docs.python.org/tutorial/errors.html#handling-exceptions :

- Mention the older "except SomeException, e:" syntax too, not just "except SomeException as e:". I have had people ask me to help them upgrade to a newer python because they thought their version of python did not support catching exception instances (their distro python being 2.5). A big fat warning that they're reading the Python 2.6 tutorial (with links to older tutorials) may also work.

- Mention "except IOError as e" before mentioning "except IOError as (errno, strerror):". The latter is an advanced and relatively unusual trick, combining regular exception catching and unpacking. Those two concepts need to be explained before the combination is. I have had people ask me how to do "except KeyError as (key, insert_something_here):" because they thought they *always* needed those parens there.

(perhaps just not mentioning unpacking here at all, using "except IOError as e:" and then using e.errno would make more sense, especially since "except IOError as (errno, strerror):" is a SyntaxError in python 3 and up (because of the unpacking) and python 2.5.x and down (because of the "as")...)

I can try to write a patch to the documentation if you like.

----------
assignee: docs at python
components: Documentation
messages: 105218
nosy: docs at python, marienz
priority: normal
severity: normal
status: open
title: Minor improvements to the "Handling Exceptions" part of the tutorial

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

From report at bugs.python.org  Fri May  7 20:39:02 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Fri, 07 May 2010 18:39:02 +0000
Subject: [New-bugs-announce] [issue8653] urlparse.urlparse/urlsplit doc
	missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

The docstrings for these functions don't explain the 'scheme' parameter.  Even renaming it to default_scheme would help.

----------
assignee: docs at python
components: Documentation
messages: 105221
nosy: dabrahams, docs at python
priority: normal
severity: normal
status: open
title: urlparse.urlparse/urlsplit doc missing

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

From report at bugs.python.org  Fri May  7 21:02:45 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 19:02:45 +0000
Subject: [New-bugs-announce] [issue8654] Improve ABI compatibility between
	UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Currently, Python can be built with an internal Unicode representation of UCS2 or UCS4.  To prevent extension modules compiled with the wrong Unicode representation from linking, unicodeobject.h #defines many of the Unicode functions.  For example, PyUnicode_FromString becomes either PyUnicodeUCS2_FromString or PyUnicodeUCS4_FromString.

Consequently, if one installs a binary egg (e.g., with easy_install), there's a good chance one will get an error such as the following when trying to use it:

        undefined symbol: PyUnicodeUCS2_FromString

In Python 2, only some extension modules were stung by this problem.  For Python 3, virtually every extension type will need to call a PyUnicode_* function, since __repr__ must return a Unicode object.  It's basically fruitless to upload a binary egg for Python 3 to PyPi, since it will generate link errors for a large fraction of downloaders (I discovered this the hard way).

Right now, nearly all the functions in unicodeobject.h are wrapped.  Several functions are not.  Many of the unwrapped functions also have no documentation, so I'm guessing they are newer functions that were not wrapped when they were added.

Most extensions treat PyUnicodeObjects as opaque and do not care if the internal representation is UCS2 or UCS4.  We can improve ABI compatibility by only wrapping functions where the representation matters from the caller's point of view.

For example, PyUnicode_FromUnicode creates a Unicode object from an array of Py_UNICODE objects.  It will interpret the data differently on UCS2 vs UCS4, so the function should be wrapped.

On the other hand, PyUnicode_FromString creates a Unicode object from a char *.  The caller can treat the returned object as opaque, so the function should not be wrapped.

The attached patch implements that rule.  It unwraps 64 opaque functions that were previously wrapped, and wraps 11 non-opaque functions that were previously unwrapped.  "make test" works with both UCS2 and UCS4 builds.

I previously brought this issue up on python-ideas, see:
http://mail.python.org/pipermail/python-ideas/2009-November/006543.html

Here's a summary of that discussion:

Zooko Wilcox-O'Hearn pointed out that my proposal is complimentary to his proposal to standardize on UCS4, to reduce the risk of extension modules built with a mismatched encoding.

Stefan Behnel pointed out that easy_install should allow eggs to specify the encoding they require.  PJE's proposed implementation of that feature (http://bit.ly/1bO62) would allow eggs to specify UCS2, UCS4, or "Don't Care".  My proposal greatly increases the number of eggs that could label themselves "Don't Care", reducing maintenance work for package maintainers.  In other words, they are complimentary fixes.

Guido liked the idea but expressed concern about the possibility of extension modules that link successfully, but later crash because they actually do depend on the UCS2/UCS4 distinction.

With my current patch, there are still two ways for that to happen:

1) The extension uses only opaque functions, but casts the returned PyObject * to PyUnicodeObject * and accesses the str member, or

2) The extension uses only opaque functions, but uses the PyUnicode_AS_UNICODE or PyUnicode_AS_DATA macros.

Most packages that poke into the internals of PyUnicodeObject also call non-opaque functions.  Consequently, they will still generate a linker error if the encoding is mismatched, as desired.

I'm trying to come up with a way to 100% guarantee that any extension poking into the internals will generate a linker error if the encoding is mismatched, even if they don't call any non-opaque functions.  I'll post about that in a separate comment to this bug.

----------
assignee: stutzbach
components: Interpreter Core, Unicode
messages: 105222
nosy: stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve ABI compatibility between UCS2 and UCS4 builds
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri May  7 22:49:54 2010
From: report at bugs.python.org (Westly Ward)
Date: Fri, 07 May 2010 20:49:54 +0000
Subject: [New-bugs-announce] [issue8655] Problem with getpeercert in the ssl
	module when	retrieving client side certs
In-Reply-To: <1273265394.09.0.646660549737.issue8655@psf.upfronthosting.co.za>
Message-ID: <1273265394.09.0.646660549737.issue8655@psf.upfronthosting.co.za>


New submission from Westly Ward <sonicrules1234 at gmail.com>:

I originally had this problem when writing my IRCd, but then tested it in a basic script.  The problem is that getpeercert() is always returning None when executed on the server side, even when the client is using an ssl cert.  I have included an example in the attachment.  Just run sslserver.py in one terminal window, and then run sslclient.py in the other.  I also included the two fresh ssl certs and keys I used.  In client.txt and server.txt I put the commands I used to generate the ssl certs and keys.

----------
components: Library (Lib)
files: ssltest.tar.gz
messages: 105227
nosy: Westly.Ward
priority: normal
severity: normal
status: open
title: Problem with getpeercert in the ssl module when retrieving client side certs
versions: Python 2.6
Added file: http://bugs.python.org/file17249/ssltest.tar.gz

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

From report at bugs.python.org  Sat May  8 03:45:28 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sat, 08 May 2010 01:45:28 +0000
Subject: [New-bugs-announce] [issue8656] urllib2 mangles file://-scheme URLs
In-Reply-To: <1273283128.63.0.607654661421.issue8656@psf.upfronthosting.co.za>
Message-ID: <1273283128.63.0.607654661421.issue8656@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

$ touch /tmp/x.html
$ python -c 'import urllib2;resp=urllib2.urlopen("file:///tmp/x.html");print resp.geturl()'
file:/tmp/x.html

note the missing // after the colon

----------
messages: 105250
nosy: dabrahams
priority: normal
severity: normal
status: open
title: urllib2 mangles file://-scheme URLs
versions: Python 2.6

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

From report at bugs.python.org  Sat May  8 04:49:08 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sat, 08 May 2010 02:49:08 +0000
Subject: [New-bugs-announce] [issue8657] urlparse.urlunsplit should be
	smarter about +
In-Reply-To: <1273286948.85.0.868221921839.issue8657@psf.upfronthosting.co.za>
Message-ID: <1273286948.85.0.868221921839.issue8657@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

from urlparse import *
urlunsplit(urlsplit('git+file:///foo/bar/baz'))
=> git+file:/foo/bar/baz

----------
messages: 105253
nosy: dabrahams
priority: normal
severity: normal
status: open
title: urlparse.urlunsplit should be smarter about +
versions: Python 2.6

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

From report at bugs.python.org  Sat May  8 06:00:34 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 08 May 2010 04:00:34 +0000
Subject: [New-bugs-announce] [issue8658] urlparse.urlunsplit should be
	smarter about + and file	urls
In-Reply-To: <1273291234.63.0.786087724907.issue8658@psf.upfronthosting.co.za>
Message-ID: <1273291234.63.0.786087724907.issue8658@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <orsenthil at gmail.com>:

>>> from urlparse import *
>>> urlsplit('git+file:///foo/bar/baz')
SplitResult(scheme='git+file', netloc='', path='/foo/bar/baz', query='', fragment='')
>>> urlunsplit(urlsplit('git+file:///foo/bar/baz'))
'git+file:/foo/bar/baz'
>>>

----------
assignee: orsenthil
files: urlparse_giturl.patch
keywords: patch
messages: 105256
nosy: orsenthil
priority: normal
severity: normal
status: open
title: urlparse.urlunsplit should be smarter about + and file urls
type: behavior
Added file: http://bugs.python.org/file17257/urlparse_giturl.patch

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

From report at bugs.python.org  Sat May  8 08:15:22 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 08 May 2010 06:15:22 +0000
Subject: [New-bugs-announce] [issue8659] ABS(x) == 0 can be simplified to x
	== 0
In-Reply-To: <1273299322.78.0.204722147586.issue8659@psf.upfronthosting.co.za>
Message-ID: <1273299322.78.0.204722147586.issue8659@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

I noticed that in longobject.c, there are a few spots that take the absolute value of an int before comparing the int to 0.  There's no -0 for C integers, so the absolute value isn't necessary.

I traced back through the commit history, and it looks like they're an artifact of the original one's-complement longobject.c (which COULD have -0).  longobject was switched to two's-complement in 1992. ;-)

----------
assignee: stutzbach
components: Interpreter Core
files: abs-zero.patch
keywords: patch
messages: 105265
nosy: stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: ABS(x) == 0 can be simplified to x == 0
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file17259/abs-zero.patch

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

From report at bugs.python.org  Sat May  8 15:10:10 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 08 May 2010 13:10:10 +0000
Subject: [New-bugs-announce] [issue8660] py3k weakref documentation mentions
	the long built-in type
In-Reply-To: <1273324210.04.0.0772545090364.issue8660@psf.upfronthosting.co.za>
Message-ID: <1273324210.04.0.0772545090364.issue8660@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

There is a sentence in the weakref module's documentation:
"Other built-in types such as tuple and long do not support weak references even when subclassed"
But there is no "long" type in py3k.

----------
assignee: docs at python
components: Documentation
messages: 105285
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: py3k weakref documentation mentions the long built-in type
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat May  8 17:33:42 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 08 May 2010 15:33:42 +0000
Subject: [New-bugs-announce] [issue8661] FAQ item 2.25 is unclear
In-Reply-To: <1273332822.19.0.471138698588.issue8661@psf.upfronthosting.co.za>
Message-ID: <1273332822.19.0.471138698588.issue8661@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at twistedmatrix.com>:

The item "How do I prepare a new branch for merging?" is unclear about which branch needs to be prepared.  It could be the source branch or the destination branch.  In #python-dev, I learned that it's probably the destination branch being discussed here.  This should be clarified (and it could also be pointed out that it is almost always the case that this step has been done by someone else already).

----------
messages: 105300
nosy: exarkun
priority: normal
severity: normal
status: open
title: FAQ item 2.25 is unclear

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

From report at bugs.python.org  Sat May  8 18:50:50 2010
From: report at bugs.python.org (Timothy Pederick)
Date: Sat, 08 May 2010 16:50:50 +0000
Subject: [New-bugs-announce] [issue8662] bytes join cannot join bytes
In-Reply-To: <1273337450.92.0.207021309047.issue8662@psf.upfronthosting.co.za>
Message-ID: <1273337450.92.0.207021309047.issue8662@psf.upfronthosting.co.za>


New submission from Timothy Pederick <pederick at gmail.com>:

This code behaves as expected:
>>> ' '.join('cat')
'c a t'

This code does not:
>>> b'\x00'.join(b'cat')
Traceback (most recent call last):
  ...
    b'\x00'.join(b'cat')
TypeError: sequence item 0: expected bytes, int found

Instead, you have to do something like this:
>>> b'\x00'.join(bytes((i,)) for i in b'cat')
b'c\x00a\x00t'

The cause is that indexing a bytes object gives an int, not a bytes. I know, it's as designed, PEP 3137, etc. But in this specific instance, it causes Python to behave inconsistently (bytes vs. str) and unintuitively (to me, anyway).

(Same problem with bytes or bytearray in either position.)

----------
files: joinerror.py
messages: 105317
nosy: perey
priority: normal
severity: normal
status: open
title: bytes join cannot join bytes
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file17262/joinerror.py

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

From report at bugs.python.org  Sat May  8 19:38:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 May 2010 17:38:41 +0000
Subject: [New-bugs-announce] [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>


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

Distutils fails logging characters which are not part of the "default encoding":

http://www.python.org/dev/buildbot/builders/AMD64%20Ubuntu%20wide%203.x/builds/1062/steps/compile/logs/stdio

[...]
  File "/home/buildbot/cpython-ucs4-nonascii-\u20ac/3.x.pitrou-ubuntu-wide/build/Lib/distutils/dir_util.py", line 67, in mkpath
    log.info("creating %s", head)
  File "/home/buildbot/cpython-ucs4-nonascii-\u20ac/3.x.pitrou-ubuntu-wide/build/Lib/distutils/log.py", line 40, in info
    self._log(INFO, msg, args)
  File "/home/buildbot/cpython-ucs4-nonascii-\u20ac/3.x.pitrou-ubuntu-wide/build/Lib/distutils/log.py", line 30, in _log
    stream.write('%s\n' % msg)
UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in position 81: ordinal not in range(128)
[54439 refs]

----------
assignee: tarek
components: Distutils
messages: 105320
nosy: haypo, pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Failed compile in a non-ASCII path
type: compile error
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat May  8 21:36:33 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 08 May 2010 19:36:33 +0000
Subject: [New-bugs-announce] [issue8664] py_compile.compile() should
	consistently create parent	directory of target file
In-Reply-To: <1273347393.41.0.872470014027.issue8664@psf.upfronthosting.co.za>
Message-ID: <1273347393.41.0.872470014027.issue8664@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Currently when cfile argument of py_compile.compile() is None, then path to target file is automatically calculated and parent directory of target file is created. If the same path of target file is explicitly passed as cfile argument of py_compile.compile(), then parent directory of target file is not created automatically.
This inconsistency in behavior can be easily fixed. Fixing it also allows to simplify compileall.compile_file() function, which calls py_compile.compile() and currently needs to earlier try to create parent directory of target file.

The following example shows inconsistent behavior:

$ mkdir test
$ touch test/test.py
$ tree test
test
??? test.py

0 directories, 1 file
$ python3.2 -c 'import py_compile; py_compile.compile("test/test.py")'
$ tree test
test
??? __pycache__
?   ??? test.cpython-32.pyc
??? test.py

1 directory, 2 files
$ rm -fr test/__pycache__
$ python3.2 -c 'import py_compile; py_compile.compile("test/test.py", "test/__pycache__/test.cpython-32.pyc")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.2/py_compile.py", line 131, in compile
    with open(cfile, 'wb') as fc:
IOError: [Errno 2] No such file or directory: 'test/__pycache__/test.cpython-32.pyc'
$ mkdir test/__pycache__
$ python3.2 -c 'import py_compile; py_compile.compile("test/test.py", "test/__pycache__/test.cpython-32.pyc")'
$ tree test
test
??? __pycache__
?   ??? test.cpython-32.pyc
??? test.py

1 directory, 2 files

----------
components: Library (Lib)
messages: 105328
nosy: Arfrever
priority: normal
severity: normal
status: open
title: py_compile.compile() should consistently create parent directory of target file
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat May  8 21:51:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 May 2010 19:51:00 +0000
Subject: [New-bugs-announce] [issue8665] "make pycremoval" fails
In-Reply-To: <1273348260.64.0.925523005722.issue8665@psf.upfronthosting.co.za>
Message-ID: <1273348260.64.0.925523005722.issue8665@psf.upfronthosting.co.za>


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

This is probably because you remove the directory while find is walking it:

$ make pycremoval
find . -name '*.py[co]' -exec rm -f {} ';'
find . -name '__pycache__' -exec rmdir {} ';'
find: `./Lib/http/__pycache__': No such file or directory
find: `./Lib/unittest/test/__pycache__': No such file or directory
find: `./Lib/unittest/__pycache__': No such file or directory
find: `./Lib/email/__pycache__': No such file or directory
find: `./Lib/test/__pycache__': No such file or directory
find: `./Lib/importlib/__pycache__': No such file or directory
find: `./Lib/urllib/__pycache__': No such file or directory
find: `./Lib/__pycache__': No such file or directory
find: `./Lib/encodings/__pycache__': No such file or directory
find: `./Lib/json/__pycache__': No such file or directory
make: [pycremoval] Error 1 (ignored)

----------
assignee: barry
components: Build
messages: 105331
nosy: barry, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: "make pycremoval" fails
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat May  8 21:56:34 2010
From: report at bugs.python.org (Tim Chase)
Date: Sat, 08 May 2010 19:56:34 +0000
Subject: [New-bugs-announce] [issue8666] Allow ConfigParser.get*() to take a
	default value
In-Reply-To: <1273348594.74.0.554904911988.issue8666@psf.upfronthosting.co.za>
Message-ID: <1273348594.74.0.554904911988.issue8666@psf.upfronthosting.co.za>


New submission from Tim Chase <python.list at tim.thechases.com>:

Patch to update ConfigParser.py so that the .get* methods can take an optional parameter rather than raising exceptions.  Usage:

  cp = ConfigParser(...)
  # ...
  value = cp.get('MySection', 'MyOption', default='some default')
  i = cp.getint('MySecton', 'MyInt', default=42)
  f = cp.getfloat('MySection', 'MyF', default=3.14)

----------
components: Library (Lib)
messages: 105333
nosy: Gumnos
priority: normal
severity: normal
status: open
title: Allow ConfigParser.get*() to take a default value
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Sun May  9 01:51:33 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 08 May 2010 23:51:33 +0000
Subject: [New-bugs-announce] [issue8667] Link to PEP 3147 from importlib docs
In-Reply-To: <1273362693.55.0.571697250376.issue8667@psf.upfronthosting.co.za>
Message-ID: <1273362693.55.0.571697250376.issue8667@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

In trying to keep importlib's docs THE place to go for links to all relevant import details, a link to PEP 3147 is needed.

----------
assignee: brett.cannon
components: Documentation
keywords: easy
messages: 105351
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Link to PEP 3147 from importlib docs
versions: Python 3.2

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

From report at bugs.python.org  Sun May  9 03:19:06 2010
From: report at bugs.python.org (Dan Buch)
Date: Sun, 09 May 2010 01:19:06 +0000
Subject: [New-bugs-announce] [issue8668] add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>


New submission from Dan Buch <daniel.buch at gmail.com>:

make a 'develop' command in distutils2 a la setuptools

(unless, of course, this has already been unilaterally refused via distutils-sig or other communication)

----------
assignee: tarek
components: Distutils2
messages: 105359
nosy: meatballhat, tarek
priority: normal
severity: normal
status: open
title: add a 'develop' command
type: feature request

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

From report at bugs.python.org  Sun May  9 03:47:13 2010
From: report at bugs.python.org (Dan Buch)
Date: Sun, 09 May 2010 01:47:13 +0000
Subject: [New-bugs-announce] [issue8669] lack of bdist_rpm module raises
	error on 'setup.py	--help-commands'
In-Reply-To: <1273369633.98.0.458470159807.issue8669@psf.upfronthosting.co.za>
Message-ID: <1273369633.98.0.458470159807.issue8669@psf.upfronthosting.co.za>


New submission from Dan Buch <daniel.buch at gmail.com>:

Running 'python setup.py --help-commands' in the distutils2 package raises an error because there is no 'bdist_rpm' module.  Should references to 'bdist_rpm' be removed, or should the 'bdist_rpm' module be (re?)introduced?

----------
assignee: tarek
components: Distutils2
messages: 105361
nosy: meatballhat, tarek
priority: normal
severity: normal
status: open
title: lack of bdist_rpm module raises error on 'setup.py --help-commands'

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

From report at bugs.python.org  Sun May  9 08:38:34 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 09 May 2010 06:38:34 +0000
Subject: [New-bugs-announce] [issue8670] c_types.c_wchar should not assume
	that sizeof(wchar_t) ==	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Using a UCS2 Python on a platform with a 32-bit wchar_t, the following code throws an exception (but should not):

>>> ctypes.c_wchar('\u10000')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: one character unicode string expected

The trouble is in the u_set() function in Modules/_ctypes/cfield.c.  The corresponding u_get() function looks correct.

On a UCS4 Python running on a system with a 16-bit wchar_t, u_set() will corrupt the data by silently truncating the character to 16-bits.

For reference, Linux and Mac OS use a 32-bit wchar_t while Windows uses a 16-bit wchar_t.

----------
assignee: theller
components: ctypes
messages: 105374
nosy: stutzbach, theller
priority: normal
severity: normal
stage: unit test needed
status: open
title: c_types.c_wchar should not assume that sizeof(wchar_t) == sizeof(Py_UNICODE)
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun May  9 14:43:35 2010
From: report at bugs.python.org (bones7456)
Date: Sun, 09 May 2010 12:43:35 +0000
Subject: [New-bugs-announce] [issue8671] A small erorr on
	http://docs.python.org/library/re.html
In-Reply-To: <1273409015.67.0.984272084937.issue8671@psf.upfronthosting.co.za>
Message-ID: <1273409015.67.0.984272084937.issue8671@psf.upfronthosting.co.za>


New submission from bones7456 <bones7456 at gmail.com>:

In section \b , original text is:

Matches the empty string, but only at the beginning or end of a word. A word is defined as a sequence of alphanumeric or underscore characters, so the end of a word is indicated by whitespace or a non-alphanumeric, non-underscore character. Note that \b  is defined as the boundary between \w and \ W, so the precise set of characters deemed to be alphanumeric depends on the values of the UNICODE and LOCALE flags. Inside a character range, \b  represents the backspace character, for compatibility with Python?s string literals.

NOTE: there is space between "\" and "W", I think it is not needed.

----------
assignee: docs at python
components: Documentation
messages: 105391
nosy: bones7456, docs at python
priority: normal
severity: normal
status: open
title: A small erorr on http://docs.python.org/library/re.html
versions: Python 2.6

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

From report at bugs.python.org  Mon May 10 00:44:06 2010
From: report at bugs.python.org (Matthew Brett)
Date: Sun, 09 May 2010 22:44:06 +0000
Subject: [New-bugs-announce] [issue8672] Error decompressing valid zlib data
In-Reply-To: <1273445046.81.0.821535662262.issue8672@psf.upfronthosting.co.za>
Message-ID: <1273445046.81.0.821535662262.issue8672@psf.upfronthosting.co.za>


New submission from Matthew Brett <matthew.brett at gmail.com>:

I have a valid zlib compressed string, attached here as 'mat.bin' (1.7M), that cause and error on zlib.decompress decompression:

>>> import zlib
>>> data = open('mat.bin', 'rb').read()
>>> out = zlib.decompress(data)
Traceback (most recent call last):
  File "<ipython console>", line 1, in <module>
error: Error -5 while decompressing data

I know these data are valid, because I get the string I was expecting with:

>>> dc_obj = zlib.decompressobj()
>>> out = dc_obj.decompress(data)

As expected, there is no remaining data after this read:

>>> assert dc_obj.flush() == ''
>>> 

I believe that the behavior of zlib.decompress(data) and zlib.decompressobj().decompress(data) should be equivalent, and that the error for zlib.decompress(data) is therefore the symptom of a bug.

----------
components: IO
files: mat.bin
messages: 105420
nosy: matthew.brett
priority: normal
severity: normal
status: open
title: Error decompressing valid zlib data
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file17279/mat.bin

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

From report at bugs.python.org  Mon May 10 12:12:09 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 10 May 2010 10:12:09 +0000
Subject: [New-bugs-announce] [issue8673] configure script doesn't recognize
	10.5 SDK correctly
In-Reply-To: <1273486329.72.0.388751753442.issue8673@psf.upfronthosting.co.za>
Message-ID: <1273486329.72.0.388751753442.issue8673@psf.upfronthosting.co.za>


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

I got a build error when building the 2.7b2 installers because the MacOS module couldn't be build. That turns out to be caused by an issue in the configure script: for some reason the check for the 10.5 SDK gives the wrong answer (both with and without building using the 10.4u SDK).

I haven't had time to research the issue and worked around it by hardcoding the right answer in the configure script during my build, but that's obviously not the correct solution.

----------
assignee: ronaldoussoren
components: Build, Macintosh
messages: 105426
nosy: ronaldoussoren
priority: high
severity: normal
stage: needs patch
status: open
title: configure script doesn't recognize 10.5 SDK correctly
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Mon May 10 15:43:29 2010
From: report at bugs.python.org (Tomas Hoger)
Date: Mon, 10 May 2010 13:43:29 +0000
Subject: [New-bugs-announce] [issue8674] audioop: incorrect integer overflow
	checks
In-Reply-To: <1273499009.24.0.283270137147.issue8674@psf.upfronthosting.co.za>
Message-ID: <1273499009.24.0.283270137147.issue8674@psf.upfronthosting.co.za>


New submission from Tomas Hoger <thoger at redhat.com>:

SVN commit r64114 added integer overflow checks to multiple modules.  Checks added to audioop module are incorrect and can still be bypassed:

http://svn.python.org/view/python/trunk/Modules/audioop.c?r1=64114&r2=64113

- audioop_tostereo - should be fine, but relies on undefined behaviour
- audioop_lin2lin - undetected overflow: size=1, size2=4, len=0x40000001
- audioop_ratecv - undetected overflow: nchannels=0x5fffffff (32bit)
- audioop_ulaw2lin - undetected overflow: size=4, len=0x40000001
- audioop_alaw2lin - same as audioop_ulaw2lin
- audioop_adpcm2lin - undetected overflow: size=4, len=0x20000001

Most of these are triggered by large fragment as an input.

Attached patch replaces checks added in r64114 by checks using INT_MAX.

----------
components: Extension Modules
files: python2.6-audioop-int-overflows.diff
keywords: patch
messages: 105434
nosy: thoger
priority: normal
severity: normal
status: open
title: audioop: incorrect integer overflow checks
type: security
versions: Python 2.6
Added file: http://bugs.python.org/file17281/python2.6-audioop-int-overflows.diff

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

From report at bugs.python.org  Mon May 10 20:38:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 10 May 2010 18:38:05 +0000
Subject: [New-bugs-announce] [issue8675] audioop module needs an int ->
	Py_ssize_t upgrade
In-Reply-To: <1273516685.47.0.439722259241.issue8675@psf.upfronthosting.co.za>
Message-ID: <1273516685.47.0.439722259241.issue8675@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The audioop module still uses 'int' for most of its sizes;  it would be better if it used 'Py_ssize_t' instead, so that data aren't artificially limited to 2Gb on 64-bit systems.

Converting ought to be a fairly straightforward task for someone wanting to get their feet wet with CPython hacking;  marking as easy.

----------
keywords: easy
messages: 105454
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: audioop module needs an int -> Py_ssize_t upgrade
type: performance
versions: Python 3.2

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

From report at bugs.python.org  Mon May 10 21:29:08 2010
From: report at bugs.python.org (Daniel Urban)
Date: Mon, 10 May 2010 19:29:08 +0000
Subject: [New-bugs-announce] [issue8676] Py3k Built-in Exceptions
	documentation mentions the raise	statement of 2.x
In-Reply-To: <1273519748.49.0.797934742899.issue8676@psf.upfronthosting.co.za>
Message-ID: <1273519748.49.0.797934742899.issue8676@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

In the documentation of the exceptions (http://docs.python.org/dev/py3k/library/exceptions) there is a sentence:
"The associated value is the second argument to the raise statement."
But in py3k there is a different raise statement than in 2.x.

----------
assignee: docs at python
components: Documentation
messages: 105457
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: Py3k Built-in Exceptions documentation mentions the raise statement of 2.x
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon May 10 21:59:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 May 2010 19:59:40 +0000
Subject: [New-bugs-announce] [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>


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

This is a list of extension modules making use of one of the "#" format codes ("s#", "y#", etc.) without defining PY_SSIZE_T_CLEAN, and therefore being 64-bit unclean:

Modules/audioop.c
Modules/_cursesmodule.c
Modules/_elementtree.c
Modules/_gdbmmodule.c
Modules/nismodule.c
Modules/ossaudiodev.c
Modules/pyexpat.c
Modules/socketmodule.c
Modules/_ssl.c
Modules/unicodedata.c

----------
components: Extension Modules
messages: 105461
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Modules needing PY_SSIZE_T_CLEAN
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon May 10 23:24:02 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 10 May 2010 21:24:02 +0000
Subject: [New-bugs-announce] [issue8678] crashers in rgbimg
In-Reply-To: <1273526642.93.0.89259252042.issue8678@psf.upfronthosting.co.za>
Message-ID: <1273526642.93.0.89259252042.issue8678@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Red Hat found some crashers in the rgbimg module along with a proposed patch: https://bugzilla.redhat.com/show_bug.cgi?id=541698 . Since the patch was sent to the PSRT privately before the bugs were announced, it should be fine to take the patch from the page and apply it.

----------
messages: 105467
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: crashers in rgbimg
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon May 10 23:39:33 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 10 May 2010 21:39:33 +0000
Subject: [New-bugs-announce] [issue8679] write a distutils to distutils2
	converter
In-Reply-To: <1273527573.05.0.844239277503.issue8679@psf.upfronthosting.co.za>
Message-ID: <1273527573.05.0.844239277503.issue8679@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

write a script that converts a distutils or setuptools based setup.py script into a distutils2 one.

This script will need to parse the AST and generate a new setup.py, using a few transformation rules.

----------
assignee: tarek
components: Distutils2
messages: 105468
nosy: tarek
priority: normal
severity: normal
status: open
title: write a distutils to distutils2 converter
type: feature request

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

From report at bugs.python.org  Tue May 11 00:15:48 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 10 May 2010 22:15:48 +0000
Subject: [New-bugs-announce] [issue8680] Add a sandbox in Distutils2
In-Reply-To: <1273529748.63.0.145688721875.issue8680@psf.upfronthosting.co.za>
Message-ID: <1273529748.63.0.145688721875.issue8680@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

Add a sandbox in distutils2, so all installation steps can be recorded or controlled.

Usage example: a dry-run mode that prevents anything to be written on the disk but just reports.

See setuptools.sandbox for example

----------
assignee: tarek
components: Distutils2
messages: 105471
nosy: tarek
priority: normal
severity: normal
status: open
title: Add a sandbox in Distutils2
type: feature request

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

From report at bugs.python.org  Tue May 11 00:37:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 May 2010 22:37:39 +0000
Subject: [New-bugs-announce] [issue8681] Make the zlib module emit more
	detailed error messages
In-Reply-To: <1273531059.62.0.905439523154.issue8681@psf.upfronthosting.co.za>
Message-ID: <1273531059.62.0.905439523154.issue8681@psf.upfronthosting.co.za>


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

This is a patch to use our own error descriptions when the zlib doesn't provide anything in particular. It would have made issue8672 easier to diagnose for the reporter (and for us).

----------
components: Extension Modules
files: zliberrors.patch
keywords: patch
messages: 105476
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Make the zlib module emit more detailed error messages
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17287/zliberrors.patch

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

From report at bugs.python.org  Tue May 11 01:32:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 May 2010 23:32:11 +0000
Subject: [New-bugs-announce] [issue8682] _ssl.c uses PyWeakref_GetObject but
	doesn't incref result
In-Reply-To: <1273534331.53.0.523751841318.issue8682@psf.upfronthosting.co.za>
Message-ID: <1273534331.53.0.523751841318.issue8682@psf.upfronthosting.co.za>


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

PyWeakref_GetObject() returns a borrowed reference, which can therefore become invalid at any time (especially when the GIL gets released). This provides a way to crash the interpreter deliberately.
The returned reference should be incref'ed immediately before any other action is taken.

----------
assignee: pitrou
components: Extension Modules
messages: 105481
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: _ssl.c uses PyWeakref_GetObject but doesn't incref result
type: crash
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue May 11 02:51:42 2010
From: report at bugs.python.org (srid)
Date: Tue, 11 May 2010 00:51:42 +0000
Subject: [New-bugs-announce] [issue8683] HPUX Segmentation Fault in
	Modules/gcmodule.c -- if	(!gc_list_is_empty(from)) {
In-Reply-To: <1273539102.07.0.573681131536.issue8683@psf.upfronthosting.co.za>
Message-ID: <1273539102.07.0.573681131536.issue8683@psf.upfronthosting.co.za>


New submission from srid <sridharr at activestate.com>:

Platform: HP-UX B.11.22 U ia64
Python: 2.7 trunk

GDB output when running built `python` binary:

Program received signal SIGSEGV, Segmentation fault (si_code: 1).
0x40000000002a2510:1 in gc_list_merge (from=0x148, to=0x148)
    at Modules/gcmodule.c:240
240         if (!gc_list_is_empty(from)) {

and the stack trace:

(gdb) bt
#0  0x40000000002a2510:1 in gc_list_merge (from=0x148, to=0x148)
    at Modules/gcmodule.c:240
#1  0x40000000002a4720:0 in collect (generation=0) at Modules/gcmodule.c:975
#2  0x40000000002a6620:0 in _PyObject_GC_Malloc (basicsize=65598)
    at Modules/gcmodule.c:996
#3  0x400000000018e540:0 in PyType_GenericAlloc (type=0x1003e, nitems=65598)
    at Objects/typeobject.c:743
#4  0x40000000003107d0:0 in PyDescr_NewWrapper (type=0x0, base=0x1003e, 
    wrapped=0x1003e) at Objects/descrobject.c:641
#5  0x40000000001a4570:0 in add_operators (type=0x0)
    at Objects/typeobject.c:6388
#6  0x4000000000193670:0 in PyType_Ready (type=0x1003e)
    at Objects/typeobject.c:4003
#7  0x40000000001485b0:0 in _Py_ReadyTypes () at Objects/object.c:2092
#8  0x4000000000270980:0 in Py_InitializeEx (install_sigs=0)
    at Python/pythonrun.c:176
#9  0x40000000002720e0:0 in Py_Initialize () at Python/pythonrun.c:370
#10 0x400000000009da70:0 in Py_Main (argc=0, argv=0x0) at Modules/main.c:507
#11 0x400000000009c770:0 in main (argc=0, argv=0x0) at ./Modules/python.c:23

----------
components: Interpreter Core
messages: 105482
nosy: srid
priority: normal
severity: normal
status: open
title: HPUX Segmentation Fault in Modules/gcmodule.c -- if (!gc_list_is_empty(from)) {
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue May 11 06:27:50 2010
From: report at bugs.python.org (Josiah Carlson)
Date: Tue, 11 May 2010 04:27:50 +0000
Subject: [New-bugs-announce] [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>


New submission from Josiah Carlson <josiahcarlson at users.sourceforge.net>:

This patch is against Python trunk, but it could be easily targeted for Python 3.2 .  It is meant to extract the scheduler updates from issue1641 without mucking with asyncore.  It's reach is reduced and simplified, which should make maintenance a bit easier.

----------
assignee: giampaolo.rodola
components: Library (Lib)
files: sched.patch
keywords: needs review, patch, patch
messages: 105483
nosy: giampaolo.rodola, josiahcarlson
priority: low
severity: normal
status: open
title: improvements to sched.py
type: feature request
Added file: http://bugs.python.org/file17289/sched.patch

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

From report at bugs.python.org  Tue May 11 11:04:19 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Tue, 11 May 2010 09:04:19 +0000
Subject: [New-bugs-announce] [issue8685]
	set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>


New submission from Andrew Bennetts <spiv at users.sourceforge.net>:

set.difference(s), when s is also a set, basically does::

    res = set()
    for elem in self:
        if elem not in other:
            res.add(elem)

This is wasteful when len(self) is much greater than len(other):

$ python -m timeit -s "s = set(range(100000)); sd = s.difference; empty = set()" "sd(empty)"
100 loops, best of 3: 12.8 msec per loop
$ python -m timeit -s "s = set(range(10)); sd = s.difference; empty = set()" "sd(empty)"
1000000 loops, best of 3: 1.18 usec per loop

Here's a patch that compares the lengths of self and other before that loop, and if len(self) is greater, swaps them.  The new timeit results are:

$ python -m timeit -s "s = set(range(100000)); sd = s.difference; empty = set()" "sd(empty)"
1000000 loops, best of 3: 0.289 usec per loop
$ python -m timeit -s "s = set(range(10)); sd = s.difference; empty = set()" "sd(empty)"
1000000 loops, best of 3: 0.294 usec per loop

----------
components: Interpreter Core
files: set-difference-speedup.diff
keywords: patch
messages: 105489
nosy: spiv
priority: normal
severity: normal
status: open
title: set(range(100000)).difference(set()) is slow
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file17292/set-difference-speedup.diff

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

From report at bugs.python.org  Tue May 11 13:13:56 2010
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 11 May 2010 11:13:56 +0000
Subject: [New-bugs-announce] [issue8686] "This isn't defined beyond that"
	phrase is not friendly	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/library/difflib.html#difflib.SequenceMatcher.quick_ratio
> This isn?t defined beyond that it is an upper bound on ratio(), and is faster to compute.

"beyond" is a bit confusing because it also means "over" and this
sentence refers upper bound.

I think "This isn't defined in detail more than..." is easier.

----------
assignee: docs at python
components: Documentation
messages: 105498
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: "This isn't defined beyond that" phrase is not friendly to non-native English speakers.
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue May 11 14:28:06 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 11 May 2010 12:28:06 +0000
Subject: [New-bugs-announce] [issue8687] sched.py module doesn't have a test
	suite
In-Reply-To: <1273580886.01.0.152818867035.issue8687@psf.upfronthosting.co.za>
Message-ID: <1273580886.01.0.152818867035.issue8687@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

sched.py module is currently lacking a test suite.
Possibly this should be resolved before fixing issue 8684.

----------
components: Tests
messages: 105503
nosy: giampaolo.rodola, josiah.carlson, josiahcarlson, pitrou
priority: normal
severity: normal
status: open
title: sched.py module doesn't have a test suite
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue May 11 14:32:48 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 11 May 2010 12:32:48 +0000
Subject: [New-bugs-announce] [issue8688] distutils sdist is too laze w.r.t.
	recalculating MANIFEST
In-Reply-To: <1273581168.94.0.337026684583.issue8688@psf.upfronthosting.co.za>
Message-ID: <1273581168.94.0.337026684583.issue8688@psf.upfronthosting.co.za>


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

The sdist command in distutils calculates the MANIFEST file from a template (by default MANIFEST.in). 

The code in sdist assumes that the contents of MANIFEST only depends on MANIFEST.in and setup.py, which can cause files to be missed when building an sdist.

In particular: given a MANIFEST.in file that includes all documentation in a 'Doc' subdirectory, using"recursive-include Doc *.txt" in the template, the MANIFEST won't get regenerated when a new file is added to the documentation subdirectory and hence that new file is not included in sdist distributions.

----------
assignee: tarek
components: Distutils
messages: 105505
nosy: ronaldoussoren, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: distutils sdist is too laze w.r.t. recalculating MANIFEST
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue May 11 18:27:02 2010
From: report at bugs.python.org (Simon Jagoe)
Date: Tue, 11 May 2010 16:27:02 +0000
Subject: [New-bugs-announce] [issue8689] sqlite3 parameter substitution
	breaks with multiple	parameters
In-Reply-To: <1273595222.03.0.475415636905.issue8689@psf.upfronthosting.co.za>
Message-ID: <1273595222.03.0.475415636905.issue8689@psf.upfronthosting.co.za>


New submission from Simon Jagoe <azriphale at gmail.com>:

I have been using sqlalchemy and sqlamp in a project for a while with Python 2.5.x and Python 2.6.4. With a recent upgrade to Python 2.6.5 (on Ubuntu Lucid Lynx), a particular operation began to fail when using sqlite.

I have tracked this to using the sqlite3 module and multiple parameter substitution. See below for a simple test case.

Set up the database:

 >>> import sqlite3
 >>> conn = sqlite3.connect('test.sqlite3')
 >>> c = conn.cursor()
 >>> c.execute('create table test (col integer)')
 >>> c.execute('insert into test values (1)')
 >>> conn.commit()

Actual result:

 >>> c.execute('SELECT coalesce(max(test.col), ?) + ? AS col FROM test', (0, 1))
 >>> c.fetchone()
 (None,)

Expected result:

 >>> c.execute('SELECT coalesce(max(test.col), ?) + ? AS col FROM test', (0, 1))
 >>> c.fetchone()
 (2,)

The expected result can be simulated like this:

 >>> c.execute('SELECT coalesce(max(test.col), 0) + 1 AS col FROM test')
 >>> c.fetchone()
 (2,)

----------
messages: 105525
nosy: azriphale
priority: normal
severity: normal
status: open
title: sqlite3 parameter substitution breaks with multiple parameters
versions: Python 2.6

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

From report at bugs.python.org  Tue May 11 20:39:44 2010
From: report at bugs.python.org (Jason Baker)
Date: Tue, 11 May 2010 18:39:44 +0000
Subject: [New-bugs-announce] [issue8690] multiprocessing.dummy.Queue does
	not expose same	interface as multiprocessing.Queue
In-Reply-To: <1273603184.02.0.789462329458.issue8690@psf.upfronthosting.co.za>
Message-ID: <1273603184.02.0.789462329458.issue8690@psf.upfronthosting.co.za>


New submission from Jason Baker <amnorvend at gmail.com>:

The multiprocessing.dummy.Queue class is merely an import of Queue.Queue.  There are a few methods that this does not provide however:  close, join_thread, and cancel_join_thread.

I don't know what the best way to handle this is, but it should be pretty trivial to add methods that do nothing or at least throw a NotImplementedError.

----------
components: Library (Lib)
messages: 105533
nosy: Jason.Baker
priority: normal
severity: normal
status: open
title: multiprocessing.dummy.Queue does not expose same interface as multiprocessing.Queue
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue May 11 22:21:18 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:21:18 +0000
Subject: [New-bugs-announce] [issue8691] Doc: left alignment is not the
	default for numbers
In-Reply-To: <1273609278.89.0.493567914757.issue8691@psf.upfronthosting.co.za>
Message-ID: <1273609278.89.0.493567914757.issue8691@psf.upfronthosting.co.za>


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

As reported on python-list by Alan G Isaac,
Lib Ref 6.1.3.1. Format Specification Mini-Language, for instance
http://docs.python.org/dev/py3k/library/string.html#formatstrings

wrongly says in the alignment section

"'<' 	Forces the field to be left-aligned within the available space (This is the default.)"

This latter, of course, is not true for number fields.

"(This is the default.)" could be replaced by "(the string default)."
(in any case, the '.' should be outside the () unless one is added after 'space' before '(') and "(the number default)" added to the next line. Or instead the issue of defaults could be addressed in the text below the table.

I am assuming that this issue affects 2.6/7.

----------
assignee: docs at python
components: Documentation
messages: 105536
nosy: docs at python, tjreedy
priority: normal
severity: normal
status: open
title: Doc: left alignment is not the default for numbers
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue May 11 22:23:01 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 11 May 2010 20:23:01 +0000
Subject: [New-bugs-announce] [issue8692] Use divide-and-conquer for faster
	factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

(Making an educated guess about who to add to the Nosy list)

Attached is a patch to improve math.factorial by using a divide-and-conquer algorithm.  The old algorithm performs n-1 multiplications, mostly on numbers with a very large number of digits.

The algorithm in this patch:
- implicitly factors out all powers of two and applies a left-shift at the end.
- performs roughly half as many multiplications (around n/2 + 2*lg n)
- groups the multiplications so most multiplications are on small numbers
- uses a lookup table for n <= 12

There are faster factorial algorithms available, but they're significantly more complicated and rely on a fast prime factorization function.  This one is around 125 lines of code in C (with comments).  I have a pure-Python version that's around 25 lines of code, if anyone is interested.

Here are some timing results for different values of n:

n : old algorithm : new algorithm
1       0.14 us      0.10 us
10      0.63 us      0.12 us
13      0.81 us      0.76 us
100    12.6  us      4.92 us
1k    576    us    118    us
10k    53.6  ms      8.16 ms
100k   12.1  s     443    ms
1M      27   min    23    s
10M    forget it    20    min

I tested that both algorithms return the same answer for all values of n up to 10,000.

----------
assignee: stutzbach
components: Extension Modules
files: factorial.patch
keywords: needs review, patch, patch
messages: 105537
nosy: mark.dickinson, rhettinger, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Use divide-and-conquer for faster factorials
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file17300/factorial.patch

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

From mbnoimi at gmx.com  Wed May 12 05:56:32 2010
From: mbnoimi at gmx.com (M. Bashir Al-Noimi)
Date: Wed, 12 May 2010 05:56:32 +0200
Subject: [New-bugs-announce] Py_Initialize: can't initialize sys standard
	streams
Message-ID: <4BEA26F0.4000400@gmx.com>

Hi All,

After installing python-3.1.2.msi I'm not able to run to python.exe at 
all because it gives me the following error message:

> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> LookupError: unknown encoding: cp720
>
> This application has requested the Runtime to terminate it in an 
> unusual way.
> Please contact the application's support team for more information.


*How I can fix this issue?*

*PS*

    * I'm using WinXp SP3 32Bit
    * I uninstalled python-2.6.3 before installing python-3.1.2.msi


-- 
Best Regards
Muhammad Bashir Al-Noimi
My Blog: http://mbnoimi.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20100512/2bf798bb/attachment.html>

From report at bugs.python.org  Wed May 12 05:25:19 2010
From: report at bugs.python.org (Muhammad Bashir Al-Noimi)
Date: Wed, 12 May 2010 03:25:19 +0000
Subject: [New-bugs-announce] [issue8693] Py_Initialize: can't initialize sys
	standard streams
In-Reply-To: <1273634719.18.0.842243568226.issue8693@psf.upfronthosting.co.za>
Message-ID: <1273634719.18.0.842243568226.issue8693@psf.upfronthosting.co.za>


New submission from Muhammad Bashir Al-Noimi <mbnoimi at gmx.com>:

After installing python-3.1.2.msi I'm not able to run to python.exe at all because it gives me the following error message:

Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp720

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

PS
    * I'm using WinXp SP3 32Bit

----------
components: Windows
files: error.log
messages: 105566
nosy: mbnoimi
priority: normal
severity: normal
status: open
title: Py_Initialize: can't initialize sys standard streams
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file17302/error.log

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

From report at bugs.python.org  Wed May 12 08:14:31 2010
From: report at bugs.python.org (Nathan Phillip Brink)
Date: Wed, 12 May 2010 06:14:31 +0000
Subject: [New-bugs-announce] [issue8694] python3 FAQ mentions unicode()
In-Reply-To: <1273644871.8.0.754393677422.issue8694@psf.upfronthosting.co.za>
Message-ID: <1273644871.8.0.754393677422.issue8694@psf.upfronthosting.co.za>


New submission from Nathan Phillip Brink <ohnobinki at ohnopublishing.net>:

http://docs.python.org/py3k/faq/programming.html#what-does-unicodeerror-ascii-decoding-encoding-error-ordinal-not-in-range-128-mean

When I try to use unicode() from within python3, the call fails. I would actually expect that the FAQ should contain more information concerning the merging of the unicode and str classes. It would be nice if, when this FAQ entry is updated, there is a short discussion on making the code compatible with both python2 and python3, as it appears that's the only way python3 adaption will ever happen.

----------
assignee: docs at python
components: Documentation
messages: 105574
nosy: docs at python, ohnobinki
priority: normal
severity: normal
status: open
title: python3 FAQ mentions unicode()
versions: Python 3.1

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

From report at bugs.python.org  Wed May 12 12:51:26 2010
From: report at bugs.python.org (Senthil)
Date: Wed, 12 May 2010 10:51:26 +0000
Subject: [New-bugs-announce] [issue8695] Issue while installing Python 2.6.5
	in IBM AIX 6.1
In-Reply-To: <1273661486.25.0.2216975723.issue8695@psf.upfronthosting.co.za>
Message-ID: <1273661486.25.0.2216975723.issue8695@psf.upfronthosting.co.za>


New submission from Senthil <senthil_l at infosys.com>:

Hi,
I am trying to install Python 2.6.5 in IBM AIX(6.1) machine. The make seems to failing with the following error.

Fatal Python error: Interpreter not initialized (version mismatch?)
make: *** [sharedmods] IOT/Abort trap (core dumped)

----------
components: Build
files: logs.zip
messages: 105580
nosy: senthil_l
priority: normal
severity: normal
status: open
title: Issue while installing Python 2.6.5 in IBM AIX 6.1
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file17305/logs.zip

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

From report at bugs.python.org  Wed May 12 16:27:13 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 12 May 2010 14:27:13 +0000
Subject: [New-bugs-announce] [issue8696] PEP 391: Adding documentation of
	logging.config.dictConfig
In-Reply-To: <1273674433.57.0.0627786943755.issue8696@psf.upfronthosting.co.za>
Message-ID: <1273674433.57.0.0627786943755.issue8696@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

The attached patch adds a first cut at documenting the PEP 391 dictConfig() feature.  I've taken the PEP 391 text and rearranged it to fit into the existing logging module docs.  I haven't gone through every paragraph and adjusted the markup to use Sphinx roles.

Vinay: I don't think you need to proofread every single bit of text in this patch.  I suggest you look at the following things:

* The start of the 'Configuring Logging' section, which I rewrote.

* The description of dictConfig(), which is assembled from several bits of the PEP.

* The details of the dictionary schema are moved to be first instead of last.  I therefore rewrote the paragraph in the PEP beginning "Before describing the schema in detail..." to one that begins "Describing a logging configuration requires listing..."  Is the new paragraph OK?

If you like the resulting ordering and the rewritten text, then I'll go through the rest of the text adding Sphinx markup, and commit the result.

Thanks!

----------
assignee: vinay.sajip
components: Documentation
files: pep391-docs.txt
keywords: needs review, patch
messages: 105587
nosy: akuchling, vinay.sajip
priority: low
severity: normal
stage: patch review
status: open
title: PEP 391: Adding documentation of logging.config.dictConfig
versions: Python 2.7
Added file: http://bugs.python.org/file17308/pep391-docs.txt

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

From report at bugs.python.org  Wed May 12 16:27:13 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 12 May 2010 14:27:13 +0000
Subject: [New-bugs-announce] [issue8697] PEP 391: Adding documentation of
	logging.config.dictConfig
In-Reply-To: <1273674433.55.0.29048689936.issue8697@psf.upfronthosting.co.za>
Message-ID: <1273674433.55.0.29048689936.issue8697@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

The attached patch adds a first cut at documenting the PEP 391 dictConfig() feature.  I've taken the PEP 391 text and rearranged it to fit into the existing logging module docs.  I haven't gone through every paragraph and adjusted the markup to use Sphinx roles.

Vinay: I don't think you need to proofread every single bit of text in this patch.  I suggest you look at the following things:

* The start of the 'Configuring Logging' section, which I rewrote.

* The description of dictConfig(), which is assembled from several bits of the PEP.

* The details of the dictionary schema are moved to be first instead of last.  I therefore rewrote the paragraph in the PEP beginning "Before describing the schema in detail..." to one that begins "Describing a logging configuration requires listing..."  Is the new paragraph OK?

If you like the resulting ordering and the rewritten text, then I'll go through the rest of the text adding Sphinx markup, and commit the result.

Thanks!

----------
assignee: vinay.sajip
components: Documentation
files: pep391-docs.txt
keywords: needs review, patch
messages: 105588
nosy: akuchling, vinay.sajip
priority: low
severity: normal
stage: patch review
status: open
title: PEP 391: Adding documentation of logging.config.dictConfig
versions: Python 2.7
Added file: http://bugs.python.org/file17307/pep391-docs.txt

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

From report at bugs.python.org  Wed May 12 16:27:17 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 12 May 2010 14:27:17 +0000
Subject: [New-bugs-announce] [issue8698] PEP 391: Adding documentation of
	logging.config.dictConfig
In-Reply-To: <1273674437.89.0.924445396649.issue8698@psf.upfronthosting.co.za>
Message-ID: <1273674437.89.0.924445396649.issue8698@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

The attached patch adds a first cut at documenting the PEP 391 dictConfig() feature.  I've taken the PEP 391 text and rearranged it to fit into the existing logging module docs.  I haven't gone through every paragraph and adjusted the markup to use Sphinx roles.

Vinay: I don't think you need to proofread every single bit of text in this patch.  I suggest you look at the following things:

* The start of the 'Configuring Logging' section, which I rewrote.

* The description of dictConfig(), which is assembled from several bits of the PEP.

* The details of the dictionary schema are moved to be first instead of last.  I therefore rewrote the paragraph in the PEP beginning "Before describing the schema in detail..." to one that begins "Describing a logging configuration requires listing..."  Is the new paragraph OK?

If you like the resulting ordering and the rewritten text, then I'll go through the rest of the text adding Sphinx markup, and commit the result.

Thanks!

----------
assignee: vinay.sajip
components: Documentation
files: pep391-docs.txt
keywords: needs review, patch
messages: 105589
nosy: akuchling, vinay.sajip
priority: low
severity: normal
stage: patch review
status: open
title: PEP 391: Adding documentation of logging.config.dictConfig
versions: Python 2.7
Added file: http://bugs.python.org/file17309/pep391-docs.txt

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

From report at bugs.python.org  Wed May 12 17:00:48 2010
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 12 May 2010 15:00:48 +0000
Subject: [New-bugs-announce] [issue8699] Equality and hashing for
	functools.partial
In-Reply-To: <1273676448.87.0.841686829268.issue8699@psf.upfronthosting.co.za>
Message-ID: <1273676448.87.0.841686829268.issue8699@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

On python-dev came up an idea [1] to support equality (== and !=) and hashing by functools.partial instances.  Van Lindberg provided an implementation written in Python [2].  I've made a very similar implementation in C (in Modules/_functoolsmodule.c).  The Python equivalent of my code is in Lib/test/test_functools.py as the PythonPartialCls class.  The hashing differs a little from Van Lindberg's implementation: I'm computing the "normal form" of the dict as the sorted list of its items (not as the sorted list of the keys followed by the items).  (It was easier to implement this way.)

I haven't made a lot of Python programming in C, so I'm not sure I made everything in the right way (especially the reference counting).  Anyway, I'm attaching my patch.  I'd appreciate every suggestion, and will try to correct my mistakes.
Thanks!

[1] http://mail.python.org/pipermail/python-dev/2010-May/099981.html
[2] http://mail.python.org/pipermail/python-dev/2010-May/099996.html

----------
components: Extension Modules
files: partial_eq_hash.diff
keywords: patch
messages: 105591
nosy: durban
priority: normal
severity: normal
status: open
title: Equality and hashing for functools.partial
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17311/partial_eq_hash.diff

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

From report at bugs.python.org  Wed May 12 20:29:39 2010
From: report at bugs.python.org (Balachander Ganesan)
Date: Wed, 12 May 2010 18:29:39 +0000
Subject: [New-bugs-announce] [issue8700] strip() is removing an extra
	character if the strip	pattern contains "-"
In-Reply-To: <1273688979.04.0.976435378464.issue8700@psf.upfronthosting.co.za>
Message-ID: <1273688979.04.0.976435378464.issue8700@psf.upfronthosting.co.za>


New submission from Balachander Ganesan <gb.balachander at gmail.com>:

Version:
========
Python 2.4.3 (#1, Jan 14 2008, 18:31:21)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-14)] on linux2

Description:
============
When the pattern used for strip contains "-" character then it removes one more characters next to it.

>>> a = 'image-abc-1.2.0-12_1234_123'
>>> b = a.strip('image-')
>>> print b
bc-1.2.0-12_1234_123


>From the above print statement we can see that instead of 'bc-1.2.0-12_1234_123', it prints only 'bc-1.2.0-12_1234_123'. 
The first character "a" next to "-" is missing.

----------
components: Library (Lib)
messages: 105598
nosy: Balachander.Ganesan
priority: normal
severity: normal
status: open
title: strip() is removing an extra character if the strip pattern contains "-"
type: behavior
versions: 3rd party

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

From report at bugs.python.org  Wed May 12 23:19:39 2010
From: report at bugs.python.org (Poor Yorick)
Date: Wed, 12 May 2010 21:19:39 +0000
Subject: [New-bugs-announce] [issue8701] tarfile: first character of member
	names doubled
In-Reply-To: <1273699179.4.0.239975221626.issue8701@psf.upfronthosting.co.za>
Message-ID: <1273699179.4.0.239975221626.issue8701@psf.upfronthosting.co.za>


New submission from Poor Yorick <pooryorick at users.sourceforge.net>:

In the following file, for python 2.6.4, tarfile.list doubles the first character of each member name:

http://watson.nci.nih.gov/cran_mirror/src/contrib/Archive/time/time_1.0.tar.gz

gnu tar handles the file correctly

----------
components: Library (Lib)
messages: 105609
nosy: pooryorick
priority: normal
severity: normal
status: open
title: tarfile: first character of member names doubled
versions: Python 2.6

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

From report at bugs.python.org  Thu May 13 10:05:26 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 13 May 2010 08:05:26 +0000
Subject: [New-bugs-announce] [issue8702] difflib: unified_diff produces
	wrong patches (again)
In-Reply-To: <1273737926.93.0.83825384013.issue8702@psf.upfronthosting.co.za>
Message-ID: <1273737926.93.0.83825384013.issue8702@psf.upfronthosting.co.za>


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

If source/target file for unified format diff context doesn't end with new line, the diff should contain this marker:

\ No newline at end of file

Or else there is information loss when such patch is applied.

http://en.wikipedia.org/wiki/Diff#Unified_format

----------
components: Library (Lib)
messages: 105630
nosy: techtonik
priority: normal
severity: normal
status: open
title: difflib: unified_diff produces wrong patches (again)
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/issue8702>
_______________________________________

From report at bugs.python.org  Thu May 13 12:16:16 2010
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 13 May 2010 10:16:16 +0000
Subject: [New-bugs-announce] [issue8703] Py3k PyList_Type documentation
	mentions types.ListType
In-Reply-To: <1273745776.41.0.112445145635.issue8703@psf.upfronthosting.co.za>
Message-ID: <1273745776.41.0.112445145635.issue8703@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

The Py3k documentation of PyList_Type [1] contains the sentence:
"This is the same object as list and types.ListType in the Python layer."
But there is no types.ListType object in py3k.

[1] http://docs.python.org/dev/py3k/c-api/list.html#PyList_Type

----------
assignee: docs at python
components: Documentation
messages: 105631
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: Py3k PyList_Type documentation mentions types.ListType
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu May 13 16:12:52 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 13 May 2010 14:12:52 +0000
Subject: [New-bugs-announce] [issue8704] cgitb sends a bogus HTTP header if
	the app crashes before	finishing headers
In-Reply-To: <1273759972.28.0.178671810955.issue8704@psf.upfronthosting.co.za>
Message-ID: <1273759972.28.0.178671810955.issue8704@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

If the CGI script crashes before finishing the headers, cgitb will emit invalid HTTP headers before showing the error message.  Below are HTTP headers I received, captured with a packet sniffer.  Note the "<--: spam".

HTTP/1.1 200 OK
Date: Thu, 13 May 2010 14:00:42 GMT
Server: Apache/2.2.9
<!--: spam
Vary: Accept-Encoding
Cache-Control: max-age=0
Expires: Thu, 13 May 2010 14:00:42 GMT
Set-Cookie: ref=; path=/; HttpOnly
Transfer-Encoding: chunked
Content-Type: text/html

That string it emitted by cgitb.reset(), which is trying to reset the browser to a sane state so the error message will be shown.  The problem can be easily fixed by having cgitb.reset() emit two CRLF pairs first, to ensure that we're done with the headers and emitting content:

-    return '''<!--: spam
+    return '''\r\n\r\n<!--: spam

----------
components: Library (Lib)
messages: 105633
nosy: stutzbach
priority: normal
severity: normal
status: open
title: cgitb sends a bogus HTTP header if the app crashes before finishing headers
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu May 13 18:57:24 2010
From: report at bugs.python.org (Dan Koch)
Date: Thu, 13 May 2010 16:57:24 +0000
Subject: [New-bugs-announce] [issue8705] shutil.rmtree with empty filepath
In-Reply-To: <1273769844.52.0.734161024788.issue8705@psf.upfronthosting.co.za>
Message-ID: <1273769844.52.0.734161024788.issue8705@psf.upfronthosting.co.za>


New submission from Dan Koch <kochdb at ornl.gov>:

The following sequence raises an exception, but nonetheless removes all files from the Desktop under Windows Vista.

import os, shutil, user

desktop_dir = os.path.join(user.home, 'Desktop')
os.chdir(desktop_dir)

shutil.rmtree('')

This does not occur under Fedora 12. Not tested on Mac OS X yet.

----------
components: Windows
messages: 105646
nosy: dbkoch
priority: normal
severity: normal
status: open
title: shutil.rmtree with empty filepath
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu May 13 21:10:55 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 May 2010 19:10:55 +0000
Subject: [New-bugs-announce] [issue8706] accept keyword arguments on all
	base type methods and	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

C Python has a real wart in that standard types and library functions that are implemented in C do not always accept keyword arguments:

>>> 'xxxxxx'.find('xx', 4)
4
>>> 'xxxxxx'.find('xx', start=4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: find() takes no keyword arguments
>>> 

While other things do accept keywords:

sorted(s, key=bla)


We should clean this up.  It is not well documented anywhere and I suspect other python implementations (haven't tested this) may accept keywords on these where C Python doesn't.

In string.find()'s case it looks like this is because it is an old style C method declaration that only gets an args tuple, no keyword args dict.

----------
messages: 105652
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: accept keyword arguments on all base type methods and builtins
type: feature request
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri May 14 01:36:30 2010
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 13 May 2010 23:36:30 +0000
Subject: [New-bugs-announce] [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/dev/library/telnetlib.html#telnetlib.Telnet

The part "number can be passed to the constructor... " is duplicated.

----------
assignee: docs at python
components: Documentation
messages: 105667
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Duplicated document in telnetlib.
versions: Python 2.7

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

From report at bugs.python.org  Fri May 14 02:42:25 2010
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 14 May 2010 00:42:25 +0000
Subject: [New-bugs-announce] [issue8708] OpenID blunder
In-Reply-To: <AANLkTikxYcJh5V8g22jQBc4fE-_NRbnEP-7MTVl8MYd9@mail.gmail.com>
Message-ID: <AANLkTikxYcJh5V8g22jQBc4fE-_NRbnEP-7MTVl8MYd9@mail.gmail.com>


New submission from Jack Diederich <jackdied at gmail.com>:

I tried logging into the tracker using my gmail login and accidentally
created a new user.  Could someone either wipe out the OpenID for
jackdied at gmail.com (but NOT the "jackdied" login with email addy of
jackdied at gmail.com) or combine the two?

In the end I just reset my password and logged in as the original "jackdied"

TIA,

-Jack

----------
messages: 105672
nosy: Jack.Diederich
priority: normal
severity: normal
status: open
title: OpenID blunder

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

From report at bugs.python.org  Fri May 14 09:43:15 2010
From: report at bugs.python.org (akira)
Date: Fri, 14 May 2010 07:43:15 +0000
Subject: [New-bugs-announce] [issue8709] mention explicitly Windows support
	for os.devnull
In-Reply-To: <1273822995.3.0.430966516538.issue8709@psf.upfronthosting.co.za>
Message-ID: <1273822995.3.0.430966516538.issue8709@psf.upfronthosting.co.za>


New submission from akira <4kir4.1i at gmail.com>:

Currently it is not obvious that os.devnull works on Windows.

----------
assignee: docs at python
components: Documentation
files: doc-os-devnull-windows-r81160.diff
keywords: patch
messages: 105688
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: mention explicitly Windows support for os.devnull
type: feature request
Added file: http://bugs.python.org/file17331/doc-os-devnull-windows-r81160.diff

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

From report at bugs.python.org  Fri May 14 12:55:57 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 14 May 2010 10:55:57 +0000
Subject: [New-bugs-announce] [issue8710] test_xpickle: compat tests:
	workaround for missing	test_support
In-Reply-To: <1273834557.81.0.420477221669.issue8710@psf.upfronthosting.co.za>
Message-ID: <1273834557.81.0.420477221669.issue8710@psf.upfronthosting.co.za>


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

When the system python does not have the Lib/test directory, the
compat tests are failing.


======================================================================
ERROR: test_attribute_name_interning (test.test_xpickle.CPicklePython26Compat)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/svn/trunk/Lib/test/pickletester.py", line 959, in test_attribute_name_interning
    s = self.dumps(x, proto)
  File "/home/stefan/svn/trunk/Lib/test/test_xpickle.py", line 114, in dumps
    return self.send_to_worker(self.python, arg, proto)
  File "/home/stefan/svn/trunk/Lib/test/test_xpickle.py", line 110, in send_to_worker
    raise RuntimeError(stderr)
RuntimeError: Traceback (most recent call last):
  File "/home/stefan/svn/trunk/Lib/test/test_xpickle.py", line 17, in <module>
    from test import test_support
ImportError: No module named test

----------
components: Tests
messages: 105698
nosy: collinwinter, skrah
priority: normal
severity: normal
status: open
title: test_xpickle: compat tests: workaround for missing test_support
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri May 14 15:34:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 13:34:16 +0000
Subject: [New-bugs-announce] [issue8711] Document PyUnicode_DecodeFSDefault()
	and	PyUnicode_DecodeFSDefaultAndSize()
In-Reply-To: <1273844056.41.0.804262105587.issue8711@psf.upfronthosting.co.za>
Message-ID: <1273844056.41.0.804262105587.issue8711@psf.upfronthosting.co.za>


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

Attached patch document PyUnicode_DecodeFSDefault() and PyUnicode_DecodeFSDefaultAndSize() in Doc/c-api/, and fix comment in Include/unicodeobject.c (remove reference to bytearray, and specify that surrogateescape is used).

The patch adds also titles to group unicode functions and methods by topic.

----------
assignee: docs at python
components: Documentation, Unicode
files: unicode_doc.patch
keywords: patch
messages: 105706
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: Document PyUnicode_DecodeFSDefault() and PyUnicode_DecodeFSDefaultAndSize()
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17336/unicode_doc.patch

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

From report at bugs.python.org  Fri May 14 16:13:58 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 14 May 2010 14:13:58 +0000
Subject: [New-bugs-announce] [issue8712] Skip libpthread related test
	failures on OpenBSD
In-Reply-To: <1273846438.33.0.702131731388.issue8712@psf.upfronthosting.co.za>
Message-ID: <1273846438.33.0.702131731388.issue8712@psf.upfronthosting.co.za>


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

[Added OpenBSD Python port maintainers to the nosy list.]

I've identified a number of tests that all pass when Python is compiled
without threads, but fail otherwise. The failures are probably caused
by libpthread issues in OpenBSD, as described in this patch:


http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.6/patches/patch-Lib_test_test_signal_py


Would you agree that it is reasonable to skip all these tests until
libpthread is fixed?

----------
components: Tests
files: openbsd_libpthread_skips.patch
keywords: needs review, patch
messages: 105709
nosy: djmdjm, henry.precheur, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Skip libpthread related test failures on OpenBSD
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17337/openbsd_libpthread_skips.patch

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

From report at bugs.python.org  Fri May 14 18:13:11 2010
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Fri, 14 May 2010 16:13:11 +0000
Subject: [New-bugs-announce] [issue8713] multiprocessing needs option to
	eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>


New submission from Brandon Craig Rhodes <brandon at rhodesmill.org>:

The "multiprocessing" module uses a bare fork() to create child processes under Linux, so the children get a copy of the entire state of the parent process.  But under Windows, child processes are freshly spun-up Python interpreters with none of the data structures or open connections of the parent process available.  This means that code that tests fine under Linux, because it is depending on residual parent state in a way that the programmer has not noticed, can fail spectacularly under Windows.

Therefore, the "multiprocessing" module should offer an option under Linux that ignores the advantage of being able to do a bare fork() and instead spins up a new interpreter instance just like Windows does.  Some developers will just use this for testing under Linux, so their test results are valid for Windows too; and some developers might even use this in production, preferring to give up a bit of efficiency under Linux in return for an application that will show the same behavior on both platforms.  Either way, an option that lets the developer subvert the simple "sys.platform != 'win32'" check in "forking.py" would go a long way towards helping us write platform-agnostic Python programs.

----------
components: Library (Lib)
messages: 105719
nosy: brandon-rhodes
priority: normal
severity: normal
status: open
title: multiprocessing needs option to eschew fork() under Linux
type: feature request
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/issue8713>
_______________________________________

From report at bugs.python.org  Fri May 14 18:26:04 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 14 May 2010 16:26:04 +0000
Subject: [New-bugs-announce] [issue8714] Delayed signals in the REPL on
	OpenBSD (possibly	libpthread related)
In-Reply-To: <1273854364.73.0.120471958938.issue8714@psf.upfronthosting.co.za>
Message-ID: <1273854364.73.0.120471958938.issue8714@psf.upfronthosting.co.za>


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

On OpenBSD, SIGINT handling in the REPL is delayed until further input:

Python 2.7b2+ (trunk:81162, May 14 2010, 14:47:52) 
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>>  <= here Ctrl-C is pressed but nothing appears
Only after hitting <Return> a traceback appears:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyboardInterrupt


This behavior was introduced (exposed by?) r68460.


When Python is compiled without threads, the behavior is normal.

----------
components: Interpreter Core
messages: 105720
nosy: djmdjm, henry.precheur, skrah
priority: normal
severity: normal
status: open
title: Delayed signals in the REPL on OpenBSD (possibly libpthread related)
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri May 14 18:53:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 16:53:54 +0000
Subject: [New-bugs-announce] [issue8715] Create PyUnicode_EncodeFSDefault()
	function
In-Reply-To: <1273856034.98.0.139429807226.issue8715@psf.upfronthosting.co.za>
Message-ID: <1273856034.98.0.139429807226.issue8715@psf.upfronthosting.co.za>


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

PyUnicode_EncodeFSDefault() is the opposite of PyUnicode_DecodeFSDefault(AndSize)() and is similar to the new function os.fsencode(). As you can see in the patch, it simplifies many functions.

/* Encodes a Unicode object to Py_FileSystemDefaultEncoding with the
   "surrogateescape" error handler and returns a bytes object.

   If Py_FileSystemDefaultEncoding is not set, fall back to UTF-8.
*/

PyAPI_FUNC(PyObject*) PyUnicode_EncodeFSDefault(
    PyObject *unicode
    );

The function unify the behaviour when Py_FileSystemDefaultEncoding is NULL: use UTF-8 whereas import uses ASCII. Other functions did already fall back to UTF-8: PyUnicode_AsEncodedString() uses PyUnicode_GetDefaultEncoding() (hardcoded to utf8 in Python3) if encoding is NULL

The patch does also fix tkinter module initializer (use surrogateescape error handler, instead of strict).

The patch was first attached to issue #8611.

----------
components: Interpreter Core, Unicode
files: pyunicode_encodefsdefault-2.patch
keywords: patch
messages: 105721
nosy: Arfrever, benjamin.peterson, ezio.melotti, gregory.p.smith, haypo, lemburg, loewis, pitrou
priority: normal
severity: normal
status: open
title: Create PyUnicode_EncodeFSDefault() function
versions: Python 3.2
Added file: http://bugs.python.org/file17340/pyunicode_encodefsdefault-2.patch

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

From report at bugs.python.org  Fri May 14 20:21:52 2010
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 14 May 2010 18:21:52 +0000
Subject: [New-bugs-announce] [issue8716] test_tk fails on OS X if run from
	buildbot slave daemon	-- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

test_tk fails on OS X if test is run from a daemon process without the privilege to access the window server, say a buildbot slave without anyone logged in to the console.  The Tk support needs to check whether it has access rights to the window server before trying to access it.

Workaround is to log buildbot into the console of the OS X machine (which usually but not always works), or to run tests manually.

----------
components: Tests, Tkinter
messages: 105733
nosy: janssen
priority: normal
severity: normal
stage: needs patch
status: open
title: test_tk fails on OS X if run from buildbot slave daemon -- crashes Python
type: crash
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/issue8716>
_______________________________________

From report at bugs.python.org  Fri May 14 20:34:36 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 14 May 2010 18:34:36 +0000
Subject: [New-bugs-announce] [issue8717] Subprocess.py broken in trunk
In-Reply-To: <1273862076.01.0.24732603883.issue8717@psf.upfronthosting.co.za>
Message-ID: <1273862076.01.0.24732603883.issue8717@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

There seems to have been some broken commit on subprocess.py in trunk - the moduel can't be imported due to unexisting argument defaults.

Here is a very quick patch, but more inquiry migh tbe necessary to find out what happened.

----------
files: broken_subprocess.patch
keywords: patch
messages: 105736
nosy: pakal
priority: normal
severity: normal
status: open
title: Subprocess.py broken in trunk
versions: Python 2.7
Added file: http://bugs.python.org/file17344/broken_subprocess.patch

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

From report at bugs.python.org  Fri May 14 23:35:59 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 14 May 2010 21:35:59 +0000
Subject: [New-bugs-announce] [issue8718] subprocess: NameError: name
	'WaitForSingleObject' is not	def
In-Reply-To: <1273872959.97.0.102305569276.issue8718@psf.upfronthosting.co.za>
Message-ID: <1273872959.97.0.102305569276.issue8718@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

This was a regression due to a commit made less than 2 days ago.

make: [build_pywin32] running 'F:\as\apy\build\pyhg_trunk-win64-x64-hgtip27-rrun
\python\PCbuild\amd64\python.exe setup.py build' in 'build\pyhg_trunk-win64-x64-
hgtip27-rrun\pywin32'
Traceback (most recent call last):
  File "setup.py", line 83, in <module>
    from distutils.command.build_ext import build_ext
  File "F:\as\apy\build\pyhg_trunk-win64-x64-hgtip27-rrun\python\lib\distutils\c
ommand\build_ext.py", line 23, in <module>
    from distutils.msvccompiler import get_build_version
  File "F:\as\apy\build\pyhg_trunk-win64-x64-hgtip27-rrun\python\lib\distutils\m
svccompiler.py", line 657, in <module>
    from distutils.msvc9compiler import MSVCCompiler
  File "F:\as\apy\build\pyhg_trunk-win64-x64-hgtip27-rrun\python\lib\distutils\m
svc9compiler.py", line 18, in <module>
    import subprocess
  File "F:\as\apy\build\pyhg_trunk-win64-x64-hgtip27-rrun\python\lib\subprocess.
py", line 611, in <module>
    class Popen(object):
  File "F:\as\apy\build\pyhg_trunk-win64-x64-hgtip27-rrun\python\lib\subprocess.
py", line 911, in Popen
    _WaitForSingleObject=WaitForSingleObject,
NameError: name 'WaitForSingleObject' is not defined

----------
components: Library (Lib)
messages: 105768
nosy: srid
priority: normal
severity: normal
status: open
title: subprocess: NameError: name 'WaitForSingleObject' is not def
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat May 15 00:19:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 22:19:41 +0000
Subject: [New-bugs-announce] [issue8719] buildbot: segfault on FreeBSD
	(signal 11)
In-Reply-To: <1273875581.36.0.231394687131.issue8719@psf.upfronthosting.co.za>
Message-ID: <1273875581.36.0.231394687131.issue8719@psf.upfronthosting.co.za>


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

There are segfaults on x86 FreeBSD 7.2 3.x. It looks like it's a regression introduced by r80876.

---

Build 556:
...
test_coding
test_hash
test_strtod
test_float
test_runpy
*** Signal 11

Build 555:
...
test_int
test_smtplib
test_asynchat
test_runpy
*** Signal 11

Build 554:
...
test_lib2to3
test_pickle
test_xml_etree
test_sys
[34438 refs]
[34470 refs]
[34728 refs]
[34468 refs]
*** Signal 11

Build 553:
...
test_robotparser
test_plistlib
test_signal
test_runpy
*** Signal 11

Build 552:
...
test_importlib
test_crypt
test_sort
test_runpy
*** Signal 11

Build 551:
...
./python -E -c 'import sys ; from sysconfig import get_platform ; print(get_platform()+"-"+sys.version[0:3])' >platform
[34466 refs]
./python -Wd -E -bb ./Lib/test/regrtest.py -uall -rwW -l 
== CPython 3.2a0 (py3k:81134, May 13 2010, 14:25:32) [GCC 4.2.1 20070719 [FreeBSD]]
==   FreeBSD-7.2-RELEASE-i386-32bit-ELF
==   /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/build/test_python_22056
Using random seed 3201291
test_exceptions
*** Signal 11

Build 550:
...
test_codecencodings_tw
test_zipfile
test_import
test_exceptions
*** Signal 11

Build 549:
...
test___future__
test_smtpnet
test_exceptions
*** Signal 11

(...)

Build 530 (r80876): ... signal 11
(Build 526..529 failed with svn exceptions)
Build 525 (r80775) didn't crashed.

----------
messages: 105775
nosy: haypo
priority: normal
severity: normal
status: open
title: buildbot: segfault on FreeBSD (signal 11)
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Sat May 15 00:59:55 2010
From: report at bugs.python.org (holger krekel)
Date: Fri, 14 May 2010 22:59:55 +0000
Subject: [New-bugs-announce] [issue8720] undo findsource regression/change
In-Reply-To: <1273877995.17.0.0354087541128.issue8720@psf.upfronthosting.co.za>
Message-ID: <1273877995.17.0.0354087541128.issue8720@psf.upfronthosting.co.za>


New submission from holger krekel <holger.krekel at gmail.com>:

Somewhere between python 3.0.1 and 3.1.2 the behaviour of inspect.findsource changed: it does not find the source code anymore for a code object whose filename/source is in the linecache.cache because instead of the previous::

    file = getsourcefile(object) or getfile(object)

it only does now::

    file = getsourcefile(object) 

IMO it is enough if findsource() raises if it can't eventually discover the source code - i don't see the need to do this ahead.

In any case, the r312 findsource version requires an ugly work around within py.test in order for it to continue to be able to use the inspect module with dynamically compiled code.  The underlying issue is that at code-compile time no sensible (PEP302 compliantly loaded) module can be constructed because this is only known at exec-time but this is not part of the test tool API and is done somewhere in user code. 

Proposed fix: revert to r301 behaviour and add back "or getfile(object)" to the first line of inspect.findsource()

----------
components: Library (Lib)
messages: 105776
nosy: benjamin.peterson, hpk
priority: normal
severity: normal
status: open
title: undo findsource regression/change
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sat May 15 04:28:53 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 15 May 2010 02:28:53 +0000
Subject: [New-bugs-announce] [issue8721] urlparse.urlsplit regression in 2.7
In-Reply-To: <1273890533.08.0.00904803911562.issue8721@psf.upfronthosting.co.za>
Message-ID: <1273890533.08.0.00904803911562.issue8721@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

[storage at nas0 ~]$ python2.6 -c "import urlparse; print urlparse.urlsplit('http://www.famfamfam.com](http://www.famfamfam.com/', 'http', True)"
SplitResult(scheme='http', netloc='www.famfamfam.com](http:', path='//www.famfamfam.com/', query='', fragment='')
[storage at nas0 ~]$ python2.7 -c "import urlparse; print urlparse.urlsplit('http://www.famfamfam.com](http://www.famfamfam.com/', 'http', True)"
('urlsplit() - %s, scheme=%s, allow_fragments=%s', 'http://www.famfamfam.com](http://www.famfamfam.com/', 'http', True)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/apy/APy27/lib/python2.7/urlparse.py", line 184, in urlsplit
    raise ValueError("Invalid IPv6 URL")
ValueError: Invalid IPv6 URL
[storage at nas0 ~]$

via http://bitbucket.org/tarek/distribute/issue/160

----------
components: Library (Lib)
messages: 105785
nosy: srid
priority: normal
severity: normal
status: open
title: urlparse.urlsplit regression in 2.7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat May 15 06:10:58 2010
From: report at bugs.python.org (Paul Davis)
Date: Sat, 15 May 2010 04:10:58 +0000
Subject: [New-bugs-announce] [issue8722] Documentation for __getattr__
In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>
Message-ID: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>


New submission from Paul Davis <paul.joseph.davis at gmail.com>:

The docs for __getattr__ in the object model section could be more specific on the behavior when a @property raises an AttributeError and there is a custom __getattr__ defined. Specifically, it wasn't exactly clear that __getattr__ would be invoked after a @property was found and evaluated.

The attached script demonstrates the issue on OS X 10.6, Python 2.6.1

I'm thinking something along the lines of:

If the attribute search encounters an AttributeError (perhaps due to a @property raising the error) the search is considered a failure and __getattr__ is invoked.

----------
assignee: docs at python
components: Documentation
files: example.py
messages: 105790
nosy: Paul.Davis, docs at python
priority: normal
severity: normal
status: open
title: Documentation for __getattr__
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file17349/example.py

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

From report at bugs.python.org  Sat May 15 08:02:46 2010
From: report at bugs.python.org (James Morgan)
Date: Sat, 15 May 2010 06:02:46 +0000
Subject: [New-bugs-announce] [issue8723] IDLE won't start import os error
In-Reply-To: <1273903366.17.0.918420762787.issue8723@psf.upfronthosting.co.za>
Message-ID: <1273903366.17.0.918420762787.issue8723@psf.upfronthosting.co.za>


New submission from James Morgan <jmorg1989 at gmail.com>:

Hi,

For some reason I have recently lost the ability to open IDLE for python 2.6.2.

I was able to open it for 2.5 without issue. I reinstalled 2.6.2 several times, removed 2.5, tried 2.6.5 instead, still cannot load IDLE. I can load the python command prompt however.

When attempting to run idle through cmd.exe I get an error in line 3 of pyshell.py

"import os
ImportError: No module named os"

Any help on this issue would be greatly appreciated.

----------
components: IDLE
messages: 105792
nosy: gromij
priority: normal
severity: normal
status: open
title: IDLE won't start import os error
versions: Python 2.6

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

From report at bugs.python.org  Sat May 15 14:22:07 2010
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 15 May 2010 12:22:07 +0000
Subject: [New-bugs-announce] [issue8724] bind_and_activate parameter is
	missed from directive
In-Reply-To: <1273926127.04.0.976754673926.issue8724@psf.upfronthosting.co.za>
Message-ID: <1273926127.04.0.976754673926.issue8724@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/dev/library/simplexmlrpcserver.html#SimpleXMLRPCServer.SimpleXMLRPCServer

bind_and_activate parameter is described but not defined in directive.

----------
messages: 105803
nosy: naoki
priority: normal
severity: normal
status: open
title: bind_and_activate parameter is missed from directive

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

From report at bugs.python.org  Sat May 15 14:39:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 May 2010 12:39:06 +0000
Subject: [New-bugs-announce] [issue8725] Python3: use ASCII for the file
	system encoding on	initfsencoding() failure
In-Reply-To: <1273927146.76.0.292282765786.issue8725@psf.upfronthosting.co.za>
Message-ID: <1273927146.76.0.292282765786.issue8725@psf.upfronthosting.co.za>


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

I introduced initfsencoding() in #8610 to ensure that Py_FileSystemEncoding is not more NULL. In the discussion, Marc Lemburg noticed that falling back the UTF-8 on nl_langinfo(CODESET) error is a bad idea: ASCII is better (I agree).

We cannot fall back to ASCII yet because there are two other problems that have to be fixed before that:

 - Python3 doesn't support surrogates in module filenames: see #8611
 - If Py_FileSystemEncoding is NULL, encoding functions fallback to utf-8 (PyUnicode_GetDefaultEncoding()). #8715 proposes a new PyUnicode_EncodeFSDefault() function to fix this problem

Attached patch is a partial fix for this issue.

----------
components: Interpreter Core, Unicode
files: fsencoding_ascii.patch
keywords: patch
messages: 105804
nosy: haypo
priority: normal
severity: normal
status: open
title: Python3: use ASCII for the file system encoding on initfsencoding() failure
versions: Python 3.2
Added file: http://bugs.python.org/file17353/fsencoding_ascii.patch

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

From report at bugs.python.org  Sat May 15 23:11:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 May 2010 21:11:00 +0000
Subject: [New-bugs-announce] [issue8726] test_capi failure
In-Reply-To: <1273957860.46.0.411830579262.issue8726@psf.upfronthosting.co.za>
Message-ID: <1273957860.46.0.411830579262.issue8726@psf.upfronthosting.co.za>


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

[...]
test_capi
test test_capi failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_capi.py", line 49, in test_no_FatalError_infinite_loop
    b'Fatal Python error:'
AssertionError: b'' != b'Fatal Python error: PyThreadState_Get: no current thread'

----------
components: Library (Lib), Tests
messages: 105824
nosy: pitrou
priority: normal
severity: normal
status: open
title: test_capi failure
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat May 15 23:11:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 May 2010 21:11:01 +0000
Subject: [New-bugs-announce] [issue8727] test_import failure
In-Reply-To: <1273957861.75.0.135836839803.issue8727@psf.upfronthosting.co.za>
Message-ID: <1273957861.75.0.135836839803.issue8727@psf.upfronthosting.co.za>


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

[...]
test_import
Warning -- sys.path was modified by test_import
test test_import failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_import.py", line 167, in test_module_with_large_stack
    exec('import ' + module)
  File "<string>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/importlib/_bootstrap.py", line 151, in decorated
    return fxn(self, module)
  File "/home/antoine/py3k/__svn__/Lib/importlib/_bootstrap.py", line 320, in load_module
    code_object = self.get_code(module.__name__)
  File "/home/antoine/py3k/__svn__/Lib/importlib/_bootstrap.py", line 429, in get_code
    "object for {0!r}".format(fullname))
ImportError: no source or bytecode available to create code object for 'longlist'

----------
components: Library (Lib), Tests
messages: 105825
nosy: pitrou
priority: normal
severity: normal
status: open
title: test_import failure
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun May 16 00:01:22 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 15 May 2010 22:01:22 +0000
Subject: [New-bugs-announce] [issue8728] 2.7 regression in httplib.py:
	AttributeError: 'NoneType'	object has no attribute 'makefile'
In-Reply-To: <1273960882.3.0.07398568579.issue8728@psf.upfronthosting.co.za>
Message-ID: <1273960882.3.0.07398568579.issue8728@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

On Linux, with Python 2.7 trunk (built on May 13th)

[...]
  File "/home/apy/as/pypm-trunk/eggs/httplib2-0.6.0-py2.7.egg/httplib2/__init__.py", line 1129, in request
    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)
  File "/home/apy/as/pypm-trunk/eggs/httplib2-0.6.0-py2.7.egg/httplib2/__init__.py", line 912, in _request
    (response, content) = self._conn_request(conn, request_uri, method, body, headers, )
  File "/home/apy/as/pypm-trunk/eggs/httplib2-0.6.0-py2.7.egg/httplib2/__init__.py", line 871, in _conn_request
    response = conn.getresponse()
  File "/opt/ActivePython-2.7/lib/python2.7/httplib.py", line 1022, in getresponse
    response = self.response_class(*args, **kwds)
  File "/opt/ActivePython-2.7/lib/python2.7/httplib.py", line 340, in __init__
    self.fp = sock.makefile('rb', 0)
AttributeError: 'NoneType' object has no attribute 'makefile'

----------
components: Library (Lib)
messages: 105831
nosy: krisvale, srid
priority: normal
severity: normal
status: open
title: 2.7 regression in httplib.py: AttributeError: 'NoneType' object has no attribute 'makefile'
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sun May 16 00:08:12 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 15 May 2010 22:08:12 +0000
Subject: [New-bugs-announce] [issue8729] The Mapping ABC's __eq__ method
	should return	NotImplemented if the other type is not a Mapping
In-Reply-To: <1273961292.4.0.504404217276.issue8729@psf.upfronthosting.co.za>
Message-ID: <1273961292.4.0.504404217276.issue8729@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The Mapping ABC's __eq__ method should return NotImplemented if the other type is not a Mapping, to give the other type a chance at the comparison.  Right now it simply returns false.

The comparison methods on the other ABCs in _abcoll.py already return NotImplemented if they don't recognize the other type.

----------
components: Library (Lib)
files: mapping.patch
keywords: patch
messages: 105833
nosy: stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: The Mapping ABC's __eq__ method should return NotImplemented if the other type is not a Mapping
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17355/mapping.patch

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

From report at bugs.python.org  Sun May 16 14:21:57 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 16 May 2010 12:21:57 +0000
Subject: [New-bugs-announce] [issue8730] Spurious test failure in distutils
In-Reply-To: <1274012517.83.0.155461681494.issue8730@psf.upfronthosting.co.za>
Message-ID: <1274012517.83.0.155461681494.issue8730@psf.upfronthosting.co.za>


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

Output of test_distutils on a older SuSE Linux system:

FAILED (errors=1, skipped=5)
Traceback (most recent call last):
  File "../Lib/test/test_distutils.py", line 18, in <module>
    test_main()
  File "../Lib/test/test_distutils.py", line 13, in test_main
    test_support.run_unittest(distutils.tests.test_suite())
  File "/home/xsupport/rtest/python-trunk/Lib/test/test_support.py", line 1038, in run_unittest
    _run_suite(suite)
  File "/home/xsupport/rtest/python-trunk/Lib/test/test_support.py", line 1021, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/home/xsupport/rtest/python-trunk/Lib/distutils/tests/test_archive_util.py", line 167, in test_compress_deprecated
    make_tarball(base_name, 'dist', compress='compress')
  File "/home/xsupport/rtest/python-trunk/Lib/distutils/archive_util.py", line 116, in make_tarball
    spawn(cmd, dry_run=dry_run)
  File "/home/xsupport/rtest/python-trunk/Lib/distutils/spawn.py", line 34, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/home/xsupport/rtest/python-trunk/Lib/distutils/spawn.py", line 141, in _spawn_posix
    (cmd[0], exit_status)
DistutilsExecError: command 'compress' failed with exit status 1


This system has a fake 'compress' command that only supports uncompress functionality:

$ compress --help
Usage: compress OPTION FILE
Dummy script for uncompressing legacy shar files.

with OPTION in:
      --help      display this help and exit
      --version   output version information and exit

  -d              uncompress

Use `gzip' for compressing files.

----------
assignee: tarek
components: Distutils
messages: 105862
nosy: ronaldoussoren, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Spurious test failure in distutils
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun May 16 14:29:21 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 16 May 2010 12:29:21 +0000
Subject: [New-bugs-announce] [issue8731] BeOS for 2.7 - add to unsupported
In-Reply-To: <1274012961.91.0.790344514824.issue8731@psf.upfronthosting.co.za>
Message-ID: <1274012961.91.0.790344514824.issue8731@psf.upfronthosting.co.za>


New submission from Roumen Petrov <bugtrack at roumenpetrov.info>:

PEP 11 describe BeOS support as : "Python 2.7 (edit configure to reenable)"

----------
components: Build
files: python-2.7-beos-unsupported.patch
keywords: patch
messages: 105863
nosy: rpetrov
priority: normal
severity: normal
status: open
title: BeOS for 2.7 - add to unsupported
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17364/python-2.7-beos-unsupported.patch

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

From report at bugs.python.org  Sun May 16 16:47:11 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sun, 16 May 2010 14:47:11 +0000
Subject: [New-bugs-announce] [issue8732] Should urrllib2.urlopen send an
	Accept-Encoding header?
In-Reply-To: <1274021231.2.0.0953300031131.issue8732@psf.upfronthosting.co.za>
Message-ID: <1274021231.2.0.0953300031131.issue8732@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

According to the RFC, the server is allowed to send back any encoding it likes when no Accept-Encoding header is supplied, but all the examples I can find of urllib2.urlopen usage assume they're getting plain text back.  I think it would be better to inject an Accept-Encoding header when none is explicitly supplied so that nobody else trips over this issue.

See http://support.github.com/discussions/site/1510

----------
components: Library (Lib)
messages: 105870
nosy: dabrahams
priority: normal
severity: normal
status: open
title: Should urrllib2.urlopen send an Accept-Encoding header?
versions: Python 2.6

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

From report at bugs.python.org  Sun May 16 18:48:56 2010
From: report at bugs.python.org (alon horev)
Date: Sun, 16 May 2010 16:48:56 +0000
Subject: [New-bugs-announce] [issue8733] list type and UserList do not call
	super in __init__ and	therefore,
	they cannot be parents in a multiple inheritence scheme
Message-ID: <1274028536.9.0.783549366424.issue8733@psf.upfronthosting.co.za>


Changes by alon horev <alonho at gmail.com>:


----------
components: Extension Modules
nosy: alonho
priority: normal
severity: normal
status: open
title: list type and UserList do not call super in __init__ and therefore, they cannot be parents in a multiple inheritence scheme
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun May 16 20:22:13 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sun, 16 May 2010 18:22:13 +0000
Subject: [New-bugs-announce] [issue8734] msvcrt get_osfhandle crash on bad FD
In-Reply-To: <1274034133.01.0.249446827178.issue8734@psf.upfronthosting.co.za>
Message-ID: <1274034133.01.0.249446827178.issue8734@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

In python trunk, _set_invalid_parameter_handler() has been dropped and replaced by custom checking functions, but in msvcrt.get_osfhandle() these checks aren't present, so providing a bad FD leads to a crash.

Here is the little fix + a test (added to test_fileio, because I can't find unit tests for the msvcrt builtin, and similar "bad fd" cases are treated there).

----------
components: IO
files: msvcrt_crash.patch
keywords: patch
messages: 105872
nosy: pakal
priority: normal
severity: normal
status: open
title: msvcrt get_osfhandle crash on bad FD
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file17369/msvcrt_crash.patch

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

From report at bugs.python.org  Sun May 16 21:34:56 2010
From: report at bugs.python.org (John W. Shipman)
Date: Sun, 16 May 2010 19:34:56 +0000
Subject: [New-bugs-announce] [issue8735] optparse: parse_args(values=...)
	does not set up default	values
In-Reply-To: <1274038496.46.0.600699975761.issue8735@psf.upfronthosting.co.za>
Message-ID: <1274038496.46.0.600699975761.issue8735@psf.upfronthosting.co.za>


New submission from John W. Shipman <john at nmt.edu>:

optparse's .parse_args() method has a 'values=...' keyword argument
that is documented as:

    'object to store option arguments in (default: a new instance of
    optparse.Values)'

There is no description of what types this argument may have.
I was writing a class to digest the command line, and my bright
idea was to request that .parse_args deposit the attribute
values right into 'self' in the class constructor.

This works only for arguments that were actually specified; it
stores no attribute value at all for missing options that have
associated default options.

Below is a small script that demonstrates this behavior.  It
accepts one '-t' option, with default value 'DEFAULT'.  Here
is the output when the option is specified, and when it is not:

$ bad -t foo
foo
$ bad
Traceback (most recent call last):
  File "bad", line 23, in <module>
    main()
  File "bad", line 13, in main
    print args.test
AttributeError: Args instance has no attribute 'test'

Here is the test script:

#!/usr/bin/env python
#================================================================
# bad:  Demonstrate defect in optparse.
#   I want optparse to honor the .parse_args(values=...)
#  argument to store the attributes directly in self in the
#  constructor.  It works only for options actually specified;
#  default values are not copied into self.
#----------------------------------------------------------------
import sys, optparse

def main():
    args = Args()
    print args.test

class Args:
    def __init__(self):
        parser = optparse.OptionParser()
        parser.add_option ( "-t", "--test", dest="test",
            type="string", default="DEFAULT" )
        discard, positionals = parser.parse_args(values=self)

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

----------
components: Library (Lib)
messages: 105875
nosy: john at nmt.edu
priority: normal
severity: normal
status: open
title: optparse: parse_args(values=...) does not set up default values
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun May 16 22:23:06 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 16 May 2010 20:23:06 +0000
Subject: [New-bugs-announce] [issue8736] *= is undocumented for lists
Message-ID: <1274041386.78.0.769910739974.issue8736@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
assignee: stutzbach
components: Documentation
keywords: easy
nosy: stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: *= is undocumented for lists
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun May 16 23:31:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 May 2010 21:31:24 +0000
Subject: [New-bugs-announce] [issue8737] ssl.RAND_add() should only accept
	bytes (not str)
In-Reply-To: <1274045484.85.0.763677080971.issue8737@psf.upfronthosting.co.za>
Message-ID: <1274045484.85.0.763677080971.issue8737@psf.upfronthosting.co.za>


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

PySSL_RAND_add() uses PyArg_ParseTuple(args, "s#d:RAND_add", ...) and so converts implicitly str to bytes using UTF-8. I would prefer that this function only accepts bytes: the user will have to encode str to bytes *explicitly*.

Attached patch replace s# format by y# format.

----------
components: Library (Lib)
files: ssl_rand_add_bytes.patch
keywords: patch
messages: 105879
nosy: haypo
priority: normal
severity: normal
status: open
title: ssl.RAND_add() should only accept bytes (not str)
versions: Python 3.2
Added file: http://bugs.python.org/file17371/ssl_rand_add_bytes.patch

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

From report at bugs.python.org  Mon May 17 12:45:20 2010
From: report at bugs.python.org (=?utf-8?q?Alberto_Planas_Dom=C3=ADnguez?=)
Date: Mon, 17 May 2010 10:45:20 +0000
Subject: [New-bugs-announce] [issue8738] cPickle dumps(tuple) !=
	dumps(loads(dumps(tuple)))
In-Reply-To: <1274093120.19.0.592599712369.issue8738@psf.upfronthosting.co.za>
Message-ID: <1274093120.19.0.592599712369.issue8738@psf.upfronthosting.co.za>


New submission from Alberto Planas Dom?nguez <aplanas at gmail.com>:

Sometimes, when I use cPickle to serialize tuples of strings, I get different dumps() result for the same tuple:

import cPickle
t = ('<s>', 'JOHN')
s1 = cPickle.dumps(t)
s2 = cPickle.dumps(cPickle.loads(cPickle.dumps(t)))
assert s1 == s2     # AssertionError

With cPickle doesn't matter what protocol use por dumps(). The assertion is Ok if I use the pickle module instead of cPickle.

This means that I can't use a serialized object as a key in a map/dict object.

----------
messages: 105896
nosy: Alberto.Planas.Dom?nguez
priority: normal
severity: normal
status: open
title: cPickle dumps(tuple) != dumps(loads(dumps(tuple)))
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon May 17 15:34:09 2010
From: report at bugs.python.org (Alberto Trevino)
Date: Mon, 17 May 2010 13:34:09 +0000
Subject: [New-bugs-announce] [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>


New submission from Alberto Trevino <alberto at byu.edu>:

This patch updates smtpd.py to be more RFC 5321 compliant.  It contains:

 - EHLO support
 - Implement DATA size limit (32 MiB by default)
 - 8-bit mime extension plumbing (doesn't do anything, but accepts and
   records command)
 - Basic VRFY support
 - Basic HELP support
 - A few improvements to messages (more in line with RFC 5321 examples)
 - Misc. documentation updates

The patch is specific to Python 3.1.  I have not tried to backport the changes to 2.x.  If possible, I would like the patch to be considered for inclusion to 3.2.

----------
components: Library (Lib)
files: smtpd.py-0.2-rfc5321-enhancements.diff
keywords: patch
messages: 105902
nosy: alfmel, barry
priority: normal
severity: normal
status: open
title: Update to smtpd.py to RFC 5321
type: feature request
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17380/smtpd.py-0.2-rfc5321-enhancements.diff

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

From report at bugs.python.org  Mon May 17 15:45:51 2010
From: report at bugs.python.org (Christophe Combelles)
Date: Mon, 17 May 2010 13:45:51 +0000
Subject: [New-bugs-announce] [issue8740] infinite recursion with
	setfilesystemencoding and pdb
In-Reply-To: <1274103951.28.0.0596224885808.issue8740@psf.upfronthosting.co.za>
Message-ID: <1274103951.28.0.0596224885808.issue8740@psf.upfronthosting.co.za>


New submission from Christophe Combelles <ccomb at free.fr>:

This leads to a maximum recursion depth error:

$ python3.1
>>> import sys, pdb
>>> sys.setfilesystemencoding('iso8859-7')
>>> pdb.set_trace()

I'm on ubuntu 10.04 x86_64, with LANG=fr_FR.utf8

----------
components: None
messages: 105904
nosy: ccomb
priority: normal
severity: normal
status: open
title: infinite recursion with setfilesystemencoding and pdb
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon May 17 19:45:45 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 17 May 2010 17:45:45 +0000
Subject: [New-bugs-announce] [issue8741] 2.7 regression in tarfile: IOError:
	link could not be	created
In-Reply-To: <1274118345.32.0.801692184283.issue8741@psf.upfronthosting.co.za>
Message-ID: <1274118345.32.0.801692184283.issue8741@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Repro steps:

Download http://appropriatesoftware.net/provide/docs/eternity-0.13.tar.gz (via 'eternity' module in PyPI) and look at the following command line session:

C:\Temp\tfbug>python27 -c "import tarfile as T; T.open('eternity-0.13.tar.gz').extractall()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Python27\lib\tarfile.py", line 2046, in extractall
    self.extract(tarinfo, path)
  File "C:\Python27\lib\tarfile.py", line 2083, in extract
    self._extract_member(tarinfo, os.path.join(path, tarinfo.name))
  File "C:\Python27\lib\tarfile.py", line 2168, in _extract_member
    self.makelink(tarinfo, targetpath)
  File "C:\Python27\lib\tarfile.py", line 2260, in makelink
    raise IOError("link could not be created")
IOError: link could not be created

C:\Temp\tfbug>python26 -c "import tarfile as T; T.open('eternity-0.13.tar.gz').extractall()"

C:\Temp\tfbug>dir eternity-0.13
 Volume in drive C has no label.
 Volume Serial Number is 1877-E6BA

 Directory of C:\Temp\tfbug\eternity-0.13

10/14/2008  06:08 PM    <DIR>          .
10/14/2008  06:08 PM    <DIR>          ..
09/05/2008  01:31 PM               115 AUTHORS
10/14/2008  06:08 PM    <DIR>          bin
09/05/2008  01:31 PM                 0 CHANGES
09/05/2008  01:31 PM            17,998 COPYING
10/14/2008  06:08 PM    <DIR>          etc
09/05/2008  01:31 PM               447 INSTALL
09/11/2008  06:06 PM               231 MANIFEST.in
10/14/2008  06:08 PM               802 PKG-INFO
09/05/2008  01:31 PM               516 README
09/10/2008  04:10 PM             2,948 setup.py
10/14/2008  06:08 PM    <DIR>          src
               8 File(s)         23,057 bytes
               5 Dir(s)   3,493,781,504 bytes free

C:\Temp\tfbug>

----------
components: Library (Lib), Windows
messages: 105920
nosy: lars.gustaebel, srid
priority: normal
severity: normal
status: open
title: 2.7 regression in tarfile: IOError: link could not be created
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon May 17 19:59:02 2010
From: report at bugs.python.org (Patrick Sabin)
Date: Mon, 17 May 2010 17:59:02 +0000
Subject: [New-bugs-announce] [issue8742] broken asdl link in Parser/asdl.py
In-Reply-To: <1274119142.14.0.911032413553.issue8742@psf.upfronthosting.co.za>
Message-ID: <1274119142.14.0.911032413553.issue8742@psf.upfronthosting.co.za>


New submission from Patrick Sabin <patricksabin at gmx.at>:

The link:
http://www.cs.princeton.edu/~danwang/Papers/dsl97/dsl97-abstract.html
in the file Parser/asdl.py seems to be broken. When I tried to open it I got a page with: "Sorry, the page you requested couldn't be found". It seems to me that this is a permanent issue and therefore the link should be removed as there is another link, that works.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 105923
nosy: docs at python, pyfex
priority: normal
severity: normal
status: open
title: broken asdl link in Parser/asdl.py

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

From report at bugs.python.org  Mon May 17 20:50:46 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 17 May 2010 18:50:46 +0000
Subject: [New-bugs-announce] [issue8743] set() operators don't work with
	collections.Set instances
In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
Message-ID: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The set() operators (__or__, __and__, __sub__, __xor__, and their in-place counterparts) require that the parameter also be an instance of set().

They're documented that way:  "This precludes error-prone constructions like set('abc') &  'cbs' in favor of the more readable set('abc').intersection('cbs')."

However, an unintended consequence of this behavior is that they don't inter-operate with user-created types that derive from collections.Set.

That leads to oddities like this:

MySimpleSet() | set()  # This works
set() | MySimpleSet()  # Raises TypeError

(MySimpleSet is a minimal class derived from collections.Set for illustrative purposes -- set attached file)

collections.Set's operators accept any iterable.

I'm not 100% certain what the correct behavior should be.  Perhaps set's operators should be a bit more liberal and accept any collections.Set instance, while collections.Set's operators should be a bit more conservative.  Perhaps not.  It's a little subjective.

It seems to me that at minimum set() and collections.Set() should inter-operate and have the same behavior.

----------
components: Interpreter Core
files: set-vs-set.py
messages: 105929
nosy: stutzbach
priority: normal
severity: normal
stage: unit test needed
status: open
title: set() operators don't work with collections.Set instances
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17383/set-vs-set.py

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

From report at bugs.python.org  Tue May 18 03:26:25 2010
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 18 May 2010 01:26:25 +0000
Subject: [New-bugs-announce] [issue8744] Maybe typo in doc
In-Reply-To: <1274145985.81.0.735711702514.issue8744@psf.upfronthosting.co.za>
Message-ID: <1274145985.81.0.735711702514.issue8744@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/dev/library/test.html#test.test_support.captured_stdout

"This is a context manager than runs the with statement body using a StringIO.StringIO object as sys.stdout."

I think "than" is typo of "that".

----------
assignee: docs at python
components: Documentation
messages: 105946
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Maybe typo in doc
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue May 18 08:08:12 2010
From: report at bugs.python.org (Goplat)
Date: Tue, 18 May 2010 06:08:12 +0000
Subject: [New-bugs-announce] [issue8745] zipimport is a bit slow
In-Reply-To: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za>
Message-ID: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za>


New submission from Goplat <mrnobo1024 at yahoo.com>:

Reading the list of files in a .zip takes a while because several seeks are done for each entry, which (on Windows at least) flushes stdio's buffer and forces a system call on the next read. For large .zips the effect on startup speed is noticeable, being perhaps 50ms per thousand files. Changing the read_directory function to read the central directory entirely sequentially would cut this time by more than half.

----------
components: Interpreter Core
files: zipimport_speedup.patch
keywords: patch
messages: 105954
nosy: Goplat
priority: normal
severity: normal
status: open
title: zipimport is a bit slow
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file17387/zipimport_speedup.patch

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

From report at bugs.python.org  Tue May 18 11:05:21 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 18 May 2010 09:05:21 +0000
Subject: [New-bugs-announce] [issue8746] *chflags detection broken on
	FreeBSD 9-CURRENT
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

os.chflags isn't `available' even though chflags support is available on the system:

>>> filter(lambda x: x.startswith('chflags'), dir(os))
[]
>>> platform.uname()
('FreeBSD', 'bayonetta.local', '9.0-CURRENT', 'FreeBSD 9.0-CURRENT #0 r206173M: Mon Apr 26 22:45:06 PDT 2010     root at bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA.ata', 'amd64', 'amd64')
>>> filter(lambda x: x.startswith('chflags'), dir(os))
[]
>>> sys.version
'2.6.5 (r265:79063, May 16 2010, 23:37:42) \n[GCC 4.2.1 20070719  [FreeBSD]]'

I'm looking into why this is not properly detected via configure (here's the snippet though):

configure:17257: checking for chflags
configure:17288: cc -o conftest -O2 -pipe -fno-strict-aliasing -pipe -O2 -march=nocona -D__wchar_t=wchar_t  -DTHREAD_STACK_SIZE=0x100000  -pthread  conftest.c  >&5
conftest.c:173: error: expected identifier or '(' before '[' token
In file included from /usr/include/sys/_types.h:33,
                 from /usr/include/sys/_timespec.h:37,
                 from /usr/include/sys/stat.h:42,
                 from conftest.c:174:
/usr/include/machine/_types.h:75: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__int_least8_t'
In file included from /usr/include/sys/time.h:37,
                 from /usr/include/sys/stat.h:99,
                 from conftest.c:174:
/usr/include/sys/types.h:64: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int8_t'
conftest.c:182: error: expected identifier or '(' before ']' token
configure:17291: $? = 1

Compiling the standalone test works:

$ cat ~/test_chflags.c 
#include <sys/stat.h>
#include <unistd.h>
int main(int argc, char*argv[])
{
  if(chflags(argv[0], 0) != 0)
    return 1;
  return 0;
}
$ gcc -o ~/test_chflags ~/test_chflags.c
$ echo $?
0

Also, another sidenote: nowhere is *chflags(2) considered a POSIX feature (I doublechecked opengroup.org and Google). It is strictly a _Unix_ feature. I say this because the POSIX functionality tester explicitly looks for this `POSIX' compatible feature.

----------
messages: 105957
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: *chflags detection broken on FreeBSD 9-CURRENT
type: compile error
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Tue May 18 11:13:41 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 18 May 2010 09:13:41 +0000
Subject: [New-bugs-announce] [issue8747] Autoconf tests in python not
	portably correct
In-Reply-To: <1274174021.7.0.201652385814.issue8747@psf.upfronthosting.co.za>
Message-ID: <1274174021.7.0.201652385814.issue8747@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

A number of features are being blindly enabled on python that aren't correct from a porting standpoint; a handful in configure.in I noticed are:

# The later defininition of _XOPEN_SOURCE disables certain features
# on Linux, so we need _GNU_SOURCE to re-enable them (makedev, tm_zone).
AC_DEFINE(_GNU_SOURCE, 1, [Define on Linux to activate all library features])

# The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables
# certain features on NetBSD, so we need _NETBSD_SOURCE to re-enable
# them.
AC_DEFINE(_NETBSD_SOURCE, 1, [Define on NetBSD to activate all library features])

# The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables
# certain features on FreeBSD, so we need __BSD_VISIBLE to re-enable
# them.
AC_DEFINE(__BSD_VISIBLE, 1, [Define on FreeBSD to activate all library features])

# The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables
# u_int on Irix 5.3. Defining _BSD_TYPES brings it back.
AC_DEFINE(_BSD_TYPES, 1, [Define on Irix to enable u_int])

# The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables
# certain features on Mac OS X, so we need _DARWIN_C_SOURCE to re-enable
# them.
AC_DEFINE(_DARWIN_C_SOURCE, 1, [Define on Darwin to activate all library features])

these are only applicable on certain platforms and thus, shouldn't be enabled on all platforms (the default should be off, and then the values should be tuned according to the platform detection performed by autoconf).

----------
components: Build
messages: 105958
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: Autoconf tests in python not portably correct
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Tue May 18 12:37:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 18 May 2010 10:37:16 +0000
Subject: [New-bugs-announce] [issue8748] integer-to-complex comparisons give
	incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

I've just discovered that integer-to-complex comparisons are broken, in all versions of Python that I've tested.  It looks as though the integer is first converted to a complex number, and then the two complex numbers are compared.  That's not correct, and it's contrary to what happens for floats, where there's special handling in place to make sure that exact values are compared.  This leads to loss of transitivity of equality:

>>> n = 2**53+1
[51529 refs]
>>> float(n) == complex(n)  # expect True
True
[51531 refs]
>>> n == float(n)           # expect False
False
[51531 refs]
>>> n == complex(n)         # expect False, but Python returns True
True
[51531 refs]

Apparently the SAGE folks noticed this some time ago, but AFAICT didn't report it as a bug. See http://www.mail-archive.com/sage-devel at googlegroups.com/msg20891.html

For a complex number z and an integer i, 'z == i' should be exactly equivalent to 'z.real == i and z.imag == 0.0'.

----------
assignee: mark.dickinson
components: Interpreter Core
messages: 105963
nosy: mark.dickinson
priority: high
severity: normal
status: open
title: integer-to-complex comparisons give incorrect results
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue May 18 14:06:29 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Tue, 18 May 2010 12:06:29 +0000
Subject: [New-bugs-announce] [issue8749] Cruft in object.c:
	PyObject_GenericGetAttr
In-Reply-To: <1274184389.99.0.605763299992.issue8749@psf.upfronthosting.co.za>
Message-ID: <1274184389.99.0.605763299992.issue8749@psf.upfronthosting.co.za>


New submission from Yaniv Aknin <yaniv.aknin at gmail.com>:

While reading the source I saw that recent py3k has this in Objects/object.c (reasonably recent trunk has it as well):

#if 0 /* XXX this is not quite _PyType_Lookup anymore */
    /* Inline _PyType_Lookup */
    { ... removed ...
    }
#else
    descr = _PyType_Lookup(tp, name);
#endif

This was commented out (on trunk, I assumed on py3k it was for the same reason) by amaury.forgeotdarc on revision 59943, when a patch to the real _PyType_Lookup was applied.

I think it can be safely removed.

----------
components: Interpreter Core
messages: 105967
nosy: Yaniv.Aknin
priority: normal
severity: normal
status: open
title: Cruft in object.c: PyObject_GenericGetAttr
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue May 18 15:44:22 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 18 May 2010 13:44:22 +0000
Subject: [New-bugs-announce] [issue8750] Many of MutableSet's methods assume
	that the other	parameter is not self
In-Reply-To: <1274190262.36.0.827917272731.issue8750@psf.upfronthosting.co.za>
Message-ID: <1274190262.36.0.827917272731.issue8750@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

For example, here is one of MutableSet's methods:

    def __isub__(self, it):
        for value in it:
            self.discard(value)
        return self

However, if I do "x -= x", then it mutates my set-like object during iteration, which even the built-in set does not support.  ior, iand, and ixor have the same problem.

I'm working on running test_set.py (with suitable modifications) on my class that derives from collections.MutableSet, so I'm going to be bumping into all kinds of fun problems like this.

I'm going to override the methods in my class, and I can contribute my new methods back to Python as a patch once they're working.

----------
assignee: stutzbach
components: Library (Lib)
messages: 105974
nosy: stutzbach
priority: normal
severity: normal
stage: unit test needed
status: open
title: Many of MutableSet's methods assume that the other parameter is not self
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue May 18 16:56:49 2010
From: report at bugs.python.org (Vignesh)
Date: Tue, 18 May 2010 14:56:49 +0000
Subject: [New-bugs-announce] [issue8751] Threading and KeyError: 51
In-Reply-To: <1274194609.13.0.380830310916.issue8751@psf.upfronthosting.co.za>
Message-ID: <1274194609.13.0.380830310916.issue8751@psf.upfronthosting.co.za>


New submission from Vignesh <vigneshk at mail.med.upenn.edu>:

I have a python script which runs a particular script large number of times (for monte carlo purpose) and the way I have scripted it is that, I queue up the script the desired number of times it should be run then I spawn threads and each thread runs the script once and again when its done.

Once the script in a particular thread is finished, the output is written to a file by accessing a lock (so my guess was that only one thread accesses the lock at a given time). Once the lock is released by one thread, the next thread accesses it and adds its output to the previously written file and rewrites it. 

I am not facing a problem when the number of iterations is small like 10 or 20 but when its large like 50 or 150, python returns a KeyError: 51 telling me element doesn't exist and the error it points out to is within the lock which puzzles me since only one thread should access the lock at once and I do not expect an error. 

This is the class I use:

class errorclass(threading.Thread):
    
     def __init__(self, queue):
         self.__queue=queue
         threading.Thread.__init__(self)
     
     def run(self):
         while 1:
               item = self.__queue.get()
               if item is None: break
               result = myfunction()
               lock = threading.RLock()
               lock.acquire()
               ADD entries from current thread to entries in file and
               REWRITE FILE           
               lock.release()

----------
components: IDLE
messages: 105981
nosy: Vignesh.K
priority: normal
severity: normal
status: open
title: Threading and KeyError: 51
versions: Python 2.5

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

From report at bugs.python.org  Tue May 18 17:21:12 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 18 May 2010 15:21:12 +0000
Subject: [New-bugs-announce] [issue8752] set_contains,
	etc. should check for collections.Set in addition to PySet_Check
In-Reply-To: <1274196072.83.0.116605329158.issue8752@psf.upfronthosting.co.za>
Message-ID: <1274196072.83.0.116605329158.issue8752@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

For operations that test membership in a set, Python coerces sets and subclasses of set into a temporary frozenset before testing membership.

For example, this works:

>>> set() in set([frozenset()])
True

Although the set() is not hashable itself, Python creates a temporary frozenset() out of the set().  It should do the same for user-types derived from collections.Set, so they can inter-operate in the same way.

In setobject.c, the following methods behave in the described manner: set_contains, set_remove, and set_discard.

----------
components: Interpreter Core
messages: 105983
nosy: stutzbach
priority: normal
severity: normal
stage: unit test needed
status: open
title: set_contains, etc. should check for collections.Set in addition to PySet_Check
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue May 18 17:55:08 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 18 May 2010 15:55:08 +0000
Subject: [New-bugs-announce] [issue8753] Py_ReprEnter and Py_ReprLeave are
	undocumented
Message-ID: <1274198108.41.0.978364995742.issue8753@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
assignee: stutzbach
components: Documentation
nosy: stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Py_ReprEnter and Py_ReprLeave are undocumented
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue May 18 19:03:20 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 18 May 2010 17:03:20 +0000
Subject: [New-bugs-announce] [issue8754] ImportError: quote bad module name
	in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>


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

ImportError messages should quote the name it cannot import since the actual problem may be whitespace in the name that is currently invisible in the message.  In other words, display

ImportError: no module named 'bad name\r'

instead of

ImportError: no module named bad name

This defect lead to the current python-list thread
  pickle unable to load collection

Peter Otten figured out that it was unable to load 'collections\r' rather than 'collections', which he demonstrated with

>>> >>> try: pickle.loads(garbled_data)
... except ImportError as e:
...     e
...
ImportError('No module named collections\r',)

The OP used 2.6, I tested 3.1, hence presume, after searching tracker issues, that this applies to 2.7 and 3.2 as well.

I marked this as a bug since the current message is wrong and misleading. I suspect the same may be true of a few other error messages, but I cannot think of any at the moment.

----------
components: Interpreter Core
messages: 105988
nosy: tjreedy
priority: normal
severity: normal
status: open
title: ImportError: quote bad module name in message
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue May 18 20:21:53 2010
From: report at bugs.python.org (Andy Harrington)
Date: Tue, 18 May 2010 18:21:53 +0000
Subject: [New-bugs-announce] [issue8755] idle crash UnicodeDecodeError utf-8
	codec
In-Reply-To: <1274206913.48.0.235847350829.issue8755@psf.upfronthosting.co.za>
Message-ID: <1274206913.48.0.235847350829.issue8755@psf.upfronthosting.co.za>


New submission from Andy Harrington <aharrin at luc.edu>:

I was editing in idle in python 3.1, typing away.  I had been doing it for hours.  I do not think I had jumped to the shell window.  Suddenly idle crashed, with this error message in the the  ubuntu 9,10 terminal window:

Traceback (most recent call last):
  File "/usr/bin/idle3", line 5, in <module>
    main()
  File "/usr/lib/python3.1/idlelib/PyShell.py", line 1420, in main
    root.mainloop()
  File "/usr/lib/python3.1/tkinter/__init__.py", line 1012, in mainloop
    self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: illegal encoding

I do not know what key combination I had just typed.  I may have just hit a crtl or alt combination.

The hardware is an Acer notebook.

This is certainly an exception that should be caught!  I did not get to even save my work.

----------
components: IDLE
messages: 105996
nosy: andyharrington
priority: normal
severity: normal
status: open
title: idle crash  UnicodeDecodeError utf-8 codec
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Tue May 18 20:38:17 2010
From: report at bugs.python.org (Gavin Roy)
Date: Tue, 18 May 2010 18:38:17 +0000
Subject: [New-bugs-announce] [issue8756] Multiprocessing and UUID bug on Mac
	OSX
In-Reply-To: <1274207897.31.0.857172476403.issue8756@psf.upfronthosting.co.za>
Message-ID: <1274207897.31.0.857172476403.issue8756@psf.upfronthosting.co.za>


New submission from Gavin Roy <gmr at myyearbook.com>:

import multiprocessing
import uuid

def test():
    print str(uuid.uuid4())

p = multiprocessing.Pool(processes=4)
for x in xrange(0, 4):
  p.apply_async(test)

In MacOS:

Gavin-M-Roys-Office-iMac:kvpbench gmr$ python
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> 
>>> 
>>> import multiprocessing
>>> import uuid
>>> 
>>> def test():
...     print str(uuid.uuid4())
... 
>>> p = multiprocessing.Pool(processes=4)
>>> for x in xrange(0, 4):
...   p.apply_async(test)
... 
<multiprocessing.pool.ApplyResult object at 0x10056bb90>
<multiprocessing.pool.ApplyResult object at 0x10064e690>
<multiprocessing.pool.ApplyResult object at 0x10064e750>
<multiprocessing.pool.ApplyResult object at 0x10064e710>
>>> 62c76035-e340-41c4-86b4-908660b73bb7
62c76035-e340-41c4-86b4-908660b73bb7
62c76035-e340-41c4-86b4-908660b73bb7
62c76035-e340-41c4-86b4-908660b73bb7

In Linux:

gmr at binti ~ $ python
Python 2.6.4 (r264:75706, Mar  9 2010, 17:27:45) 
[GCC 4.1.2 (Gentoo 4.1.2 p1.0.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing
>>> import uuid
>>> 
>>> def test():
...     print str(uuid.uuid4())
... 
>>> p = multiprocessing.Pool(processes=4)
>>> for x in xrange(0, 4):
...   p.apply_async(test)
... 
<multiprocessing.pool.ApplyResult object at 0x7dd990>
<multiprocessing.pool.ApplyResult object at 0x86d310>
<multiprocessing.pool.ApplyResult object at 0x86d390>
<multiprocessing.pool.ApplyResult object at 0x86d410>
>>> 6121782c-008d-42db-9df5-bbf619fb6568
ee7d3ef8-1c54-4ab5-bf06-1eddf5bcf2cb
40efe282-65a5-4160-96ee-b4cc0d14029d
9eb799f2-a46c-41e8-901f-423177f3467d

----------
assignee: ronaldoussoren
components: Macintosh
messages: 105997
nosy: Gavin.Roy, ronaldoussoren
priority: normal
severity: normal
status: open
title: Multiprocessing and UUID bug on Mac OSX
versions: Python 2.6

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

From report at bugs.python.org  Tue May 18 23:07:34 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 18 May 2010 21:07:34 +0000
Subject: [New-bugs-announce] [issue8757] Race condition when checking for
	set in set
In-Reply-To: <1274216854.13.0.448353373516.issue8757@psf.upfronthosting.co.za>
Message-ID: <1274216854.13.0.448353373516.issue8757@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

"some_set in some_set_of_sets" contains a race condition that can lead to odd behavior.  To perform the test, the set_contains() function in setobject.c creates a temporary frozenset object (t), swaps the bodies of some_set and t, checks if t is in some_set_of_sets, then swaps the bodies back.

Unfortunately, comparisons or hash functions may release the GIL, so the swapped bodies may be exposed on a different thread, i.e., "some_set in some_set_of_sets" may cause "some_set" to be empty on some other thread.

The same race condition exists in set_discard() and set_remove().

Attached is a short script that demonstrates the problem and could be easily converted to a unit test.

----------
components: Interpreter Core
files: set-race.py
messages: 106007
nosy: stutzbach
priority: normal
severity: normal
status: open
title: Race condition when checking for set in set
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17388/set-race.py

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

From report at bugs.python.org  Tue May 18 23:46:10 2010
From: report at bugs.python.org (Alex)
Date: Tue, 18 May 2010 21:46:10 +0000
Subject: [New-bugs-announce] [issue8758] BUILD_LIST followed by
	BINARY_SUBSCR can be optimized to	a BUILD_TUPLE if all
	members of the list are constants
In-Reply-To: <1274219170.67.0.325819344919.issue8758@psf.upfronthosting.co.za>
Message-ID: <1274219170.67.0.325819344919.issue8758@psf.upfronthosting.co.za>


New submission from Alex <alex.gaynor at gmail.com>:

We do the same thing for a BUILD_LIST followed by a COMPARE_OP (in).

----------
components: Interpreter Core
messages: 106008
nosy: alex
priority: normal
severity: normal
status: open
title: BUILD_LIST followed by BINARY_SUBSCR can be optimized to a BUILD_TUPLE if all members of the list are constants
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue May 18 23:57:44 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 18 May 2010 21:57:44 +0000
Subject: [New-bugs-announce] [issue8759] 2.7: wrong user site directory on
	Linux; totally missing on OSX
In-Reply-To: <1274219864.93.0.0086254840372.issue8759@psf.upfronthosting.co.za>
Message-ID: <1274219864.93.0.0086254840372.issue8759@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

sridharr at triple:~$ /opt/ActivePython-2.7/bin/python -c "import sys; print sys.path; import cmdln"
['', '/opt/ActivePython-2.7/lib/python27.zip', '/opt/ActivePython-2.7/lib/python2.7', '/opt/ActivePython-2.7/lib/python2.7/plat-linux2', '/opt/ActivePython-2.7/lib/python2.7/lib-tk', '/opt/ActivePython-2.7/lib/python2.7/lib-old', '/opt/ActivePython-2.7/lib/python2.7/lib-dynload', '/home/sridharr/.local/lib/python/2.7/site-packages', '/opt/ActivePython-2.7/lib/python2.7/site-packages']
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named cmdln
sridharr at triple:~$ file /home/sridharr/.local/lib/python2.7/site-packages/cmdln.py 
/home/sridharr/.local/lib/python2.7/site-packages/cmdln.py: a python script text executable


On OSX, I don't even see a ~/.local directory!

python2.7 -c "import sys; print sys.path"
['', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages']

Works as expected on Windows, though.

----------
components: Library (Lib)
messages: 106009
nosy: srid
priority: normal
severity: normal
status: open
title: 2.7: wrong user site directory on Linux; totally missing on OSX
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed May 19 00:30:53 2010
From: report at bugs.python.org (Orlando Irrazabal)
Date: Tue, 18 May 2010 22:30:53 +0000
Subject: [New-bugs-announce] [issue8760] Python 2.6.5 fails to build on AIX
	5.3
In-Reply-To: <1274221853.63.0.90590760776.issue8760@psf.upfronthosting.co.za>
Message-ID: <1274221853.63.0.90590760776.issue8760@psf.upfronthosting.co.za>


New submission from Orlando Irrazabal <oirraza at mendoza.gov.ar>:

Build of Python 2.6.5 on AIX 5.3 fails with the below error message.

The configure line is:
./configure 

[...]
building '_multiprocessing' extension
cc_r -qlanglvl=extc89 -DNDEBUG -O -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I. -I/sw_install/python-2.6.5/./Include -I. -IInclude -I./Include -I/usr/local/include -I/sw_install/python-2.6.5/Include -I/sw_install/python-2.6.5 -c /sw_install/python-2.6.5/Modules/_multiprocessing/multiprocessing.c -o build/temp.aix-5.3-2.6/sw_install/python-2.6.5/Modules/_multiprocessing/multiprocessing.o
cc_r -qlanglvl=extc89 -DNDEBUG -O -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I. -I/sw_install/python-2.6.5/./Include -I. -IInclude -I./Include -I/usr/local/include -I/sw_install/python-2.6.5/Include -I/sw_install/python-2.6.5 -c /sw_install/python-2.6.5/Modules/_multiprocessing/socket_connection.c -o build/temp.aix-5.3-2.6/sw_install/python-2.6.5/Modules/_multiprocessing/socket_connection.o
cc_r -qlanglvl=extc89 -DNDEBUG -O -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I. -I/sw_install/python-2.6.5/./Include -I. -IInclude -I./Include -I/usr/local/include -I/sw_install/python-2.6.5/Include -I/sw_install/python-2.6.5 -c /sw_install/python-2.6.5/Modules/_multiprocessing/semaphore.c -o build/temp.aix-5.3-2.6/sw_install/python-2.6.5/Modules/_multiprocessing/semaphore.o
./Modules/ld_so_aix cc_r -qlanglvl=extc89 -bI:Modules/python.exp build/temp.aix-5.3-2.6/sw_install/python-2.6.5/Modules/_multiprocessing/multiprocessing.o build/temp.aix-5./multim3-2.6/sw_install/python-2.6.5/Modules/_multiprocessing/socket_connection.o build/temp.aix-5.3-2.6/sw_install/python-2.6.5/Modules/_multiprocessing/semaphore.o -L/usr/local/lib -o build/lib.aix-5.3-2.6/_multiprocessing.so
checking build system type... powerpc-ibm-aix5.3.0.0
checking host system type... powerpc-ibm-aix5.3.0.0
checking target system type... powerpc-ibm-aix5.3.0.0
checking for a BSD-compatible install... /sw_install/python-2.6.5/Modules/_ctypes/libffi/install-sh -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /sw_install/python-2.6.5/Modules/_ctypes/libffi/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking for gcc... cc_r -qlanglvl=extc89
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether cc_r -qlanglvl=extc89 accepts -g... yes
checking for cc_r -qlanglvl=extc89 option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of cc_r -qlanglvl=extc89... none
checking dependency style of cc_r -qlanglvl=extc89... none
checking whether cc_r -qlanglvl=extc89 and cc understand -c and -o together... yes
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for non-GNU ld... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognize dependent libraries... pass_all
checking how to run the C preprocessor... cc_r -qlanglvl=extc89 -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl.exe... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... xlC_r
checking whether we are using the GNU C++ compiler... no
checking whether xlC_r accepts -g... yes
checking dependency style of xlC_r... none
checking how to run the C++ preprocessor... xlC_r -E
checking for g77... no
checking for xlf... no
checking for f77... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for xlf90... no
checking for f90... no
checking for pgf90... no
checking for pghpf... no
checking for epcf90... no
checking for gfortran... no
checking for g95... no
checking for xlf95... no
checking for f95... no
checking for fort... no
checking for ifort... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for ftn... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether  accepts -g... no
checking the maximum length of command line arguments... 18432
checking command to parse /usr/bin/nm -B output from cc_r -qlanglvl=extc89 object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking for cc_r -qlanglvl=extc89 option to produce PIC...
checking if cc_r -qlanglvl=extc89 static flag -bnso -bI:/lib/syscalls.exp works... no
checking if cc_r -qlanglvl=extc89 supports -c -o file.o... yes
checking whether the cc_r -qlanglvl=extc89 linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... aix5.3.0.0 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking whether to enable maintainer-specific portions of Makefiles... no
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking for mmap... yes
checking for sys/mman.h... (cached) yes
checking for mmap... (cached) yes
checking whether read-only mmap of a plain file works... yes
checking whether mmap from /dev/zero works... yes
checking for MAP_ANON(YMOUS)... yes
checking whether mmap with MAP_ANON(YMOUS) works... yes
checking for ANSI C header files... (cached) yes
checking for memcpy... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for double... yes
checking size of double... 8
checking for long double... yes
checking size of long double... 8
checking whether byte ordering is bigendian... yes
checking assembler .cfi pseudo-op support... no
checking whether .eh_frame section should be read-only... no
checking for __attribute__((visibility("hidden")))... no
cc_r: 1501-210 command option t contains an incorrect subargument
configure: creating ./config.status
config.status: creating include/ffi.h
sed: Command line is too long.
config.status: creating fficonfig.py
sed: Command line is too long.
config.status: creating fficonfig.h
config.status: linking /sw_install/python-2.6.5/Modules/_ctypes/libffi/src/powerpc/ffitarget.h to include/ffitarget.h
config.status: linking /sw_install/python-2.6.5/Modules/_ctypes/libffi/include/ffi_common.h to include/ffi_common.h
config.status: executing depfiles commands
config.status: executing include commands
config.status: executing src commands
Traceback (most recent call last):
  File "./setup.py", line 1919, in <module>
    main()
  File "./setup.py", line 1914, in main
    'Lib/smtpd.py']
  File "/sw_install/python-2.6.5/Lib/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/sw_install/python-2.6.5/Lib/distutils/dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "/sw_install/python-2.6.5/Lib/distutils/dist.py", line 995, in run_command
    cmd_obj.run()
  File "/sw_install/python-2.6.5/Lib/distutils/command/build.py", line 134, in run
    self.run_command(cmd_name)
  File "/sw_install/python-2.6.5/Lib/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/sw_install/python-2.6.5/Lib/distutils/dist.py", line 995, in run_command
    cmd_obj.run()
  File "/sw_install/python-2.6.5/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "./setup.py", line 201, in build_extensions
    build_ext.build_extensions(self)
  File "/sw_install/python-2.6.5/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self.build_extension(ext)
  File "./setup.py", line 234, in build_extension
    if not self.configure_ctypes(ext):
  File "./setup.py", line 1730, in configure_ctypes
    extra_compile_args = fficonfig['ffi_cflags'].split()
KeyError: 'ffi_cflags'
make: 1254-004 The error code from the last command is 1.


Stop.


Thanks.

Orlando

----------
components: Build
messages: 106011
nosy: oirraza
priority: normal
severity: normal
status: open
title: Python 2.6.5 fails to build on AIX 5.3
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Wed May 19 01:50:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 May 2010 23:50:22 +0000
Subject: [New-bugs-announce] [issue8761] PyUnicode_CompareWithASCIIString
	name is not mangled	(UCS2, UCS4)
In-Reply-To: <1274226622.99.0.33307621938.issue8761@psf.upfronthosting.co.za>
Message-ID: <1274226622.99.0.33307621938.issue8761@psf.upfronthosting.co.za>


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

In unicodeobject.h, you can see:

# define PyUnicode_CompareWithASCII PyUnicodeUCS2_CompareASCII
...
# define PyUnicode_CompareWithASCII PyUnicodeUCS4_CompareWithASCII
...
PyAPI_FUNC(int) PyUnicode_CompareWithASCIIString(
    PyObject *left,
    const char *right
    );

The defines miss the String suffix :-/

Attached patch adds the suffix but I guess that it breaks backward compatibility. Is it a problem to apply this patch in Python 3.2 (but not in Python 3.1)?

----------
components: Unicode
files: pyunicode_compareascii.patch
keywords: patch
messages: 106015
nosy: haypo
priority: normal
severity: normal
status: open
title: PyUnicode_CompareWithASCIIString name is not mangled (UCS2, UCS4)
versions: Python 3.2
Added file: http://bugs.python.org/file17391/pyunicode_compareascii.patch

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

From report at bugs.python.org  Wed May 19 02:35:35 2010
From: report at bugs.python.org (andrew)
Date: Wed, 19 May 2010 00:35:35 +0000
Subject: [New-bugs-announce] [issue8762] default value in constructor not
	unique across objects
In-Reply-To: <1274229335.16.0.189072837052.issue8762@psf.upfronthosting.co.za>
Message-ID: <1274229335.16.0.189072837052.issue8762@psf.upfronthosting.co.za>


New submission from andrew <atcuno at gmail.com>:

After debugging for a while I finally released that I stumbled across a Python bug (at least I believe it is). Here is a proof of concept that produces the issue:

!/usr/bin/python

class blah:

    def __init__(self, items=[]):
        self.items = items

a = blah()
b = blah()

a.items.append("apples")
b.items.append("oranges")

print a.items
print b.items
print id(a.items)
print id(b.items)


and here is the output when the program is run:

root at x:~# python pythonbug.py
['apples', 'oranges']
['apples', 'oranges']
135923500
135923500
root at x:~#

as you can see the 'items' reference is the same for both objects even though they are different objects. I checked the manual and I couldn't find anything explaining such behavior. Can this possibly be correct?

My python info:

Python 2.5.2 (r252:60911, Jan 20 2010, 21:48:48)

----------
messages: 106018
nosy: bolt
priority: normal
severity: normal
status: open
title: default value in constructor not unique across objects
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Wed May 19 12:19:51 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 19 May 2010 10:19:51 +0000
Subject: [New-bugs-announce] [issue8763] py3K bdist_msi wrongly installs
	itself in ALL python	versions
In-Reply-To: <1274264391.85.0.389216005018.issue8763@psf.upfronthosting.co.za>
Message-ID: <1274264391.85.0.389216005018.issue8763@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

I've created a pure-python package with py3k's bdist_msi, and weirdly, even though the windows installer asks for the target directory, it installs the package in ALL python distributions installed (py26, py27 and py31), which is particularly embarassing since it's a py3k-only pure-python package...

----------
assignee: tarek
components: Distutils
files: RSFile-1.0.win32.msi
messages: 106042
nosy: pakal, tarek
priority: normal
severity: normal
status: open
title: py3K bdist_msi wrongly installs itself in ALL python versions
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17398/RSFile-1.0.win32.msi

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

From report at bugs.python.org  Wed May 19 12:56:44 2010
From: report at bugs.python.org (davy zhang)
Date: Wed, 19 May 2010 10:56:44 +0000
Subject: [New-bugs-announce] [issue8764] logging RotatingFileHandler cause
	too long to fininsh
In-Reply-To: <1274266604.24.0.270763712229.issue8764@psf.upfronthosting.co.za>
Message-ID: <1274266604.24.0.270763712229.issue8764@psf.upfronthosting.co.za>


New submission from davy zhang <davyzhang at gmail.com>:

the function below is used to determine the proper file name of the next log file. But the question is if I set a large number of self.backupCount like 10000000, it will take too long to calculate the right file name. I think it could be a better way to do this instead of finding from the end.

    def doRollover(self):
        """
        Do a rollover, as described in __init__().
        """

        self.stream.close()
        if self.backupCount > 0:
            for i in range(self.backupCount - 1, 0, -1):
                sfn = "%s.%d" % (self.baseFilename, i)
                dfn = "%s.%d" % (self.baseFilename, i + 1)
                if os.path.exists(sfn):
                    #print "%s -> %s" % (sfn, dfn)
                    if os.path.exists(dfn):
                        os.remove(dfn)
                    os.rename(sfn, dfn)
            dfn = self.baseFilename + ".1"
            if os.path.exists(dfn):
                os.remove(dfn)
            os.rename(self.baseFilename, dfn)
            #print "%s -> %s" % (self.baseFilename, dfn)
        self.mode = 'w'
        self.stream = self._open()

----------
messages: 106043
nosy: davy.zhang
priority: normal
severity: normal
status: open
title: logging RotatingFileHandler cause too long to fininsh
versions: Python 2.6

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

From report at bugs.python.org  Wed May 19 14:17:55 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 19 May 2010 12:17:55 +0000
Subject: [New-bugs-announce] [issue8765] Tests unwillingly writing unicocde
	to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

In test_fileio, one of the tests wants to ensure writing to closed raw streams fails, but it actually tries to write an unicode string, which should rather lead to an immediate TypeError.

Here is a tiny patch to prevent the "double error cause" danger - this test is bugging me because my own I/O library cant pass the stdlib io tests in this case.

The initial problem here is that we can't write unicode to a buffered binary stream (TypeError), but we can do it with an unbufferred raw stream - as the C implementation of the latter does string coercion instead of raising TypeError.
Shouldn't we unify the behaviour of binary streams in such cases ?

----------
components: IO
files: test_fileio_errclosedonwrite.patch
keywords: patch
messages: 106053
nosy: pakal
priority: normal
severity: normal
status: open
title: Tests unwillingly writing unicocde to raw streams
versions: Python 2.7
Added file: http://bugs.python.org/file17400/test_fileio_errclosedonwrite.patch

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

From report at bugs.python.org  Wed May 19 15:27:22 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 19 May 2010 13:27:22 +0000
Subject: [New-bugs-announce] [issue8766] Segmentation fault with empty
	"encodings" subdirectory of	directory in PYTHONPATH
In-Reply-To: <1274275642.68.0.971287952925.issue8766@psf.upfronthosting.co.za>
Message-ID: <1274275642.68.0.971287952925.issue8766@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Python 3.1 and 3.2 fail with segmentation fault when a directory in PYTHONPATH contains an empty "encodings" subdirectory.

$ cd /tmp 
$ mkdir encodings
$ PYTHONPATH=. python3.1
Segmentation fault

----------
components: Interpreter Core, Unicode
messages: 106066
nosy: Arfrever, haypo
priority: normal
severity: normal
status: open
title: Segmentation fault with empty "encodings" subdirectory of directory in PYTHONPATH
type: crash
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed May 19 18:21:55 2010
From: report at bugs.python.org (Charles Solar)
Date: Wed, 19 May 2010 16:21:55 +0000
Subject: [New-bugs-announce] [issue8767] Configure: Cannot disable unicode
In-Reply-To: <1274286115.56.0.588868311562.issue8767@psf.upfronthosting.co.za>
Message-ID: <1274286115.56.0.588868311562.issue8767@psf.upfronthosting.co.za>


New submission from Charles Solar <charlessolar at gmail.com>:

I am compiling python on AIX 5.3.  The normal configure and make works, except it fails to compile the unicodedata module.  The assembler reports a bunch of these errors:
Error: value of 000000000001268b too large for field of 2 bytes at 000000000000006d

The module is labeled as optional, but if that one fails python will not install.  One of the .py files it tries to compile requires unicodedata so the whole thing fails.

I tried --enable-unicode=ucs4 and got the same results so then I tried just --disable-unicode all together and configure spits out: 
checking what type to use for unicode... configure: error: invalid value for --enable-unicode. Use either ucs2 or ucs4 (lowercase).

I had to go into the configure script itself remove a default case statement that produced the error to disable it completely.

Building Python2.7b1 on AIX 5.3

----------
components: Build
files: config.log
messages: 106076
nosy: redcomet
priority: normal
severity: normal
status: open
title: Configure: Cannot disable unicode
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file17403/config.log

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

From report at bugs.python.org  Wed May 19 18:55:00 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 19 May 2010 16:55:00 +0000
Subject: [New-bugs-announce] [issue8768] The checkempty_symmetric_difference
	test is never called
In-Reply-To: <1274288100.9.0.0116762037364.issue8768@psf.upfronthosting.co.za>
Message-ID: <1274288100.9.0.0116762037364.issue8768@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

In test_set.py (and test_sets.py in 2.x), there's a method named "checkempty_symmetric_difference".  It should be named "test_checkempty_symmetric_difference" so that it will actually be called as a test.  It's not referenced anywhere else.

The test verifies the XOR identity: some_set == some_set ^ empty_set.

Patch against trunk attached.

----------
components: Tests
files: missing-test.patch
keywords: patch
messages: 106080
nosy: stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: The checkempty_symmetric_difference test is never called
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17405/missing-test.patch

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

From report at bugs.python.org  Wed May 19 22:55:19 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 19 May 2010 20:55:19 +0000
Subject: [New-bugs-announce] [issue8769] Straightforward usage of email
	package fails to round-trip
In-Reply-To: <1274302519.83.0.146401120937.issue8769@psf.upfronthosting.co.za>
Message-ID: <1274302519.83.0.146401120937.issue8769@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

The attached test program shows how parsing an e-mail message with the email package, then converting the resulting message to a string, fails to round-trip properly.  Instead it breaks the encoding of the subject line.

The root of the problem: the subject is RFC-2047 quoted, long enough to require line wrapping, and it contains one of the splitchars used by Header.encode() -- meaning a semi-colon or comma.  In my example, this is:

Subject: =?utf-8?Q?2010_Foundation_Salary_and_Benefits_Report;_Important_Legislative_Efforts?=

Parsing the message turns that into a string S.  generator.Generator._write_headers() then outputs Header(S).encode(), so it keeps treating the value as an ASCII string, and therefore breaks the header at the semicolon, resulting in:
  
Subject: =?utf-8?Q?2010_Foundation_Salary_and_Benefits_Report;<NEWLINE><SPACE>_Important_Legislative_Efforts?=

Newline and space aren't legal in Q encoding, so MUAs give up and display all the =?utf-8?Q? stuff.

----------
assignee: barry
components: Library (Lib)
files: email-roundtrip-failure.py
keywords: patch
messages: 106100
nosy: akuchling, barry
priority: normal
severity: normal
status: open
title: Straightforward usage of email package fails to round-trip
versions: Python 2.7
Added file: http://bugs.python.org/file17410/email-roundtrip-failure.py

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

From report at bugs.python.org  Thu May 20 00:43:18 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 19 May 2010 22:43:18 +0000
Subject: [New-bugs-announce] [issue8770] Make 'python -m sysconfig' print
	something useful
In-Reply-To: <1274308998.81.0.84185176486.issue8770@psf.upfronthosting.co.za>
Message-ID: <1274308998.81.0.84185176486.issue8770@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

"python2.7 -m sysconfig" at the moment does not print anything. "python2.7 -m site", for instant, prints useful information.

Perhaps the output of `sysconfig.get_path` can be pretty printed?

----------
assignee: tarek
components: Distutils
messages: 106111
nosy: srid, tarek
priority: normal
severity: normal
status: open
title: Make 'python -m sysconfig' print something useful
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu May 20 01:37:27 2010
From: report at bugs.python.org (Alice Bevan-McGregor)
Date: Wed, 19 May 2010 23:37:27 +0000
Subject: [New-bugs-announce] [issue8771] Socket freezing under load issue on
	Mac.
In-Reply-To: <1274312247.36.0.878213869408.issue8771@psf.upfronthosting.co.za>
Message-ID: <1274312247.36.0.878213869408.issue8771@psf.upfronthosting.co.za>


New submission from Alice Bevan-McGregor <alice at gothcandy.com>:

Using the wsgiref simple HTTP server or any other capable of > 2000 requests/sec. demonstrates an issue with Macintosh sockets.

Mac OS X Version: 10.6.3 (Build 10D573)
Python Version: 2.6.1 (32-bit)

The minimal application needed to demonstrate the problem is:

    import sys, cStringIO
    from wsgiref.simple_server import make_server
    
    sys.stderr = cStringIO.StringIO() # disable request logging
    
    def app(environ, start_response):
        start_response("200 OK", [('Content-Type', 'text/plain')])
        return ['Hello world!\n']
    
    httpd = make_server('', 8080, app)
    httpd.serve_forever()

Then hammer the server using Apache Bench:

    ab -n 20000 -c 5 http://127.0.0.1:8080/

At almost exactly the 16000 request mark socket connections begin to time out.  Sockets are then freed up at the rate of about 40/second (on my box).  Killing the ab run when it freezes then immediately re-trying (and cancelling after a few seconds) will show this rate.  Time must pass for some connection 'pool' to free the connections before you can do another 16000 requests.

This problem does not appear on the following setup:

Operating System: Gentoo Linux
Python Version: 2.6.4 (32-bit)

----------
components: Library (Lib)
messages: 106117
nosy: amcgregor
priority: normal
severity: normal
status: open
title: Socket freezing under load issue on Mac.
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu May 20 02:37:11 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 20 May 2010 00:37:11 +0000
Subject: [New-bugs-announce] [issue8772] sysconfig: _get_default_scheme can
	be made public?
In-Reply-To: <1274315831.51.0.95937905223.issue8772@psf.upfronthosting.co.za>
Message-ID: <1274315831.51.0.95937905223.issue8772@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Currently there is no way to get the default scheme for *current* platform other than plainly *assuming* that that is os.name unless it is posix, in which case it becomes posix_prefix. 

PyPM needs to know this. But I am slightly reluctant to hardcode it. I would rather use the _get_default_scheme() .. but only if it is known to be maintained for backward compat.

Thoughts?

----------
assignee: tarek
components: Distutils
messages: 106122
nosy: srid, tarek
priority: normal
severity: normal
status: open
title: sysconfig: _get_default_scheme can be made public?
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu May 20 04:45:16 2010
From: report at bugs.python.org (Dan Buch)
Date: Thu, 20 May 2010 02:45:16 +0000
Subject: [New-bugs-announce] [issue8773] mailbox module is needlessly
	executable
In-Reply-To: <1274323516.06.0.854227668919.issue8773@psf.upfronthosting.co.za>
Message-ID: <1274323516.06.0.854227668919.issue8773@psf.upfronthosting.co.za>


New submission from Dan Buch <daniel.buch at gmail.com>:

While running various modules with the ``-m`` flag to check for command-line behavior, I noticed that the mailbox module currently has svn:executable set.  The module contains no ``if __name__ == '__main__'`` magic and, as one would expect, nothing happens when invoking ``python3 -m mailbox``.  Because svn doesn't support an extended diff format that deals with file modes, I would just propose that somebody with commit rights do the following::

    svn propdel svn:executable Lib/mailbox.py

----------
components: Library (Lib)
messages: 106128
nosy: meatballhat
priority: normal
severity: normal
status: open
title: mailbox module is needlessly executable
versions: Python 3.2

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

From report at bugs.python.org  Thu May 20 05:17:32 2010
From: report at bugs.python.org (Dan Buch)
Date: Thu, 20 May 2010 03:17:32 +0000
Subject: [New-bugs-announce] [issue8774] 0xe7 in ``heapq.__about__`` causes
	badness
In-Reply-To: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>
Message-ID: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>


New submission from Dan Buch <daniel.buch at gmail.com>:

I noticed while running ``python3 -m tabnanny -v Lib/*.py`` that the process died at heapq.py.  The 0x37 char in "Fran?ois Pinard" (in the ``__about__`` attr) was the culprit.  The attached patch replaces it with '\xe7'.  Changing the encoding cookie was not necessary to make it work, but seemed like a good idea at the time (I forget if it even matters... haven't worked much in py3k yet.)

----------
components: Library (Lib)
files: fran?ois-pinard-killed-my-tabnanny.patch
keywords: patch
messages: 106129
nosy: meatballhat
priority: normal
severity: normal
status: open
title: 0xe7 in ``heapq.__about__`` causes badness
versions: Python 3.2
Added file: http://bugs.python.org/file17413/fran?ois-pinard-killed-my-tabnanny.patch

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

From report at bugs.python.org  Thu May 20 14:09:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 May 2010 12:09:25 +0000
Subject: [New-bugs-announce] [issue8775] Use locale encoding to decode
	sys.argv, not the file system encoding
In-Reply-To: <1274357365.37.0.0731450159524.issue8775@psf.upfronthosting.co.za>
Message-ID: <1274357365.37.0.0731450159524.issue8775@psf.upfronthosting.co.za>


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

The file system is hardcoded to UTF-8 on Mac OS X, whereas the locale encoding... depends on the locale. See issue #4388 for the details.

I think that we should use the locale encoding to encode and decode command line arguments. We have to create a new encoding variable used for the command line arguments:
 * Py_CommandLineEncoding
 * sys.getcmdlineencoding()
 * (no sys.setcmdlineencoding() please!)
 * ...

This encoding only should be used on POSIX: Windows native type is unicode (wchar_t*). It should be used to decode sys.argv and to encode child processes arguments (subprocess, os.exec*(), etc.)).

On Linux, it should change anything because the file system encoding is the locale encoding. Said differently, Python3 does already use the locale encoding for the command arguments on Linux.

If you pass a filename on the command line and then open it: the filename is decoded with the locale encoding, and then encoded with the file system encoding. I fear that it will fail if both encodings are differents...

----------
messages: 106139
nosy: haypo
priority: normal
severity: normal
status: open
title: Use locale encoding to decode sys.argv, not the file system encoding
versions: Python 3.2

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

From report at bugs.python.org  Thu May 20 14:10:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 May 2010 12:10:56 +0000
Subject: [New-bugs-announce] [issue8776] Bytes version of sys.argv
In-Reply-To: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za>
Message-ID: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za>


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

In some situations, the encoding of the command line is incorrect or unknown. sys.argv is decoded with the file system encoding which can be wrong. Eg. see issue #4388 (ok, it's a bug, it should be fixed).

As os.environb, it would be useful to have bytes version of sys.argv to have able to decide the encoding used to decode each argument, or to manipulate bytes if we don't care about the encoding.

See also issue #8775 which propose to add a new encoding to decode sys.argv.

----------
components: Interpreter Core, Unicode
messages: 106140
nosy: haypo
priority: normal
severity: normal
status: open
title: Bytes version of sys.argv
versions: Python 3.2

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

From report at bugs.python.org  Thu May 20 19:07:42 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 20 May 2010 17:07:42 +0000
Subject: [New-bugs-announce] [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>


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

The "barrier" synchronization primitive is often very useful.  It is simpler to use than an Event, for example, when waiting for threads to start up, or to finish.
The patch contains a simple barrier implementation based on a Condition variable, for your perusal.

See http://en.wikipedia.org/wiki/Barrier_(computer_science) for info.

This particular implementation contains an important feature:  The ability to adjust the 'count' of the barrier.  This is useful in case a thread dies for some reason, to avoid a deadlock for the other threads.

There is still no documentation, since this is only a proposal, but there is a unittest.

----------
components: Library (Lib)
files: barrier.patch
keywords: patch, patch
messages: 106167
nosy: krisvale
priority: normal
severity: normal
status: open
title: Add threading.Barrier
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file17417/barrier.patch

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

From martin at v.loewis.de  Thu May 20 19:23:02 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 20 May 2010 19:23:02 +0200
Subject: [New-bugs-announce] [issue8775] Use locale encoding to decode
 sys.argv, not the file system encoding
In-Reply-To: <1274357365.37.0.0731450159524.issue8775@psf.upfronthosting.co.za>
References: <1274357365.37.0.0731450159524.issue8775@psf.upfronthosting.co.za>
Message-ID: <4BF56FF6.60302@v.loewis.de>

> I think that we should use the locale encoding to encode and decode command line arguments. 

I disagree. IIUC, this is only about OSX. Now, we shouldn't take any
action until either some OSX expert explains us how command line
arguments are being passed on OSX, or we find some Apple documentation
that can be taken as a specification.

I think the C locale is very poorly supported on OSX, and we shouldn't
really use it for anything. What may be useful is the terminal encoding
(which may be different both from UTF-8 and the locale encoding),
however, it's not possible to find out what the terminal encoding is.
In addition, programs may be started "directly" (i.e. not from the
terminal), in which case the terminal encoding would be irrelevant.

For file name arguments at least, it's very clear that the command line
arguments also use the file system encoding.



From martin at v.loewis.de  Thu May 20 19:24:30 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 20 May 2010 19:24:30 +0200
Subject: [New-bugs-announce] [issue8776] Bytes version of sys.argv
In-Reply-To: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za>
References: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za>
Message-ID: <4BF5704E.2040206@v.loewis.de>

> As os.environb, it would be useful to have bytes version of sys.argv
> to have able to decide the encoding used to decode each argument, or
> to manipulate bytes if we don't care about the encoding.

-1. Py_Main expects wchar_t*, so no byte-oriented representation of the
command line is readily available.

From report at bugs.python.org  Thu May 20 23:51:42 2010
From: report at bugs.python.org (Terrence Cole)
Date: Thu, 20 May 2010 21:51:42 +0000
Subject: [New-bugs-announce] [issue8778] typo in docs for
	symtable.SymbolTable.has_import_star
In-Reply-To: <1274392302.58.0.224644067181.issue8778@psf.upfronthosting.co.za>
Message-ID: <1274392302.58.0.224644067181.issue8778@psf.upfronthosting.co.za>


New submission from Terrence Cole <terrence at zettabytestorage.com>:

The documentation for symtable.SymbolTable [http://docs.python.org/py3k/library/symtable.html] lists the function has_import_start.  This should be has_import_star, as listed in help(symtable.SymbolTable).

I've attached a patch, although it would probably be faster for a committer to just remove the 't' themselves.

----------
assignee: docs at python
components: Documentation
files: fix-has-import-star-doc.diff
keywords: patch
messages: 106194
nosy: docs at python, terrence
priority: normal
severity: normal
status: open
title: typo in docs for symtable.SymbolTable.has_import_star
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17420/fix-has-import-star-doc.diff

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

From report at bugs.python.org  Fri May 21 00:02:01 2010
From: report at bugs.python.org (Roman Gershman)
Date: Thu, 20 May 2010 22:02:01 +0000
Subject: [New-bugs-announce] [issue8779] utf8 codec fails to parse a
	character
In-Reply-To: <1274392921.12.0.376049496737.issue8779@psf.upfronthosting.co.za>
Message-ID: <1274392921.12.0.376049496737.issue8779@psf.upfronthosting.co.za>


New submission from Roman Gershman <romange at gmail.com>:

The following code fails to parse the attached file:


#!/usr/bin/python3.1

if __name__ == '__main__':
 f = open("c:\\1.txt", mode ='r', encoding='utf-8')
 for line in f:
     print (line)

----------
components: Unicode
files: 1.txt
messages: 106195
nosy: Roman.Gershman
priority: normal
severity: normal
status: open
title: utf8 codec fails to parse a character
versions: Python 3.1
Added file: http://bugs.python.org/file17421/1.txt

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

From report at bugs.python.org  Fri May 21 14:37:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 12:37:56 +0000
Subject: [New-bugs-announce] [issue8780] py3k: child process don't inherit
	stdout / stdout
In-Reply-To: <1274445476.8.0.294880351172.issue8780@psf.upfronthosting.co.za>
Message-ID: <1274445476.8.0.294880351172.issue8780@psf.upfronthosting.co.za>


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

The following code works on 2.6, 2.7 (trunk), 3.1, but not on py3k.

import subprocess, sys
subprocess.call([sys.executable, '-c', 'print("Hello World!")'])

On py3k, sys.stdout and sys.stderr are equal to... None.

I hope that it's a problem with my setup.

----------
components: Interpreter Core, Library (Lib)
messages: 106232
nosy: haypo
priority: normal
severity: normal
status: open
title: py3k: child process don't inherit stdout / stdout
versions: Python 3.2

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

From report at bugs.python.org  Fri May 21 14:44:00 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 21 May 2010 12:44:00 +0000
Subject: [New-bugs-announce] [issue8781] 32-bit wchar_t doesn't need to be
	unsigned to be usable	(I think)
In-Reply-To: <1274445840.82.0.641304229797.issue8781@psf.upfronthosting.co.za>
Message-ID: <1274445840.82.0.641304229797.issue8781@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

If ./configure detects that the system's wchar_t type is compatible, it will define "#define PY_UNICODE_TYPE wchar_t" and enable certain optimizations when converting between Py_UNICODE and wchar_t (i.e., it can just do a memcpy).

Right now, ./configure considers wchar_t to be compatible if it is the same bit-width as Py_UNICODE and if wchar_t is unsigned.  In practice, that means Python only uses wchar_t on Windows, which uses an unsigned 16-bit wchar_t.  On Linux, wchar_t is 32-bit and signed.

In the original Unicode implementation for Python, Py_UNICODE was always 16-bit.  I believe the "unsigned" requirement heralds back to that time.  A 32-bit wchar_t gives us plenty of space to hold the maximum Unicode code point of 0x10FFFF, regardless of whether wchar_t is signed or unsigned.

I believe the condition could be relaxed to the following:
- wchar_t must be the same bit-width as Py_UNICODE, and
- if wchar_t is 16-bit, it must be unsigned

That would allow a UCS4 Python to use wchar_t on Linux.

I experimented by manually tweaking my pyconfig.h to treat Linux's signed 32-bit wchar_t as compatible.  The unit test suite encountered no problems.

However, it's quite possible that I'm missing some important detail here.  Someone familiar with the guts of Python's Unicode implementation  will presumably have a much better idea of whether I have this right or not. ;-)

----------
components: Interpreter Core, Unicode
messages: 106235
nosy: stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: 32-bit wchar_t doesn't need to be unsigned to be usable (I think)
type: performance
versions: Python 3.2

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

From report at bugs.python.org  Fri May 21 16:34:09 2010
From: report at bugs.python.org (holger krekel)
Date: Fri, 21 May 2010 14:34:09 +0000
Subject: [New-bugs-announce] [issue8782] inspect.getsource returns invalid
	source for	non-newline-ending module
In-Reply-To: <1274452449.06.0.949392077471.issue8782@psf.upfronthosting.co.za>
Message-ID: <1274452449.06.0.949392077471.issue8782@psf.upfronthosting.co.za>


New submission from holger krekel <holger.krekel at gmail.com>:

Executing the attached "inspect_failure.py" under python2.6 or python3.1 results in an assertion error: Python fails to obtain the source code of a function that is defined at the end of a module whose last line does not contain a line ending character. 

After brief analysis i think there are two approaches to fixing it: normalizing newlines in inspect.findsource (see attached inspect.patch file against r312) or performing normalization in linecache.updatecache which does it already for source code obtained from PEP302 loaders. Or any other ideas?

----------
files: inspect.patch
keywords: patch
messages: 106245
nosy: hpk
priority: normal
severity: normal
status: open
title: inspect.getsource returns invalid source for non-newline-ending module
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17431/inspect.patch

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

From report at bugs.python.org  Fri May 21 22:09:38 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 21 May 2010 20:09:38 +0000
Subject: [New-bugs-announce] [issue8783] The external link to a "Hash
	Collision FAQ" points to	some company's homepage
In-Reply-To: <1274472578.65.0.146372643456.issue8783@psf.upfronthosting.co.za>
Message-ID: <1274472578.65.0.146372643456.issue8783@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

At the bottom of the documentation for hashlib, there's a link to
http://www.cryptography.com/cnews/hash.html

which the hashlib documentation describes as "Hash Collision FAQ with information on which algorithms have known issues and what that means regarding their use."

However, the page at that link is identical to http://www.cryptography.com/

which is just the homepage of some company that happens to deal with cryptography.  If they do in fact host a Hash Collision FAQ, I couldn't find it. :-(

Googling for "Hash Collision FAQ" (with quotes) mostly turns up references to the Python documentation, so I'm guessing the intended document no longer exists.

The following wikipedia link might be an OK substitute, although it makes for pretty dense reading.
http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cryptographic_hash_algorithms

----------
assignee: docs at python
components: Documentation
messages: 106259
nosy: docs at python, stutzbach
priority: normal
severity: normal
status: open
title: The external link to a "Hash Collision FAQ" points to some company's homepage

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

From report at bugs.python.org  Sat May 22 03:22:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 May 2010 01:22:15 +0000
Subject: [New-bugs-announce] [issue8784] tarfile/Windows: Don't use mbcs as
	the default encoding
In-Reply-To: <1274491335.43.0.732437213128.issue8784@psf.upfronthosting.co.za>
Message-ID: <1274491335.43.0.732437213128.issue8784@psf.upfronthosting.co.za>


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

mbcs encoding replace non encodable characters (loose information) and doesn't support surrogateescape error handler. It ignores the error handler argument: see #850997, and tarfile now uses surrogateescape error handler by default (#8390). This encoding is just horrible for unicode support :-)

Since Windows native API use unicode character (UTF-16), I think that it would be better to use utf-8 for the default encoding on Windows. utf-8 is able to encode and decode the full Unicode charset and supports all error handlers (especially surrogateescape).

Attached patch sets the default encoding to utf-8 on Windows, and removes the test ENCODING is None because sys.getfilesystemencoding() cannot be None anymore (in 3.2 only, it's a recent change: #8610).

----------
components: Library (Lib), Unicode, Windows
files: tarfile_windows_utf8.patch
keywords: patch
messages: 106276
nosy: haypo, lars.gustaebel
priority: normal
severity: normal
status: open
title: tarfile/Windows: Don't use mbcs as the default encoding
versions: Python 3.2
Added file: http://bugs.python.org/file17435/tarfile_windows_utf8.patch

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

From report at bugs.python.org  Sat May 22 10:03:34 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 22 May 2010 08:03:34 +0000
Subject: [New-bugs-announce] [issue8785] findall() and finditer() docs
	misleading
In-Reply-To: <1274515414.72.0.273770511107.issue8785@psf.upfronthosting.co.za>
Message-ID: <1274515414.72.0.273770511107.issue8785@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

The docs for the RegexpObject methods findall and finditer are misleading: They are said to behave the same way as the respective functions, but in fact the parameter semantics are different.

----------
assignee: docs at python
components: Documentation
messages: 106286
nosy: docs at python, hagen
priority: normal
severity: normal
status: open
title: findall() and finditer() docs misleading
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat May 22 12:28:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 May 2010 10:28:33 +0000
Subject: [New-bugs-announce] [issue8786] Add support for IEEE 754 contexts
	to decimal module.
In-Reply-To: <1274524113.24.0.215320207255.issue8786@psf.upfronthosting.co.za>
Message-ID: <1274524113.24.0.215320207255.issue8786@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Discussion migrated from issue 8540 into its own issue.

For ease of communication with other libraries, it would be good to be able to easily create contexts corresponding to the IEEE 754 (2008) decimal interchange formats.

----------
messages: 106294
nosy: facundobatista, mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
status: open
title: Add support for IEEE 754 contexts to decimal module.
versions: Python 3.2

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

From report at bugs.python.org  Sat May 22 16:00:32 2010
From: report at bugs.python.org (Sebastian)
Date: Sat, 22 May 2010 14:00:32 +0000
Subject: [New-bugs-announce] [issue8787] PySys_Get
In-Reply-To: <1274536832.39.0.220188636264.issue8787@psf.upfronthosting.co.za>
Message-ID: <1274536832.39.0.220188636264.issue8787@psf.upfronthosting.co.za>


New submission from Sebastian <python.10.webmaster at spamgourmet.com>:

Hi all,

I found a bug in the exception handler. When I
start the app without any arguments I get an
output I expect:

__main__:2:DeprecationWarning: Deprecated function.

When I run the app with arguments, the arguments
are printed somehow in the exception output:

-test=HALLO:1:DeprecationWarning: Deprecated function

Can anyone please confirm?

Bye, Seb



[code]
#include "Python/Python.h"

static PyObject *testfunc(PyObject *self, PyObject *args, PyObject *keywords)
{
	PyErr_Warn(PyExc_DeprecationWarning, "Deprecated function.");
	Py_RETURN_NONE;
}

static PyMethodDef testmod[] =
{		
	{"testfunc", (PyCFunction)testfunc, METH_NOARGS, "Prints out a text to stdout."},
	{NULL}
};

int main (int argc, char **argv)
{
	Py_Initialize();
	
	PySys_SetArgv(argc, argv);
	
	PyObject *mod = Py_InitModule4("testmod", testmod, "", NULL, PYTHON_API_VERSION);
	if(mod == NULL) return -1;
	
	PyRun_SimpleString(	"import testmod\n"
											"testmod.testfunc()");
	Py_Finalize();
	return 0;
}
[/code]

----------
components: None
messages: 106306
nosy: Sebastian
priority: normal
severity: normal
status: open
title: PySys_Get
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat May 22 17:43:03 2010
From: report at bugs.python.org (Jeroen Habraken)
Date: Sat, 22 May 2010 15:43:03 +0000
Subject: [New-bugs-announce] [issue8788] urllib.urlencode documentation
	unclear on doseq
In-Reply-To: <1274542983.4.0.702068503568.issue8788@psf.upfronthosting.co.za>
Message-ID: <1274542983.4.0.702068503568.issue8788@psf.upfronthosting.co.za>


New submission from Jeroen Habraken <vexocide at gmail.com>:

The urllib.urlencode documentation is unclear with regard to the 'doseq' option. In my opinion it does not clearly state what its functionality is.

----------
assignee: docs at python
components: Documentation
messages: 106311
nosy: VeXocide, docs at python
priority: normal
severity: normal
status: open
title: urllib.urlencode documentation unclear on doseq

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

From report at bugs.python.org  Sat May 22 19:30:59 2010
From: report at bugs.python.org (reynaldo)
Date: Sat, 22 May 2010 17:30:59 +0000
Subject: [New-bugs-announce] [issue8789] See "Hamster" on your Google
	homepage
In-Reply-To: <0016e64b04fe72c1c70487322bd7@google.com>
Message-ID: <0016e64b04fe72c1c70487322bd7@google.com>


New submission from reynaldo <renben77 at gmail.com>:

Your friend, renben77 at gmail.com, has sent you the following Google Gadget.

See "Hamster" on your Google homepage ??

screenshot

----------
files: unnamed
messages: 106317
nosy: renben
priority: normal
severity: normal
status: open
title: See "Hamster" on your Google homepage
Added file: http://bugs.python.org/file17442/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8789>
_______________________________________
-------------- next part --------------
Your friend, renben77 at gmail.com, has sent you the following Google Gadget.<br/><br/><div style="font-size:large"><b><a href="http://www.google.com/ig/adde?moduleurl=http://hosting.gmodules.com/ig/gadgets/file/112581010116074801021/hamster.xml&source=imag">See "Hamster" on your Google homepage &raquo;</a></b></div><br/><br/><img style="border:1px solid #000;padding:12px" src="http://hosting.gmodules.com/ig/gadgets/file/112581010116074801021/hamster.png" alt="screenshot">

From report at bugs.python.org  Sat May 22 19:31:01 2010
From: report at bugs.python.org (reynaldo)
Date: Sat, 22 May 2010 17:31:01 +0000
Subject: [New-bugs-announce] [issue8790] See "Hamster" on your Google
	homepage
In-Reply-To: <0016e64b1e0a8e5b070487322ba4@google.com>
Message-ID: <0016e64b1e0a8e5b070487322ba4@google.com>


New submission from reynaldo <renben77 at gmail.com>:

Your friend, renben77 at gmail.com, has sent you the following Google Gadget.

See "Hamster" on your Google homepage ??

screenshot

----------
files: unnamed
messages: 106318
nosy: renben
priority: normal
severity: normal
status: open
title: See "Hamster" on your Google homepage
Added file: http://bugs.python.org/file17443/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8790>
_______________________________________
-------------- next part --------------
Your friend, renben77 at gmail.com, has sent you the following Google Gadget.<br/><br/><div style="font-size:large"><b><a href="http://www.google.com/ig/adde?moduleurl=http://hosting.gmodules.com/ig/gadgets/file/112581010116074801021/hamster.xml&source=imag">See "Hamster" on your Google homepage &raquo;</a></b></div><br/><br/><img style="border:1px solid #000;padding:12px" src="http://hosting.gmodules.com/ig/gadgets/file/112581010116074801021/hamster.png" alt="screenshot">

From report at bugs.python.org  Sat May 22 19:31:03 2010
From: report at bugs.python.org (reynaldo)
Date: Sat, 22 May 2010 17:31:03 +0000
Subject: [New-bugs-announce] [issue8791] See "Hamster" on your Google
	homepage
In-Reply-To: <0016e64caf888b30cb0487322b7d@google.com>
Message-ID: <0016e64caf888b30cb0487322b7d@google.com>


New submission from reynaldo <renben77 at gmail.com>:

Your friend, renben77 at gmail.com, has sent you the following Google Gadget.

See "Hamster" on your Google homepage ??

screenshot

----------
files: unnamed
messages: 106319
nosy: renben
priority: normal
severity: normal
status: open
title: See "Hamster" on your Google homepage
Added file: http://bugs.python.org/file17444/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8791>
_______________________________________
-------------- next part --------------
Your friend, renben77 at gmail.com, has sent you the following Google Gadget.<br/><br/><div style="font-size:large"><b><a href="http://www.google.com/ig/adde?moduleurl=http://hosting.gmodules.com/ig/gadgets/file/112581010116074801021/hamster.xml&source=imag">See "Hamster" on your Google homepage &raquo;</a></b></div><br/><br/><img style="border:1px solid #000;padding:12px" src="http://hosting.gmodules.com/ig/gadgets/file/112581010116074801021/hamster.png" alt="screenshot">

From report at bugs.python.org  Sat May 22 21:55:14 2010
From: report at bugs.python.org (Attila Nagy)
Date: Sat, 22 May 2010 19:55:14 +0000
Subject: [New-bugs-announce] [issue8792] xmlrpclib compatibility issues with
	Apache XML-RPC library
In-Reply-To: <1274558114.05.0.260300491762.issue8792@psf.upfronthosting.co.za>
Message-ID: <1274558114.05.0.260300491762.issue8792@psf.upfronthosting.co.za>


New submission from Attila Nagy <bra at fsn.hu>:

When talking to an Apache XML-RPC library based application via python 2.6.5 xmlrpclib, I get this exception:
Traceback (most recent call last):
  File "prb.py", line 4, in <module>
    proxy.catv.getEndpointIdByIp('1.1.1.1')
  File "/tmp/Python-2.6.5/Lib/xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "/tmp/Python-2.6.5/Lib/xmlrpclib.py", line 1491, in __request
    verbose=self.__verbose
  File "/tmp/Python-2.6.5/Lib/xmlrpclib.py", line 1253, in request
    return self._parse_response(h.getfile(), sock)
  File "/tmp/Python-2.6.5/Lib/xmlrpclib.py", line 1389, in _parse_response
    p.feed(response)
  File "/tmp/Python-2.6.5/Lib/xmlrpclib.py", line 601, in feed
    self._parser.Parse(data, 0)
  File "/tmp/Python-2.6.5/Lib/xmlrpclib.py", line 868, in end
    return f(self, join(self._data, ""))
  File "/tmp/Python-2.6.5/Lib/xmlrpclib.py", line 935, in end_struct
    dict[_stringify(items[i])] = items[i+1]
IndexError: list index out of range

The exception is caused by the XML response, which includes a value with "ex:i8" type. According to this: http://ws.apache.org/xmlrpc/types.html, there are a lot more types, which are not understood by python's xmlrpclib.

It's easy to fix the above by adding "ex:i8" to the list of end_int dispatcher:
    def end_int(self, data):
        self.append(int(data))
        self._value = 0
    dispatch["i4"] = end_int
    dispatch["i8"] = end_int
    dispatch["ex:i8"] = end_int
    dispatch["int"] = end_int

This makes the error disappear (and the program to work).
Of course, it would be nice to support all other types as well (in both directions).

----------
components: XML
messages: 106322
nosy: bra
priority: normal
severity: normal
status: open
title: xmlrpclib compatibility issues with Apache XML-RPC library
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun May 23 11:42:00 2010
From: report at bugs.python.org (royf)
Date: Sun, 23 May 2010 09:42:00 +0000
Subject: [New-bugs-announce] [issue8793] IDLE crashes on opening invalid file
In-Reply-To: <1274607720.78.0.880248664053.issue8793@psf.upfronthosting.co.za>
Message-ID: <1274607720.78.0.880248664053.issue8793@psf.upfronthosting.co.za>


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

1. Create a file containing this line:
'\xdk'

2. Open the file for editing in IDLE 2.6.4. Banner:
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32

3. Run Module (F5) -> Bug#1: no error is shown

4. Run Module 7 more times (exactly!) -> Bug#2: IDLE crashes

----------
components: IDLE
messages: 106328
nosy: royf
priority: normal
severity: normal
status: open
title: IDLE crashes on opening invalid file
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Sun May 23 12:13:15 2010
From: report at bugs.python.org (reynaldo)
Date: Sun, 23 May 2010 10:13:15 +0000
Subject: [New-bugs-announce] [issue8794] Python,
	reynaldo bendijo wants to chat
In-Reply-To: <AANLkTin1qYGaiqdB6aGrPtCK59MYdDVGuiUGst_E--Nw@mail.gmail.com>
Message-ID: <AANLkTin1qYGaiqdB6aGrPtCK59MYdDVGuiUGst_E--Nw@mail.gmail.com>


New submission from reynaldo <renben77 at gmail.com>:

I've been using Google Talk and thought you might like to try it out.
We can use it to call each other for free over the internet. Here's an
invitation to download Google Talk. Give it a try!

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

reynaldo bendijo wants to stay in better touch using some of Google's
coolest new
products.

If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-bea89ac769-8aa0f7d30c-M7u-8vnkjuK6niiM4o2sjhHHJRw
You'll need to click this link to be able to chat with reynaldo bendijo.

To get Gmail - a free email account from Google with over 2,800 megabytes of
storage - and chat with reynaldo bendijo, visit:
http://mail.google.com/mail/a-bea89ac769-8aa0f7d30c-M7u-8vnkjuK6niiM4o2sjhHHJRw

Gmail offers:
- Instant messaging right inside Gmail
- Powerful spam protection
- Built-in search for finding your messages and a helpful way of organizing
  emails into "conversations"
- No pop-up ads or untargeted banners - just text ads and related information
  that are relevant to the content of your messages

All this, and its yours for free. But wait, there's more! By opening a Gmail
account, you also get access to Google Talk, Google's instant messaging
service:

http://www.google.com/talk/

Google Talk offers:
- Web-based chat that you can use anywhere, without a download
- A contact list that's synchronized with your Gmail account
- Free, high quality PC-to-PC voice calls when you download the Google Talk
  client

We're working hard to add new features and make improvements, so we might also
ask for your comments and suggestions periodically. We appreciate your help in
making our products even better!

Thanks,
The Google Team

To learn more about Gmail and Google Talk, visit:
http://mail.google.com/mail/help/about.html
http://www.google.com/talk/about.html

(If clicking the URLs in this message does not work, copy and paste them into
the address bar of your browser).

----------
messages: 106329
nosy: renben
priority: normal
severity: normal
status: open
title: Python, reynaldo bendijo wants to chat

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

From report at bugs.python.org  Sun May 23 13:28:44 2010
From: report at bugs.python.org (Arie Skliarouk)
Date: Sun, 23 May 2010 11:28:44 +0000
Subject: [New-bugs-announce] [issue8795] Error sending utf8 strings over
	syslog udp protocol
In-Reply-To: <1274614124.24.0.553377006251.issue8795@psf.upfronthosting.co.za>
Message-ID: <1274614124.24.0.553377006251.issue8795@psf.upfronthosting.co.za>


New submission from Arie Skliarouk <skliarie at gmail.com>:

I am trying to send utf8 strings over syslog/udp and get strange error:
Traceback (most recent call last):
  File "/usr/lib/python2.6/logging/handlers.py", line 788, in emit
    self.socket.sendto(msg, self.address)
TypeError: sendto() takes exactly 3 arguments (2 given)

See the attached program, at the beginning it has two parameters - log to file or udp and use utf8 or not. It works in all cases but the udp+utf8.

----------
components: Unicode
files: logger_udp_utf8.py
messages: 106330
nosy: skliarie
priority: normal
severity: normal
status: open
title: Error sending utf8 strings over syslog udp protocol
versions: Python 2.6
Added file: http://bugs.python.org/file17445/logger_udp_utf8.py

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

From report at bugs.python.org  Sun May 23 21:27:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 23 May 2010 19:27:55 +0000
Subject: [New-bugs-announce] [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>


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

codecs module (and codecs.open() function) was added to Python 2.0. codecs.open() creates a StreamReaderWriter object which use two other objects: StreamReader and StreamWriter.

Python 2.6 and 3.0 have a new API: the io module. io.open() creates a TextIOWrapper object which is fully compatible with the file object API (it *is* the (text) file object API :-)). TextIOWrapper supports univeral newline and does better support reading+writing than StreamReaderWriter. TextIOWrapper has a better test suite and is used by default to read and write text files in Python3 (since Python 3.0). The io module has an *optimized* design and the io module was rewritten in C (in Python 2.7 and 3.1).

codecs.open() should be deprecated in Python 3.2 and removed in Python 3.3 (not in Python 2.7). Maybe also StreamReader, StreamWriter and StreamReaderWriter: I don't know if any program use directly these classes, but I think that TextIOWrapper can be used instead.

----------
components: Library (Lib), Unicode
messages: 106339
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Deprecate codecs.open()
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon May 24 03:42:14 2010
From: report at bugs.python.org (Ionut Turturica)
Date: Mon, 24 May 2010 01:42:14 +0000
Subject: [New-bugs-announce] [issue8797] urllib2 basicauth broken in 2.6.5:
	RuntimeError: maximum	recursion depth exceeded in cmp
In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>
Message-ID: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>


New submission from Ionut Turturica <jonozzz at yahoo.com>:

The URL I'm trying to open is using basicauth and the username/password is incorrect.

This works flawlessly in 2.6.4.

  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 391, in open
    response = self._open(req, data)
  File "/home/jono/work/sites/test123/urllib2.py", line 409, in _open
    '_open', req)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 1169, in https_open
    return self.do_open(httplib.HTTPSConnection, req)
  File "/home/jono/work/sites/test123/urllib2.py", line 1107, in do_open
    h = http_class(host, timeout=req.timeout) # will parse host:port
  File "/usr/lib64/python2.6/httplib.py", line 1104, in __init__
    HTTPConnection.__init__(self, host, port, strict, timeout)
  File "/usr/lib64/python2.6/httplib.py", line 660, in __init__
    self._set_hostport(host, port)
  File "/usr/lib64/python2.6/httplib.py", line 689, in _set_hostport
    if host and host[0] == '[' and host[-1] == ']':
RuntimeError: maximum recursion depth exceeded in cmp

----------
components: Library (Lib)
messages: 106342
nosy: jonozzz
priority: normal
severity: normal
status: open
title: urllib2 basicauth broken in 2.6.5: RuntimeError: maximum recursion depth exceeded in cmp
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Mon May 24 11:06:47 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 24 May 2010 09:06:47 +0000
Subject: [New-bugs-announce] [issue8798] tkinter build variants on OSX
In-Reply-To: <1274692007.27.0.519809230611.issue8798@psf.upfronthosting.co.za>
Message-ID: <1274692007.27.0.519809230611.issue8798@psf.upfronthosting.co.za>


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

It would be nice if the binary installer supported both Tk 8.4 and Tk 8.5: the former is present on all current versions of OSX as part of the system, the latter is the only one that is supported in 64-bit code on OSX  10.6.

A number of Tkinter users have also mentioned that they would much prefer to target Tk 8.5 due to a large number of bugfixes in that version (on OSX).

What I'm thinking of is:

have _tkinter.py that does:

try:
   from _tkinter85 import *
except ImportError:
   from _tkinter84 import *

Then patch setup.py to build _tkinter84.so and _tkinter85.so from _tkinter.c while linking to the right version of Tk. This should only be done when a special configure argument is present, if it isn't setup.py should default to building _tkinter.so like it currently does. 

I don't have time to work on a patch myself.

Workaround for this request: build your own copy of _tkinter when you want to use Tk 8.5 (or later) and use sys.path manipulation to ensure that that copy is used.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 106347
nosy: ronaldoussoren
priority: low
severity: normal
stage: needs patch
status: open
title: tkinter build variants on OSX
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon May 24 11:44:18 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 24 May 2010 09:44:18 +0000
Subject: [New-bugs-announce] [issue8799] Hang in lib/test/test_threading.py
In-Reply-To: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za>
Message-ID: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za>


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

The tests for the ConditionVariable a fragile.  On a slow computer, or when running a DEBUG build, the main thread can issue a condition.notify() call, even though the worker threads have not settled in on a wait() call.  This causes the test to stall.
The provided patch "fixes" this by adding a short _wait() before the notify.

----------
components: Library (Lib)
files: locktest.patch
keywords: easy, patch, patch
messages: 106349
nosy: krisvale
priority: normal
severity: normal
status: open
title: Hang in lib/test/test_threading.py
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17447/locktest.patch

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

From report at bugs.python.org  Mon May 24 11:55:42 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 24 May 2010 09:55:42 +0000
Subject: [New-bugs-announce] [issue8800] add threading.RWLock
In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za>
Message-ID: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za>


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

Provided is a patch, implementing a RWLock using a ConditionVariable and Lock.
It has rdlock() and wrlock() methods, and an unlock() method, similar to the rwlock API in pthreads.
It has context managers rdlocked() and wrlocked().
In addition, it conforms to the RLock interface, with acquire() and release() being aliases to wrlock() and unlock() respectively and when used as a context manager, it gets a wrlock()
There is no documentation yet, since this is just a proposal, but there are unit tests.

See also issue 8777 for another locking primitive, the Barrier.

----------
components: Library (Lib)
files: rwlock.patch
keywords: needs review, patch, patch
messages: 106350
nosy: krisvale
priority: normal
severity: normal
status: open
title: add threading.RWLock
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file17448/rwlock.patch

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

From report at bugs.python.org  Mon May 24 12:23:23 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 24 May 2010 10:23:23 +0000
Subject: [New-bugs-announce] [issue8801] Inconsistency in behaviour of
	urllib and urllib2 with	file:// URLs
In-Reply-To: <1274696603.9.0.49787272885.issue8801@psf.upfronthosting.co.za>
Message-ID: <1274696603.9.0.49787272885.issue8801@psf.upfronthosting.co.za>


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

I encountered what seems like an incompatibility between urllib and urllib2 in the way they handle file:// URLs. Here's a console session to illustrate:

vinay <at> eta-karmic:/tmp$ echo Hello, world! >hello.txt
vinay <at> eta-karmic:/tmp$ cat hello.txt 
Hello, world!
vinay <at> eta-karmic:/tmp$ python
Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib,urllib2
>>> s = 'file:////tmp/hello.txt'
>>> f1 = urllib.urlopen(s)
>>> f1.read()
'Hello, world!\n'
>>> f2 = urllib2.urlopen(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/urllib2.py", line 124, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.6/urllib2.py", line 389, in open
    response = self._open(req, data)
  File "/usr/lib/python2.6/urllib2.py", line 407, in _open
    '_open', req)
  File "/usr/lib/python2.6/urllib2.py", line 367, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 1240, in file_open
    return self.parent.open(req)
  File "/usr/lib/python2.6/urllib2.py", line 389, in open
    response = self._open(req, data)
  File "/usr/lib/python2.6/urllib2.py", line 407, in _open
    '_open', req)
  File "/usr/lib/python2.6/urllib2.py", line 367, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 1287, in ftp_open
    raise URLError('ftp error: no host given')
urllib2.URLError: <urlopen error ftp error: no host given>
>>> 

The problem appears to be that urllib allows a badly-formed file URL (with file://// rather than file:///) when it shouldn't (errors should not pass silently).

----------
messages: 106351
nosy: vinay.sajip
priority: low
severity: normal
status: open
title: Inconsistency in behaviour of urllib and urllib2 with file:// URLs
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon May 24 13:39:21 2010
From: report at bugs.python.org (sivaramakrishna uddanti)
Date: Mon, 24 May 2010 11:39:21 +0000
Subject: [New-bugs-announce] [issue8802] about oa module
In-Reply-To: <1274701161.14.0.0502226898234.issue8802@psf.upfronthosting.co.za>
Message-ID: <1274701161.14.0.0502226898234.issue8802@psf.upfronthosting.co.za>


New submission from sivaramakrishna uddanti <sivaram.uddanti at gmail.com>:

i want to know about the oa module in python .. i searched in google but it was to no avail .. please provide me with the details of the mentioned module ..

----------
components: Extension Modules
messages: 106353
nosy: sudanti
priority: normal
severity: normal
status: open
title: about oa module
versions: Python 2.6

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

From report at bugs.python.org  Mon May 24 13:41:26 2010
From: report at bugs.python.org (sivaramakrishna uddanti)
Date: Mon, 24 May 2010 11:41:26 +0000
Subject: [New-bugs-announce] [issue8803] about oa module
In-Reply-To: <1274701286.05.0.166496398386.issue8803@psf.upfronthosting.co.za>
Message-ID: <1274701286.05.0.166496398386.issue8803@psf.upfronthosting.co.za>


New submission from sivaramakrishna uddanti <sivaram.uddanti at gmail.com>:

i want to know about the oa module in python.. i searched in the google but it was to no avail . please provide me with the details of mentioned module..

----------
components: Extension Modules
messages: 106354
nosy: sudanti
priority: normal
severity: normal
status: open
title: about oa module
versions: Python 2.6

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

From report at bugs.python.org  Mon May 24 18:02:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:02:04 +0000
Subject: [New-bugs-announce] [issue8804] http.client should support SSL
	contexts
In-Reply-To: <1274716924.32.0.357648768076.issue8804@psf.upfronthosting.co.za>
Message-ID: <1274716924.32.0.357648768076.issue8804@psf.upfronthosting.co.za>


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

3.2 introduces SSL contexts, which allow bundling SSL configuration options, certificates and private keys into a single (potentially long-lived) structure.
http://docs.python.org/dev/py3k/library/http.client.html

http.client.HTTPSConnection should allow passing an SSL context object instead of a cert/key pair.

----------
components: Library (Lib)
messages: 106362
nosy: giampaolo.rodola, orsenthil, pitrou
priority: normal
severity: normal
status: open
title: http.client should support SSL contexts
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon May 24 18:04:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:04:04 +0000
Subject: [New-bugs-announce] [issue8805] urllib should support SSL contexts
In-Reply-To: <1274717044.09.0.580152326927.issue8805@psf.upfronthosting.co.za>
Message-ID: <1274717044.09.0.580152326927.issue8805@psf.upfronthosting.co.za>


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

3.2 introduces SSL contexts, which allow bundling SSL configuration options, certificates and private keys into a single (potentially long-lived) structure.
http://docs.python.org/dev/py3k/library/http.client.html

urllib.request.*URLOpener should allow passing an SSL context object, if not already possible.

(I hope you don't mind the multiple similar issues, but I think one separate issue per stdlib module is more manageable)

----------
components: Library (Lib)
messages: 106363
nosy: pitrou
priority: normal
severity: normal
status: open
title: urllib should support SSL contexts
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon May 24 18:07:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:07:42 +0000
Subject: [New-bugs-announce] [issue8806] ftplib should support SSL contexts
In-Reply-To: <1274717262.45.0.585988052804.issue8806@psf.upfronthosting.co.za>
Message-ID: <1274717262.45.0.585988052804.issue8806@psf.upfronthosting.co.za>


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

3.2 introduces SSL contexts, which allow bundling SSL configuration options, certificates and private keys into a single (potentially long-lived) structure.
http://docs.python.org/dev/py3k/library/ssl.html#ssl.SSLContext

The FTP_TLS constructor should allow passing an SSL context object instead of a key/cert pair.

----------
messages: 106366
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: ftplib should support SSL contexts
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon May 24 18:10:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:10:53 +0000
Subject: [New-bugs-announce] [issue8807] poplib should support SSL contexts
In-Reply-To: <1274717453.42.0.117034220477.issue8807@psf.upfronthosting.co.za>
Message-ID: <1274717453.42.0.117034220477.issue8807@psf.upfronthosting.co.za>


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

3.2 introduces SSL contexts, which allow bundling SSL configuration options, certificates and private keys into a single (potentially long-lived) structure.
http://docs.python.org/dev/py3k/library/ssl.html#ssl.SSLContext

The POP3_SSL constructor should allow passing an SSL context object instead of a key/cert pair.

----------
components: Library (Lib)
messages: 106367
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: poplib should support SSL contexts
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon May 24 18:13:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:13:57 +0000
Subject: [New-bugs-announce] [issue8808] imaplib should support SSL contexts
In-Reply-To: <1274717637.39.0.0073929793702.issue8808@psf.upfronthosting.co.za>
Message-ID: <1274717637.39.0.0073929793702.issue8808@psf.upfronthosting.co.za>


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

3.2 introduces SSL contexts, which allow bundling SSL configuration options, certificates and private keys into a single (potentially long-lived) structure.
http://docs.python.org/dev/py3k/library/ssl.html#ssl.SSLContext

The IMAP4_SSL constructor should allow passing an SSL context object instead of a key/cert pair.

----------
components: Library (Lib)
messages: 106368
nosy: pitrou
priority: normal
severity: normal
status: open
title: imaplib should support SSL contexts
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon May 24 18:15:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:15:42 +0000
Subject: [New-bugs-announce] [issue8809] smptlib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>


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

3.2 introduces SSL contexts, which allow bundling SSL configuration options, certificates and private keys into a single (potentially long-lived) structure.
http://docs.python.org/dev/py3k/library/ssl.html#ssl.SSLContext

The SMTP_SSL constructor should allow passing an SSL context object instead of a key/cert pair.

----------
components: Library (Lib)
messages: 106369
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: smptlib should support SSL contexts
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon May 24 18:20:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 May 2010 16:20:21 +0000
Subject: [New-bugs-announce] [issue8810] TZ offset description is unclear in
	docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>From <http://docs.python.org/dev/py3k/library/datetime.html#datetime.tzinfo.utcoffset>:

"""
tzinfo.utcoffset(self, dt)

    Return offset of local time from UTC, in minutes east of UTC. 
"""

This suggests that the return value is an integer representing the number of minutes.  It is later explained that in fact "the value returned must be a timedelta object specifying a whole number of minutes", but many users won't read past the first sentence.

I suggest s/in minutes east of UTC/as a timedelta object/.  I think "east of UTC" is redundant given the next sentence, "If local time is west of UTC, this should be negative", but that can also be reworded for clarity as "The offset for timezones west of UTC is negative, and for those east of UTC is positive."

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 106371
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: TZ offset description is unclear in docs
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon May 24 21:57:09 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 24 May 2010 19:57:09 +0000
Subject: [New-bugs-announce] [issue8811] fixing sqlite3 docs for py3k
In-Reply-To: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>
Message-ID: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>


New submission from Shashwat Anand <anand.shashwat at gmail.com>:

The docs of sqlite3 for python 3.0 and 3.1 seems to be written for python 2.6 and hence wrong at many places.
like, 
>>> for member in r: print member 

However the docs for sqlite3 in py3k trunk seems fine. The sqlite3 doc in py3k trunk should be used in these places.

http://docs.python.org/release/3.0.1/library/sqlite3.html
http://docs.python.org/release/3.1/library/sqlite3.html

----------
assignee: docs at python
components: Documentation
files: sqlite.rst.patch
keywords: patch
messages: 106382
nosy: docs at python, georg.brandl, ghaering, l0nwlf
priority: normal
severity: normal
status: open
title: fixing sqlite3 docs for py3k
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17451/sqlite.rst.patch

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

From report at bugs.python.org  Mon May 24 23:00:30 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 24 May 2010 21:00:30 +0000
Subject: [New-bugs-announce] [issue8812] Show package path in repr string
	for packages installed	to user site
In-Reply-To: <1274734830.9.0.699148777816.issue8812@psf.upfronthosting.co.za>
Message-ID: <1274734830.9.0.699148777816.issue8812@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

I see this in Python 2.7. No idea if this is a regression, mere future request, but doesn't it make sense to print the value `__path__` in the repr string?

>>> import paste
>>> paste
<module 'paste' (built-in)>
>>> paste.__path__
['/home/sridharr/.local/lib/python2.7/site-packages/paste']

It does for stdlib packages/modules:

>>> import xml
>>> xml
<module 'xml' from '/opt/ActivePython-2.7/lib/python2.7/xml/__init__.pyc'>

Happens on Windows, Linux and Mac using Python 2.7 hg hash eaeebf8cda33.0.

----------
components: Library (Lib)
messages: 106391
nosy: srid
priority: normal
severity: normal
status: open
title: Show package path in repr string for packages installed to user site
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Mon May 24 23:17:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 May 2010 21:17:10 +0000
Subject: [New-bugs-announce] [issue8813] SSLContext doesn't support loading
	a CRL
In-Reply-To: <1274735830.03.0.714974872377.issue8813@psf.upfronthosting.co.za>
Message-ID: <1274735830.03.0.714974872377.issue8813@psf.upfronthosting.co.za>


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

SSL Context should support loading a CRL. See M2Crypto patches:
https://bugzilla.osafoundation.org/show_bug.cgi?id=12954
https://bugzilla.osafoundation.org/show_bug.cgi?id=11694

Or PyOpenSSL branch supporting CRL:
https://launchpad.net/~rick-fdd/pyopenssl/crl_and_revoked

----------
components: Library (Lib)
messages: 106393
nosy: haypo
priority: normal
severity: normal
status: open
title: SSLContext doesn't support loading a CRL
versions: Python 3.2

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

From report at bugs.python.org  Mon May 24 23:20:59 2010
From: report at bugs.python.org (Terrence Cole)
Date: Mon, 24 May 2010 21:20:59 +0000
Subject: [New-bugs-announce] [issue8814] functools.WRAPPER_ASSIGNMENTS
	should include	__annotations__
In-Reply-To: <1274736059.05.0.616257463555.issue8814@psf.upfronthosting.co.za>
Message-ID: <1274736059.05.0.616257463555.issue8814@psf.upfronthosting.co.za>


New submission from Terrence Cole <terrence at zettabytestorage.com>:

__annotations__ should be included in the set of attributes copied by default to a wrapped method.

An example of the problem:
>>> from functools import wraps
>>> def mydecorator(fn):
...     @wraps(fn)
...     def inner(*args, **kwargs):
...         return fn(*args, **kwargs)
...     return inner
...
>>> @mydecorator
... def foo(a:int, b:str):
...     pass
... 
>>> foo.__annotations__
{}

With the included fix:
>>> foo.__annotations__
{'a': <class 'int'>, 'b': <class 'str'>}

----------
components: Library (Lib)
files: functools-wrapper-assign-annotations.diff
keywords: patch
messages: 106394
nosy: terrence
priority: normal
severity: normal
status: open
title: functools.WRAPPER_ASSIGNMENTS should include __annotations__
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17453/functools-wrapper-assign-annotations.diff

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

From report at bugs.python.org  Tue May 25 00:43:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 May 2010 22:43:18 +0000
Subject: [New-bugs-announce] [issue8815] 65001
Message-ID: <1274740998.1.0.335248912242.issue8815@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: haypo
priority: normal
severity: normal
status: open
title: 65001

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

From report at bugs.python.org  Tue May 25 03:47:12 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Tue, 25 May 2010 01:47:12 +0000
Subject: [New-bugs-announce] [issue8816] Add test cases for builtins
In-Reply-To: <1274752032.87.0.724423132707.issue8816@psf.upfronthosting.co.za>
Message-ID: <1274752032.87.0.724423132707.issue8816@psf.upfronthosting.co.za>


New submission from Gregory Nofi <crackityjones2004-p at yahoo.com>:

I'm attaching 2 patches with additional test cases for these built-in functions. They are mostly negative tests.

* abs
* callable: trunk only
* len
* long: trunk only
* range: copied some py3k range tests into trunk
* reduce: trunk only
* vars

I'm currently helping port IronPython tests into CPython. This is part of that series.

----------
components: Tests
files: builtins.trunk.patch
keywords: patch
messages: 106410
nosy: gnofi
priority: normal
severity: normal
status: open
title: Add test cases for builtins
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file17457/builtins.trunk.patch

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

From report at bugs.python.org  Tue May 25 14:56:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 May 2010 12:56:02 +0000
Subject: [New-bugs-announce] [issue8817] Expose round-to-nearest division
	algorithm in	Objects/longobject.c
In-Reply-To: <1274792162.57.0.293855829379.issue8817@psf.upfronthosting.co.za>
Message-ID: <1274792162.57.0.293855829379.issue8817@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The implementation of 'round' for Python integers uses a round-to-nearest form of divmod:  a, b -> q, r, where q is the nearest integer to a / b and r = a - b*q.

This form of divmod would be useful elsewhere.  In particular, it's currently needed for implementing multiplication and division of timedeltas by a float:  see issue 1289118  .

This patch exposes the operation to Python C code as _PyLong_Divmod_Near, and refactors long_round to use this operation.

----------
assignee: mark.dickinson
files: div_nearest.patch
keywords: patch
messages: 106431
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Expose round-to-nearest division algorithm in Objects/longobject.c
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17459/div_nearest.patch

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

From report at bugs.python.org  Tue May 25 16:40:19 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 14:40:19 +0000
Subject: [New-bugs-announce] [issue8818] urlsplit and urlparse add extra
	slash when using scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>


New submission from AdamN <adam at varud.com>:

urlsplit and urlparse place the host into the path when using a default scheme:

(Pdb) urlsplit('regionalhelpwanted.com/browseads/?sn=2',scheme='http')
SplitResult(scheme='http', netloc='', path='regionalhelpwanted.com/browseads/', query='sn=2', fragment='')

When using default_scheme as referenced in the documentation, it simply doesn't work:

(Pdb) urlsplit('regionalhelpwanted.com/browseads/?sn=2',default_scheme='http')
*** TypeError: urlsplit() got an unexpected keyword argument 'default_scheme'

----------
components: Library (Lib)
messages: 106438
nosy: adamnelson
priority: normal
severity: normal
status: open
title: urlsplit and urlparse add extra slash when using scheme
versions: Python 2.6

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

From report at bugs.python.org  Tue May 25 18:49:08 2010
From: report at bugs.python.org (Colin Hawkett)
Date: Tue, 25 May 2010 16:49:08 +0000
Subject: [New-bugs-announce] [issue8819] variable resolution within exec()
	incorrect
In-Reply-To: <1274806148.14.0.229053975552.issue8819@psf.upfronthosting.co.za>
Message-ID: <1274806148.14.0.229053975552.issue8819@psf.upfronthosting.co.za>


New submission from Colin Hawkett <hawkett at gmail.com>:

A discussion on stack overflow - http://stackoverflow.com/questions/2904274/globals-and-locals-in-python-exec - has led to the conclusion that the variable lookup behaviour within code run using exec() is not behaving as expected. Variable lookup inside a class definition does not search the enclosing scope's locals() prior to issuing a NameError - there are full details and test cases at the above URL.

----------
components: None
messages: 106447
nosy: hawkett
priority: normal
severity: normal
status: open
title: variable resolution within exec() incorrect
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed May 26 04:48:04 2010
From: report at bugs.python.org (Joseph)
Date: Wed, 26 May 2010 02:48:04 +0000
Subject: [New-bugs-announce] [issue8820] IDLE not launching correctly
In-Reply-To: <1274842084.45.0.257196773636.issue8820@psf.upfronthosting.co.za>
Message-ID: <1274842084.45.0.257196773636.issue8820@psf.upfronthosting.co.za>


New submission from Joseph <joseph.a.marlin at gmail.com>:

I am on Windows 7 64 bit. Issue occurs trying to open IDLE or Module Docs.

My problem is very similar to this one: http://bugs.python.org/issue8247
Also, it is almost identical to this: http://bugs.python.org/issue7265

Followed the directions in issue 7265, here is the error message. 


c:\Python26>python.exe Lib\idlelib\idle.py
Traceback (most recent call last):
  File "Lib\idlelib\idle.py", line 6, in <module>
    import PyShell
  File "c:\Python26\Lib\idlelib\PyShell.py", line 14, in <module>
    import macosxSupport
  File "c:\Python26\Lib\idlelib\macosxSupport.py", line 6, in <module>
    import Tkinter
  File "c:\Python26\lib\lib-tk\Tkinter.py", line 38, in <module>
    import FixTk
  File "c:\Python26\lib\lib-tk\FixTk.py", line 63, in <module>
    import _tkinter
ImportError: DLL load failed: %1 is not a valid Win32 application.


Note that I am definitely running Windows 64 bit, and I definitely downloaded the 64 bit version of Python. Also, I did not apply the fix that worked in 7265 because first of all, that wasn't the issue, (here I can't import tkinter, there he couldn't open a file), and secondly, I don't have the file he mentioned that he unhid.

----------
components: IDLE
messages: 106504
nosy: NightFalcon
priority: normal
severity: normal
status: open
title: IDLE not launching correctly
versions: Python 2.6

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

From report at bugs.python.org  Wed May 26 06:11:53 2010
From: report at bugs.python.org (Matt Giuca)
Date: Wed, 26 May 2010 04:11:53 +0000
Subject: [New-bugs-announce] [issue8821] Range check on unicode repr
In-Reply-To: <1274847113.25.0.171149609237.issue8821@psf.upfronthosting.co.za>
Message-ID: <1274847113.25.0.171149609237.issue8821@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

In unicodeobject.c's unicodeescape_string, in UCS2 builds, if the last character of the string is the start of a UTF-16 surrogate pair (between '\ud800' and '\udfff'), there is a slight overrun problem. For example:

>>> repr(u'abcd\ud800')

Upon reading ch = 0xd800, the test (ch >= 0xD800 && ch < 0xDC00) succeeds, and it then reads ch2 = *s++. Note that preceding this line, s points at one character past the end of the string, so the value read will be garbage. I imagine that unless it falls on a segment boundary, the worst that could happen is the character '\ud800' is interpreted as some other wide character. Nevertheless, this is bad.

Note that *technically* this is never bad, because _PyUnicode_New allocates an extra character and sets it to '\u0000', and thus the above example will always set ch2 to 0, and it will behave correctly. But this is a tenuous thing to rely on, especially given the comment above _PyUnicode_New:

/* We allocate one more byte to make sure the string is
   Ux0000 terminated -- XXX is this needed ?
*/

I thought about removing that XXX, but I'd rather fix the problem. Therefore, I have attached a patch which does a range check before reading ch2:

--- Objects/unicodeobject.c	(revision 81539)
+++ Objects/unicodeobject.c	(working copy)
@@ -3065,7 +3065,7 @@
         }
 #else
         /* Map UTF-16 surrogate pairs to '\U00xxxxxx' */
-        else if (ch >= 0xD800 && ch < 0xDC00) {
+        else if (ch >= 0xD800 && ch < 0xDC00 && size > 0) {
             Py_UNICODE ch2;
             Py_UCS4 ucs;

Also affects Python 3.

----------
components: Unicode
files: unicode-range-check.patch
keywords: patch
messages: 106506
nosy: mgiuca
priority: normal
severity: normal
status: open
title: Range check on unicode repr
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17465/unicode-range-check.patch

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

From report at bugs.python.org  Wed May 26 14:07:27 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 26 May 2010 12:07:27 +0000
Subject: [New-bugs-announce] [issue8822] datetime naive and aware types
	should have a well-defined	definition that can be cross-referenced
In-Reply-To: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>
Message-ID: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>


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

'naive' and 'aware' are key datetime types - they need a proper definition and anchor for crossrefences. If you take a look at http://docs.python.org/library/datetime.html - the definition of distinction between them is too vague and this seeds of uncertainty grow through the rest of the doc. It is not said how to make non-naive object, how to detect if object of naive or aware. All this stuff is very important for troubleshooting datetims issues in Python projects. It needs a proper documentation.

----------
assignee: docs at python
components: Documentation
messages: 106524
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: datetime naive and aware types should have a well-defined definition that can be cross-referenced

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

From report at bugs.python.org  Wed May 26 15:44:10 2010
From: report at bugs.python.org (AdamN)
Date: Wed, 26 May 2010 13:44:10 +0000
Subject: [New-bugs-announce] [issue8823] urllib2 does not catch
	httplib.BadStatusLine
In-Reply-To: <1274881450.55.0.827580135846.issue8823@psf.upfronthosting.co.za>
Message-ID: <1274881450.55.0.827580135846.issue8823@psf.upfronthosting.co.za>


New submission from AdamN <adam at varud.com>:

When running urllib2 and getting a BadStatus from an http server, this error is raised:

  File "/var/www/pinax-env/pline/apps/page/models.py", line 303, in render
    content = urllib2.urlopen(self.url,timeout=10).read()
  File "/usr/lib/python2.6/urllib2.py", line 124, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.6/urllib2.py", line 389, in open
    response = self._open(req, data)
  File "/usr/lib/python2.6/urllib2.py", line 407, in _open
    '_open', req)
  File "/usr/lib/python2.6/urllib2.py", line 367, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 1146, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "/usr/lib/python2.6/urllib2.py", line 1119, in do_open
    r = h.getresponse()
  File "/usr/lib/python2.6/httplib.py", line 974, in getresponse
    response.begin()
  File "/usr/lib/python2.6/httplib.py", line 391, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python2.6/httplib.py", line 355, in _read_status
    raise BadStatusLine(line)
httplib.BadStatusLine

Because urllib2 doesn't catch it with this:

lines 1116-1120

try:
    h.request(req.get_method(), req.get_selector(), req.data, headers)
    r = h.getresponse()
except socket.error, err: # XXX what error?
    raise URLError(err)

It is not caught anywhere else and the call blows up unless I make a special exception for all httplib exceptions.  The specific url that blew this up is:

http://phoenix.untd.com/oasx/rqst/type=sx/rdb=8203014d740000555355533a415a2d2d2d2d2d2d2d2d2d2d0100001d494a0901000000000000/version=3/origin=uol/isp=et_cau

----------
messages: 106526
nosy: adamnelson
priority: normal
severity: normal
status: open
title: urllib2 does not catch httplib.BadStatusLine
type: behavior

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

From report at bugs.python.org  Wed May 26 19:36:47 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 26 May 2010 17:36:47 +0000
Subject: [New-bugs-announce] [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>


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

This doc improvement suggestion is inspired by #991196 (and subsequent duplicates) and the current discussion on py-dev in the thread
  'variable name resolution in exec is incorrect'
(which is not a correct claim). I believe there is consensus that the doc for exec needs improving.

My suggestion (which others may amend) is that the following paragraph (from the 3.x builtin functions exec entry)

"In all cases, if the optional parts are omitted, the code is executed in the current scope. If only globals is provided, it must be a dictionary, which will be used for both the global and the local variables. If globals  and locals are given, they are used for the global and local variables, respectively. If provided, locals can be any mapping object."

have these two sentences added:

"If only globals is provided or if onedict is provided as both globals and locals, the code is executed in a new top-level scope. If different objects are given as globals and locals, the code is executed as if it were in a class statement in a new top-level scope."

----------
assignee: docs at python
components: Documentation
messages: 106552
nosy: docs at python, tjreedy
priority: normal
severity: normal
status: open
title: Improve documentation of exec
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed May 26 19:44:21 2010
From: report at bugs.python.org (C Moss)
Date: Wed, 26 May 2010 17:44:21 +0000
Subject: [New-bugs-announce] [issue8825] int("0",0) throws exception
In-Reply-To: <1274895861.73.0.0531929444904.issue8825@psf.upfronthosting.co.za>
Message-ID: <1274895861.73.0.0531929444904.issue8825@psf.upfronthosting.co.za>


New submission from C Moss <cm.byu.fan at gmail.com>:

The expression int("0",0) throws an exception, though the expectation would be to return 0 (zero).

int("0x0",0) == 0
int("00",0) = 0

----------
components: None
messages: 106554
nosy: cmoss60
priority: normal
severity: normal
status: open
title: int("0",0) throws exception
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed May 26 20:01:58 2010
From: report at bugs.python.org (Tomas Zulberti)
Date: Wed, 26 May 2010 18:01:58 +0000
Subject: [New-bugs-announce] [issue8826] Invalid expires date in cookiejar
In-Reply-To: <1274896918.81.0.357583266037.issue8826@psf.upfronthosting.co.za>
Message-ID: <1274896918.81.0.357583266037.issue8826@psf.upfronthosting.co.za>


New submission from Tomas Zulberti <tzulberti at gmail.com>:

This happens when creating a SimpleCookie from an string. The value in the cookie is: "expires=Fri, 31-Dec-2010 23:59:59 GMT"

But in the cookiejar, the value if only "Fri,". 

As far as I know, the error is in the regular expresion _LegalCharsPatt, that doesn't allows whitespaces. The format of the expires date was taken from the wikipedia: http://en.wikipedia.org/wiki/HTTP_cookie#Cookie_attributes

----------
components: None
messages: 106557
nosy: tzulberti
priority: normal
severity: normal
status: open
title: Invalid expires date in cookiejar
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed May 26 21:31:31 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 26 May 2010 19:31:31 +0000
Subject: [New-bugs-announce] [issue8827] poplib.POP3_SSL doesn't have an
	actual test suite
In-Reply-To: <1274902291.16.0.0457634401694.issue8827@psf.upfronthosting.co.za>
Message-ID: <1274902291.16.0.0457634401694.issue8827@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

As done for ftplib.FTP_TLS the tests executed in TestPOP3Class should be replicated to use poplib.POP3_SSL instead of poplib.POP3.

asyncore-based SSL test server used in test_ftplib.py can be used as an example on how to do this.

----------
assignee: giampaolo.rodola
components: Tests
messages: 106570
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: poplib.POP3_SSL doesn't have an actual test suite
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu May 27 01:41:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 May 2010 23:41:41 +0000
Subject: [New-bugs-announce] [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>


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

os.rename() is atomic on Linux, but on Windows it raises an error if the destination does already exist.

Not atomic pseudo-code for Windows:
  if exists(b):
     unlink(b)
  rename(a, b)

Windows offers different functions depending on the version:
 - MoveFileTransacted(): atomic! version >= (Windows Vista, Windows Server 2008)
 - ReplaceFile(): version >= Windows 2000
 - MoveFileEx() with MOVEFILE_REPLACE_EXISTING and MOVEFILE_WRITE_THROUGH flags: not atomic (eg. "If the file is to be moved to a different volume, the function simulates the move by using the CopyFile and DeleteFile functions."), version >= Windows 2000

I don't think that it's possible to write an atomic rename (file) function for any OS, so it's only a "best effort" atomic function. The documentation will give a list of OS on which the operation *is* atomic (eg. Linux).

Note: os.rename() uses MoveFileW() on Windows.

----------
components: Library (Lib), Windows
messages: 106587
nosy: haypo
priority: normal
severity: normal
status: open
title: Atomic function to rename a file
versions: Python 3.2

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

From report at bugs.python.org  Thu May 27 02:12:19 2010
From: report at bugs.python.org (Celia Horne)
Date: Thu, 27 May 2010 00:12:19 +0000
Subject: [New-bugs-announce] [issue8829] IDLE editior not opening
In-Reply-To: <1274919139.94.0.215202967128.issue8829@psf.upfronthosting.co.za>
Message-ID: <1274919139.94.0.215202967128.issue8829@psf.upfronthosting.co.za>


New submission from Celia Horne <oneidiotinatree at gmail.com>:

Hey there!

I'm very new to Python, but I've been getting along fairly well. However, last night I tried to open the IDLE editor (on its own and with a .py file)but nothing would open. It just sat there acting like it was going to load, but still nothing occurred.

Originally I was using version 2.6.5, but I started experiencing these same problems with it. I looked online but could find no help or suggestions. I tried uninstalling/reinstalling, I made sure I am already set as the Admin, (as I am the only user on this computer, and there is only my account, not even a guest account) and I looked to see if there was a Windows Vista patch or Vista-only issue, but to no avail. At this point, I am completely lost and I really need some assistance.

I installed the newer version (3.1.2) and I'm still having the same issues. The CMD prompt works just fine, as it did with the older version, but nothing I do can bring up the IDLE editor.

Any help would be VERY appreciated, because I was really looking forward to using and learning python, but now I'm feeling very defeated.

Thanks

----------
components: IDLE, Windows
messages: 106589
nosy: Celia.Horne
priority: normal
severity: normal
status: open
title: IDLE editior not opening
type: performance
versions: Python 3.1

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

From report at bugs.python.org  Thu May 27 03:25:10 2010
From: report at bugs.python.org (ipatrol)
Date: Thu, 27 May 2010 01:25:10 +0000
Subject: [New-bugs-announce] [issue8830] Add nondestructive selection to sets
In-Reply-To: <1274923510.24.0.670260490915.issue8830@psf.upfronthosting.co.za>
Message-ID: <1274923510.24.0.670260490915.issue8830@psf.upfronthosting.co.za>


New submission from ipatrol <ipatrol6010 at yahoo.com>:

I see in a lot of references for computer programming a function that returns an arbitrary value from a standard or frozen set. http://en.wikipedia.org/wiki/Set_%28computer_science%29 describes it as pick. It surprised me when I discovered that Python sets don't have this method. I would suggest the returned value be somewhat random to prevent repeated calls from returning repeated results. Perhaps a small C-level counter could control that, which can then roll over uneventfully if enough calls are made.

----------
components: None
messages: 106590
nosy: ipatrol
priority: normal
severity: normal
status: open
title: Add nondestructive selection to sets
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu May 27 10:43:14 2010
From: report at bugs.python.org (Alessandro Roat)
Date: Thu, 27 May 2010 08:43:14 +0000
Subject: [New-bugs-announce] [issue8831] recv and recvfrom on UDP socket do
	not return/throw	exception after a close()
In-Reply-To: <1274949794.75.0.209181492423.issue8831@psf.upfronthosting.co.za>
Message-ID: <1274949794.75.0.209181492423.issue8831@psf.upfronthosting.co.za>


New submission from Alessandro Roat <alexroat at gmail.com>:

A thread blocked on a recv or a recvfrom method on a UDP socket (waiting for a datagram) can not be unlocked calling a .close() from a different thread.
This is in contrast with the standard C++/C behavior, where a close() on a socket causes an asynchronous and immediate exception/return with error on the functions that are using the socket at the same time (but in another thread).
Thus, it is impossible to unlock a waiting recv/recvfrom calling a close() or a shutdown() if no more datagrams are coming.

----------
components: IO
messages: 106596
nosy: Alessandro.Roat
priority: normal
severity: normal
status: open
title: recv and recvfrom on UDP socket do not return/throw exception after a close()
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu May 27 15:03:02 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 27 May 2010 13:03:02 +0000
Subject: [New-bugs-announce] [issue8832] automate minidom.unlink() with a
	context manager
In-Reply-To: <1274965382.14.0.210712489615.issue8832@psf.upfronthosting.co.za>
Message-ID: <1274965382.14.0.210712489615.issue8832@psf.upfronthosting.co.za>


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

It is all to easy to forget to "unlink()" minidom documents resulting in huge memory usage.
This patch allows to automate that process with a context manager, similar to how files can be closed in the same way:

with xml.dom.minidom.parse() as dom:
    workwith(dom)

will automatically call dom.unlink() when context manager is exited.
Patch provided.

----------
components: Library (Lib)
files: minidomcontext.patch
keywords: easy, needs review, patch, patch
messages: 106610
nosy: krisvale
priority: normal
severity: normal
status: open
title: automate minidom.unlink() with a context manager
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17472/minidomcontext.patch

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

From report at bugs.python.org  Thu May 27 18:07:09 2010
From: report at bugs.python.org (Justin Bronder)
Date: Thu, 27 May 2010 16:07:09 +0000
Subject: [New-bugs-announce] [issue8833] tarfile: broken hardlink handling
	and testcase.
In-Reply-To: <1274976429.42.0.686584361847.issue8833@psf.upfronthosting.co.za>
Message-ID: <1274976429.42.0.686584361847.issue8833@psf.upfronthosting.co.za>


New submission from Justin Bronder <jsbronder at gentoo.org>:

When adding hardlinks to an archive, tarfile does not set the size
of each additional link to zero as specified by the tar format [1].

In addition, the current test case hardlinks is also broken.
Instead of testing that the size of a hardlink to a non-empty file
is 0, it tests that the size to a empty file is zero, which cannot
fail.

A patch against current svn trunk is attached and was tested with
'python -m test.regrtest  -v test_tarfile'


1. http://www.gnu.org/software/tar/manual/tar.html#SEC170

----------
components: Library (Lib)
files: python-2.7-tarfile-hardlinks.patch
keywords: patch
messages: 106612
nosy: jsbronder
priority: normal
severity: normal
status: open
title: tarfile:  broken hardlink handling and testcase.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17474/python-2.7-tarfile-hardlinks.patch

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

From report at bugs.python.org  Thu May 27 22:46:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 27 May 2010 20:46:21 +0000
Subject: [New-bugs-announce] [issue8834] Define order of Misc/ACKS entries
In-Reply-To: <1274993181.13.0.347164864235.issue8834@psf.upfronthosting.co.za>
Message-ID: <1274993181.13.0.347164864235.issue8834@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

This is a semi-serious feature request following a brief discussion on #python-dev IRC.

Brett Cannon pointed out on python-checkins list [1] that the names should be alphabetized.  However, given that the names are international, it is not obvious what it means.

I propose to add a comment at the top of Misc/ACKS that the list is maintained in "rough alphabetical order" but not define it any further.

[1] http://mail.python.org/pipermail/python-checkins/2010-May/093650.html

----------
assignee: docs at python
components: Documentation
messages: 106615
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Define order of Misc/ACKS entries
type: feature request

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

From report at bugs.python.org  Thu May 27 23:47:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 21:47:37 +0000
Subject: [New-bugs-announce] [issue8835] buildbot:
	support.transient_internet() doesn't catch DNS	socket.gaierror
In-Reply-To: <1274996857.49.0.779391183304.issue8835@psf.upfronthosting.co.za>
Message-ID: <1274996857.49.0.779391183304.issue8835@psf.upfronthosting.co.za>


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

The nameserver responsible of sha2.hboeck.de is down and this hostname is used in test_ssl. The result is that all trunk buildbots are red (error).

support.transient_internet() should catch socket.gaierror.

--

One example: http://www.python.org/dev/buildbot/all/builders/amd64%20gentoo%20trunk/builds/1007

Traceback (most recent call last):
  File ".../Lib/test/test_ssl.py", line 261, in test_algorithms
    s.connect(remote)
  ...
gaierror: [Errno -2] Name or service not known

----------
components: Tests
messages: 106617
nosy: haypo
priority: normal
severity: normal
status: open
title: buildbot: support.transient_internet() doesn't catch DNS socket.gaierror
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri May 28 00:26:16 2010
From: report at bugs.python.org (Anthony Foglia)
Date: Thu, 27 May 2010 22:26:16 +0000
Subject: [New-bugs-announce] [issue8836] Conflicting default values of
	parameter to __import__
In-Reply-To: <1274999176.58.0.342464262777.issue8836@psf.upfronthosting.co.za>
Message-ID: <1274999176.58.0.342464262777.issue8836@psf.upfronthosting.co.za>


New submission from Anthony Foglia <afoglia at gmail.com>:

Looking at the documentation for the __import__ builtin, the default value of the level parameter is unclear.  Two different values are mentioned.  The function signature is written:

__import__(name, globals={}, locals={}, fromlist=[], level=-1)

But the third paragraph begins: "level specifies whether to use absolute or relative imports. 0 (the default) means only perform absolute imports."

So which is it, -1 or 0?

I'm guessing 0.  If -1 is still a valid value, it needs to be described.

----------
assignee: docs at python
components: Documentation
messages: 106621
nosy: afoglia, docs at python
priority: normal
severity: normal
status: open
title: Conflicting default values of parameter to __import__
versions: Python 3.1

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

From report at bugs.python.org  Fri May 28 00:59:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 22:59:41 +0000
Subject: [New-bugs-announce] [issue8837] PyArg_ParseTuple(): remove old and
	unused "O?" format
In-Reply-To: <1275001181.3.0.513228371252.issue8837@psf.upfronthosting.co.za>
Message-ID: <1275001181.3.0.513228371252.issue8837@psf.upfronthosting.co.za>


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

"O?" format was introduced by r4301 (15 years, 9 months ago). PyArg_ParseTuple() was first documented in Python 2.2, but without the full list of all formats. The format list was added to Python 2.3, but "O?" was never documented. So I get that no third party progam use it.

In Python trunk, "O?" is no more used and so I propose to remove it to simplify getarg.c (simplify getarg cannot be a bad thing). PyArg_ParseTuple() has now better formats than "O?".

--

"O&" calls a callback: if the callback returns 0, raise an error; otherwise gets the object. Example of callbacks: PyXXX_Check() function (eg. PyInt_Check()).

--

The full Python test suite pass without any error on a patched Python (trunk).

----------
components: Interpreter Core
files: getarg_oquestion.patch
keywords: patch
messages: 106624
nosy: haypo
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple(): remove old and unused "O?" format
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17478/getarg_oquestion.patch

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

From report at bugs.python.org  Fri May 28 01:13:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 23:13:37 +0000
Subject: [New-bugs-announce] [issue8838] Remove codecs.readbuffer_encode()
	and	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>


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

readbuffer_encode() and charbuffer_encode() are not really encoder nor related to encodings: they are related to PyBuffer. readbuffer_encode() uses "s#" format and charbuffer_encode() uses "t#" format to parse their arguments. Both functions were introduced by the creation of the _codecs module 10 years ago (r14660).

I think that these functions should be removed. memoryview() should be used instead.

Note: charbuffer_encode() is the last function using on of the "t" format (t, t#, t*) in Python3.

----------
components: Interpreter Core
messages: 106625
nosy: haypo
priority: normal
severity: normal
status: open
title: Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
versions: Python 3.2

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

From report at bugs.python.org  Fri May 28 01:29:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 23:29:09 +0000
Subject: [New-bugs-announce] [issue8839] PyArg_ParseTuple(): remove "t#
	format
In-Reply-To: <1275002949.14.0.769648340098.issue8839@psf.upfronthosting.co.za>
Message-ID: <1275002949.14.0.769648340098.issue8839@psf.upfronthosting.co.za>


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

"t#" format was introduced by r11803 (11 years ago): "Implement new format character 't#'. This is like s#, accepting an object that implements the buffer interface, but requires a buffer that contains 8-bit character data."

Python3 now has a strict separation between byte string (bytes and bytearray types) and unicode string (str), and has PyBuffer and PyCapsule APIs. "t#" format can be replaced by "y#" or "y*".

Extract of getarg.c:

      /*TEO: This can be eliminated --- here only for backward
        compatibility */
    case 't': { /* 8-bit character buffer, read-only access */

In Python, the last function using "t#" is _codecs.charbuffer_encode() and I proposed to remove this function in #8838. We can also patch this function.

I don't know if third party modules use this format or not. I don't know if it can be just removed or if it should raise a deprecation warning (but who will notice such warning since there are disabled by default?).

----------
components: Interpreter Core
messages: 106627
nosy: haypo
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple(): remove "t# format
versions: Python 3.2

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

From report at bugs.python.org  Fri May 28 02:12:26 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 May 2010 00:12:26 +0000
Subject: [New-bugs-announce] [issue8840] io.StringIO: truncate+print
	disabled in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>


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

Some of my tests use io.StringIO and assert that captured print output equals expected output. Until now, I reused one buffer by truncating between tests. I recently replaced 3.1.1 with 3.1.2 (WinXP) and the *second* test of each run started failing. The following minimal code shows the problem (and should suggest a new unit test):

from io import StringIO; s = StringIO(); print(repr(s.getvalue()))
print('abc', file=s); print(repr(s.getvalue()))
s.truncate(0); print(repr(s.getvalue()))
print('abc', file=s); print(repr(s.getvalue()))

prints (both command window and IDLE)

''
'abc\n'
''
'\x00\x00\x00\x00abc\n' 
# should be and previously would have been 'abc\n'

s.truncate(0) zeros the buffer and appears to set the length to 0, but a subsequent print sees the length as what it was before the truncate and appends after the zeroed characters. Ugh.

I presume the problem is StringIO-emulation specific but have not tested 'real' files to be sure.

---
also...

>>> help(s.truncate)
Help on built-in function truncate:

truncate(...)
    Truncate size to pos.
...

should be, for greater clarity, something like

truncate([pos])
    Truncate the size of the file or buffer to pos
...

----------
components: IO, Library (Lib)
messages: 106630
nosy: tjreedy
priority: normal
severity: normal
stage: needs patch
status: open
title: io.StringIO: truncate+print disabled in 3.1.2
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri May 28 02:44:10 2010
From: report at bugs.python.org (Richard Lowe)
Date: Fri, 28 May 2010 00:44:10 +0000
Subject: [New-bugs-announce] [issue8841] GetoptError strings should be
	localized
In-Reply-To: <1275007450.32.0.944656023036.issue8841@psf.upfronthosting.co.za>
Message-ID: <1275007450.32.0.944656023036.issue8841@psf.upfronthosting.co.za>


New submission from Richard Lowe <richlowe at richlowe.net>:

The GetoptError exception raised by getopt.getopt() to indicate errors in provided arguments seems intended to be displayed to the user[1], but is not localized and doesn't contain enough information, short of interpreting the error string, for consumers to raise their own, localized, error.

[1] http://docs.python.org/library/getopt.html

----------
components: Library (Lib)
messages: 106632
nosy: richlowe
priority: normal
severity: normal
status: open
title: GetoptError strings should be localized
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Fri May 28 13:24:07 2010
From: report at bugs.python.org (Marko Kohtala)
Date: Fri, 28 May 2010 11:24:07 +0000
Subject: [New-bugs-announce] [issue8842] sqlite3 library outdated in Windows
	builds
In-Reply-To: <1275045847.96.0.603082208201.issue8842@psf.upfronthosting.co.za>
Message-ID: <1275045847.96.0.603082208201.issue8842@psf.upfronthosting.co.za>


New submission from Marko Kohtala <marko.kohtala at gmail.com>:

The Windows builds seem to come with SQLite library version 3.5.9, as seen from sqlite3.sqlite_version. This is from 2008-May-12.

I've been using the sqlite3 module, but keep running into bugs on Windows. Replacing the DLLs\sqlite3.dll with a newer library (sqlite is going at version 3.6.23), seems to fix those problems.

One problem was locking failures when performing a lot of changes and committing after each change. This happens within a single script accessing the file, apparently locking himself out. I did not want users needing to patch installed Python, so I got around that by removing the smaller commits and making one huge commit at end.

Now I had a problem that ANALYZE does not result in good queries. Performing ANALYZE with newer library speeded queries significantly. I do not know how to get around that.

On Linux I see Python 2.6 using sqlite 3.6.x versions, so I'd expect the reason for old library on Windows can not be incompatibility.

----------
components: Library (Lib), Windows
messages: 106647
nosy: Marko.Kohtala
priority: normal
severity: normal
status: open
title: sqlite3 library outdated in Windows builds
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri May 28 13:33:18 2010
From: report at bugs.python.org (Andrew Nelis)
Date: Fri, 28 May 2010 11:33:18 +0000
Subject: [New-bugs-announce] [issue8843] urllib2 Digest Authorization uri
	must match request URI
In-Reply-To: <1275046398.81.0.158910525846.issue8843@psf.upfronthosting.co.za>
Message-ID: <1275046398.81.0.158910525846.issue8843@psf.upfronthosting.co.za>


New submission from Andrew Nelis <andrew.nelis at gmail.com>:

When using Digest authentication to authenticate with a web server, according to rfc2617 (section 3.2.2.5) the uri in the Authorization header MUST match the request URI.

urllib2.AbstractDigestAuthHandler doesn't honour this when we request a url of the form 'http://hostname' without the trailing slash and we end up with request headers of the form:

GET / 1.1
...
Authorization: Digest ... uri="" <- should be uri="/"!

A web server will return 400 Bad Request error.

I attach a patch to fix urllib2.AbstractDigestAuthHandler.get_authorization that simply checks for the empty uri and uses '/' instead. It's the same thing that httplib.HTTPConnection does when it builds the GET line.

However I do wonder if this uri normalisation should be part of Request.get_selector?

Following is a script to demonstrate the behaviour, if you call it as:

./do_digest_request.py http://myserver username password

(and assuming myserver is using Digest authentication) there will a 400 response instead of it working.

--- do_digest_request.py
#!/usr/bin/env python

import sys
import urllib2
import urlparse

def request( url, username, password ):

    p = urlparse.urlparse( url )
    password_manager = urllib2.HTTPPasswordMgrWithDefaultRealm()
    password_manager.add_password( None, p.hostname, username, password )

    handlers = [
        urllib2.HTTPDigestAuthHandler( password_manager ),
    ]

    opener = urllib2.build_opener( *handlers )
    request = urllib2.Request( url )
    response = opener.open( request )
    response.read()


if __name__ == '__main__':
    request( sys.argv[1], sys.argv[2], sys.argv[3] )

----------
components: Library (Lib)
files: urllib2.diff
keywords: patch
messages: 106649
nosy: anelis
priority: normal
severity: normal
status: open
title: urllib2 Digest Authorization uri must match request URI
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17480/urllib2.diff

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

From report at bugs.python.org  Fri May 28 18:48:12 2010
From: report at bugs.python.org (Mike Hobbs)
Date: Fri, 28 May 2010 16:48:12 +0000
Subject: [New-bugs-announce] [issue8844] Condition.wait() doesn't raise
	KeyboardInterrupt
In-Reply-To: <1275065292.27.0.238026363438.issue8844@psf.upfronthosting.co.za>
Message-ID: <1275065292.27.0.238026363438.issue8844@psf.upfronthosting.co.za>


New submission from Mike Hobbs <mhobbs at alvenda.com>:

Condition.wait() without a timeout will never raise a KeyboardInterrupt:

cond = threading.Condition()
cond.acquire()
cond.wait()

*** Pressing Ctrl-C now does nothing ***



If you pass a timeout to Condition.wait(), however, it does behave as expected:

cond.wait()

^CTraceback (most recent call last):
  File "/usr/lib/python3.1/threading.py", line 242, in wait
    _sleep(delay)
KeyboardInterrupt



This may affect other problems reported with multiprocessing pools. Most notably:
http://bugs.python.org/issue8296
http://stackoverflow.com/questions/1408356

----------
components: Library (Lib)
messages: 106678
nosy: hobb0001
priority: normal
severity: normal
status: open
title: Condition.wait() doesn't raise KeyboardInterrupt
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri May 28 19:54:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 May 2010 17:54:09 +0000
Subject: [New-bugs-announce] [issue8845] Expose sqlite3 connection
	inTransaction as read-only	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>


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

I have a use case where I'd like to be able to check whether or not there is an uncommitted transaction.  The use case is a REPL database editor.  If the user issues the 'save' command a commit is done.  When they quit the application, I'd like to be able to prompt them with a 'save or discard' if and only if they have made changes since the last save.  Exposing the connection's inTransaction attribute would allow me to do this.  The attached patch does this as a read only attribute named in_transaction.  I'll add unit tests if this idea isn't rejected.

----------
components: Extension Modules
files: sqlite.in_transaction.patch
keywords: easy, patch
messages: 106683
nosy: ghaering, r.david.murray
priority: normal
severity: normal
stage: unit test needed
status: open
title: Expose sqlite3 connection inTransaction as read-only in_transaction attribute
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17482/sqlite.in_transaction.patch

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

From report at bugs.python.org  Fri May 28 22:54:40 2010
From: report at bugs.python.org (Andre Wobst)
Date: Fri, 28 May 2010 20:54:40 +0000
Subject: [New-bugs-announce] [issue8846] cgi.py bug report + fix: tailing
	carriage return and	newline characters in multipart cgi input broken
In-Reply-To: <1275080080.41.0.761400748474.issue8846@psf.upfronthosting.co.za>
Message-ID: <1275080080.41.0.761400748474.issue8846@psf.upfronthosting.co.za>


New submission from Andre Wobst <wobsta at users.sourceforge.net>:

There are serious bugs in carriage return and newline handling at the end of a multipart cgi input. The enclosed patch extends the test_cgi.py (and actually reverts two wrong tests to what they had been for python2.x). Additionally, the bugs are fixed by two small corrections to cgi.py and email/feedparser.py. Thanks for consideration.

----------
components: Library (Lib)
files: fix-cgi.patch
keywords: patch
messages: 106691
nosy: wobsta
priority: normal
severity: normal
status: open
title: cgi.py bug report + fix: tailing carriage return and newline characters in multipart cgi input broken
versions: Python 3.3
Added file: http://bugs.python.org/file17487/fix-cgi.patch

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

From report at bugs.python.org  Sat May 29 00:53:47 2010
From: report at bugs.python.org (benrg)
Date: Fri, 28 May 2010 22:53:47 +0000
Subject: [New-bugs-announce] [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>


New submission from benrg <benrudiak at gmail.com>:

c:\>python
  Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>> from collections import namedtuple
  >>> foo = namedtuple('foo', '')
  >>> [1] + foo()

At this point the interpreter crashes. Also happens when foo has named arguments, and in batch scripts. foo() + [1] throws a TypeError as expected. [] + foo() returns (). The immediate cause of the crash is the CALL instruction at 1E031D5A in python31.dll jumping into uninitialized memory.

----------
components: Interpreter Core, Library (Lib), Windows
messages: 106695
nosy: benrg
priority: normal
severity: normal
status: open
title: crash appending list and namedtuple
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Sat May 29 03:38:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 May 2010 01:38:48 +0000
Subject: [New-bugs-announce] [issue8848] Remove "U" and "U#" formats of
	Py_BuildValue()
In-Reply-To: <1275097128.66.0.216673219733.issue8848@psf.upfronthosting.co.za>
Message-ID: <1275097128.66.0.216673219733.issue8848@psf.upfronthosting.co.za>


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

"U" and "U#" formats were introduced by r55433 (Python3). At this same, "s" and "U" formats were different: "s" called PyString_FromStringAndSize() and "U" called PyUnicode_FromStringAndSize(). Two months later, PyString_FromStringAndSize() was replaced by PyUnicode_FromStringAndSize() for format "s", and so both formats are exactly the same.

"U" and "U#" were introduced during the transition between bytes, str and unicode. They can now be replaced by "s" and "s#", and then be removed.

There is just one usage of "U": definition of sys.subversion (Python/sysmodule.c), whereas there are 36 usages of "s" format. (U# and s# are not used.)

----------
components: Interpreter Core
messages: 106700
nosy: doerwalter, haypo
priority: normal
severity: normal
status: open
title: Remove "U" and "U#" formats of Py_BuildValue()
versions: Python 3.2

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

From report at bugs.python.org  Sat May 29 04:24:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 May 2010 02:24:20 +0000
Subject: [New-bugs-announce] [issue8850] Remove "w" format of
	PyParse_ParseTuple()
In-Reply-To: <1275099860.74.0.46695580149.issue8850@psf.upfronthosting.co.za>
Message-ID: <1275099860.74.0.46695580149.issue8850@psf.upfronthosting.co.za>


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

"w" format is dangerous because it doesn't give the size of the buffer: the caller may write outside the buffer (buffer overflow).

"w*" and "w#" formats are fine.

It looks like "w" format is not used in trunk nor py3k (only w# and w*).

----------
components: Interpreter Core
messages: 106702
nosy: haypo
priority: normal
severity: normal
status: open
title: Remove "w" format of PyParse_ParseTuple()
versions: Python 3.2

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

From report at bugs.python.org  Sat May 29 06:38:20 2010
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Sat, 29 May 2010 04:38:20 +0000
Subject: [New-bugs-announce] [issue8851] pkgutil document needs more markups
In-Reply-To: <1275107900.09.0.840689685245.issue8851@psf.upfronthosting.co.za>
Message-ID: <1275107900.09.0.840689685245.issue8851@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi <mft at users.sourceforge.net>:

The library reference of pkgutil is only sparsely marked up.

The attached patch is against 2.6 version, because I'm currently working with 2.6.  Since a part of markups (namely :pep:'s) has already been done for 3.2 version, the patch cannot be applied directly to that version, and I haven't checked the versions in between.

----------
assignee: docs at python
components: Documentation
files: pkgutil.diff
keywords: patch
messages: 106708
nosy: docs at python, mft
priority: normal
severity: normal
status: open
title: pkgutil document needs more markups
versions: Python 2.6
Added file: http://bugs.python.org/file17492/pkgutil.diff

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

From report at bugs.python.org  Sat May 29 16:30:13 2010
From: report at bugs.python.org (David Kirkby)
Date: Sat, 29 May 2010 14:30:13 +0000
Subject: [New-bugs-announce] [issue8852] _socket fails to build on
	OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>


New submission from David Kirkby <david.kirkby at onetel.net>:

Using Python 2.6.5, the module _socket is failing to build on OpenSolaris. The problem can be worked around with a hack, but I've not verified if the hack actually results in working code - but at least it compiles. See below. 

The problem seems to be that HAVE_NETPACKET_PACKET_H gets defined, despite the fact there is no file called netpacket.h

running build
running build_ext
building '_socket' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/Python-2.6.5/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/Python-2.6.5/Include -I/export/home/drkirkby/Python-2.6.5 -c /export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.o
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c: In function ?makesockaddr?:
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1107: error: ?struct ifreq? has no member named ?ifr_ifindex?
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1108: error: ?SIOCGIFNAME? undeclared (first use in this function)
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1108: error: (Each undeclared identifier is reported only once
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1108: error: for each function it appears in.)
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c: In function ?getsockaddrarg?:
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1415: error: ?SIOCGIFINDEX? undeclared (first use in this function)
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1427: error: ?struct ifreq? has no member named ?ifr_ifindex?
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c: In function ?init_socket?:
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:4596: error: ?PACKET_LOOPBACK? undeclared (first use in this function)
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:4597: error: ?PACKET_FASTROUTE? undeclared (first use in this function)
building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/Python-2.6.5/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/Python-2.6.5/Include -I/export/home/drkirkby/Python-2.6.5 -c /export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.o
/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.c: In function ?PyCursesWindow_ChgAt?:
/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.c:708: warning: implicit declaration of function ?mvwchgat?
/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.c:712: warning: implicit declaration of function ?wchgat?
gcc -shared build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.o -L/usr/local/lib -lcurses -ltermcap -o build/lib.solaris-2.11-i86pc-2.6/_curses.so
*** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.11-i86pc-2.6/_curses.so: symbol mvwchgat: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/Python-2.6.5/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/Python-2.6.5/Include -I/export/home/drkirkby/Python-2.6.5 -c /export/home/drkirkby/Python-2.6.5/Modules/_curses_panel.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/_curses_panel.o
gcc -shared build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/_curses_panel.o -L/usr/local/lib -lpanel -lcurses -ltermcap -o build/lib.solaris-2.11-i86pc-2.6/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses
building 'sunaudiodev' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/Python-2.6.5/./Include -I. -IInclude -I.

A patch (which is a hack, rather than a real solution), is below. 

drkirkby at hawk:~/Python-2.6.5/Modules$ diff -U 10  socketmodule.c.orig socketmodule.c
--- socketmodule.c.orig	Sat May 29 14:58:17 2010
+++ socketmodule.c	Sat May 29 15:26:08 2010
@@ -1089,20 +1089,21 @@
 		}
 #endif
 
 		default:
 			PyErr_SetString(PyExc_ValueError,
 					"Unknown Bluetooth protocol");
 			return NULL;
 		}
 #endif
 
+#undef HAVE_NETPACKET_PACKET_H /* Hack to build on OpenSolaris x64 */
 #ifdef HAVE_NETPACKET_PACKET_H
 	case AF_PACKET:
 	{
 		struct sockaddr_ll *a = (struct sockaddr_ll *)addr;
 		char *ifname = "";
 		struct ifreq ifr;
 		/* need to look up interface name give index */
 		if (a->sll_ifindex) {
 			ifr.ifr_ifindex = a->sll_ifindex;
 			if (ioctl(sockfd, SIOCGIFNAME, &ifr) == 0)

----------
messages: 106719
nosy: drkirkby
priority: normal
severity: normal
status: open
title: _socket fails to build on OpenSolaris x64
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Sat May 29 19:48:13 2010
From: report at bugs.python.org (AndiDog)
Date: Sat, 29 May 2010 17:48:13 +0000
Subject: [New-bugs-announce] [issue8853] getaddrinfo should accept port of
	type long
In-Reply-To: <1275155293.8.0.373298822378.issue8853@psf.upfronthosting.co.za>
Message-ID: <1275155293.8.0.373298822378.issue8853@psf.upfronthosting.co.za>


New submission from AndiDog <AndiDog at web.de>:

socket.getaddrinfo("127.0.0.1", 80L)
error: Int or String expected

I would expect getaddrinfo to convert the port number to an integer.

----------
components: Library (Lib)
messages: 106726
nosy: AndiDog
priority: normal
severity: normal
status: open
title: getaddrinfo should accept port of type long
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun May 30 01:30:31 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 29 May 2010 23:30:31 +0000
Subject: [New-bugs-announce] [issue8854] msvc9compiler.py: find_vcvarsall()
	doesn't work with	VS2008 on Windows x64
In-Reply-To: <1275175831.39.0.913540756271.issue8854@psf.upfronthosting.co.za>
Message-ID: <1275175831.39.0.913540756271.issue8854@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

When installing Visual Studio 2008 SP1 on a Windows Vista x64 system, the installer registers the various registry keys under

Software\Wow6432Node\Microsoft\VisualStudio\9.0\

rather than

Software\Microsoft\VisualStudio\9.0\

This is due to some redirection MS is applying to registry names when running 32-bit apps (such as the VS2008 installer) on 64-bit Windows:

http://support.microsoft.com/kb/896459

Since the tools in msvc9compiler.py rely on the registry to find the various dirs, batch files and tools, these operations fail.

A simple solution is to just update the globals at the top of the file to:

VS_BASE = r"Software\Wow6432Node\Microsoft\VisualStudio\%0.1f"
WINSDK_BASE = r"Software\Wow6432Node\Microsoft\Microsoft SDKs\Windows"
NET_BASE = r"Software\Wow6432Node\Microsoft\.NETFramework"

but that would of course have to be done with some extra checks to not break these settings on other Windows systems.

I'm not sure whether this is specific to Windows Vista or also occurs on Windows 7.

----------
assignee: tarek
components: Distutils
keywords: 64bit
messages: 106745
nosy: lemburg, tarek
priority: normal
severity: normal
status: open
title: msvc9compiler.py: find_vcvarsall() doesn't work with VS2008 on Windows x64
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sun May 30 02:53:53 2010
From: report at bugs.python.org (Longpoke)
Date: Sun, 30 May 2010 00:53:53 +0000
Subject: [New-bugs-announce] [issue8855] Shelve documentation lacks security
	warning
In-Reply-To: <1275180833.97.0.966181786946.issue8855@psf.upfronthosting.co.za>
Message-ID: <1275180833.97.0.966181786946.issue8855@psf.upfronthosting.co.za>


New submission from Longpoke <longpoke at gmail.com>:

Loading a shelve can cause arbitrary code to be executed [1] and other black magic (because it's backed by Pickle). Shouldn't there be a big fat warning at the top of the shelve documentation page?

Unless you're like me and assume anything to do with serialization in any language is insecure until proved otherwise, you aren't going to intuitively think there is anything wrong with "unshelving" untrusted data (unless you already know that Pickle is insecure).

1. http://nadiana.com/python-pickle-insecure#comment-261

----------
assignee: docs at python
components: Documentation
messages: 106746
nosy: docs at python, q94IjzUfnNoyv4c75mMw
priority: normal
severity: normal
status: open
title: Shelve documentation lacks security warning

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

From report at bugs.python.org  Sun May 30 11:20:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 30 May 2010 09:20:03 +0000
Subject: [New-bugs-announce] [issue8856] Error in ceval.c when buildind
	--without-threads
In-Reply-To: <1275211203.78.0.734042112342.issue8856@psf.upfronthosting.co.za>
Message-ID: <1275211203.78.0.734042112342.issue8856@psf.upfronthosting.co.za>


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

I can?t build py3k HEAD without threads:

$ gcc -v 2>&1 | tail -2
Thread model: posix
gcc version 4.4.4 (Debian 4.4.4-1)

$ ./configure --without-threads
[snip snip]

$ make -s
Python/ceval.c: In function ?Py_AddPendingCall?:
Python/ceval.c:622: error: request for member ?_value? in something not a structure or union
Python/ceval.c:622: warning: type defaults to ?int? in declaration of ?new_val?
Python/ceval.c:622: error: request for member ?_value? in something not a structure or union
Python/ceval.c:622: error: request for member ?_value? in something not a structure or union
Python/ceval.c:622: error: memory input 1 is not directly addressable
Python/ceval.c: In function ?Py_MakePendingCalls?:
Python/ceval.c:635: error: request for member ?_value? in something not a structure or union
Python/ceval.c:635: warning: type defaults to ?int? in declaration of ?new_val?
Python/ceval.c:635: error: request for member ?_value? in something not a structure or union
Python/ceval.c:635: error: request for member ?_value? in something not a structure or union
Python/ceval.c:635: error: request for member ?_value? in something not a structure or union
Python/ceval.c:635: warning: type defaults to ?int? in declaration of ?result?
Python/ceval.c:635: error: request for member ?_value? in something not a structure or union
Python/ceval.c:648: error: request for member ?_value? in something not a structure or union
Python/ceval.c:648: warning: type defaults to ?int? in declaration of ?new_val?
Python/ceval.c:648: error: request for member ?_value? in something not a structure or union
Python/ceval.c:648: error: request for member ?_value? in something not a structure or union
Python/ceval.c:635: error: memory input 1 is not directly addressable
Python/ceval.c:648: error: memory input 1 is not directly addressable
Python/ceval.c: In function ?PyEval_EvalFrameEx?:
Python/ceval.c:1255: error: request for member ?_value? in something not a structure or union
Python/ceval.c:1255: warning: type defaults to ?int? in declaration of ?result?
Python/ceval.c:1255: error: request for member ?_value? in something not a structure or union
Python/ceval.c:1279: error: request for member ?_value? in something not a structure or union
Python/ceval.c:1279: warning: type defaults to ?int? in declaration of ?result?
Python/ceval.c:1279: error: request for member ?_value? in something not a structure or union
make: *** [Python/ceval.o] Erreur 1

It?s my first build failure report. What other information is needed?

----------
components: Build
messages: 106751
nosy: merwok
priority: normal
severity: normal
status: open
title: Error in ceval.c when buildind --without-threads
versions: Python 3.2

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

From report at bugs.python.org  Sun May 30 18:58:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 May 2010 16:58:11 +0000
Subject: [New-bugs-announce] [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>


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

socket.getaddrinfo has no tests at all. This should be fixed.

----------
components: Library (Lib), Tests
messages: 106767
nosy: pitrou
priority: high
severity: normal
status: open
title: socket.getaddrinfo needs tests
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun May 30 19:04:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 May 2010 17:04:39 +0000
Subject: [New-bugs-announce] [issue8858] socket.getaddrinfo returns wrong
	results for IPv6	addresses
In-Reply-To: <1275239079.49.0.0162981325247.issue8858@psf.upfronthosting.co.za>
Message-ID: <1275239079.49.0.0162981325247.issue8858@psf.upfronthosting.co.za>


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

It seems socket.getaddrinfo gives wrong results for IPv6 address under py3k:

>>> pprint.pprint(socket.getaddrinfo("www.python.org", 0))
[(2, 1, 6, '', ('82.94.164.162', 0)),
 (2, 2, 17, '', ('82.94.164.162', 0)),
 (2, 3, 0, '', ('82.94.164.162', 0)),
 (10, 1, 6, '', (10, b'\x00\x00\x00\x00\x00\x00 \x01\x08\x88 \x00\x00\r')),
 (10, 2, 17, '', (10, b'\x00\x00\x00\x00\x00\x00 \x01\x08\x88 \x00\x00\r')),
 (10, 3, 0, '', (10, b'\x00\x00\x00\x00\x00\x00 \x01\x08\x88 \x00\x00\r'))]

The results given by 2.x make much more sense:
>>> pprint.pprint(socket.getaddrinfo("www.python.org", 0))
[(2, 1, 6, '', ('82.94.164.162', 0)),
 (2, 2, 17, '', ('82.94.164.162', 0)),
 (2, 3, 0, '', ('82.94.164.162', 0)),
 (10, 1, 6, '', ('2001:888:2000:d::a2', 0, 0, 0)),
 (10, 2, 17, '', ('2001:888:2000:d::a2', 0, 0, 0)),
 (10, 3, 0, '', ('2001:888:2000:d::a2', 0, 0, 0))]

----------
messages: 106768
nosy: pitrou
priority: high
severity: normal
status: open
title: socket.getaddrinfo returns wrong results for IPv6 addresses
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun May 30 20:54:14 2010
From: report at bugs.python.org (Peter Landgren)
Date: Sun, 30 May 2010 18:54:14 +0000
Subject: [New-bugs-announce] [issue8859] split() splits on non whitespace
	char when ther is no	separator given.
In-Reply-To: <1275245654.33.0.885682282706.issue8859@psf.upfronthosting.co.za>
Message-ID: <1275245654.33.0.885682282706.issue8859@psf.upfronthosting.co.za>


New submission from Peter Landgren <peter.talken at telia.com>:

When the variable label is equal to '\xc5\xa0 Z\nX W'
this line sequence
label = " ".join(label.split())
label = unicode(label)
results in:
7347: ERROR: gramps.py: line 138: Unhandled exception
Traceback (most recent call last):
  File "C:\Program Files (x86)\gramps\gui\views\listview.py", line 660, in row_changed
    self.uistate.modify_statusbar(self.dbstate)
  File "C:\Program Files (x86)\gramps\DisplayState.py", line 521, in modify_statusbar
    name, obj = navigation_label(dbstate.db, nav_type, active_handle)
  File "C:\Program Files (x86)\gramps\Utils.py", line 1358, in navigation_label
    label = unicode(label)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: invalid data

While this line sequence:
label = unicode(label)
label = " ".join(label.split())
gives correct result and no error.

With the error the variable label changes from
'\xc5\xa0 Z\nX W'
to
'\xc5 Z X W'
by the line:
label = " ".join(label.split())
Note '\xa0' has been dropped, interpreted as "whitespace"?
This happens on Windows. It works perfectly well on Linux.

----------
components: Library (Lib)
messages: 106773
nosy: PeterL
priority: normal
severity: normal
status: open
title: split() splits on non whitespace char when ther is no separator given.
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon May 31 18:39:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 May 2010 16:39:41 +0000
Subject: [New-bugs-announce] [issue8860] Rounding in timedelta constructor
	is inconsistent with	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>From issue1289118, msg106389:

"""
>>> from datetime import timedelta as d
>>> [d(microseconds=i + .5)//d.resolution for i in range(-10,10)]
[-10, -9, -8, -7, -6, -5, -4, -3, -2, -1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

Should this be considered a bug?

For comparison,

>>> [d.resolution*(i+0.5)//d.resolution for i in range(-10,10)]
[-10, -8, -8, -6, -6, -4, -4, -2, -2, 0, 0, 2, 2, 4, 4, 6, 6, 8, 8, 10]

and
>>> [round(i+0.5) for i in range(-10,10)]
[-10, -8, -8, -6, -6, -4, -4, -2, -2, 0, 0, 2, 2, 4, 4, 6, 6, 8, 8, 10]

I checked the documentation and while it says: "If any argument is a float and there are fractional microseconds, the fractional microseconds left over from all arguments are combined and their sum is rounded to the nearest microsecond." it does not specify how half-integers should be handled.

While it may not be a bug in strict sense, it looks like the code in question can be improved. 
"""

----------
assignee: belopolsky
messages: 106793
nosy: belopolsky, haypo, mark.dickinson, mcherm, rhettinger, stutzbach, tim_one
priority: normal
severity: normal
stage: unit test needed
status: open
title: Rounding in timedelta constructor is inconsistent with that in timedelta arithmetics
type: feature request

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

From report at bugs.python.org  Mon May 31 19:32:15 2010
From: report at bugs.python.org (July Tikhonov)
Date: Mon, 31 May 2010 17:32:15 +0000
Subject: [New-bugs-announce] [issue8861] curses.wrapper : unnessesary code
In-Reply-To: <1275327135.19.0.0185418659015.issue8861@psf.upfronthosting.co.za>
Message-ID: <1275327135.19.0.0185418659015.issue8861@psf.upfronthosting.co.za>


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

wrapper() code in Lib/curses/wrapper.py
has an unnesesary line:

    res = None

This variable is not used anywhere else in wrapper().
Inspecting the history of trunk, we can see that it was used used as a result of applying func(), but later was replaced by another construction.

Patch added.

----------
components: Library (Lib)
files: curses-wrapper-cleanup.patch
keywords: patch
messages: 106798
nosy: july
priority: normal
severity: normal
status: open
title: curses.wrapper : unnessesary code
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17506/curses-wrapper-cleanup.patch

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

From report at bugs.python.org  Mon May 31 20:23:59 2010
From: report at bugs.python.org (July Tikhonov)
Date: Mon, 31 May 2010 18:23:59 +0000
Subject: [New-bugs-announce] [issue8862] curses.wrapper does not restore
	terminal if	curses.getkey() gets KeyboardInterrupt
In-Reply-To: <1275330239.59.0.0964939469403.issue8862@psf.upfronthosting.co.za>
Message-ID: <1275330239.59.0.0964939469403.issue8862@psf.upfronthosting.co.za>


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

Run test.py (below) in terminal, and interrupt it with Ctrl-C.

Result: terminal settings are not restored (checked with linux console and xterm, with Python 2.7 and 3.2).

# test.py
# Broke it with KeyboardInterrupt
import curses
def main(screen):
    k = screen.getkey()
curses.wrapper(main)
# Results are hardly readable due to the broken terminal.
# Something about KeyboardInterrupt

However, if getkey() is surrounded by try-except, behavior changes:

# test2.py
# Broke it with KeyboardInterrupt
import curses
def main2(screen):
    try:
        k = screen.getkey()
    except KeyboardInterrupt:
        raise
curses.wrapper(main2)
# Terminal is restored to its normal state.

In python3.2 test2.py results in traceback:

Traceback (most recent call last):
  File "test2.py", line 4, in main2
    k = screen.getkey()
_curses.error: no input

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test2.py", line 7, in <module>
    curses.wrapper(main2)
  File "/usr/local/lib/python3.2/curses/wrapper.py", line 44, in wrapper
    return func(stdscr, *args, **kwds)
  File "test2.py", line 4, in main2
    k = screen.getkey()
KeyboardInterrupt


In 2.7 it results only in the latest part of traceback:

Traceback (most recent call last):
  File "test2.py", line 7, in <module>
    curses.wrapper(main2)
  File "/usr/local/lib/python2.7/curses/wrapper.py", line 44, in wrapper
    return func(stdscr, *args, **kwds)
  File "test2.py", line 4, in main2
    k = screen.getkey()
KeyboardInterrupt


The problem is that instead of a single KeyboardInterrupt, two exceptions are raised: KeyboardInterrupt and _curses.error('no input').

Possible solution is to suppress _curses.error in this case (since it is less relevant than KeyboardInterrupt, IMO).

----------
components: Library (Lib)
messages: 106799
nosy: july
priority: normal
severity: normal
status: open
title: curses.wrapper does not restore terminal if curses.getkey() gets KeyboardInterrupt
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon May 31 21:01:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 31 May 2010 19:01:25 +0000
Subject: [New-bugs-announce] [issue8863] Segfault handler: display Python
	backtrace on segfault
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>


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

Attached patch implements an handler for the signal SIGSEGV. It uses its own stack to be able to allocate memory on the stack (eg. call a function), even on stack overflow.

The patch requires sigaction() and sigaltstack() functions, but I didn't patched configure.in script. These functions are available on Linux, but should be available on other UNIX OSes.

segfault() signal handler supposes that the thread state is consistent (interp->frame chained list). It calls indirectly PyUnicode_EncodeUTF8() and so call PyBytes_FromStringAndSize() which allocates memory on the heap. It clears PyUnicode "defenc" attribute (the result of PyUnicode_EncodeUTF8()) to free directly the memory.

To test it, try some scripts in Lib/test/crashers/.

One example:
--------------------
$ ./python Lib/test/crashers/recursive_call.py
Fatal Python error: segmentation fault

Traceback (most recent call first):
  File "Lib/test/crashers/recursive_call.py", line 12, depth 15715
  File "Lib/test/crashers/recursive_call.py", line 12, depth 15714
  File "Lib/test/crashers/recursive_call.py", line 12, depth 15713
...
  File "Lib/test/crashers/recursive_call.py", line 12, depth 3
  File "Lib/test/crashers/recursive_call.py", line 12, depth 2
  File "Lib/test/crashers/recursive_call.py", line 9, depth 1
Segmentation fault
--------------------

----------
components: Interpreter Core
files: segfault_handler.patch
keywords: patch
messages: 106801
nosy: haypo
priority: normal
severity: normal
status: open
title: Segfault handler: display Python backtrace on segfault
versions: Python 3.2
Added file: http://bugs.python.org/file17507/segfault_handler.patch

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

From report at bugs.python.org  Mon May 31 23:42:26 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 31 May 2010 21:42:26 +0000
Subject: [New-bugs-announce] [issue8864] multiprocessing: undefined
	struct/union member:	msg_control
In-Reply-To: <1275342146.08.0.266544809639.issue8864@psf.upfronthosting.co.za>
Message-ID: <1275342146.08.0.266544809639.issue8864@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

There is apparently a regression on ^/trunk with multiprocessing on solaris10-x86 today. (used to work a few weeks before)

cc -Kpic -OPT:Olimit=0 -g -DNDEBUG -O -IModules/_multiprocessing -I. -IInclude -I./Include -I/export/home/apy/rrun/build/activepyt
hon-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Include -I/export/home/apy/rrun/build/activepython-svn-trunk/buil
d/pyhg_trunk-solaris10-x86-hgtip27-rrun/python -c /export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c -o build/temp.solaris-2.10-i86pc-2.7/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.o
cc: Warning: illegal option -OPT:Olimit=0
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 126: undefined struct/union member: msg_control
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 126: warning: improper pointer/integer combination: op "="
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 127: undefined struct/union member: msg_controllen
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 130: warning: implicit function declaration: CMSG_FIRSTHDR
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 130: warning: improper pointer/integer combination: op "="
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 134: improper member use: msg_controllen
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 135: warning: implicit function declaration: CMSG_DATA
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 161: undefined struct/union member: msg_control
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 161: warning: improper pointer/integer combination: op "="
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 162: undefined struct/union member: msg_controllen
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 165: warning: improper pointer/integer combination: op "="
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 169: improper member use: msg_controllen
cc: acomp failed for /export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c

----------
components: Build, Library (Lib)
messages: 106813
nosy: srid
priority: normal
severity: normal
status: open
title: multiprocessing: undefined struct/union member: msg_control
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sat May 29 04:17:55 2010
From: report at bugs.python.org (jroach)
Date: Sat, 29 May 2010 02:17:55 -0000
Subject: [New-bugs-announce] [issue8849] python.exe problem with cvxopt
In-Reply-To: <4C007915.6020901@internode.on.net>
Message-ID: <4C007915.6020901@internode.on.net>


New submission from jroach <jroach at internode.on.net>:

I have encountered a runtime problem with python26 (same problem not 
encountered with python25). The reported error is in python.exe.
I have written a brief .doc file describing the problem which I will 
attach. ( The problem was first encountered with an older version of 
python26, it also occurs with the latest  version  2.6.5). The Python 
cvxopt package is available on the internet.
This is my first communication of this type. I hope that it is appropriate.
jroach

----------
files: python26problem.doc
messages: 106701
nosy: jroach
priority: normal
severity: normal
status: open
title: python.exe problem with cvxopt
Added file: http://bugs.python.org/file17489/python26problem.doc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8849>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python26problem.doc
Type: application/msword
Size: 1137664 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20100529/ba8b005d/attachment-0001.doc>