From report at bugs.python.org  Thu Apr  1 00:06:52 2010
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Wed, 31 Mar 2010 22:06:52 +0000
Subject: [New-bugs-announce] [issue8276] useless PyEval_CallObject function
In-Reply-To: <1270073212.98.0.119754246418.issue8276@psf.upfronthosting.co.za>
Message-ID: <1270073212.98.0.119754246418.issue8276@psf.upfronthosting.co.za>


New submission from Maciek Fijalkowski <fijal at genesilico.pl>:

In ceval.c there is such code:

PyObject *
PyEval_CallObject(PyObject *func, PyObject *arg)
{
	return PyEval_CallObjectWithKeywords(func, arg, (PyObject *)NULL);
}
#define PyEval_CallObject(func,arg) \
        PyEval_CallObjectWithKeywords(func, arg, (PyObject *)NULL)

Is this needed any longer? (both #define and function have the same name)

----------
components: Interpreter Core
messages: 102038
nosy: fijal
severity: normal
status: open
title: useless PyEval_CallObject function
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr  1 03:37:46 2010
From: report at bugs.python.org (Patrick W.)
Date: Thu, 01 Apr 2010 01:37:46 +0000
Subject: [New-bugs-announce] [issue8277] ElementTree won't parse comments
In-Reply-To: <1270085866.99.0.0885322891054.issue8277@psf.upfronthosting.co.za>
Message-ID: <1270085866.99.0.0885322891054.issue8277@psf.upfronthosting.co.za>


New submission from Patrick W. <poke at BornToLaugh.de>:

When using xml.etree.ElementTree to parse external XML files, all XML comments within that file are being stripped out. I guess that happens because there is no comment handler in the expat parser.

Example:

test.xml
--------
<example>
  <nodeA />
  <!-- some comment -->
  <nodeB />
</example>

test.py
-------
from xml.etree import ElementTree
with open( 'test.xml', 'r' ) as f:
    xml = ElementTree.parse( f )
ElementTree.dump( xml )

Result
------
<example>
  <nodeA />

  <nodeB />
</example>

----------
components: XML
messages: 102051
nosy: poke
severity: normal
status: open
title: ElementTree won't parse comments
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu Apr  1 09:46:06 2010
From: report at bugs.python.org (Ramin Sabet)
Date: Thu, 01 Apr 2010 07:46:06 +0000
Subject: [New-bugs-announce] [issue8278] os.utime doesn't allow a atime
	(Last Access) which is 27	years in the future.
In-Reply-To: <1270107966.42.0.283455861085.issue8278@psf.upfronthosting.co.za>
Message-ID: <1270107966.42.0.283455861085.issue8278@psf.upfronthosting.co.za>


New submission from Ramin Sabet <ramin.sabet at gmail.com>:

Error Message is:
OverflowError: long int too large to convert to int
---
Python Version:
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32
---
Sample Code attached.

----------
components: IO
files: utime_test.py
messages: 102069
nosy: Ramin.Sabet
severity: normal
status: open
title: os.utime doesn't allow a atime (Last Access) which is 27 years in the future.
versions: Python 2.6
Added file: http://bugs.python.org/file16717/utime_test.py

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

From report at bugs.python.org  Thu Apr  1 09:47:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 01 Apr 2010 07:47:41 +0000
Subject: [New-bugs-announce] [issue8279] python-gdb PyListTests fail
In-Reply-To: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>
Message-ID: <1270108061.33.0.213932386799.issue8279@psf.upfronthosting.co.za>


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

regrtest reports

======================================================================
FAIL: test_basic_command (test.test_gdb.PyListTests)                  
Verify that the "py-list" command works                               
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 518, in test_basic_command
    cmds_after_breakpoint=['py-list'])                                             
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 111, in get_stack_trace   
    self.assertEquals(err, '')
AssertionError: "/home/martin/work/27/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_one_abs_arg (test.test_gdb.PyListTests)
Verify the "py-list" command with one absolute argument
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 535, in test_one_abs_arg
    cmds_after_breakpoint=['py-list 9'])
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/martin/work/27/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_two_abs_args (test.test_gdb.PyListTests)
Verify the "py-list" command with two absolute arguments
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 548, in test_two_abs_args
    cmds_after_breakpoint=['py-list 1,3'])
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/martin/work/27/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

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

----------
assignee: dmalcolm
messages: 102070
nosy: dmalcolm, loewis
severity: normal
status: open
title: python-gdb PyListTests fail

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

From report at bugs.python.org  Thu Apr  1 18:08:33 2010
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 01 Apr 2010 16:08:33 +0000
Subject: [New-bugs-announce] [issue8280] urllib2 passes fragment identifier
	to server
In-Reply-To: <1270138113.06.0.589316518246.issue8280@psf.upfronthosting.co.za>
Message-ID: <1270138113.06.0.589316518246.issue8280@psf.upfronthosting.co.za>


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

>>> urllib2.urlopen("http://wave-robot-python-client.googlecode.com/svn/trunk/pydocs/index.html#module-wavelet")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\usr\Python2.6\lib\urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "C:\usr\Python2.6\lib\urllib2.py", line 398, in open
    response = meth(req, response)
  File "C:\usr\Python2.6\lib\urllib2.py", line 511, in http_response
    'http', request, response, code, msg, hdrs)
  File "C:\usr\Python2.6\lib\urllib2.py", line 436, in error
    return self._call_chain(*args)
  File "C:\usr\Python2.6\lib\urllib2.py", line 370, in _call_chain
    result = func(*args)
  File "C:\usr\Python2.6\lib\urllib2.py", line 519, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 400: Bad Request

This happens when redirected URL contains fragment.

>>> urllib2.urlopen("http://goo.gl/z1d5")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\usr\Python2.6\lib\urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "C:\usr\Python2.6\lib\urllib2.py", line 398, in open
    response = meth(req, response)
  File "C:\usr\Python2.6\lib\urllib2.py", line 511, in http_response
    'http', request, response, code, msg, hdrs)
  File "C:\usr\Python2.6\lib\urllib2.py", line 430, in error
    result = self._call_chain(*args)
  File "C:\usr\Python2.6\lib\urllib2.py", line 370, in _call_chain
    result = func(*args)
  File "C:\usr\Python2.6\lib\urllib2.py", line 606, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "C:\usr\Python2.6\lib\urllib2.py", line 398, in open
    response = meth(req, response)
  File "C:\usr\Python2.6\lib\urllib2.py", line 511, in http_response
    'http', request, response, code, msg, hdrs)
  File "C:\usr\Python2.6\lib\urllib2.py", line 436, in error
    return self._call_chain(*args)
  File "C:\usr\Python2.6\lib\urllib2.py", line 370, in _call_chain
    result = func(*args)
  File "C:\usr\Python2.6\lib\urllib2.py", line 519, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 400: Bad Request

urllib2.Request.get_selector() should be:

    def get_selector(self):
        return self.__r_host.split('#')[0]

----------
messages: 102103
nosy: naoki
severity: normal
status: open
title: urllib2 passes fragment identifier to server

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

From report at bugs.python.org  Thu Apr  1 18:44:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Apr 2010 16:44:56 +0000
Subject: [New-bugs-announce] [issue8281] test_gdb_sample fails
In-Reply-To: <1270140296.29.0.699227538452.issue8281@psf.upfronthosting.co.za>
Message-ID: <1270140296.29.0.699227538452.issue8281@psf.upfronthosting.co.za>


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

This doesn't happen in verbose mode, because stdout isn't checked:


$ ./python -m test.regrtest test_gdb_sample
test_gdb_sample
test test_gdb_sample produced unexpected output:
**********************************************************************
42

**********************************************************************
1 test failed:
    test_gdb_sample

----------
assignee: dmalcolm
components: Library (Lib), Tests
messages: 102104
nosy: dmalcolm, loewis, pitrou
severity: normal
stage: needs patch
status: open
title: test_gdb_sample fails
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr  1 20:07:23 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 01 Apr 2010 18:07:23 +0000
Subject: [New-bugs-announce] [issue8282] Windows uninstaller requests admin
	access for	unindentified program
In-Reply-To: <1270145243.88.0.407783271533.issue8282@psf.upfronthosting.co.za>
Message-ID: <1270145243.88.0.407783271533.issue8282@psf.upfronthosting.co.za>


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

Uninstall on Vista requires administrative privileges to "Unindentified program" from "Unindentified publisher".

Tested 2.6.5 and 2.7a4

----------
components: Installation
messages: 102117
nosy: techtonik
severity: normal
status: open
title: Windows uninstaller requests admin access for unindentified program
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Apr  1 20:26:02 2010
From: report at bugs.python.org (alan hoover)
Date: Thu, 01 Apr 2010 18:26:02 +0000
Subject: [New-bugs-announce] [issue8283] series of lamdas in loop sets the
	paramater on all calls	to that of the last call
In-Reply-To: <1270146362.25.0.403939205554.issue8283@psf.upfronthosting.co.za>
Message-ID: <1270146362.25.0.403939205554.issue8283@psf.upfronthosting.co.za>


New submission from alan hoover <alan.hoover at gmail.com>:

Background:
building a screen using Tkinter based on information from a database to let user take action on the database rows.  I don't know how many rows there will be, so I'm storing the widgets in arrays for each column.

Code:
for row in getDBrows():
    self.buttons.append(Tkinter.Button(self,text='UnLoad it', command=lambda :self.unload(row[0])))

Problem:
When executing the above code, all the buttons have the key to the database table that belongs to the last row.  I found a work around -- by moving the call to create the button (containing the lambda) to a separate function and call that function to create the button instead of creating the button directly, the buttons then make their callback with a correct database key.

Workaround:
for row in getDBrows():
    self.buttons.append(self.buildbutton(row[0]))
.
.
def buildbutton(self,key):
    return Tkinter.Button(self,text='UnLoad it', command=lambda: self.unload(key))

When using the workaround code instead of the original code, the button
for each row has the appropriate key to the database.

Speculation:
It acts like the lambda definitions don't get solidified until the containing block exits; at that time, the lambda definition(s) get locked in with the current value of the variable getting passed into the lambda as a parameter.  By moving the lambda call to a different block (separate function), the lambda gets "locked" when that block (function) exits instead of when the containing block (loop) exits.

----------
components: IDLE, Tkinter, Windows
messages: 102120
nosy: alan.hoover
severity: normal
status: open
title: series of lamdas in loop sets the paramater on all calls to that of the last call
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Apr  1 21:39:23 2010
From: report at bugs.python.org (OMFGROFLMAO)
Date: Thu, 01 Apr 2010 19:39:23 +0000
Subject: [New-bugs-announce] [issue8284] urlparse incorrect parse
In-Reply-To: <1270150763.27.0.00719913444678.issue8284@psf.upfronthosting.co.za>
Message-ID: <1270150763.27.0.00719913444678.issue8284@psf.upfronthosting.co.za>


New submission from OMFGROFLMAO <benjaminworwa at gmail.com>:

>>> urlparse.urlparse("example.com/directory/file.ext")

ParseResult(scheme='', netloc='', path='example.com/directory/file.ext', params='', query='', fragment='')

Where it should be:

ParseResult(scheme='', netloc='example.com', path='/directory/file.ext', params='', query='', fragment='')

----------
messages: 102127
nosy: OMFGROFLMAO
severity: normal
status: open
title: urlparse incorrect parse
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Apr  1 22:50:22 2010
From: report at bugs.python.org (Tofystedeth)
Date: Thu, 01 Apr 2010 20:50:22 +0000
Subject: [New-bugs-announce] [issue8285] IDLE not smart indenting correctly
	in nested statements
Message-ID: <1270155022.9.0.253546918439.issue8285@psf.upfronthosting.co.za>


Changes by Tofystedeth <nancedr at gmail.com>:


----------
components: IDLE
nosy: Tofystedeth
severity: normal
status: open
title: IDLE not smart indenting correctly in nested statements
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  2 06:02:59 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 02 Apr 2010 04:02:59 +0000
Subject: [New-bugs-announce] [issue8286] distutils: path '[...]' cannot end
	with '/'
In-Reply-To: <1270180979.93.0.404335172952.issue8286@psf.upfronthosting.co.za>
Message-ID: <1270180979.93.0.404335172952.issue8286@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

I noticed this exception in http://pypm-free.activestate.com/2.6/win32-x86/pool/d/dj/django-navbar-0.2.0_win32-x86_2.6_1.pypm.d/log


[...]

reading manifest file 'django_navbar.egg-info\SOURCES.txt'

reading manifest template 'MANIFEST.in'

Traceback (most recent call last):

  File "setup.py", line 25, in <module>

    zip_safe=False,

  File "C:\ActivePython32Python26\lib\distutils\core.py", line 152, in setup

    dist.run_commands()

  File "C:\ActivePython32Python26\lib\distutils\dist.py", line 975, in run_commands

    self.run_command(cmd)

  File "C:\ActivePython32Python26\lib\distutils\dist.py", line 995, in run_command

    cmd_obj.run()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\install.py", line 53, in run

    return _install.run(self)

  File "C:\ActivePython32Python26\lib\distutils\command\install.py", line 577, in run

    self.run_command('build')

  File "C:\ActivePython32Python26\lib\distutils\cmd.py", line 333, in run_command

    self.distribution.run_command(command)

  File "C:\ActivePython32Python26\lib\distutils\dist.py", line 995, in run_command

    cmd_obj.run()

  File "C:\ActivePython32Python26\lib\distutils\command\build.py", line 134, in run

    self.run_command(cmd_name)

  File "C:\ActivePython32Python26\lib\distutils\cmd.py", line 333, in run_command

    self.distribution.run_command(command)

  File "C:\ActivePython32Python26\lib\distutils\dist.py", line 995, in run_command

    cmd_obj.run()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\build_py.py", line 78, in run

    self.build_package_data()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\build_py.py", line 133, in build_package_data

    for package, src_dir, build_dir, filenames in self.data_files:

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\build_py.py", line 90, in __getattr__

    self.data_files = files = self._get_data_files(); return files

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\build_py.py", line 101, in _get_data_files

    self.analyze_manifest()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\build_py.py", line 153, in analyze_manifest

    self.run_command('egg_info')

  File "C:\ActivePython32Python26\lib\distutils\cmd.py", line 333, in run_command

    self.distribution.run_command(command)

  File "C:\ActivePython32Python26\lib\distutils\dist.py", line 995, in run_command

    cmd_obj.run()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\egg_info.py", line 179, in run

    self.find_sources()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\egg_info.py", line 254, in find_sources

    mm.run()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\egg_info.py", line 310, in run

    self.read_template()

  File "C:\ActivePython32Python26\lib\site-packages\distribute-0.6.10-py2.6.egg\setuptools\command\sdist.py", line 204, in read_template

    _sdist.read_template(self)

  File "C:\ActivePython32Python26\lib\distutils\command\sdist.py", line 336, in read_template

    self.filelist.process_template_line(line)

  File "C:\ActivePython32Python26\lib\distutils\filelist.py", line 129, in process_template_line

    (action, patterns, dir, dir_pattern) = self._parse_template_line(line)

  File "C:\ActivePython32Python26\lib\distutils\filelist.py", line 104, in _parse_template_line

    dir = convert_path(words[1])

  File "C:\ActivePython32Python26\lib\distutils\util.py", line 191, in convert_path

    raise ValueError, "path '%s' cannot end with '/'" % pathname

ValueError: path 'examples/templates/' cannot end with '/'

----------
assignee: tarek
components: Distutils
messages: 102142
nosy: srid, tarek
severity: normal
status: open
title: distutils: path '[...]' cannot end with '/'
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  2 12:56:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 02 Apr 2010 10:56:20 +0000
Subject: [New-bugs-announce] [issue8287] python-gdb.py triggers compile
	errors on FreeBSD and	Solaris
In-Reply-To: <1270205780.23.0.00384755916779.issue8287@psf.upfronthosting.co.za>
Message-ID: <1270205780.23.0.00384755916779.issue8287@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

The compile step fails on "python-gdb.py" on some buildbots.


# #### sparc solaris 10 gcc ####

running build_scripts
[51847 refs]
./install-sh -c  python-gdb.py
./install-sh: python-gdb.py does not exist
*** Error code 1
make: Fatal error: Command failed for target `python-gdb.py'


# #### x86 FreeBSD ####

running build_scripts
[53576 refs]
/usr/bin/install -c  python-gdb.py
usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
               [-o owner] file1 file2
       install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
               [-o owner] file1 ... fileN directory
       install -d [-v] [-g group] [-m mode] [-o owner] directory ...
*** Error code 64

----------
components: Build
keywords: buildbot
messages: 102155
nosy: doko, flox, loewis
priority: high
severity: normal
stage: needs patch
status: open
title: python-gdb.py triggers compile errors on FreeBSD and Solaris
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr  2 15:52:57 2010
From: report at bugs.python.org (Grigory)
Date: Fri, 02 Apr 2010 13:52:57 +0000
Subject: [New-bugs-announce] [issue8288] zipfile module documentation
	misprint
In-Reply-To: <1270216377.49.0.632972257682.issue8288@psf.upfronthosting.co.za>
Message-ID: <1270216377.49.0.632972257682.issue8288@psf.upfronthosting.co.za>


New submission from Grigory <matpuk at gmail.com>:

Zipfile module documentaion says:
"""
The file-like object is read-only and provides the following methods: read(), readline(), readlines(), __iter__(), next()
"""

But ZipExtFile class doesn't provide next(), it provides __next__().

----------
assignee: georg.brandl
components: Documentation
messages: 102168
nosy: georg.brandl, matpuk
severity: normal
status: open
title: zipfile module documentation misprint
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri Apr  2 17:06:49 2010
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 02 Apr 2010 15:06:49 +0000
Subject: [New-bugs-announce] [issue8289] multiprocessing.Process.__init__
	pickles all arguments
In-Reply-To: <1270220809.31.0.384012166997.issue8289@psf.upfronthosting.co.za>
Message-ID: <1270220809.31.0.384012166997.issue8289@psf.upfronthosting.co.za>


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

Currently, when you create a Process, all arguments you pass to its __init__ get pickled. I understood this is done because arguments to __init__ almost always become attributes to the Process. Like this:

def MyProcess(multiprocessing.Process):
    def __init__(self, whatever):
         self.whatever = whatever

Of course, attributes must be pickled so they can be accessed from the separate process (on Windows). And indeed in most cases all arguments to __init__ become attributes, so this makes sense.

But, in some cases you pass in arguments to __init__ that do not become attributes. In my case, __init__ takes an object, and takes some attributes of this object as attributes to itself. The object is unpicklable, but the attributes are. So I had to make some ugly workaround to make the program run.

So I think it would be better if Process would be smart enough to pickle only the arguments that get set as attributes.

----------
components: Library (Lib)
messages: 102172
nosy: cool-RR
severity: normal
status: open
title: multiprocessing.Process.__init__ pickles all arguments
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/issue8289>
_______________________________________

From report at bugs.python.org  Fri Apr  2 18:03:51 2010
From: report at bugs.python.org (LOLLA RADHA KRISHNA MURTHY)
Date: Fri, 02 Apr 2010 16:03:51 +0000
Subject: [New-bugs-announce] [issue8290] I HAVE A PROBLEM WITH PYTHON
In-Reply-To: <1270224231.7.0.39248878914.issue8290@psf.upfronthosting.co.za>
Message-ID: <1270224231.7.0.39248878914.issue8290@psf.upfronthosting.co.za>


New submission from LOLLA RADHA KRISHNA MURTHY <radhakrishna21 at rocketmail.com>:

I HAVE TO PERFORM A TASK THAT IS CALENDER.PY
in what way it is easier to me please tell

----------
files: day.py
messages: 102175
nosy: krishnalolla
severity: normal
status: open
title: I HAVE A PROBLEM WITH PYTHON
type: performance
Added file: http://bugs.python.org/file16736/day.py

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

From report at bugs.python.org  Fri Apr  2 18:19:03 2010
From: report at bugs.python.org (LOLLA RADHA KRISHNA MURTHY)
Date: Fri, 02 Apr 2010 16:19:03 +0000
Subject: [New-bugs-announce] [issue8291] i have a doubt with using __init__
	and .self and classes
In-Reply-To: <1270225143.56.0.0738074047322.issue8291@psf.upfronthosting.co.za>
Message-ID: <1270225143.56.0.0738074047322.issue8291@psf.upfronthosting.co.za>


New submission from LOLLA RADHA KRISHNA MURTHY <radhakrishna21 at rocketmail.com>:

i have a doubt with __init__ and .self how it is useful to us?
are we have to define a class in another class?if it is by what function

----------
messages: 102177
nosy: krishnalolla, skip.montanaro
severity: normal
status: open
title: i have a doubt with using __init__ and .self and classes
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr  2 18:48:38 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 02 Apr 2010 16:48:38 +0000
Subject: [New-bugs-announce] [issue8292] Incorrect condition test in
	platform.py
In-Reply-To: <1270226918.36.0.398729222231.issue8292@psf.upfronthosting.co.za>
Message-ID: <1270226918.36.0.398729222231.issue8292@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

While looking at #4440, I grepped for similar problems and found one in
platform.py in the following line:

if no_os_uname or not filter(None, (system, node, release, version, machine))

In 3.x, filter() returns an object, not a list, so 'not filter()' will always be false.  

One fix is to either convert filter's output by adding list() or tuple(). Another fix could be 'not any ((system, node, release, version, machine))', but I don't know if platform.py is trying to stay compatible with versions of Python that lack any().

----------
assignee: lemburg
keywords: easy
messages: 102179
nosy: akuchling, lemburg
severity: normal
status: open
title: Incorrect condition test in platform.py
versions: Python 3.2

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

From report at bugs.python.org  Fri Apr  2 20:58:28 2010
From: report at bugs.python.org (David Andrzejewski)
Date: Fri, 02 Apr 2010 18:58:28 +0000
Subject: [New-bugs-announce] [issue8293] HTTPSConnection.close() does not
	immediately close the	connection.
In-Reply-To: <1270234708.91.0.197021276581.issue8293@psf.upfronthosting.co.za>
Message-ID: <1270234708.91.0.197021276581.issue8293@psf.upfronthosting.co.za>


New submission from David Andrzejewski <site+python.org at davidandrzejewski.com>:

Python 2.6.4, Windows XP.

If you run the following code:

import httplib

http_connection = httplib.HTTPConnection("192.168.192.196")
http_connection.request("GET", "/")
http_connection.sock.settimeout(20)
response = http_connection.getresponse()
data = response.read()
http_connection.close()


And then run a netstat -a, you'll see that the connection is no longer established (it'll have a status of TIME_WAIT or something along those lines).

However, if you run the following code:

import httplib

http_connection = httplib.HTTPSConnection("192.168.192.196")
http_connection.request("GET", "/")
http_connection.sock.settimeout(20)
response = http_connection.getresponse()
data = response.read()
http_connection.close()

And run a netstat, the connection will still be in the ESTABLISHED state.  The connection does not end for several minutes (or when you terminate the program).

I can get the connection to end when I want it by doing a del on the connection object and then manually running garbage collection - although that seems a bit wonky.

I'm not really sure what all the differences are between HTTPConnection and HTTPSConnection, but it seems like they should both behave the same way in this regard.

----------
components: Library (Lib)
messages: 102186
nosy: dandrzejewski
severity: normal
status: open
title: HTTPSConnection.close() does not immediately close the connection.
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  2 22:42:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 02 Apr 2010 20:42:42 +0000
Subject: [New-bugs-announce] [issue8294] Allow Fraction constructor to
	accept float and decimal	instances directly.
In-Reply-To: <1270240962.97.0.707473120534.issue8294@psf.upfronthosting.co.za>
Message-ID: <1270240962.97.0.707473120534.issue8294@psf.upfronthosting.co.za>


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

Here's a patch that allows direct construction of a Fraction instance from a float or Decimal instance, performing an exact conversion in either case.

>>> from fractions import Fraction
>>> from decimal import Decimal
>>> Fraction(1.1)
Fraction(2476979795053773, 2251799813685248)
>>> Fraction(Decimal('1.1'))
Fraction(11, 10)
>>> Fraction(Decimal(1.1))
Fraction(2476979795053773, 2251799813685248)

----------
assignee: rhettinger
components: Library (Lib)
files: fraction_from_float.patch
keywords: patch
messages: 102198
nosy: mark.dickinson, rhettinger
severity: normal
status: open
title: Allow Fraction constructor to accept float and decimal instances directly.
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16738/fraction_from_float.patch

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

From report at bugs.python.org  Sat Apr  3 01:26:00 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 02 Apr 2010 23:26:00 +0000
Subject: [New-bugs-announce] [issue8295] add unpack_archive to shutil
In-Reply-To: <1270250760.18.0.650473997279.issue8295@psf.upfronthosting.co.za>
Message-ID: <1270250760.18.0.650473997279.issue8295@psf.upfronthosting.co.za>


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

unpack_archive is the reverse operation of make_archive and works the same way: it has a registery of function for each archive format.

----------
assignee: tarek
components: Library (Lib)
messages: 102212
nosy: tarek
priority: normal
severity: normal
status: open
title: add unpack_archive to shutil
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Apr  3 05:37:15 2010
From: report at bugs.python.org (Andrey Vlasovskikh)
Date: Sat, 03 Apr 2010 03:37:15 +0000
Subject: [New-bugs-announce] [issue8296] multiprocessing.Pool hangs when
	issuing KeyboardInterrupt
In-Reply-To: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za>
Message-ID: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za>


New submission from Andrey Vlasovskikh <andrey.vlasovskikh at gmail.com>:

multiprocessing.Pool methods map, imap, etc. are said to be able to normally handle exceptions. But it seems that it is true only for synchronous exceptions inside their first func arguments.

When (typically during a long-running parallel map) a user hits ^C, an asynchronous KeyboardInterrupt isn't handled properly and leads to the interpreter hangup. More precisely, children processes become <defunct> (on Linux), so the only way to terminate the whole program is to issue the KILL signal.

As stopping a program with ^C while running potentially long parallel computations is probably quite a common scenario, the interpreter should not hang up in such a case.

I'm using Python 2.6.5 (r265:79063, Mar 23 2010, 04:44:21) [GCC 4.4.3] on linux2. I've also tried to use the current multiprocessing.pool module from the current (2.7) trunk with my 2.6.5 installation, but the bug persists.

----------
components: Library (Lib)
messages: 102219
nosy: vlasovskikh
severity: normal
status: open
title: multiprocessing.Pool hangs when issuing KeyboardInterrupt
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat Apr  3 07:30:07 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 03 Apr 2010 05:30:07 +0000
Subject: [New-bugs-announce] [issue8297] AttributeError message text should
	include module name
In-Reply-To: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za>
Message-ID: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za>


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

It would be nice if the error message for an AttributeError could include the module name when getting from a module -- just like it does for getting from a class.

This would make the message more helpful.  For example, it would help in diagnosing issues like the ones mentioned in this report:

http://bugs.python.org/issue7559

EXAMPLE (using latest from trunk Python 2.7a4+):

import sys

class TestClass(object):
    pass

m = sys
c = TestClass

print "CLASS: %s" % c

try:
    c.asdf
except AttributeError, err:
    print err

print "\nMODULE: %s" % m

try:
    m.adsf
except AttributeError, err:
    print err

***
OUTPUT:

CLASS: <class '__main__.TestClass'>
type object 'TestClass' has no attribute 'asdf'

MODULE: <module 'sys' (built-in)>
'module' object has no attribute 'adsf'

***
The latter message could instead be (paralleling the text in the case of a class)--

module object 'sys' has no attribute 'adsf'

----------
components: Library (Lib)
messages: 102224
nosy: cjerdonek
severity: normal
status: open
title: AttributeError message text should include module name
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr  3 07:51:50 2010
From: report at bugs.python.org (LOLLA RADHA KRISHNA MURTHY)
Date: Sat, 03 Apr 2010 05:51:50 +0000
Subject: [New-bugs-announce] [issue8298] in what way we have to save tha
	module?
In-Reply-To: <1270273910.06.0.788971475779.issue8298@psf.upfronthosting.co.za>
Message-ID: <1270273910.06.0.788971475779.issue8298@psf.upfronthosting.co.za>


New submission from LOLLA RADHA KRISHNA MURTHY <radhakrishna21 at rocketmail.com>:

what is the process to save the module in python?

----------
messages: 102225
nosy: krishnalolla
severity: normal
status: open
title: in what way we have to save tha module?

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

From report at bugs.python.org  Sat Apr  3 12:27:25 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 03 Apr 2010 10:27:25 +0000
Subject: [New-bugs-announce] [issue8299] Improve GIL in 2.7
In-Reply-To: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>
Message-ID: <1270290445.01.0.906567593131.issue8299@psf.upfronthosting.co.za>


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

This patch does several things:
1) Creates a separate lock type PyThread_type_gil and locking functions for that.  This allows tweaking of the GIL without affecting regular lock behaviour.
2) Creates a uniform implementation of the GIL on windows/pthreads using macros, with emulated condition variables on windows (Lifted Antoine's code from py3k, adding own improvements to the slightly problematic windows implementation).  This makes the GIL behave the same on windows and pthreads platforms, if we so choose, and allows cross-platform development.
3) provide three GIL implementations:
 a) legacy gil, which is the same as the one used on pthreads
 b) a roundrobin gil, which fixes the multicore problem on pthreads and    exhibits the same behaviour as the legacy GIL on windows did (no jumping the gil queue)
 c) a priority based gil, with n given priority levels, and optionally, the ability to request immediate GIL drop by the ceval.c loop.

See thread_gil.h for details of the three modes.

In my experiments using David Beazley's scripts from http://www.dabeaz.com/blog/dablog.html, implementation "b" fixed the performance problems encountered on multicore machines.  This is, I believe, the original impetus for Antoine Pitrou's work on the new GIL.
Implementation "c" improved data transfer still, by allowing faster wakeup of completed IO.

Please note that I was not able to test this patch on a pthreads machine, I can only hope that it compiles :)

----------
components: Interpreter Core
files: gil.patch
keywords: patch, patch
messages: 102234
nosy: beazley, krisvale, pitrou
severity: normal
status: open
title: Improve GIL in 2.7
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file16744/gil.patch

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

From report at bugs.python.org  Sat Apr  3 13:51:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 11:51:47 +0000
Subject: [New-bugs-announce] [issue8300] Allow struct.pack to handle objects
	with an __index__	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>


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

In Python 2.7, struct.pack with an integer format can handle non-integers that provide an __int__ method (although this *does* raise a DeprecationWarning).

Python 2.7a4+ (trunk:79659:79661, Apr  3 2010, 11:28:19) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from struct import pack
[35194 refs]
>>> pack('L', 3.1415)
'\x03\x00\x00\x00\x00\x00\x00\x00'
[35210 refs]

This behaviour isn't particularly desirable for floats or Decimal instances, but it's useful for integer-like objects.

In Python 3.x, there's no provision for handling integer-like objects than aren't actually integers.

I propose that in 3.x, struct.pack should try to convert any non-integer to an integer by using its __index__ method, before packing.

----------
assignee: mark.dickinson
messages: 102245
nosy: mark.dickinson
severity: normal
status: open
title: Allow struct.pack to handle objects with an __index__ method.
versions: Python 3.2

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

From report at bugs.python.org  Sat Apr  3 15:32:04 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 03 Apr 2010 13:32:04 +0000
Subject: [New-bugs-announce] [issue8301] Putting a function in a
	unittest.TestSuite doesn't work
In-Reply-To: <1270301524.85.0.299541369901.issue8301@psf.upfronthosting.co.za>
Message-ID: <1270301524.85.0.299541369901.issue8301@psf.upfronthosting.co.za>


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

Putting functions (rather than TestCase instances) directly in TestSuites was never officially supported but it used to work:

>>> from unittest import TestSuite, TestResult
>>> def f(): pass
... 
>>> s = TestSuite()
>>> s.addTest(f)
>>> s.run(TestResult())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/compile/python-trunk/Lib/unittest/suite.py", line 85, in run
    self._wrapped_run(result)
  File "/compile/python-trunk/Lib/unittest/suite.py", line 100, in _wrapped_run
    self._handleClassSetUp(test, result)
  File "/compile/python-trunk/Lib/unittest/suite.py", line 122, in _handleClassSetUp
    currentClass._classSetupFailed = False
TypeError: can't set attributes of built-in/extension type 'function'

----------
assignee: michael.foord
components: Library (Lib)
messages: 102259
nosy: michael.foord
severity: normal
stage: needs patch
status: open
title: Putting a function in a unittest.TestSuite doesn't work
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Apr  3 15:34:12 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 03 Apr 2010 13:34:12 +0000
Subject: [New-bugs-announce] [issue8302] SkipTest exception in setUpClass or
	setUpModule is marked	as an error rather than a skip
In-Reply-To: <1270301652.92.0.301047962487.issue8302@psf.upfronthosting.co.za>
Message-ID: <1270301652.92.0.301047962487.issue8302@psf.upfronthosting.co.za>


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

SkipTest exception in setUpClass or setUpModule is marked as an error rather than a skip.

----------
assignee: michael.foord
messages: 102260
nosy: michael.foord
severity: normal
stage: needs patch
status: open
title: SkipTest exception in setUpClass or setUpModule is marked as an error rather than a skip
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Apr  3 16:54:13 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 03 Apr 2010 14:54:13 +0000
Subject: [New-bugs-announce] [issue8303] python -m unittest -h and python -m
	unittest discover -h	message slightly incorrect
In-Reply-To: <1270306453.69.0.686553855544.issue8303@psf.upfronthosting.co.za>
Message-ID: <1270306453.69.0.686553855544.issue8303@psf.upfronthosting.co.za>


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

The usage messages for unittest from the command line are slightly incorrect.

They show: "Usage: unittest [options]" when it should be "Usage: python -m unittest [options]" (or even "python -m unittest discover").

----------
assignee: michael.foord
messages: 102267
nosy: michael.foord
severity: normal
status: open
title: python -m unittest -h and python -m unittest discover -h message slightly incorrect
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Apr  3 17:08:44 2010
From: report at bugs.python.org (AndiDog)
Date: Sat, 03 Apr 2010 15:08:44 +0000
Subject: [New-bugs-announce] [issue8304] strftime and Unicode characters
In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>
Message-ID: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>


New submission from AndiDog <AndiDog at web.de>:

There is inconsistent behavior in time.strftime, comparing Python 2.6 and 3.1. In 3.1, non-ASCII Unicode characters seem to get dropped whereas in 2.6 you can keep them using the necessary Unicode-to-UTF8 workaround.

This should be fixed if it isn't intended behavior.

Python 2.6

>>> time.strftime(u"%d\u200F%A".encode("utf-8"), time.gmtime()).decode("utf-8")
u'03\u200fSaturday'
>>> time.strftime(u"%d\u0041%A".encode("utf-8"), time.gmtime()).decode("utf-8")
u'03ASaturday'

Python 3.1

>>> time.strftime("%d\u200F%A", time.gmtime())
''
>>> len(time.strftime("%d\u200F%A", time.gmtime()))
0
>>> time.strftime("%d\u0041%A", time.gmtime())
'03ASaturday'

----------
components: Library (Lib), Unicode
messages: 102269
nosy: AndiDog
severity: normal
status: open
title: strftime and Unicode characters
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Sat Apr  3 17:24:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Apr 2010 15:24:42 +0000
Subject: [New-bugs-announce] [issue8305] memoview[0] creates an invalid view
	if ndim != 1
In-Reply-To: <1270308282.65.0.542260907353.issue8305@psf.upfronthosting.co.za>
Message-ID: <1270308282.65.0.542260907353.issue8305@psf.upfronthosting.co.za>


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

memory_item() function creates a new memoryview object if ndim is different than 1. Example with numpy:

   from numpy import array
   y=array([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11])
   y.shape = 3,4
   view=memoryview(y)
   view2 = view[0]
   print type(view2)

Result: <type 'memoryview'>. (Without the shape, ndim equals 1, and view2 is a standard str object.)

The problem is that view attribute of the view2 (PyMemoryViewObject) is not initialized. Extract of memory_item():

        /* Return a new memory-view object */
        Py_buffer newview;
        memset(&newview, 0, sizeof(newview));
        /* XXX:  This needs to be fixed so it actually returns a sub-view */
        return PyMemoryView_FromBuffer(&newview);

"This needs to be fixed" :-/

--

view2 is not initialized and so view2.tolist() does crash.

----------
messages: 102270
nosy: haypo
severity: normal
status: open
title: memoview[0] creates an invalid view if ndim != 1
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Apr  3 18:57:48 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Apr 2010 16:57:48 +0000
Subject: [New-bugs-announce] [issue8306] ctypes.create_string_buffer should
	only accept bytes
In-Reply-To: <1270313868.4.0.365365163519.issue8306@psf.upfronthosting.co.za>
Message-ID: <1270313868.4.0.365365163519.issue8306@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

These coercions shouldn't be allowed:

import ctypes
>>> buf = ctypes.create_string_buffer("hi")
>>> buf.value
b'hi'
>>> buf.value = "23"
>>> buf.value
b'23'

----------
assignee: theller
components: ctypes
messages: 102282
nosy: benjamin.peterson, theller
severity: normal
status: open
title: ctypes.create_string_buffer should only accept bytes
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Apr  3 23:00:21 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Apr 2010 21:00:21 +0000
Subject: [New-bugs-announce] [issue8307] test_pep263 failure on OS X
In-Reply-To: <1270328421.06.0.903952382784.issue8307@psf.upfronthosting.co.za>
Message-ID: <1270328421.06.0.903952382784.issue8307@psf.upfronthosting.co.za>


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

I'm seeing a very peculiar test_pep263 failure when doing 'make test' on OS X 10.6.3.  It's enough to run test___all__ and test_pep263, in that order:

Mark-Dickinsons-MacBook-Pro:trunk dickinsm$ ./python.exe -Wd -3 -E -tt ./Lib/test/regrtest.py test___all__ test_pep263
test___all__
/Users/dickinsm/python/svn/trunk/Lib/test/test___all__.py:3: DeprecationWarning: in 3.x, the bsddb module has been removed; please use the pybsddb project instead
  import bsddb
/Users/dickinsm/python/svn/trunk/Lib/bsddb/__init__.py:67: PendingDeprecationWarning: The CObject type is marked Pending Deprecation in Python 2.7.  Please use capsule objects instead.
  import _bsddb
test_pep263
test test_pep263 failed -- Traceback (most recent call last):
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_pep263.py", line 39, in test_issue7820
    self.assertRaises(SyntaxError, eval, '\xff\x20')
  File "/Users/dickinsm/python/svn/trunk/Lib/unittest/case.py", line 444, in assertRaises
    callableObj(*args, **kwargs)
  File "<string>", line 1, in <module>
NameError: name '?' is not defined

1 test OK.
1 test failed:
    test_pep263
[218378 refs]


The failing test is expecting a SyntaxError, but gets a NameError instead.  I've narrowed down the cause of the failure to a Tkinter import:

Python 2.7a4+ (trunk:79716, Apr  3 2010, 20:30:09) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> eval('\xff\x20')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    ? 
    ^
SyntaxError: invalid syntax
[35036 refs]
>>> import Tkinter
[51314 refs]
>>> eval('\xff\x20')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
NameError: name '?' is not defined
[51324 refs]

But I'm now mystified:  why does the eval raise a SyntaxError before the import and a TypeError afterwards?

----------
messages: 102294
nosy: mark.dickinson
severity: normal
status: open
title: test_pep263 failure on OS X
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr  4 01:40:18 2010
From: report at bugs.python.org (John Machin)
Date: Sat, 03 Apr 2010 23:40:18 +0000
Subject: [New-bugs-announce] [issue8308] raw_bytes.decode('cp932') --
	spurious mappings
In-Reply-To: <1270338018.63.0.0227454811381.issue8308@psf.upfronthosting.co.za>
Message-ID: <1270338018.63.0.0227454811381.issue8308@psf.upfronthosting.co.za>


New submission from John Machin <sjmachin at users.sourceforge.net>:

According to the following references, the bytes 80, A0, FD, FE, and FF are not defined in cp932:

http://msdn.microsoft.com/en-au/goglobal/cc305152.aspx
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
http://demo.icu-project.org/icu-bin/convexp?conv=ibm-943_P15A-2003&s=ALL

However CPython 3.1.2 does this:

 >>> print(ascii(b'\x80\xa0\xfd\xfe\xff'.decode('cp932')))
 '\x80\uf8f0\uf8f1\uf8f2\uf8f3'

(as do 2.5, 2.6. and 2.7 with the appropriate syntax)

This maps 80 to U+0080 (not very useful) and maps the other 4 bytes into the Private Use Area ("PUA")!! Each case should be treated as undefined/unexpected/error/...

----------
components: Unicode
messages: 102308
nosy: sjmachin
severity: normal
status: open
title: raw_bytes.decode('cp932') -- spurious mappings
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun Apr  4 03:04:34 2010
From: report at bugs.python.org (Derek O'Connor)
Date: Sun, 04 Apr 2010 01:04:34 +0000
Subject: [New-bugs-announce] [issue8309] Sin(x) is Wrong
In-Reply-To: <1270343074.04.0.0881828805303.issue8309@psf.upfronthosting.co.za>
Message-ID: <1270343074.04.0.0881828805303.issue8309@psf.upfronthosting.co.za>


New submission from Derek O'Connor <derekroconnor at eircom.net>:

Dell Precision 690, Intel 2xQuad-Core E5345  @ 2.33GHz
16GB RAM, Windows7 64-bit Professional.

Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) 
[MSC v.1500 32 bit (Intel)] on win32

>>> from math import sin
>>> sin(1e22)
0.41214336710708466   (WRONG)
>>>

Python 3.1.2 (r312:79149, Mar 20 2010, 22:55:39)
[MSC v.1500 64 bit (AMD64)] on win32

>>> from math import sin
>>> sin(1e22)
-0.8522008497671888  (CORRECT)

The correct result, rounded to 20 digits is

 sin(10^22) = -8.5220 08497 67188 80177 e-001

Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is

10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22

Hence fl(10^22) = 10^22, whereas fl(10^23) ~= 10^23.

This incorrect result suggests that the range-reduction step, where the argument x is reduced to lie in a small interval around 0, such as [-pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect.

Yours sincerely,

Derek O'Connor

----------
components: Library (Lib)
messages: 102312
nosy: derekroconnor
severity: normal
status: open
title: Sin(x) is Wrong
type: performance
versions: Python 3.1

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

From report at bugs.python.org  Sun Apr  4 14:57:33 2010
From: report at bugs.python.org (Ozgur Dogan Ugurlu)
Date: Sun, 04 Apr 2010 12:57:33 +0000
Subject: [New-bugs-announce] [issue8310] dis.dis function skips new-style
	classes in a module
In-Reply-To: <1270385853.05.0.694104105245.issue8310@psf.upfronthosting.co.za>
Message-ID: <1270385853.05.0.694104105245.issue8310@psf.upfronthosting.co.za>


New submission from Ozgur Dogan Ugurlu <dogeen at gmail.com>:

The documentation says:

dis.dis([bytesource])
Disassemble the bytesource object. bytesource can denote either a module, a class, a method, a function, or a code object. For a module, it disassembles all functions. For a class, it disassembles all methods. For a single code sequence, it prints one line per bytecode instruction. If no object is provided, it disassembles the last traceback.

And the behavior is correct for old-style classes. However, since the if check in the function dis.dis is like this:

if hasattr(x, '__dict__'):
        items = x.__dict__.items()
        items.sort()
        for name, x1 in items:
            if type(x1) in (types.MethodType,
                            types.FunctionType,
                            types.CodeType,
                            types.ClassType):

when given a module (x), it doesn't handle new-style classes which are types.TypeType. (types.ClassType are old-style classes)

A simple addition of types.TypeType to the list used by the inner if clause fixes the problem for me but I don't know if it could introduce another bug.

----------
components: Library (Lib)
messages: 102338
nosy: dogeen
severity: normal
status: open
title: dis.dis function skips new-style classes in a module
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Apr  4 15:36:53 2010
From: report at bugs.python.org (Jeff Pursell)
Date: Sun, 04 Apr 2010 13:36:53 +0000
Subject: [New-bugs-announce] [issue8311] wave module sets data subchunk size
	incorrectly when	writing wav file
In-Reply-To: <1270388213.12.0.14457017538.issue8311@psf.upfronthosting.co.za>
Message-ID: <1270388213.12.0.14457017538.issue8311@psf.upfronthosting.co.za>


New submission from Jeff Pursell <jpursell at gmail.com>:

I tried to create a 4 second file and only heard the first 2 seconds.  The file size was correct for a 44.1 kHz, 16 bit mono file at 4 seconds, but both aplay and audactiy ignored the second half of the file.  I went to this page https://ccrma.stanford.edu/courses/422/projects/WaveFormat/ and opened the output with a hex editor in little endian mode.  I found that at offset 40, the data chunk size was wrong.  It looked like it was just set to the number of samples.  It should be the number of samples times bytes-per-sample (2) times number-of-channels (1 in my case).  I manually set the number from 176400 to 352800 and that solved the problem for that wav file.

I'm guessing this was just an oversight and the fix will be simple.

I'll attach the code I used to generate the test tone.  Just run python -i testTone.py and it will generate out.wav with the incorrect field.

I am using pything 2.6.4 in ubuntu.

----------
components: Extension Modules
files: testTone.zip
messages: 102342
nosy: Jeff.Pursell
severity: normal
status: open
title: wave module sets data subchunk size incorrectly when writing wav file
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16757/testTone.zip

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

From report at bugs.python.org  Sun Apr  4 23:55:01 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 04 Apr 2010 21:55:01 +0000
Subject: [New-bugs-announce] [issue8312] Add post/pre hooks for distutils
	commands
In-Reply-To: <1270418101.32.0.698965190272.issue8312@psf.upfronthosting.co.za>
Message-ID: <1270418101.32.0.698965190272.issue8312@psf.upfronthosting.co.za>


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

Add hooks to a script can be launched before/after a command.

This will be useful to build pre/post commit hooks for install/uninstall commands for instance

----------
assignee: tarek
components: Distutils2
messages: 102353
nosy: tarek
severity: normal
status: open
title: Add post/pre hooks for distutils commands

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

From report at bugs.python.org  Mon Apr  5 12:56:29 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 05 Apr 2010 10:56:29 +0000
Subject: [New-bugs-announce] [issue8313] <unprintable AssertionError object>
	message in unittest	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>


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

>>> import unittest
>>> class Foo(unittest.TestCase):
...   def test_fffd(self): self.assertEqual(u'\ufffd', u'\ufffd\ufffd')
...
>>> unittest.main(exit=False)
F
======================================================================
FAIL: test_fffd (__main__.Foo)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<stdin>", line 2, in test_fffd
AssertionError: <unprintable AssertionError object>

----------------------------------------------------------------------
Ran 1 test in 0.001s


The problem with creating unicode tracebacks is that they could fail when being output on terminals not capable of showing the full range of unicode characters (the default terminal on Windows is CP1252).

This can already happen with Unicode messages that aren't part of the traceback.

Detecting the 'unprintable' message before calling into traceback and replacing it with the repr of the unicode is one possibility.

----------
assignee: michael.foord
components: Library (Lib)
messages: 102368
nosy: ezio.melotti, michael.foord
severity: normal
status: open
title: <unprintable AssertionError object> message in unittest tracebacks
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Apr  5 14:18:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Apr 2010 12:18:05 +0000
Subject: [New-bugs-announce] [issue8314] test_ctypes fails in test_ulonglong
	on sparc buildbots
In-Reply-To: <1270469885.55.0.752027246289.issue8314@psf.upfronthosting.co.za>
Message-ID: <1270469885.55.0.752027246289.issue8314@psf.upfronthosting.co.za>


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

======================================================================
FAIL: test_ulonglong (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 68, in test_ulonglong
    self.check_type(c_ulonglong, 42)
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 31, in check_type
    self.assertEqual(result, arg)
AssertionError: 0L != 42

----------
components: Tests
keywords: buildbot
messages: 102371
nosy: r.david.murray, theller
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ctypes fails in test_ulonglong on sparc buildbots
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr  5 17:36:33 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 05 Apr 2010 15:36:33 +0000
Subject: [New-bugs-announce] [issue8315] ./python -m unittest
	test.test_importlib doesn't work
In-Reply-To: <1270481793.28.0.468676978723.issue8315@psf.upfronthosting.co.za>
Message-ID: <1270481793.28.0.468676978723.issue8315@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Actually, ./python -m unittest test.test_email doesn't work either and those are two cases where the Lib/test module just forwards to the package's own test suite, so maybe that's the problem.

----------
assignee: michael.foord
components: Library (Lib)
messages: 102377
nosy: barry, michael.foord
severity: normal
status: open
title: ./python -m unittest test.test_importlib doesn't work
versions: Python 3.2

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

From report at bugs.python.org  Mon Apr  5 18:10:34 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 05 Apr 2010 16:10:34 +0000
Subject: [New-bugs-announce] [issue8316] test_gdb is susceptible to tty
	width settings
In-Reply-To: <1270483834.31.0.175074168079.issue8316@psf.upfronthosting.co.za>
Message-ID: <1270483834.31.0.175074168079.issue8316@psf.upfronthosting.co.za>


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

test_gdb's get_gdb_repr carves up a gdb backtrace to try to extract how gdb representated the data.

When connected to a tty, gdb will insert additional newlines and spaces based on the width of the tty (internally it has a wrap_here() function to do this), so the test turned out to be somewhat susceptible to whitespace and tty configuration.

I'm attaching a patch against trunk which I believe fixes this.  I've tested it with various tty widths (from 5 columns wide through to 235 columns wide), and redirecting to a file, and all tests pass.

[Seen on buildbot on this run:
http://www.python.org/dev/buildbot/builders/sparc%20Ubuntu%20trunk/builds/37/steps/test/logs/stdio
and I believe this was the cause of all of four of the five failures there.

The remaining one "test_corrupt_tp_name" seems to be a different issue]

----------
assignee: r.david.murray
files: fix-test_gdb-whitespace-issues.txt
keywords: buildbot
messages: 102383
nosy: dmalcolm, r.david.murray
severity: normal
stage: patch review
status: open
title: test_gdb is susceptible to tty width settings
versions: Python 2.7
Added file: http://bugs.python.org/file16766/fix-test_gdb-whitespace-issues.txt

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

From report at bugs.python.org  Mon Apr  5 19:24:20 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 05 Apr 2010 17:24:20 +0000
Subject: [New-bugs-announce] [issue8317] test_tarfile fails intermittently
	on Windows
In-Reply-To: <1270488260.7.0.624220930721.issue8317@psf.upfronthosting.co.za>
Message-ID: <1270488260.7.0.624220930721.issue8317@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Using Windows 7 32-bit, and /branches/py3k at 79802.

When I run the test_tarfile from the regrtest script, often the first run will succeed and subsequent runs will fail (though sometimes a first run will fail and rarely a subsequent run will succeed). It appears to be a timing issue. The output from a failed attempt is included below.

Passing -v to the regrtest script prevents the failure from occurring. Also disabling test_extract_hardlink test prevents the failure from occurring in most cases. I found that enabling pdb and setting a trace in test_extract_hardlink prevented the error from occurring. I also attempted closing the tarfile explicitly (including in a finally block) and putting time.sleep(1) at the beginning or end of that test, but that seemed to have no effect.

I am beginning to suspect that this problem is related to an indexer or malware scanner on the system checking the file after it's created, causing it to be locked at the time it's scheduled to be deleted.

PS C:\Users\jaraco\projects\public\python-core-3.x-svn> pcbuild\python .\lib\test\regrtest.py test_tarfile
test_tarfile
test test_tarfile crashed -- <class 'WindowsError'>: [Error 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\jaraco\\projects\\public\\python-core-3.x-svn\\build\\test_python_5196\\@test_5196_tmp\\testtar.tar.gz'
'test_tarfile' left behind directory '@test_5196_tmp' and it couldn't be removed: [Error 32] The process cannot access the file because it is being used by another process: '@test_5196_tmp\\testtar.tar.gz'
1 test failed:
    test_tarfile
Traceback (most recent call last):
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\test\support.py", line 400, in temp_cwd
    yield os.getcwd()
  File ".\lib\test\regrtest.py", line 1473, in <module>
    main()
  File ".\lib\test\regrtest.py", line 687, in main
    sys.exit(len(bad) > 0 or interrupted)
SystemExit: True

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File ".\lib\test\regrtest.py", line 1473, in <module>
    main()
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\contextlib.py", line 35, in __exit__
    self.gen.throw(type, value, traceback)
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\test\support.py", line 404, in temp_cwd
    rmtree(name)
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\test\support.py", line 184, in rmtree
    shutil.rmtree(path)
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\shutil.py", line 251, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\shutil.py", line 256, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "C:\Users\jaraco\projects\public\python-core-3.x-svn\lib\shutil.py", line 254, in rmtree
    os.remove(fullname)
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\jaraco\\projects\\public\\python-core-3.x-svn\\build\\test_python_5196\\@test_5196_tmp\\testtar.tar.gz'

----------
components: Tests
messages: 102386
nosy: jaraco
severity: normal
status: open
title: test_tarfile fails intermittently on Windows
versions: Python 3.2

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

From report at bugs.python.org  Mon Apr  5 19:42:02 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 05 Apr 2010 17:42:02 +0000
Subject: [New-bugs-announce] [issue8318] Deprecation of multifile
	inappropriate or incomplete
In-Reply-To: <1270489322.03.0.368739706632.issue8318@psf.upfronthosting.co.za>
Message-ID: <1270489322.03.0.368739706632.issue8318@psf.upfronthosting.co.za>


New submission from Tres Seaver <tseaver at agendaless.com>:

Import of the multifile module emits a DeprecationWarning, but the
warning is either incomplete:

- The documentation[1] states that the 'email' module is to be
  preferred, but doesn't describe what APIs should be used from that
  module.

- In fact, the 'email' module doesn't appear to provide an equivalent
  API to the 'multifile' module.

or perhaps inappropriate, as not all handling of 'multipart' MIME is
email related (e.g., processing HTTP form POSTs which include file uploads).

At a minimum, the docs for 'multifile' should include examples showing
the "preferred" way to implement its own native examples using
the'email' module's APIs.


[1] http://docs.python.org/library/multifile.html

----------
components: Library (Lib)
messages: 102390
nosy: barry, tseaver
severity: normal
status: open
title: Deprecation of multifile inappropriate or incomplete
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Apr  5 20:08:55 2010
From: report at bugs.python.org (Winfried Plappert)
Date: Mon, 05 Apr 2010 18:08:55 +0000
Subject: [New-bugs-announce] [issue8319] HTMLparser does not handle call to
	handle_data when a tag	contains nor data.
In-Reply-To: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>
Message-ID: <1270490935.7.0.673554223896.issue8319@psf.upfronthosting.co.za>


New submission from Winfried Plappert <Winfried.Plappert at gmail.com>:

When parsing HTML and having a string along the lines of <td></td>, a call to handle_data is not issued between handle_starttag and handle_endtag, but afterwards. The problem is in HTMLparser.goahead, where the position i and j are calculated. The code reads
if i < j: self.handle_data(rawdata[i:j]) but it should be
if i <= j: self.handle_data(rawdata[i:j])

If there is data between <td> and </td>, everything works fine.

I just checked the trunk of 2.6, this occurs in line 142 of Lib/HTMLParser.py. The size of HTMLParser.py is 13407 bytes, and is dated 'Feb 26 19:25'.

----------
components: Library (Lib)
messages: 102392
nosy: wplappert
severity: normal
status: open
title: HTMLparser does not handle call to handle_data when a tag contains nor data.
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Apr  5 20:13:36 2010
From: report at bugs.python.org (Irmen de Jong)
Date: Mon, 05 Apr 2010 18:13:36 +0000
Subject: [New-bugs-announce] [issue8320] docs on socket.recv_into doesn't
	mention the return value
In-Reply-To: <1270491216.65.0.230513280348.issue8320@psf.upfronthosting.co.za>
Message-ID: <1270491216.65.0.230513280348.issue8320@psf.upfronthosting.co.za>


New submission from Irmen de Jong <irmen at razorvine.net>:

Doc/library/socket.rst doesn't mention the return value for recv_into. Adding a simple "Returns the number of bytes received." should fix this. 
(note that recvfrom_into does mention its return value)

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 102393
nosy: georg.brandl, irmen
severity: normal
status: open
title: docs on socket.recv_into doesn't mention the return value
type: feature request
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Apr  5 22:42:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 20:42:55 +0000
Subject: [New-bugs-announce] [issue8321] Give access to openssl version
	number
In-Reply-To: <1270500175.51.0.74783261026.issue8321@psf.upfronthosting.co.za>
Message-ID: <1270500175.51.0.74783261026.issue8321@psf.upfronthosting.co.za>


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

This patch gives access to the OpenSSL version the _ssl module is linked against, through three attributes: one gives the raw integer, another the decoded 5-tuple of ints, the last one the version string as returned by OpenSSL.

----------
components: Library (Lib)
files: sslversion.patch
keywords: patch
messages: 102406
nosy: benjamin.peterson, flox, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Give access to openssl version number
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16767/sslversion.patch

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

From report at bugs.python.org  Mon Apr  5 22:45:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Apr 2010 20:45:36 +0000
Subject: [New-bugs-announce] [issue8322] test_ssl failures with OpenSSL 1.0.0
In-Reply-To: <1270500336.1.0.699742916544.issue8322@psf.upfronthosting.co.za>
Message-ID: <1270500336.1.0.699742916544.issue8322@psf.upfronthosting.co.za>


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

When I compile and link against a local build of OpenSSL 1.0.0 (vanilla), I get the following errors in test_ssl:

======================================================================
ERROR: testProtocolSSL2 (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 869, in testProtocolSSL2
    tryProtocolCombo(ssl.PROTOCOL_SSLv2, ssl.PROTOCOL_SSLv23, True)
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 736, in tryProtocolCombo
    CERTFILE, CERTFILE, client_protocol, chatty=False)
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 688, in serverParamsTest
    raise test_support.TestFailed("Unexpected exception:  " + str(x))
TestFailed: Unexpected exception:  [Errno 104] Connection reset by peer

======================================================================
ERROR: testProtocolSSL3 (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 903, in testProtocolSSL3
    tryProtocolCombo(ssl.PROTOCOL_SSLv3, ssl.PROTOCOL_SSLv23, False)
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 745, in tryProtocolCombo
    ssl.get_protocol_name(server_protocol)))
TestFailed: Client protocol SSLv23 succeeded with server protocol SSLv3!

======================================================================
ERROR: testProtocolTLS1 (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 914, in testProtocolTLS1
    tryProtocolCombo(ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_SSLv23, False)
  File "/home/antoine/cpython/newssl/Lib/test/test_ssl.py", line 745, in tryProtocolCombo
    ssl.get_protocol_name(server_protocol)))
TestFailed: Client protocol SSLv23 succeeded with server protocol TLSv1!

----------
components: Library (Lib)
messages: 102409
nosy: flox, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ssl failures with OpenSSL 1.0.0
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Apr  6 00:45:18 2010
From: report at bugs.python.org (Robin Schoonover)
Date: Mon, 05 Apr 2010 22:45:18 +0000
Subject: [New-bugs-announce] [issue8323] multiprocessing.Queue ignores
	pickle restrictions in	.put()
In-Reply-To: <1270507518.5.0.340159262485.issue8323@psf.upfronthosting.co.za>
Message-ID: <1270507518.5.0.340159262485.issue8323@psf.upfronthosting.co.za>


New submission from Robin Schoonover <end at cornhooves.org>:

The multiprocessing module's version of the Queue class, which causes objects to be pickled for process to process transfer, ignores pickle restrictions when objects are added to the queue.  Example code (buffer isn't pickleable):

    from multiprocessing import Queue

    q = Queue()
    q.put(buffer("this is a buffer"))
    print(q.get())

It results in an exception, which is expected, but the exception is confusing, after the problem has already occurred, and if I were actually using multiple processes, not in the process that tried to send an unsendable object:

Traceback (most recent call last):                                                           
  File "mppkbuffer.py", line 5, in <module>                                                
    print(q.get())
  File "/usr/lib/python2.6/multiprocessing/queues.py", line 91, in get
    res = self._recv()
TypeError: buffer() takes at least 1 argument (0 given)

Expected result would be a thrown exception when we attempt to put the object into the queue using .put(), NOT when we attempt pull it out of the queue using .get(), when it gets unpickled.  Basically, while pickle fails when it tries to dump, Queue succeeds the dump (somehow) and fails to load.

I have tested with python 2.6.4 and 2.7a4.  3.1 doesn't appear to have this bug (but it does have a different one which I will report later).

----------
components: Library (Lib)
messages: 102423
nosy: rschoon
severity: normal
status: open
title: multiprocessing.Queue ignores pickle restrictions in .put()
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Apr  6 01:19:34 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 05 Apr 2010 23:19:34 +0000
Subject: [New-bugs-announce] [issue8324] add a test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>


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

Add a test command in distutils, ala setuptools

----------
assignee: tarek
components: Distutils2
keywords: gsoc
messages: 102426
nosy: tarek
priority: normal
severity: normal
status: open
title: add a test command
type: feature request

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

From report at bugs.python.org  Tue Apr  6 11:35:14 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 06 Apr 2010 09:35:14 +0000
Subject: [New-bugs-announce] [issue8325] improve regrtest command line help
In-Reply-To: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>
Message-ID: <1270546514.38.0.076876301482.issue8325@psf.upfronthosting.co.za>


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

regrtest command line help can be greatly improved to encourage users run tests.

----------
components: Tests
messages: 102443
nosy: techtonik
severity: normal
status: open
title: improve regrtest command line help
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr  6 12:29:51 2010
From: report at bugs.python.org (David Coconut)
Date: Tue, 06 Apr 2010 10:29:51 +0000
Subject: [New-bugs-announce] [issue8326] Cannot import name SemLock
In-Reply-To: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>
Message-ID: <1270549791.67.0.929964356468.issue8326@psf.upfronthosting.co.za>


New submission from David Coconut <coconut at redbrick.dcu.ie>:

Operating system: Ubuntu 10.04 Lucid Lynx (Beta)

This worked with Python 3.1 on 9.10 Karmic Koala. The same error appears on two separate installations of Lucid.

Issue 3770 does not seem to be relevant here.

Traceback (most recent call last):
File "/usr/lib/python3.1/multiprocessing/synchronize.py", line 28, in <module>
from _multiprocessing import SemLock
ImportError: cannot import name SemLock

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
                                                                        File "main.py", line 16, in <module>
q = JoinableQueue()
File "/usr/lib/python3.1/multiprocessing/__init__.py", line 218, in JoinableQueue
from multiprocessing.queues import JoinableQueue

File "/usr/lib/python3.1/multiprocessing/queues.py", line 22, in <module>
from multiprocessing.synchronize import Lock, BoundedSemaphore, Semaphore, Condition

File "/usr/lib/python3.1/multiprocessing/synchronize.py", line 33, in <module>
" function, see issue 3770.")
                                                                    ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.

----------
messages: 102447
nosy: coconutrb
severity: normal
status: open
title: Cannot import name SemLock
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Tue Apr  6 19:21:06 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Tue, 06 Apr 2010 17:21:06 +0000
Subject: [New-bugs-announce] [issue8327] unintuitive behaviour of logging
	message propagation
In-Reply-To: <1270574466.45.0.74894426001.issue8327@psf.upfronthosting.co.za>
Message-ID: <1270574466.45.0.74894426001.issue8327@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

Hello

Crawling into the logging module, I've just discovered its behaviour was actually far from the one I expected, in a consequent gap that the documentation had left.

I thought that depending on the "propagate" parameter of each logger, a message would always try to propagate up the logger hierarchy, and that if that message matched the level of a logger (as well as the global disable() level), then this message would be tested against each handler of that logger.

But it's not at all the way it is : actually, only the level of the "entrance" logger is checked ; if the message is blocked by it, it's the end, parent loggers will never hear about it (even thoiugh they might have a lower level set). On the contrary, if that entrance logger accepts the message, then ALL handlers from the hierarchy are snet the message, without caring about the own level of their related logger.

That's really not the behaviour I would have expected, considering the global_disable > logger_level > handler_level precedence that the doc implicitly showed. Are there rationales behind this that I'm lacking ?

So I'd advocate either (if possible) a patching of the logging system, to reflect that semantic ; or the adding of comprehensive paragraphs to teh doc, to explain what the exact relationship between levels and propagation attribuets are.
Just tell me if a patch is conceivable B-)

----------
components: Library (Lib)
messages: 102477
nosy: pakal
severity: normal
status: open
title: unintuitive behaviour of logging message propagation
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr  6 20:38:29 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 06 Apr 2010 18:38:29 +0000
Subject: [New-bugs-announce] [issue8328] longobject.c: silence warnings
	(Visual Studio)
In-Reply-To: <1270579109.17.0.48402121763.issue8328@psf.upfronthosting.co.za>
Message-ID: <1270579109.17.0.48402121763.issue8328@psf.upfronthosting.co.za>


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

Mark, are you ok with silencing these conversion warnings?

----------
components: Build
files: longobject_vs_warnings_py3k.patch
keywords: patch
messages: 102482
nosy: mark.dickinson, skrah
severity: normal
status: open
title: longobject.c: silence warnings (Visual Studio)
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16786/longobject_vs_warnings_py3k.patch

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

From report at bugs.python.org  Tue Apr  6 23:19:38 2010
From: report at bugs.python.org (Mike Kent)
Date: Tue, 06 Apr 2010 21:19:38 +0000
Subject: [New-bugs-announce] [issue8329] select.select() can return lists
	with identical id()'s
In-Reply-To: <1270588778.99.0.319971832918.issue8329@psf.upfronthosting.co.za>
Message-ID: <1270588778.99.0.319971832918.issue8329@psf.upfronthosting.co.za>


New submission from Mike Kent <mike.kent at sage.com>:

If select.select() returns two or more empty lists, these empty lists will all refer to the same list; that is, they will have identical id()'s.  If you then have reason to alter one of the returned empty lists, you are altering all of the returned empty lists.  This can result in some significant debugging time spent, and curse words uttered.

I encountered this in Python 2.5.4, but have not yet verified it on a more recent version.  Searching through the Issue Tracker showed nothing similar.

----------
components: Library (Lib)
messages: 102496
nosy: mrmakent
severity: normal
status: open
title: select.select() can return lists with identical id()'s
versions: Python 2.5

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

From report at bugs.python.org  Wed Apr  7 02:45:26 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 07 Apr 2010 00:45:26 +0000
Subject: [New-bugs-announce] [issue8330] Failures seen in test_gdb on
	buildbots
In-Reply-To: <1270601126.21.0.71359722213.issue8330@psf.upfronthosting.co.za>
Message-ID: <1270601126.21.0.71359722213.issue8330@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/trunk/builders/alpha%20Debian%20trunk/builds/52/steps/test/logs/stdio
shows some failures in test_gdb:

======================================================================
FAIL: test_corrupt_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a corrupt ob_type is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_gdb.py", line 361, in test_corrupt_ob_type
    'set op->ob_type=0xDEADBEEF')
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_gdb.py", line 341, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: '< at remote 0x1202cf5a8>'
Breakpoint 1 at 0x12007a9e8: file Objects/object.c, line 330.
[Thread debugging using libthread_db enabled]

Breakpoint 1, PyObject_Print (op=42, fp=0x200002f87b0, flags=1)
    at Objects/object.c:330
330		return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=< at remote 0x1202cf5a8>, fp=0x200002f87b0, flags=1)
    at Objects/object.c:330
#1  0x000000012003eaa0 in file_PyObject_Print (op=< at remote 0x1202cf5a8>, f=
    0x20000326280, flags=1) at Objects/fileobject.c:110
#2  0x0000000120045bc8 in PyFile_WriteObject (v=< at remote 0x1202cf5a8>, f=
    <file at remote 0x20000326280>, flags=1) at Objects/fileobject.c:2470
#3  0x000000012010bb90 in PyEval_EvalFrameEx (f=
    Frame 0x1203a0ba0, for file <string>, line 1, in <module> (), throwflag=0)
    at Python/ceval.c:1769
#4  0x00000001201134bc in PyEval_EvalCodeEx (co=0x120305880, globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=0x0, argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#5  0x0000000120107294 in PyEval_EvalCode (co=0x120305880, globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:666
#6  0x0000000120152e08 in run_mod (mod=0x12038b848, filename=
    0x12021cf00 "<string>", globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0x11f48b4d8, arena=0x1203406b0)
    at Python/pythonrun.c:1340
#7  0x0000000120152c2c in PyRun_StringFlags (str=0x1202b2010 "print 42\n", 
    start=257, globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0x11f48b4d8)
    at Python/pythonrun.c:1303
#8  0x0000000120150f50 in PyRun_SimpleStringFlags (command=
    0x1202b2010 "print 42\n", flags=0x11f48b4d8) at Python/pythonrun.c:962
#9  0x00000001200185a0 in Py_Main (argc=4, argv=0x11f48b6b8)
    at Modules/main.c:525
#10 0x0000000120016e88 in main (argc=4, argv=0x11f48b6b8)
    at ./Modules/python.c:23


======================================================================
FAIL: test_corrupt_tp_name (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_name is handled
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_gdb.py", line 372, in test_corrupt_tp_name
    'set op->ob_type->tp_name=0xDEADBEEF')
  File "/home/doko/buildarea/trunk.klose-debian-alpha/build/Lib/test/test_gdb.py", line 341, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: '42'
Breakpoint 1 at 0x12007a9e8: file Objects/object.c, line 330.
[Thread debugging using libthread_db enabled]

Breakpoint 1, PyObject_Print (op=42, fp=0x200002f87b0, flags=1)
    at Objects/object.c:330
330		return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=42, fp=0x200002f87b0, flags=1) at Objects/object.c:330
#1  0x000000012003eaa0 in file_PyObject_Print (op=42, f=0x20000326280, flags=1)
    at Objects/fileobject.c:110
#2  0x0000000120045bc8 in PyFile_WriteObject (v=42, f=
    <file at remote 0x20000326280>, flags=1) at Objects/fileobject.c:2470
#3  0x000000012010bb90 in PyEval_EvalFrameEx (f=
    Frame 0x1203a0ba0, for file <string>, line 1, in <module> (), throwflag=0)
    at Python/ceval.c:1769
#4  0x00000001201134bc in PyEval_EvalCodeEx (co=0x120305880, globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=0x0, argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#5  0x0000000120107294 in PyEval_EvalCode (co=0x120305880, globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:666
#6  0x0000000120152e08 in run_mod (mod=0x12038b848, filename=
    0x12021cf00 "<string>", globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0x11f4174d8, arena=0x1203406b0)
    at Python/pythonrun.c:1340
#7  0x0000000120152c2c in PyRun_StringFlags (str=0x1202b2010 "print 42\n", 
    start=257, globals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x20000337470>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0x11f4174d8)
    at Python/pythonrun.c:1303
#8  0x0000000120150f50 in PyRun_SimpleStringFlags (command=
    0x1202b2010 "print 42\n", flags=0x11f4174d8) at Python/pythonrun.c:962
#9  0x00000001200185a0 in Py_Main (argc=4, argv=0x11f4176b8)
    at Modules/main.c:525
#10 0x0000000120016e88 in main (argc=4, argv=0x11f4176b8)
    at ./Modules/python.c:23


----------------------------------------------------------------------
Ran 31 tests in 27.624s

FAILED (failures=2)

----------
assignee: dmalcolm
keywords: buildbot
messages: 102509
nosy: dmalcolm
severity: normal
status: open
title: Failures seen in test_gdb on buildbots
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  7 03:36:32 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 07 Apr 2010 01:36:32 +0000
Subject: [New-bugs-announce] [issue8331] a documentation grammar fix in
	logging module
In-Reply-To: <1270604192.13.0.509346290398.issue8331@psf.upfronthosting.co.za>
Message-ID: <1270604192.13.0.509346290398.issue8331@psf.upfronthosting.co.za>


New submission from Shashwat Anand <anand.shashwat at gmail.com>:

Just fixed some grammatical error in the docs of logging module.

----------
assignee: georg.brandl
components: Documentation
files: logging.patch
keywords: patch
messages: 102510
nosy: georg.brandl, l0nwlf, vinay.sajip
severity: normal
status: open
title: a documentation grammar fix in logging module
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16792/logging.patch

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

From report at bugs.python.org  Wed Apr  7 11:19:18 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 07 Apr 2010 09:19:18 +0000
Subject: [New-bugs-announce] [issue8332] regrtest single
	TestClass/test_method
In-Reply-To: <1270631958.05.0.652340331128.issue8332@psf.upfronthosting.co.za>
Message-ID: <1270631958.05.0.652340331128.issue8332@psf.upfronthosting.co.za>


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

It would be convenient for debug to execute single test_method or TestClass. Running all tests in file can take a long time.

----------
components: Tests
messages: 102524
nosy: techtonik
severity: normal
status: open
title: regrtest single TestClass/test_method
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  7 15:34:36 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Apr 2010 13:34:36 +0000
Subject: [New-bugs-announce] [issue8333] test_multiprocessing: pickling
	failures
In-Reply-To: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>
Message-ID: <1270647276.97.0.3813963585.issue8333@psf.upfronthosting.co.za>


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

On Windows/amd64, I get loads of pickling errors in test_multiprocessing.

Type 1 error:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 347, in main
    self = load(from_parent)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 1378, in load
    return Unpickler(file).load()
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 858, in load
    dispatch[key](self)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 880, in load_eof
    raise EOFError
EOFError


Type 2 error:

======================================================================
ERROR: test_fork (__main__.WithManagerTestQueue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "..\..\Lib\test\test_multiprocessing.py", line 485, in test_fork
    p.start()
  File "C:\Users\stefan\svn\trunk\lib\multiprocessing\process.py", line 104, in start
    self._popen = Popen(self)
  File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 244, in __init__
    dump(process_obj, to_child, HIGHEST_PROTOCOL)
  File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 167, in dump
    ForkingPickler(file, protocol).dump(obj)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 224, in dump
    self.save(obj)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 419, in save_reduce
    save(state)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 681, in _batch_setitems
    save(v)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Users\stefan\svn\trunk\lib\multiprocessing\forking.py", line 40, in dispatcher
    self.save_reduce(obj=obj, *rv)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 401, in save_reduce
    save(args)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 548, in save_tuple
    save(element)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 419, in save_reduce
    save(state)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 681, in _batch_setitems
    save(v)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 419, in save_reduce
    save(state)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 681, in _batch_setitems
    save(v)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 396, in save_reduce
    save(cls)
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Users\stefan\svn\trunk\lib\pickle.py", line 748, in save_global
    (obj, module, name))
PicklingError: Can't pickle <type 'cStringIO.StringO'>: it's not found as cStringIO.StringO

----------
components: Library (Lib)
messages: 102539
nosy: skrah
priority: high
severity: normal
stage: needs patch
status: open
title: test_multiprocessing: pickling failures
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  7 17:52:25 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 07 Apr 2010 15:52:25 +0000
Subject: [New-bugs-announce] [issue8334] winreg.QueryValue should return
	bytes, not unicode
In-Reply-To: <1270655545.35.0.413426657032.issue8334@psf.upfronthosting.co.za>
Message-ID: <1270655545.35.0.413426657032.issue8334@psf.upfronthosting.co.za>


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

The Windows RegQueryValue function returns a registry value without returning the corresponding type information (e.g., REG_SZ for string, REG_BINARY for binary data, REG_DWORD for a 32-bit number, etc.).

The corresponding wrapper winreg.QueryValue currently calls PyUnicode_FromUnicode on the return data, which is fine if the type happens to be REG_SZ, but gibberish for anything else.  Since the format of data is unknown, it should return a bytes object rather than a unicode object.

If the user wants a REG_SZ converted to the unicode type automatically, than can use winreg.QueryValueEx instead.  QueryValueEx wraps RegQueryValueEx which *does* return the type information of the underlying value.  QueryValueEx uses the type information to convert to an appropriate Python type if possible (or returns a bytes object for unsupported types).

----------
components: Library (Lib), Windows
messages: 102543
nosy: stutzbach
severity: normal
status: open
title: winreg.QueryValue should return bytes, not unicode
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Apr  7 19:54:02 2010
From: report at bugs.python.org (jan matejek)
Date: Wed, 07 Apr 2010 17:54:02 +0000
Subject: [New-bugs-announce] [issue8335] distutils test_build_ext's
	test_get_outputs fails in	bootstrap environment
In-Reply-To: <1270662842.61.0.49246293202.issue8335@psf.upfronthosting.co.za>
Message-ID: <1270662842.61.0.49246293202.issue8335@psf.upfronthosting.co.za>


New submission from jan matejek <jmatejek at suse.cz>:

when running testsuite in a clean environment without pre-installed system python, test_distutils fail in test_build_ext, test_get_outputs:
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: cannot find -lpython2.6
LinkError: command 'gcc' failed with exit status 1

full traceback is below.

this is most likely caused by change in r72637:
http://svn.python.org/view/python/branches/release26-maint/Lib/distutils/tests/test_build_ext.py?r1=72637&r2=72636&pathrev=72637
this changes compiler's working directory, so that it can no longer find libpython2.6.so with "-L."
(related to issue 6022 - the comments there point it out)

not sure about proper fix - personally, i don't care much about leaving one more file in builddir, whereas i do care about tests passing in clean env, so for SUSE i'm reverting r72637


full traceback:

test_distutils
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: cannot find -lpython2.6
collect2: ld returned 1 exit status
test test_distutils failed -- Traceback (most recent call last):
  File "/usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/tests/test_build_ext.py", line 261, in test_get_outputs
    cmd.run()
  File "/usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self.build_extension(ext)
  File "/usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/command/build_ext.py", line 531, in build_extension
    target_lang=language)
  File "/usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/ccompiler.py", line 769, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/usr/src/packages/BUILD/Python-2.6.5/Lib/distutils/unixccompiler.py", line 259, in link
    raise LinkError, msg
LinkError: command 'gcc' failed with exit status 1

----------
assignee: tarek
components: Distutils
messages: 102552
nosy: matejcik, tarek
severity: normal
status: open
title: distutils test_build_ext's test_get_outputs fails in bootstrap environment
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr  7 21:09:54 2010
From: report at bugs.python.org (Krauzi)
Date: Wed, 07 Apr 2010 19:09:54 +0000
Subject: [New-bugs-announce] [issue8336] PyObject_CallObject - Not
	"reference-count-neutral"
In-Reply-To: <1270667394.03.0.256734130503.issue8336@psf.upfronthosting.co.za>
Message-ID: <1270667394.03.0.256734130503.issue8336@psf.upfronthosting.co.za>


New submission from Krauzi <krauzi_gmbh at yahoo.de>:

In the docs there is written:
"PyObject_CallObject() is ?reference-count-neutral? with respect to its arguments."
This is not correct. Its only reference-count neutral if the call was SUCCESSFUL otherwise the argument is INCREFED! 
Can anyone confirm this?

Cheers Krauzi.

----------
assignee: georg.brandl
components: Documentation
messages: 102557
nosy: Krauzi, georg.brandl
severity: normal
status: open
title: PyObject_CallObject - Not "reference-count-neutral"
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr  7 21:10:35 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 07 Apr 2010 19:10:35 +0000
Subject: [New-bugs-announce] [issue8337] test_gdb fails on Sparc Ubuntu
In-Reply-To: <1270667435.08.0.757406826173.issue8337@psf.upfronthosting.co.za>
Message-ID: <1270667435.08.0.757406826173.issue8337@psf.upfronthosting.co.za>


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

test_gdb fails on Sparc-Ubuntu, e.g.

http://www.python.org/dev/buildbot/trunk/builders/sparc%20Ubuntu%20trunk/builds/45/steps/test/logs/stdio

test test_gdb failed -- Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 372, in test_corrupt_tp_name
    'set op->ob_type->tp_name=0xDEADBEEF')
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 341, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: '42'
Breakpoint 1 at 0x876a8: file Objects/object.c, line 330.
[Thread debugging using libthread_db enabled]

Breakpoint 1, PyObject_Print (op=42, fp=0x70300d38, flags=1)
    at Objects/object.c:330
330		return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=42, fp=0x70300d38, flags=1) at Objects/object.c:330
#1  0x000492f8 in file_PyObject_Print (op=42, f=0x70336098, flags=1)
    at Objects/fileobject.c:110
#2  0x00050774 in PyFile_WriteObject (v=42, f=<file at remote 0x70336098>, 
    flags=1) at Objects/fileobject.c:2470
#3  0x00120d98 in PyEval_EvalFrameEx (f=
    Frame 0x2ab788, for file <string>, line 1, in <module> (), throwflag=0)
    at Python/ceval.c:1769
#4  0x00129658 in PyEval_EvalCodeEx (co=0x70353c28, globals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=0x0, argcount=0, kws=0x0, kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#5  0x0011b99c in PyEval_EvalCode (co=0x70353c28, globals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:666
#6  0x0016c3c8 in run_mod (mod=0x2b1c38, filename=0x23d850 "<string>", globals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0xfff8d664, arena=0x2b69d0)
    at Python/pythonrun.c:1340
#7  0x0016c240 in PyRun_StringFlags (str=0x28c008 "print 42\n", start=257, 
    globals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x7032d508>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0xfff8d664) at Python/pythonrun.c:1303
#8  0x0016a494 in PyRun_SimpleStringFlags (command=0x28c008 "print 42\n", 
    flags=0xfff8d664) at Python/pythonrun.c:962
#9  0x0002190c in Py_Main (argc=4, argv=0xfff8d7e4) at Modules/main.c:536
#10 0x0001fe88 in main (argc=4, argv=0xfff8d7e4) at ./Modules/python.c:23


Because of these ongoing failures, I'm completely disabling the gdb tests for now.

----------
assignee: dmalcolm
keywords: buildbot
messages: 102558
nosy: dmalcolm, loewis
severity: normal
status: open
title: test_gdb fails on Sparc Ubuntu
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  7 23:06:02 2010
From: report at bugs.python.org (David W. Lambert)
Date: Wed, 07 Apr 2010 21:06:02 +0000
Subject: [New-bugs-announce] [issue8338] Outdated information
In-Reply-To: <1270674362.74.0.217445647634.issue8338@psf.upfronthosting.co.za>
Message-ID: <1270674362.74.0.217445647634.issue8338@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

http://docs.python.org/py3k/library/multiprocessing.html

Doc/library/multiprocessing.rst refers to "SimpleHTTPServer.HttpServer".  The patch changes this to "SimpleHTTPRequestHandler" although you may prefer "http.server.SimpleHTTPRequestHandler" or, of course, something entirely different.

Thanks, Dave.

----------
assignee: georg.brandl
components: Documentation
files: multiprocessing_docs.patch
keywords: patch
messages: 102567
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: Outdated information
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16807/multiprocessing_docs.patch

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

From report at bugs.python.org  Wed Apr  7 23:42:07 2010
From: report at bugs.python.org (Michael Glassford)
Date: Wed, 07 Apr 2010 21:42:07 +0000
Subject: [New-bugs-announce] [issue8339] urlunparse(urlparse('x://')) now
	returns 'x:' instead of	'x://'
In-Reply-To: <1270676527.4.0.372149513422.issue8339@psf.upfronthosting.co.za>
Message-ID: <1270676527.4.0.372149513422.issue8339@psf.upfronthosting.co.za>


New submission from Michael Glassford <glassfordmjg at gmail.com>:

An unfortunate side-effect of this change: 

http://svn.python.org/view/python/branches/release26-maint/Lib/urlparse.py?r1=66717&r2=78235

which was made to fix this issue: 

http://bugs.python.org/issue7904

is that urlparse.urlunparse(urlparse.urlparse('x://')) now returns 'x:' instead of 'x://', and urlparse.urlunparse(urlparse.urlparse('x:///y')) now returns 'x:/y' instead of 'x:///y'.

This behavior exists in at least Python 2.6 and 3.1, but not in 2.5.

----------
messages: 102569
nosy: Michael Glassford
severity: normal
status: open
title: urlunparse(urlparse('x://')) now returns 'x:' instead of 'x://'
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Thu Apr  8 01:22:59 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 07 Apr 2010 23:22:59 +0000
Subject: [New-bugs-announce] [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>


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

It looks like the bytearray documentation wasn't backported when the bytearray code was. See Doc/library/functions.rst

----------
assignee: georg.brandl
components: Documentation
messages: 102576
nosy: brian.curtin, georg.brandl
severity: normal
stage: needs patch
status: open
title: bytearray undocumented on trunk
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr  8 03:18:03 2010
From: report at bugs.python.org (David W. Lambert)
Date: Thu, 08 Apr 2010 01:18:03 +0000
Subject: [New-bugs-announce] [issue8341] sphinx bug?
In-Reply-To: <1270689483.48.0.0642742972458.issue8341@psf.upfronthosting.co.za>
Message-ID: <1270689483.48.0.0642742972458.issue8341@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

http://docs.python.org/py3k/library/multiprocessing.html

Indentation is incorrect as displayed and copied from google chrome browser:


 from multiprocessing import Process

def f(name):
    print('hello', name)

 if __name__ == '__main__':
     p = Process(target=f, args=('bob',))
     p.start()
     p.join()

----------
assignee: georg.brandl
components: Documentation
messages: 102583
nosy: LambertDW, georg.brandl
severity: normal
status: open
title: sphinx bug?
versions: Python 3.2

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

From report at bugs.python.org  Thu Apr  8 03:21:36 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 08 Apr 2010 01:21:36 +0000
Subject: [New-bugs-announce] [issue8342] Python fails to run if launched
	from NTFS symlink and DLL	not in PATH
In-Reply-To: <1270689696.22.0.100417980949.issue8342@psf.upfronthosting.co.za>
Message-ID: <1270689696.22.0.100417980949.issue8342@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

While trying to work out a failing test_platform.PlatformTest.test_architecture_via_symlink, I found a more fundamental problem.

In the build environment, python.exe depends on pythonXX.dll being in the same directory as sys.executable to load the interpreter. If Python is launched from an NTFS symlink, sys.executable may be located in a directory other than the DLL, and the interpreter fails to run (returning exit code 0xC0000135).

This may be expected behavior, but it causes test_architecture_via_symlink to fail once Python becomes aware of symlinks in Windows (sans cygwin).

It took me a while to track this down, so I wanted to be sure to document the behavior.

----------
components: Tests, Windows
messages: 102584
nosy: jaraco
severity: normal
status: open
title: Python fails to run if launched from NTFS symlink and DLL not in PATH
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Apr  8 10:52:11 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 08 Apr 2010 08:52:11 +0000
Subject: [New-bugs-announce] [issue8343] improve re parse error messages for
	named groups
In-Reply-To: <1270716731.5.0.82696133579.issue8343@psf.upfronthosting.co.za>
Message-ID: <1270716731.5.0.82696133579.issue8343@psf.upfronthosting.co.za>


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

sre_parse has some messages among repeated code sequences, but can be tweaked for user convenience

----------
components: Library (Lib)
files: lib.re.improve-error-message.diff
keywords: patch
messages: 102604
nosy: techtonik
severity: normal
status: open
title: improve re parse error messages for named groups
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16816/lib.re.improve-error-message.diff

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

From report at bugs.python.org  Thu Apr  8 11:45:13 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 08 Apr 2010 09:45:13 +0000
Subject: [New-bugs-announce] [issue8344] test_tag_configure fails on FreeBSD
In-Reply-To: <1270719913.05.0.699032461994.issue8344@psf.upfronthosting.co.za>
Message-ID: <1270719913.05.0.699032461994.issue8344@psf.upfronthosting.co.za>


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

The FreeBSD buildbot reports

FAIL: test_tag_configure (test_ttk.test_widgets.TreeviewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/trunk.bolen-freebsd7/build/Lib/lib-tk/test/test_ttk/test_widgets.py", line 1116, in test_tag_configure
    'blue')
AssertionError: <color object at 0x29715378> != 'blue'

----------
keywords: buildbot
messages: 102607
nosy: loewis
severity: normal
status: open
title: test_tag_configure fails on FreeBSD
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr  8 12:06:10 2010
From: report at bugs.python.org (Derk Drukker)
Date: Thu, 08 Apr 2010 10:06:10 +0000
Subject: [New-bugs-announce] [issue8345] missing method MatchObject.groups
	in re module doc
In-Reply-To: <1270721170.37.0.731757178416.issue8345@psf.upfronthosting.co.za>
Message-ID: <1270721170.37.0.731757178416.issue8345@psf.upfronthosting.co.za>


New submission from Derk Drukker <derk.drukker at gmail.com>:

The method MatchObject.groups disappeared from Doc/library/re.rst in py3k branch r79434 after a merge. (trunk, release26-maint, and release31-maint are fine.)

----------
assignee: georg.brandl
components: Documentation
messages: 102612
nosy: drukker, georg.brandl
severity: normal
status: open
title: missing method MatchObject.groups in re module doc
versions: Python 3.2

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

From report at bugs.python.org  Thu Apr  8 14:09:15 2010
From: report at bugs.python.org (Firat Ozgul)
Date: Thu, 08 Apr 2010 12:09:15 +0000
Subject: [New-bugs-announce] [issue8346] Old Version Name in Interactive Mode
In-Reply-To: <1270728555.35.0.913114676338.issue8346@psf.upfronthosting.co.za>
Message-ID: <1270728555.35.0.913114676338.issue8346@psf.upfronthosting.co.za>


New submission from Firat Ozgul <kistihza at yahoo.com>:

In Python 2.7a4 tutorial, under section "2.1 Invoking the Interpreter" set path command is "set path=%path%;C:\python26". Also under section "2.1.2 Interactive Mode" python command is shown to give "Python 2.6 (#1, Feb 28 2007, 00:02:06)"

----------
assignee: georg.brandl
components: Documentation
messages: 102615
nosy: georg.brandl, istihza
severity: normal
status: open
title: Old Version Name in Interactive Mode
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr  8 19:05:33 2010
From: report at bugs.python.org (Martin)
Date: Thu, 08 Apr 2010 17:05:33 +0000
Subject: [New-bugs-announce] [issue8347] string capitalize erroneously
	lower-case any non-first	letters
In-Reply-To: <1270746333.31.0.107951036323.issue8347@psf.upfronthosting.co.za>
Message-ID: <1270746333.31.0.107951036323.issue8347@psf.upfronthosting.co.za>


New submission from Martin <famart80 at gmail.com>:

When the following is run:
  s='the Los Angeles Symphony';
  s.capitalize();
it displays 'The los angeles symphony'
instead of 'The Los Angeles Symphony'

the str.capitalize() should only deal with the first letter, not lower-case the rest of the letters. The manual correctly describes this, but the actual behavior is not consistent with this description.

----------
components: None
messages: 102629
nosy: famart
severity: normal
status: open
title: string capitalize erroneously lower-case any non-first letters
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Apr  8 19:33:42 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 08 Apr 2010 17:33:42 +0000
Subject: [New-bugs-announce] [issue8348] test_urllib2net fails because of
	bad URL
In-Reply-To: <1270748022.01.0.642764123246.issue8348@psf.upfronthosting.co.za>
Message-ID: <1270748022.01.0.642764123246.issue8348@psf.upfronthosting.co.za>


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

Recently, test_urllib2net started failing

======================================================================
ERROR: test_ftp_basic (test.test_urllib2net.TimeoutTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_urllib2net.py", line 227, in test_ftp_basic
    u = _urlopen_with_retry(self.FTP_HOST)
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_urllib2net.py", line 24, in wrapped
    return _retry_thrice(func, exc, *args, **kwargs)
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_urllib2net.py", line 20, in _retry_thrice
    raise last_exc
URLError: <urlopen error ftp error: 550 Failed to change directory.>

Apparently, the directory /pub/mirror/gnu does not exist anymore.

----------
messages: 102633
nosy: doko, loewis
severity: normal
status: open
title: test_urllib2net fails because of bad URL

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

From report at bugs.python.org  Thu Apr  8 23:37:23 2010
From: report at bugs.python.org (Dan Brandow)
Date: Thu, 08 Apr 2010 21:37:23 +0000
Subject: [New-bugs-announce] [issue8349] os.environ.get returns incorrect
	data
In-Reply-To: <1270762643.12.0.684015717592.issue8349@psf.upfronthosting.co.za>
Message-ID: <1270762643.12.0.684015717592.issue8349@psf.upfronthosting.co.za>


New submission from Dan Brandow <dan.brandow at gmail.com>:

I have a Windows 7 64 bit machine, which means it has a few different environment variables concerning the program files location:
PROGRAMFILES=C:\Program Files (x86)
ProgramFiles(x86)=C:\Program Files (x86)

Note that both env variables have "(x86)" at the end.

When I do an os.environ.get I get the following results:

Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32
>>> import os
>>> print os.environ.get('ProgramFiles(x86)')
C:\Program Files (x86)
>>> print os.environ.get('PROGRAMFILES')
C:\Program Files
>>> print os.environ.get('ProgramFiles')
C:\Program Files
>>>

Note the missing "(x86)" on the last two test cases.

I tried it on the 64-bit version of 2.5.4 as well:

Python 2.5.4 (r254:67916, Dec 23 2008, 15:19:34) [MSC v.1400 64 bit (AMD64)] on win32
>>> import os
>>> print os.environ.get('ProgramFiles(x86)')
C:\Program Files (x86)
>>> print os.environ.get('PROGRAMFILES')
C:\Program Files
>>> print os.environ.get('ProgramFiles')
C:\Program Files
>>>

Same result.  So I tried the 32-bit version of 2.5.4:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
>>> import os
>>> print os.environ.get('ProgramFiles(x86)')
C:\Program Files (x86)
>>> print os.environ.get('PROGRAMFILES')
C:\Program Files (x86)
>>> print os.environ.get('ProgramFiles')
C:\Program Files (x86)
>>>

...which gave the correct strings...

----------
components: Extension Modules
messages: 102646
nosy: dbrandow
severity: normal
status: open
title: os.environ.get returns incorrect data
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  9 00:02:39 2010
From: report at bugs.python.org (Todd Whiteman)
Date: Thu, 08 Apr 2010 22:02:39 +0000
Subject: [New-bugs-announce] [issue8350] os.mkdir doc comment is incorrect
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>


New submission from Todd Whiteman <twhitema at yahoo.com.au>:

The doc command for os.mkdir is incorrect (at least for posix). It specifies that there is an optional mode keyword, but it's not a keyword argument, see below:

>>> import os
>>> help(os.mkdir)
mkdir(...)
    mkdir(path [, mode=0777])
    
    Create a directory.

>>> os.mkdir("/tmp/1", mode=777) 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: mkdir() takes no keyword arguments


Suggest the following doc comment change:

mkdir(...)
    mkdir(path [, mode])
    
    Create a directory. Mode defaults to 0777 if not specified.

----------
assignee: georg.brandl
components: Documentation
messages: 102648
nosy: georg.brandl, twhitema
severity: normal
status: open
title: os.mkdir doc comment is incorrect
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri Apr  9 01:36:44 2010
From: report at bugs.python.org (Floris Bruynooghe)
Date: Thu, 08 Apr 2010 23:36:44 +0000
Subject: [New-bugs-announce] [issue8351] Suppress large diffs
	in	unitttest.TestCase.assertSequenceEqual()
In-Reply-To: <1270769804.42.0.714910786313.issue8351@psf.upfronthosting.co.za>
Message-ID: <1270769804.42.0.714910786313.issue8351@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

This patch adds the ability to suppress large diffs in the failure message of TestCase.assertSequenceEqual().  The maximum size of the diff is customisable as an new keyword parameter with hopefully a sensible default.

----------
components: Library (Lib)
files: case_seq.diff
keywords: patch
messages: 102653
nosy: flub
severity: normal
status: open
title: Suppress large diffs in unitttest.TestCase.assertSequenceEqual()
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file16831/case_seq.diff

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

From report at bugs.python.org  Fri Apr  9 03:11:38 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 09 Apr 2010 01:11:38 +0000
Subject: [New-bugs-announce] [issue8352] imp.find_module of a .py ending dir
	causes glibc double	free crash
In-Reply-To: <1270775498.57.0.166335853456.issue8352@psf.upfronthosting.co.za>
Message-ID: <1270775498.57.0.166335853456.issue8352@psf.upfronthosting.co.za>


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

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

seen with 2.5.5, 2.6.5 and 2.7alpha4:

The imp.find_module function causes a glibc double free or corruption if
it would be invoked with a directory with a ".py" ending. It can be
reproduced with:

mkdir bla.py; python -c 'import imp; imp.find_module("bla", ["."])'

This causes bpython to crash after the first input char if such a
directory exist.


stacktrace with 2.6.5:
(gdb) bt
#0  0x00355906 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00358e05 in *__GI_abort () at abort.c:88
#2  0x0038c78d in __libc_message (do_abort=2, fmt=0x453088 "*** glibc detected *** %s: %s: 0x%s ***\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:173
#3  0x00396905 in malloc_printerr (action=2, str=0x453230 "double free or corruption (!prev)", ptr=
    0x83004e0) at malloc.c:6239
#4  0x003981a3 in _int_free (av=0x46f3c0, p=0x83004d8) at malloc.c:4772
#5  0x0039b22d in *__GI___libc_free (mem=0x83004e0) at malloc.c:3738
#6  0x00386b55 in _IO_new_fclose (fp=0x83004e0) at iofclose.c:88
#7  0x08116efc in call_find_module (name=0xb7f52a54 "bla", path=['.']) at ../Python/import.c:2844
#8  0x08117011 in imp_find_module (self=<unknown at remote 0x0>, args=('bla', ['.']))
    at ../Python/import.c:2865
#9  0x081b1755 in PyCFunction_Call (func=<builtin_function_or_method at remote 0xb7f3cc3c>, arg=
    ('bla', ['.']), kw=<unknown at remote 0x0>) at ../Objects/methodobject.c:81
#10 0x080fbf03 in call_function (pp_stack=0xbffff3cc, oparg=2) at ../Python/ceval.c:3750
#11 0x080f75ac in PyEval_EvalFrameEx (f=File <string>, line 1, in <module> (), throwflag=0)
    at ../Python/ceval.c:2412
#12 0x080f9c48 in PyEval_EvalCodeEx (co=0xb7fe6da8, globals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}, locals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, closure=<unknown at remote 0x0>) at ../Python/ceval.c:3000
#13 0x080efd6b in PyEval_EvalCode (co=0xb7fe6da8, globals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}, locals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}) at ../Python/ceval.c:541
#14 0x0812376c in run_mod (mod=0x83565c0, filename=0x81ef6b1 "<string>", globals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}, locals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}, flags=0xbffff6c0, arena=0x82f5700)
    at ../Python/pythonrun.c:1339
#15 0x08123640 in PyRun_StringFlags (str=0x82e5008 "import imp; imp.find_module(\"bla\", [\".\"])\n", 
    start=257, globals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}, locals=
    {'__builtins__': <module at remote 0xb7fb50c4>, '__name__': '__main__', '__package__': None, '__doc__': None, 'imp': <module at remote 0xb7fb5964>}, flags=0xbffff6c0) at ../Python/pythonrun.c:1302
#16 0x081223e9 in PyRun_SimpleStringFlags (command=
    0x82e5008 "import imp; imp.find_module(\"bla\", [\".\"])\n", flags=0xbffff6c0)
    at ../Python/pythonrun.c:961
#17 0x0805e3f6 in Py_Main (argc=3, argv=0xbffff7b4) at ../Modules/main.c:521
#18 0x0805d51f in main (argc=3, argv=0xbffff7b4) at ../Modules/python.c:23

----------
components: Interpreter Core
messages: 102662
nosy: doko
severity: normal
status: open
title: imp.find_module of a .py ending dir causes glibc double free crash
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Apr  9 07:57:25 2010
From: report at bugs.python.org (Chris Ward)
Date: Fri, 09 Apr 2010 05:57:25 +0000
Subject: [New-bugs-announce] [issue8353] Negative exponentiation behaving
	oddly in python shell
In-Reply-To: <1270792645.79.0.439452519354.issue8353@psf.upfronthosting.co.za>
Message-ID: <1270792645.79.0.439452519354.issue8353@psf.upfronthosting.co.za>


New submission from Chris Ward <cwardusc at gmail.com>:

When using exponentiation interactively in the python shell, it returns all negative results when a negative number is the input. For example:

-4 ** 2 will return -16
-4 ** 2 should evaluate as -4 * -4, which correctly returns 16

This does not occur when using the 'Run Module' feature of IDLE and the exponentiation is processed from the module, it only seems to occur when directly typed into the interactive prompt. I couldn't find anything to suggest this is expected behavior. Using pow() from the prompt returns the correct result, so it only happens in this one situation. Obviously this is low priority since it only affects the prompt and there's a working alternative, but I figured I'd report it anyways. :)

----------
components: IDLE
messages: 102681
nosy: CWardUSC
severity: normal
status: open
title: Negative exponentiation behaving oddly in python shell
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri Apr  9 08:50:37 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Fri, 09 Apr 2010 06:50:37 +0000
Subject: [New-bugs-announce] [issue8354] siginterrupt with flag=False is
	reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>


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

The effect of signal.siginterrupt(somesig, False) is reset the first time a that signal is received.  This is not the documented behaviour, and I do not think this is a desireable behaviour.  It renders siginterrupt effectively useless at providing the robustness against EINTR it is intended to provide.

Attached is a fairly simple program to show this using SIGWINCH: run it in a resizeable terminal, and resize it twice.  Notice that on the second terminal resize (i.e. the second SIGWINCH signal) the program crashes with an EINTR from the os.read.

A partial workaround for the problem is to call signal.siginterrupt(somesig, False) again inside your signal handler, but it's very fragile.  It depends on Python getting a chance to run the Python function registered by the signal.signal call, but this is not guaranteed.  If there's frequent IO, that workaround might suffice.  For the sig-test.py example attached to this bug, it doesn't (try it).

The cause seems to be that signal_handler in signalmodule.c unconditionally does PyOS_setsig(sig_num, signal_handler) [except for SIGCHLD], which unconditionally invokes siginterrupt(sig, 1).  A possible fix would be to add a 'int siginterrupt_flag;' to the Handlers array, and arrange for that value to be passed instead of the hard-coded 1.  Another might be to not call PyOS_setsig from signal_handler at all -- I'm not sure why it is trying to reinstall itself, but perhaps there's some issue there I'm not aware of.

----------
components: Library (Lib)
files: sig-test.py
messages: 102688
nosy: spiv
severity: normal
status: open
title: siginterrupt with flag=False is reset when signal received
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16837/sig-test.py

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

From report at bugs.python.org  Fri Apr  9 10:54:25 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 09 Apr 2010 08:54:25 +0000
Subject: [New-bugs-announce] [issue8355] diff.py produce unified format by
	default
In-Reply-To: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>
Message-ID: <1270803265.38.0.592538535243.issue8355@psf.upfronthosting.co.za>


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

Script/diff.py default context diff format is outdated. It makes sense to produce unified diff by default.

----------
components: Demos and Tools
messages: 102701
nosy: techtonik
severity: normal
status: open
title: diff.py produce unified format by default
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Apr  9 13:00:44 2010
From: report at bugs.python.org (Martin Zimmermann)
Date: Fri, 09 Apr 2010 11:00:44 +0000
Subject: [New-bugs-announce] [issue8356] SyntaxError: integer assignment
	with leading zeros (only	8 and 9)
In-Reply-To: <1270810844.03.0.603411749549.issue8356@psf.upfronthosting.co.za>
Message-ID: <1270810844.03.0.603411749549.issue8356@psf.upfronthosting.co.za>


New submission from Martin Zimmermann <info at posativ.org>:

try this:
x = (05, 06, 07)
y = (08, 09, 019)

you will get SyntaxError: invalid token.
(also in python 2.5.2)

----------
components: Interpreter Core
messages: 102706
nosy: posativ
severity: normal
status: open
title: SyntaxError: integer assignment with leading zeros (only 8 and 9)
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  9 17:15:17 2010
From: report at bugs.python.org (Tim Kersten)
Date: Fri, 09 Apr 2010 15:15:17 +0000
Subject: [New-bugs-announce] [issue8357] distutils does not allow
	installation with --root and	--prefix,
	and give's incorrect error message
In-Reply-To: <1270826117.06.0.843410920049.issue8357@psf.upfronthosting.co.za>
Message-ID: <1270826117.06.0.843410920049.issue8357@psf.upfronthosting.co.za>


New submission from Tim Kersten <tim.kersten at lincor.com>:

$ python setup.py install --root=/tmp/ --prefix=/usr
running install
error: must supply either home or prefix/exec-prefix -- not both

I believe that this should work. --root and --prefix are, from what I can tell, two unrelated options.

----------
assignee: tarek
components: Distutils
messages: 102724
nosy: tarek, timkersten
severity: normal
status: open
title: distutils does not allow installation with --root and --prefix, and give's incorrect error message
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Fri Apr  9 19:09:50 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 09 Apr 2010 17:09:50 +0000
Subject: [New-bugs-announce] [issue8358] absolute_import future directive
	ignored by 2to3
In-Reply-To: <1270832990.09.0.0431237155361.issue8358@psf.upfronthosting.co.za>
Message-ID: <1270832990.09.0.0431237155361.issue8358@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

I'm using Python 3.1.2 64-bit on Windows.

I've found that even if "absolute_import" is imported from __future__, 2to3 will convert imports to be treated as relative.

To demonstrate this behavior, I created a small package "abs_imp_test" (attached).

abs_imp_test.__init__ is 0 bytes.
abs_imp_test.string is a one-line file.
  foo = 'bar'
abs_imp_test.main contains 4 lines:
  from __future__ import absolute_import
  import string
  assert not hasattr(string, 'foo'), 'fail'
  print("success")

Put abs_imp_test package somewhere in the python path (just having it relative to current directory works).

Note that the code is designed to be future-proof (using the future directive), so will run under Python 2.6 and Python 3.1 without errors.

> python26\python -c "from abs_imp_test import main"
success
> python31\python -c "from abs_imp_test import main"
success

However, if I run 2to3 on main, it converts "import string" to "from . import string" which changes the fundamental meaning of the import and breaks the test.

> 2to3 abs_import_test
...
RefactoringTool: Files that were modified:
RefactoringTool: abs_imp_test\main.py

> python -c "from abs_imp_test import main"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "abs_imp_test\main.py", line 4, in <module>
    assert not hasattr(string, 'foo'), "fail"
AssertionError: fail

Is it possible that if the absolute_import future directive is present that the imports not be modified for relativity?

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: abs_imp_test.zip
messages: 102733
nosy: jaraco
severity: normal
status: open
title: absolute_import future directive ignored by 2to3
versions: Python 3.1
Added file: http://bugs.python.org/file16846/abs_imp_test.zip

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

From report at bugs.python.org  Sat Apr 10 11:37:59 2010
From: report at bugs.python.org (=?utf-8?b?2LnYqNiv2KfZhNmE2Ycg2LTZhNmKIChBYmRlbGxhaCBDaGVsbGkp?=)
Date: Sat, 10 Apr 2010 09:37:59 +0000
Subject: [New-bugs-announce] [issue8359] % formating - TypeError: not all
	arguments converted	during string formatting
In-Reply-To: <1270892279.77.0.4172116449.issue8359@psf.upfronthosting.co.za>
Message-ID: <1270892279.77.0.4172116449.issue8359@psf.upfronthosting.co.za>


New submission from ??????? ??? (Abdellah Chelli) <sneetsher at gmail.com>:

c/printf accepts this:

n=1;
printf("One hour.", n);

in other hand python/print rises an error:

n=1
print "One hour." % n

Exactly the % formatting operation.
(TypeError: not all arguments converted during string formatting)

This feature is very important when we come to I18n (translation using gettext).

As most translator don't know this work around "%i hour." or "(%i) One hour.". This is not correct for many languages as I know like Arabic where they should write some thing like "One hour." or "An hour.".

https://bugs.launchpad.net/python/+bug/341015

Could this fixed to have same behaviour as in c? More robust.

----------
components: Interpreter Core
messages: 102764
nosy: sneetsher
severity: normal
status: open
title: % formating - TypeError: not all arguments converted during string formatting
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Sat Apr 10 12:41:46 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 10 Apr 2010 10:41:46 +0000
Subject: [New-bugs-announce] [issue8360] doc: unittest.skipTest method added
	in 2.7
Message-ID: <1270896106.71.0.804820199929.issue8360@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
assignee: georg.brandl
components: Documentation
files: doc.python-version-for-skiptest.diff
keywords: patch
nosy: georg.brandl, techtonik
severity: normal
status: open
title: doc: unittest.skipTest method added in 2.7
versions: Python 2.7
Added file: http://bugs.python.org/file16851/doc.python-version-for-skiptest.diff

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

From report at bugs.python.org  Sat Apr 10 13:41:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Apr 2010 11:41:25 +0000
Subject: [New-bugs-announce] [issue8361] Remove assert in
	functools.total_ordering
In-Reply-To: <1270899685.49.0.0758628614803.issue8361@psf.upfronthosting.co.za>
Message-ID: <1270899685.49.0.0758628614803.issue8361@psf.upfronthosting.co.za>


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

Hello

The correct behavior of functools.total_ordering depends on a check performed with an assert. Attached patch changes it to a test that always runs.

Since it?s a kind of protocol error, I went for TypeError but you may disagree.

Regards

----------
components: Library (Lib)
files: remove-assert-in-total_ordering.diff
keywords: patch
messages: 102770
nosy: merwok, rhettinger
severity: normal
status: open
title: Remove assert in functools.total_ordering
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16852/remove-assert-in-total_ordering.diff

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

From report at bugs.python.org  Sat Apr 10 14:14:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Apr 2010 12:14:39 +0000
Subject: [New-bugs-announce] [issue8362] Add Misc/maintainers.rst to 2.x
	branch
In-Reply-To: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>
Message-ID: <1270901679.67.0.500277129776.issue8362@psf.upfronthosting.co.za>


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

Hello

The maintainers listing is helpful for us outside bug reporters, but only present in the py3k branch. I copied it and reverted module name changes. Attached is the resulting file and the diff against py3k.

Regards

----------
assignee: georg.brandl
components: Documentation
files: maintainers.rst
messages: 102772
nosy: georg.brandl, merwok, r.david.murray
severity: normal
status: open
title: Add Misc/maintainers.rst to 2.x branch
versions: Python 2.7
Added file: http://bugs.python.org/file16853/maintainers.rst

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

From report at bugs.python.org  Sat Apr 10 15:13:14 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 10 Apr 2010 13:13:14 +0000
Subject: [New-bugs-announce] [issue8363] Lots of duplicate code between
	test_classify_oldstyle and	test_classify_newstyle in test_inspect.py
In-Reply-To: <1270905194.18.0.8131280541.issue8363@psf.upfronthosting.co.za>
Message-ID: <1270905194.18.0.8131280541.issue8363@psf.upfronthosting.co.za>


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

There are two tests for the way inspect.classify_class_attrs handles various sorts of attributes.  The tests are identical, except one uses a classic class and one a new-style class.  The tests sources have actually begun to diverge, but so far only in whitespace.  This code will be easier to maintain (not to mention shorter) if there is just one copy of the actual test parts.

----------
assignee: exarkun
components: Library (Lib), Tests
keywords: needs review, patch
messages: 102776
nosy: exarkun
severity: normal
status: open
title: Lots of duplicate code between test_classify_oldstyle and test_classify_newstyle in test_inspect.py
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 10 15:15:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Apr 2010 13:15:42 +0000
Subject: [New-bugs-announce] [issue8364] Update site.setquit docstring
In-Reply-To: <1270905342.7.0.63449376457.issue8364@psf.upfronthosting.co.za>
Message-ID: <1270905342.7.0.63449376457.issue8364@psf.upfronthosting.co.za>


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

Hello

The docstring for site.setquit was not updated when  r42948 changed quit and exit from strings to callables. Attached patch fixes it.

By the way, is ?Library? the right component for docstring-related bugs or is it ?Documentation??

Regards

----------
components: Library (Lib)
messages: 102777
nosy: merwok
severity: normal
status: open
title: Update site.setquit docstring
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Apr 11 04:21:19 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 11 Apr 2010 02:21:19 +0000
Subject: [New-bugs-announce] [issue8365] 'readline' module fails to build on
	OS X - some recent	change broke it
In-Reply-To: <1270952479.32.0.785527713521.issue8365@psf.upfronthosting.co.za>
Message-ID: <1270952479.32.0.785527713521.issue8365@psf.upfronthosting.co.za>


New submission from Shashwat Anand <anand.shashwat at gmail.com>:

'readline' module fails to build on OS X  in case of trunk and python 3.x. It have no issues with python 2.5 and 2.6 and python 2.7 alpha.

Here is the trace after running ./configure; make in trunk

Python build finished, but the necessary bits to build these modules were not found:
bsddb185           dl                 gdbm            
imageop            linuxaudiodev      ossaudiodev     
readline           spwd               sunaudiodev  

With that the uparrow-downarrow and other features fails which I suppose depends on 'readline'

07:31:51 l0nwlf-MBP:python-svn $ ./python.exe 
Python 2.7b1+ (trunk:79945M, Apr 11 2010, 07:14:54) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> t = 'test'      
>>> ^[[A^[[A^[[B^[[B

07:32:53 l0nwlf-MBP:CoreHD $ python3.2
Python 3.2a0 (py3k:79532, Apr  1 2010, 01:48:52) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named readline
>>> t = 'test'
>>> ^[[A^[[A

(pressing up-arrow for repeating the previous command fails)

However, an interesting observation is, 

07:34:00 l0nwlf-MBP:CoreHD $ python2.7
Python 2.7a4+ (trunk:78750, Mar  7 2010, 08:09:00) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
>>> t = 'test'
>>> t = 'test'
 
No such issue here, 'uparrow' is working, thereby completing the previous command on interpretor. The version is python2.7 alpha as you can see. So I assume some recent changes broke something, it was fine earlier.

----------
components: Build
messages: 102807
nosy: l0nwlf, ronaldoussoren
severity: normal
status: open
title: 'readline' module fails to build on OS X - some recent change broke it
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Apr 11 08:46:40 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Apr 2010 06:46:40 +0000
Subject: [New-bugs-announce] [issue8366] OS X universal builds fail on 2.7b1
	and py3k with "Don't	know machine value for archs"
In-Reply-To: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>
Message-ID: <1270968400.64.0.539813943684.issue8366@psf.upfronthosting.co.za>


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

Prior to r79392 (trunk) and r79401 (py3k), the changes introduced for Issue8211, the gcc lines produced for an OS X universal build, say

./configure --enable-universalsdk --with-universal-archs=32-bit ; make

might look like this:

gcc-4.0 -c -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -fno-common -dynamic -DNDEBUG -g -O3 -I/tmp/_py/libraries/usr/local/include  -I. -IInclude -I/private/tmp/_t/Include -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -DPy_BUILD_CORE -o Modules/python.o /private/tmp/_t/Modules/python.c

With the changes introduced by r79392 and r79401 to save and restore the original value of CFLAGS across the AC_PROG_CC macro call (see trunk configure.in at about line 496), the same gcc call now looks like this:

gcc-4.0 -c -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -fno-common -dynamic -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -DNDEBUG -g -O3 -I/tmp/_py/libraries/usr/local/include  -I. -IInclude -I/private/tmp/_t/Include -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -DPy_BUILD_CORE -o Modules/python.o /private/tmp/_t/Modules/python.c

Note that there are now two sets of -arch and -sysroot flags because the CFLAGS ones were being lost before but are now preserved.  While the duplicate flags do not seem to bother gcc and friends, the code in sysconfig.py to determine the machine name for OS X is not prepared to handle them and the build fails when the interpreter starts up:

Traceback (most recent call last):
  File "/private/tmp/_t/Lib/site.py", line 542, in <module>
    main()
  File "/private/tmp/_t/Lib/site.py", line 521, in main
    addbuilddir()
  File "/private/tmp/_t/Lib/site.py", line 118, in addbuilddir
    s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
  File "/private/tmp/_t/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

----------
assignee: ronaldoussoren
components: Macintosh
messages: 102810
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: OS X universal builds fail on 2.7b1 and py3k with "Don't know machine value for archs"
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Apr 11 12:07:50 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 11 Apr 2010 10:07:50 +0000
Subject: [New-bugs-announce] [issue8367] test_winsound: failure on systems
	without soundcard
In-Reply-To: <1270980470.8.0.919577975963.issue8367@psf.upfronthosting.co.za>
Message-ID: <1270980470.8.0.919577975963.issue8367@psf.upfronthosting.co.za>


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

Got this test failure on Windows/qemu:

======================================================================
FAIL: test_stopasync (__main__.PlaySoundTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_winsound.py", line 199, in test_stopasync
    None, winsound.SND_PURGE
AssertionError: RuntimeError not raised


The problem is that PlaySound(None, winsound.SND_PURGE) does not
raise on systems without a soundcard. The wrapped C function returns
success in this case, so I think it's ok to go along with it and
disable this assertion.

----------
messages: 102821
nosy: skrah
severity: normal
status: open
title: test_winsound: failure on systems without soundcard

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

From report at bugs.python.org  Sun Apr 11 15:32:16 2010
From: report at bugs.python.org (Krauzi)
Date: Sun, 11 Apr 2010 13:32:16 +0000
Subject: [New-bugs-announce] [issue8368] Memory leak on multi-threaded
	PyObject_CallObject
In-Reply-To: <1270992736.41.0.985730063076.issue8368@psf.upfronthosting.co.za>
Message-ID: <1270992736.41.0.985730063076.issue8368@psf.upfronthosting.co.za>


New submission from Krauzi <krauzi_gmbh at yahoo.de>:

Hi guys, i think this is a bug and Matt from help at python.org suggested me to report it here:
I attached a sample project where the memory leak occurs.I created a sample project where the memory leak occurs.
It's a visual studio 2008 project and uses windows threads so you have to recompile when using linux (makefile not included). 500 thread calls result in a memory leak of about 1 MB.

----------
files: Python Bug.zip
messages: 102832
nosy: Krauzi
severity: normal
status: open
title: Memory leak on multi-threaded PyObject_CallObject
versions: Python 2.6
Added file: http://bugs.python.org/file16868/Python Bug.zip

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

From report at bugs.python.org  Sun Apr 11 16:17:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 14:17:06 +0000
Subject: [New-bugs-announce] [issue8369] Add a lint command to distutils
In-Reply-To: <1270995426.89.0.712440512698.issue8369@psf.upfronthosting.co.za>
Message-ID: <1270995426.89.0.712440512698.issue8369@psf.upfronthosting.co.za>


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

Add a command to run lint tools such as Python -3, pep8, pyflakes, pychecker, pylint.

I think this should not be a subcommand of test.

The idea comes from buildutils (http://pypi.python.org/pypi/buildutils/).

----------
assignee: tarek
components: Distutils2
messages: 102834
nosy: merwok, tarek
severity: normal
status: open
title: Add a lint command to distutils
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr 11 17:00:42 2010
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 11 Apr 2010 15:00:42 +0000
Subject: [New-bugs-announce] [issue8370] change module "builtins" to
	"__builtin__" in __import__	documentation
In-Reply-To: <1270998042.37.0.434397625456.issue8370@psf.upfronthosting.co.za>
Message-ID: <1270998042.37.0.434397625456.issue8370@psf.upfronthosting.co.za>


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

The "builtins" module referenced in the Python 2.6 __import__ documentation does not seem to exist in Python 2.6:

http://docs.python.org/library/functions.html#__import__

These should probably be changed to __builtin__:

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

----------
messages: 102841
nosy: cjerdonek
severity: normal
status: open
title: change module "builtins" to "__builtin__" in __import__ documentation
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Apr 11 18:50:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Apr 2010 16:50:31 +0000
Subject: [New-bugs-announce] [issue8371] Add a command to download
	distributions
In-Reply-To: <1271004631.29.0.0742687502668.issue8371@psf.upfronthosting.co.za>
Message-ID: <1271004631.29.0.0742687502668.issue8371@psf.upfronthosting.co.za>


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

Distutils2 should have a command responsible for downloading distributions. This would factor it out of other code in one clear location and allow users to download for later installation.

If setup.cfg files grow options for extras, test-requires, build-requires and such specific kinds of dependencies, matching options would appear on the download (or get) command.

Side note: Is it okay to post this as a bug or should I rather mail distutils-sig first? Or mail them now?

Regards

----------
assignee: tarek
components: Distutils2
messages: 102853
nosy: merwok, tarek
severity: normal
status: open
title: Add a command to download distributions
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr 11 20:33:05 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 11 Apr 2010 18:33:05 +0000
Subject: [New-bugs-announce] [issue8372] socket: Buffer overrun while
	reading unterminated AF_UNIX	addresses
In-Reply-To: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>
Message-ID: <1271010785.16.0.286802399648.issue8372@psf.upfronthosting.co.za>


New submission from David Watson <baikie at users.sourceforge.net>:

The makesockaddr() function in the socket module assumes that
AF_UNIX addresses have a null-terminated sun_path, but Linux
actually allows unterminated addresses using all 108 bytes of
sun_path (for normal filesystem sockets, that is, not just
abstract addresses).

When receiving such an address (e.g. in accept() from a
connecting peer), makesockaddr() will run past the end and return
extraneous bytes from the stack, or fail because they can't be
decoded, or perhaps segfault in extreme cases.

This can't currently be tested from within Python as Python also
refuses to accept address arguments which would fill the whole of
sun_path, but the attached linux-pass-unterminated.diff (for 2.x
and 3.x) enables them for Linux.  With the patch applied:

Python 2.7a4+ (trunk, Apr  8 2010, 18:20:28) 
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> s = socket.socket(socket.AF_UNIX)
>>> s.bind("a" * 108)
>>> s.getsockname()
'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\xfa\xbf\xa8)\xfa\xbf\xec\x15\n\x08l\xaaY\xb7\xb8CZ\xb7'
>>> len(_)
126

Also attached are some unit tests for use with the above patch, a
couple of C programs for checking OS behaviour (you can also see
the bug by doing accept() in Python and using the bindconn
program), and patches aimed at fixing the problem.

Firstly, the return-unterminated-* patches make makesockaddr()
scan sun_path for the first null byte as before (if it's not a
Linux abstract address), but now stop at the end of the structure
as indicated by the addrlen argument.

However, there's one more catch before this will work on Linux,
which is that Linux system calls return the length of the address
they *would* have stored in the structure had there been room for
it, which in this case is one byte longer than the official size
of a sockaddr_un structure, due to the missing null terminator.

The addrlen-* patches handle this by always calling
makesockaddr() with the actual buffer size if it is less than the
returned length.  This silently ignores any truncation, but I'm
not sure how to do anything sensible about that, and some
operating systems (e.g. FreeBSD) just silently truncate the
address anyway and don't return the original length (POSIX
doesn't make clear which, if either, behaviour is required).
Once these patches are applied, the tests pass.

There is one other issue: the patches for 3.x retain the
assumption that socket paths are in UTF-8, but they should
actually be handled according to PEP 383.  I've got a patch for
that, but I'll open a separate issue for it since the handling of
the Linux abstract namespace isn't documented and there's some
slightly unobvious behaviour that people might be depending on.

----------
components: Extension Modules
files: linux-pass-unterminated.diff
keywords: patch
messages: 102861
nosy: baikie
severity: normal
status: open
title: socket: Buffer overrun while reading unterminated AF_UNIX addresses
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/file16874/linux-pass-unterminated.diff

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

From report at bugs.python.org  Sun Apr 11 20:45:28 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 11 Apr 2010 18:45:28 +0000
Subject: [New-bugs-announce] [issue8373] socket: AF_UNIX socket paths not
	handled according to PEP	383
In-Reply-To: <1271011528.87.0.0855011916856.issue8373@psf.upfronthosting.co.za>
Message-ID: <1271011528.87.0.0855011916856.issue8373@psf.upfronthosting.co.za>


New submission from David Watson <baikie at users.sourceforge.net>:

In 3.x, the socket module assumes that AF_UNIX addresses use
UTF-8 encoding - this means, for example, that accept() will
raise UnicodeDecodeError if the peer socket path is not valid
UTF-8, which could crash an unwary server.

Python 3.1.2 (r312:79147, Mar 23 2010, 19:02:21) 
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from socket import *
>>> s = socket(AF_UNIX, SOCK_STREAM)
>>> s.bind(b"\xff")
>>> s.getsockname()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 0: unexpected code byte

I'm attaching a patch to handle socket paths according to PEP
383.  Normally this would use PyUnicode_FSConverter, but there
are a couple of ways in which the address handling currently
differs from normal filename handling.

One is that embedded null bytes are passed through to the system
instead of being rejected, which is needed for the Linux abstract
namespace.  These abstract addresses are returned as bytes
objects, but they can currently be specified as strings with
embedded null characters as well.  The patch preserves this
behaviour.

The current code also accepts read-only buffer objects (it uses
the "s#" format), so in order to accept these as well as
bytearray filenames (which the posix module accepts), the patch
simply accepts any single-segment buffer, read-only or not.

This patch applies on top of the patches I submitted for issue
#8372 (rather than knowingly running past the end of sun_path).

----------
components: Extension Modules
files: af_unix-pep383.diff
keywords: patch
messages: 102865
nosy: baikie
severity: normal
status: open
title: socket: AF_UNIX socket paths not handled according to PEP 383
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16881/af_unix-pep383.diff

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

From report at bugs.python.org  Sun Apr 11 23:20:24 2010
From: report at bugs.python.org (Luke Jennings)
Date: Sun, 11 Apr 2010 21:20:24 +0000
Subject: [New-bugs-announce] [issue8374] Some locales are unsupported
In-Reply-To: <1271020824.21.0.72658096394.issue8374@psf.upfronthosting.co.za>
Message-ID: <1271020824.21.0.72658096394.issue8374@psf.upfronthosting.co.za>


New submission from Luke Jennings <ubuntujenkins at googlemail.com>:

In the locale module there are some locales that are not supported these the ones that I am aware of are nl_AW, sr_RS sr_ME. This information was due to a project that captures screenshots in different languages and we have to retrieve the language code. Related to the origin of the bug https://bugs.edge.launchpad.net/quickshot/+bug/554861 .

If any more information is required please let me know.

----------
components: Extension Modules
messages: 102891
nosy: ubuntujenkins
severity: normal
status: open
title: Some locales are unsupported
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Apr 12 01:03:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Apr 2010 23:03:01 +0000
Subject: [New-bugs-announce] [issue8375] test_distutils fails when run with
	-j
In-Reply-To: <1271026981.38.0.880810451818.issue8375@psf.upfronthosting.co.za>
Message-ID: <1271026981.38.0.880810451818.issue8375@psf.upfronthosting.co.za>


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

test_distutils fails in py3k when run with -j (e.g. 
"python -m test.regrtest -j1 -v test_distutils")


======================================================================
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmpyn8Vpj'

======================================================================
ERROR: test_check_extensions_list (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmp4r36LO'

======================================================================
ERROR: test_compiler_deprecation_warning (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmpGz62QC'

======================================================================
ERROR: test_compiler_option (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmpUoqcH9'

======================================================================
ERROR: test_ext_fullpath (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmpqHPvDG'

======================================================================
ERROR: test_finalize_options (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmp2WXDKn'

======================================================================
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmp_kkj2U'

======================================================================
ERROR: test_get_source_files (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmp13Y9c9'

======================================================================
ERROR: test_optional_extension (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmp6f6ENV'

======================================================================
ERROR: test_solaris_enable_shared (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmpNXs6vs'

======================================================================
ERROR: test_user_site (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_build_ext.py", line 61, in tearDown
    super(BuildExtTestCase, self).tearDown()
  File "/home/antoine/py3k/__svn__/Lib/distutils/tests/support.py", line 66, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 243, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/py3k/__svn__/Lib/shutil.py", line 241, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '/tmp/tmpDcrnD8'

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

----------
assignee: tarek
components: Distutils
messages: 102908
nosy: pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_distutils fails when run with -j
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Apr 12 08:35:58 2010
From: report at bugs.python.org (Anders Kaseorg)
Date: Mon, 12 Apr 2010 06:35:58 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue8376=5D_Tutorial_offers_dan?=
 =?utf-8?b?Z2Vyb3VzIGFkdmljZSBhYm91dCBpdGVyYXRvcnM6IOKAnF9faXRlcl9fKCkg?=
 =?utf-8?q?can_just_return_self=E2=80=9D?=
In-Reply-To: <1271054158.9.0.672918640444.issue8376@psf.upfronthosting.co.za>
Message-ID: <1271054158.9.0.672918640444.issue8376@psf.upfronthosting.co.za>


New submission from Anders Kaseorg <andersk at mit.edu>:

The Python tutorial offers some dangerous advice about adding iterator behavior to a class:
http://docs.python.org/tutorial/classes.html#iterators
?By now you have probably noticed that most container objects can be looped over using a for statement:
?
Having seen the mechanics behind the iterator protocol, it is easy to add iterator behavior to your classes. Define a __iter__() method which returns an object with a next() method. If the class defines next(), then __iter__() can just return self:?

This is reasonable advice for writing an iterator class, but terrible advice for writing a container class, because it encourages you to associate a single iterator with the container, which breaks nested iteration and leads to hard-to-find bugs.  (One of those bugs recently made its way into the code handout for a problem set in MIT?s introductory CS course, 6.00.)

A container class?s __iter__() should return a generator or an instance of a separate iterator class, not self.  The tutorial should make this clearer.

----------
assignee: georg.brandl
components: Documentation
messages: 102918
nosy: andersk, georg.brandl
severity: normal
status: open
title: Tutorial offers dangerous advice about iterators: ?__iter__() can just return self?

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

From report at bugs.python.org  Mon Apr 12 11:11:45 2010
From: report at bugs.python.org (Jatin Sanghvi)
Date: Mon, 12 Apr 2010 09:11:45 +0000
Subject: [New-bugs-announce] [issue8377] Errata
	on	page:http://docs.python.org/library/stdtypes.html
In-Reply-To: <1271063505.25.0.821351537014.issue8377@psf.upfronthosting.co.za>
Message-ID: <1271063505.25.0.821351537014.issue8377@psf.upfronthosting.co.za>


New submission from Jatin Sanghvi <jatin085 at gmail.com>:

Open link: http://docs.python.org/library/stdtypes.html

The statement:

If i or j is negative, the index is relative to the end of the string: len(s) + i or len(s) + j is substituted.

is incorrect, should be:

If i or j is negative, the index is relative to the end of the string: len(s) - i or len(s) - j is substituted.

----------
assignee: georg.brandl
components: Documentation
messages: 102927
nosy: georg.brandl, jatin085
severity: normal
status: open
title: Errata on page:http://docs.python.org/library/stdtypes.html
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Apr 12 14:49:11 2010
From: report at bugs.python.org (John Van Praag)
Date: Mon, 12 Apr 2010 12:49:11 +0000
Subject: [New-bugs-announce] [issue8378] PYTHONSTARTUP broken on Windows
In-Reply-To: <1271076551.49.0.597917544476.issue8378@psf.upfronthosting.co.za>
Message-ID: <1271076551.49.0.597917544476.issue8378@psf.upfronthosting.co.za>


New submission from John Van Praag <john at jvp247.com>:

The PYTHONSTARTUP environment variable does not work--does not import the indicated startup file--when IDLE is started under Windows. I have tested under Windows XP SP2, and under Windows Vista Ultimate 64 bit.

The os.environ variable does list the startup file, but IDLE fails to run it.

----------
messages: 102943
nosy: jvanpraag
severity: normal
status: open
title: PYTHONSTARTUP broken on Windows
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Apr 12 23:34:07 2010
From: report at bugs.python.org (Andy Friesen)
Date: Mon, 12 Apr 2010 21:34:07 +0000
Subject: [New-bugs-announce] [issue8379] if __debug__: has nonobvious
	behaviour when evaluating	.pyo without -O
In-Reply-To: <1271108047.08.0.236449263776.issue8379@psf.upfronthosting.co.za>
Message-ID: <1271108047.08.0.236449263776.issue8379@psf.upfronthosting.co.za>


New submission from Andy Friesen <andy at imvu.com>:

In certain circumstances, "if __debug__" seems to be evaluating its "else" clause even when -O is not specified.  This can cause very  surprising behavior.

a.zip contains a single file named a/__init__.pyo.  It is the compiled form of the following code:

    if __debug__:
        print 'DEBUG'
    else:
        print 'RELEASE'
        if __debug__ == True:
            raise Exception("this is impossible")

pythonbug.py evaluates this script with the following:

    import sys
    sys.path = ['a.zip']
    import a

When using Windows Python 2.6.2 and 2.6.5, running pythonbug.py produces this output:

    RELEASE
    Traceback (most recent call last):
      File "pythonbug.py", line 3, in <module>
        import a
      File "__init__.py", line 8, in <module>
        raise Exception("this is impossible")
    Exception: this is impossible

When -O is passed, the exception is not raised.

My best guess is that the Python bytecode is optimizing the "if __debug__" test away in the produced .pyo, but does not actually affect the value of __debug__ or check more complex expressions involving __debug__.

----------
files: pythonbug.zip
messages: 102975
nosy: afriesen
severity: normal
status: open
title: if __debug__: has nonobvious behaviour when evaluating .pyo without -O
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16901/pythonbug.zip

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

From report at bugs.python.org  Tue Apr 13 00:09:33 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 12 Apr 2010 22:09:33 +0000
Subject: [New-bugs-announce] [issue8380] Port of the gdb7 debugging hooks to
	the "py3k" branch
In-Reply-To: <1271110173.15.0.608430881051.issue8380@psf.upfronthosting.co.za>
Message-ID: <1271110173.15.0.608430881051.issue8380@psf.upfronthosting.co.za>


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

I'm attaching a patch for the py3k branch to port the gdb hooks to Python 3.

The libpython.py code installed to python-gdb.py "knows" about the internal details of the Python within the tree.  This patch makes the necessary changes to that code for the internals of Python 3, rather than Python 2.

Note that libpython.py is intended to run inside a gdb linked against libpython2, and so libpython.py is still Python 2 code; however I've updated it to expect the so-called "inferior process" to be Python 3:
* Py_TPFLAGS_STRING_SUBCLASS becomes Py_TPFLAGS_BYTES_SUBCLASS
* PyStringObjectPtr becomes PyBytesObjectPtr
* change PyObjectPtr to correctly locate "ob_size": with Python 2 variable-sized subclasses we could simply look it up as a field of the subclass struct, but for Python 3 the field may be in an ob_base member, or in an ob_base.ob_base member.  We have to cast to a PyVarObject* to find it
* PyIntObject went away; PyBoolObject is now a subclass of PyLongObject
* writing out frames needed a slight rewrite with the change from co_filename and co_name from PyStringObject* to PyUnicodeObject*

This makes the "proxy values" concept a bit awkward; for example a "str" in the inferior Python 3 process looks like a "unicode" to the gdb Python 2 process.  This and the int->long change required a lot of minor updating to expected values in the selftests.

The test_gdb.py and gdb_sample.py code _are_ for Python 3.  I've assumed that all output is in UTF-8 for now.

For Python 2, I was testing the code by putting a breakpoint on PyObject_Print, and printing objects, as a convenient hook for scraping gdb's stdout.

PyObject_Print still exists in Python 3, but isn't used by the "print" implementation, so I needed a handy function that I could put a breakpoint on, and invoke from the Python side: I looked for something with METH_O that isn't called by site.py and doesn't require an import.  I chose the "id" builtin, which corresponds to Python/ceval.c:builtin_id ()

Some minor 2to3-style fixes were also needed in the test code

All of the selftests are currently commented out to keep the buildbot clean (apparently from a merge from trunk), and I've kept them commented out.  They all pass on my machine with:
  make -j4 ; ./python -Wd ./Lib/test/regrtest.py -v test_gdb

This also contains a port of the (partial?) fix for issue 8330 from trunk's r79986 that doesn't seem to have been merged to py3k (it needed a fair amount of rewriting).

----------
assignee: loewis
components: Demos and Tools
files: port-gdb7-hooks-to-py3k.patch
keywords: patch
messages: 102980
nosy: dmalcolm, loewis
severity: normal
stage: patch review
status: open
title: Port of the gdb7 debugging hooks to the "py3k" branch
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file16902/port-gdb7-hooks-to-py3k.patch

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

From report at bugs.python.org  Tue Apr 13 00:48:48 2010
From: report at bugs.python.org (Aaron)
Date: Mon, 12 Apr 2010 22:48:48 +0000
Subject: [New-bugs-announce] [issue8381] New Window Error
In-Reply-To: <1271112528.95.0.966124391171.issue8381@psf.upfronthosting.co.za>
Message-ID: <1271112528.95.0.966124391171.issue8381@psf.upfronthosting.co.za>


New submission from Aaron <aaron.the.cow at gmail.com>:

When ever I try to open a new window or open a saved file in the IDLE (on a mac) it freezes. I am running snow leppord on a very new mac.

----------
components: IDLE
messages: 102987
nosy: aaron.the.cow
severity: normal
status: open
title: New Window Error
type: crash

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

From report at bugs.python.org  Tue Apr 13 01:56:53 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 12 Apr 2010 23:56:53 +0000
Subject: [New-bugs-announce] [issue8382] cStringIO and StringIO doesn't
	behave the same way
In-Reply-To: <1271116613.01.0.381000084861.issue8382@psf.upfronthosting.co.za>
Message-ID: <1271116613.01.0.381000084861.issue8382@psf.upfronthosting.co.za>


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

Looks like the python version of StringIO can write tuples, but not the C version. I am not sure this is intended:

>>> from cStringIO import StringIO as cStringIO
>>> from StringIO import StringIO as StringIO
>>> string = StringIO()
>>> string.write(('my', 'tuple'))
>>> cstring = cStringIO()
>>> cstring.write(('my', 'tuple'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: write() argument 1 must be string or read-only character buffer, not tuple

----------
components: Library (Lib)
messages: 102991
nosy: tarek
severity: normal
status: open
title: cStringIO and StringIO doesn't behave the same way
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Apr 13 02:39:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 00:39:57 +0000
Subject: [New-bugs-announce] [issue8383] pickle is unable to encode unicode
	surrogates
In-Reply-To: <1271119197.6.0.824303125234.issue8383@psf.upfronthosting.co.za>
Message-ID: <1271119197.6.0.824303125234.issue8383@psf.upfronthosting.co.za>


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

Python3 uses unicode surrogates to store undecodable filenames. Eg. the filename b"abc\xff.py" is encoded as "abc\xdcff.py" if the file system encoding is ASCII. Pickle is unable to store them:

./python -c 'import pickle; pickle.dumps("abc\udcff")'
(...)
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 20: surrogates not allowed

This is a limitation of pickle (in the binary mode): Python accepts to store any unicode character, but pickle doesn't.

Using "surrogatepass" error handler should be enough to fix this issue.

Related issue: #3672 (Reject surrogates in utf-8 codec) -> r72208 creates "surrogatepass" error handler.

----------
components: Library (Lib)
messages: 102996
nosy: haypo, lemburg, loewis
severity: normal
status: open
title: pickle is unable to encode unicode surrogates
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Apr 13 03:15:38 2010
From: report at bugs.python.org (Craig McQueen)
Date: Tue, 13 Apr 2010 01:15:38 +0000
Subject: [New-bugs-announce] [issue8384] Distutils C extension build with
	MinGW on Windows fails
In-Reply-To: <1271121338.06.0.379239271673.issue8384@psf.upfronthosting.co.za>
Message-ID: <1271121338.06.0.379239271673.issue8384@psf.upfronthosting.co.za>


New submission from Craig McQueen <python at craig.mcqueen.id.au>:

I tried to build a C extension in Python 3.1.2.

    \Python31\python.exe setup.py build --compiler=mingw32

I got a stack-trace:

...
  File "C:\Python31\lib\distutils\cygwinccompiler.py", line 280, in __init__
    CygwinCCompiler.__init__ (self, verbose, dry_run, force)
  File "C:\Python31\lib\distutils\cygwinccompiler.py", line 124, in __init__
    if self.ld_version >= "2.10.90":
TypeError: unorderable types: NoneType() >= str()

This is Windows 2000 SP4, with MinGW 5.1.6.

----------
assignee: tarek
components: Distutils
messages: 103000
nosy: cmcqueen1975, tarek
severity: normal
status: open
title: Distutils C extension build with MinGW on Windows fails
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Tue Apr 13 14:21:01 2010
From: report at bugs.python.org (Tim Golden)
Date: Tue, 13 Apr 2010 12:21:01 +0000
Subject: [New-bugs-announce] [issue8385] _winreg remaining in test_winsound
In-Reply-To: <1271161261.72.0.0289506148873.issue8385@psf.upfronthosting.co.za>
Message-ID: <1271161261.72.0.0289506148873.issue8385@psf.upfronthosting.co.za>


New submission from Tim Golden <mail at timgolden.me.uk>:

There is a reference to _winreg left in test_winsound. Trivial patch attached renames this to winreg.

----------
components: Tests
files: test_winsound.patch
keywords: patch
messages: 103042
nosy: tim.golden
severity: normal
status: open
title: _winreg remaining in test_winsound
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file16908/test_winsound.patch

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

From report at bugs.python.org  Tue Apr 13 15:04:26 2010
From: report at bugs.python.org (Tim Golden)
Date: Tue, 13 Apr 2010 13:04:26 +0000
Subject: [New-bugs-announce] [issue8386] test_pickle failing
In-Reply-To: <4BC46BD2.2070102@timgolden.me.uk>
Message-ID: <4BC46BD2.2070102@timgolden.me.uk>


New submission from Tim Golden <mail at timgolden.me.uk>:

test_pickle failing on WinXP

http://svn.python.org/projects/python/branches/py3k/Lib r80044

======================================================================
ERROR: test_unicode (__main__.CPicklerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "test\pickletester.py", line 523, in test_unicode
     p = self.dumps(u, proto)
   File "C:\work_in_progress\make-snapshots\branches\py3k\python\Lib\test\test_pickle.py", line 30, in dumps
     p.dump(arg)
UnicodeEncodeError: 'utf-8' codec can't encode character '\udc80' in position 1: surrogates not allowed

======================================================================
ERROR: test_unicode (__main__.CDumpPickle_LoadPickle)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "test\pickletester.py", line 523, in test_unicode
     p = self.dumps(u, proto)
   File "C:\work_in_progress\make-snapshots\branches\py3k\python\Lib\test\test_pickle.py", line 30, in dumps
     p.dump(arg)
UnicodeEncodeError: 'utf-8' codec can't encode character '\udc80' in position 1: surrogates not allowed

======================================================================
ERROR: test_unicode (__main__.DumpPickle_CLoadPickle)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "test\pickletester.py", line 524, in test_unicode
     u2 = self.loads(p)
   File "C:\work_in_progress\make-snapshots\branches\py3k\python\Lib\test\test_pickle.py", line 37, in loads
     return u.load()
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1-3: illegal encoding

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

----------
messages: 103045
nosy: tim.golden
severity: normal
status: open
title: test_pickle failing

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

From report at bugs.python.org  Tue Apr 13 23:11:26 2010
From: report at bugs.python.org (sfinnie)
Date: Tue, 13 Apr 2010 21:11:26 +0000
Subject: [New-bugs-announce] [issue8387] use universal newline mode in csv
	module examples
In-Reply-To: <1271193086.18.0.201846291594.issue8387@psf.upfronthosting.co.za>
Message-ID: <1271193086.18.0.201846291594.issue8387@psf.upfronthosting.co.za>


New submission from sfinnie <scott.finnie at gmail.com>:

Running the examples in the csv module docs (http://docs.python.org/library/csv.html) causes problems reading file on a mac.  This is highlighted in issue 1072404 (http://bugs.python.org/issue1072404).

Commentary on the bug indicates a no fix, meaning most/many people using a mac will get an error if they use the sample code in the docs.

A simpler solution would be to use universal newline mode in the doc examples.  This is actually mentioned in commentary on the bug, and appears to work.

Proposal
--------
In all example code blocks, use mode 'rU' when opening the file.  1st code block, for example, would become:

spamReader = csv.reader(open('eggs.csv', 'rU'), delimiter=' ', quotechar='|')

That should solve the problem on mac without impacting compatibility on other operating systems.  Note: Haven't been able to verify this on other platforms.

----------
assignee: georg.brandl
components: Documentation
messages: 103086
nosy: georg.brandl, sfinnie
severity: normal
status: open
title: use universal newline mode in csv module examples
type: feature request
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Apr 14 01:01:54 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 13 Apr 2010 23:01:54 +0000
Subject: [New-bugs-announce] [issue8388] None shouldn't be passed to
	traceback.format_exception
In-Reply-To: <1271199714.1.0.812266738214.issue8388@psf.upfronthosting.co.za>
Message-ID: <1271199714.1.0.812266738214.issue8388@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

When porting recent unittest patches to py3k, I encountered a failure in testBufferOutputAddErrorOrFailure. The reason is that the test passes None to traceback.format_exception, which works by accident in 2.x.

I added these lines in _exc_info_to_string to fix it:
            chain = exctype is not None
            msgLines = traceback.format_exception(exctype, value, tb,
                                                  chain=chain)

It would be nice if the nice didn't have to rely on that behavior and that hack could be removed.

----------
assignee: michael.foord
components: Library (Lib)
messages: 103089
nosy: benjamin.peterson, michael.foord
priority: normal
severity: normal
status: open
title: None shouldn't be passed to traceback.format_exception
versions: Python 3.2

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

From report at bugs.python.org  Wed Apr 14 01:19:18 2010
From: report at bugs.python.org (Torsten Landschoff)
Date: Tue, 13 Apr 2010 23:19:18 +0000
Subject: [New-bugs-announce] [issue8389] Incomprehensibly import error
In-Reply-To: <1271200758.32.0.654156615612.issue8389@psf.upfronthosting.co.za>
Message-ID: <1271200758.32.0.654156615612.issue8389@psf.upfronthosting.co.za>


New submission from Torsten Landschoff <t.landschoff at gmx.net>:

I ran into an ImportError I was unable to explain:

$ python -c "import a.b"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "a/b/__init__.py", line 1, in <module>
    import a.b.c
  File "a/b/c.py", line 2, in <module>
    import a.b.t as t
AttributeError: 'module' object has no attribute 'b'

This is the source code:
$ tail `find -name \*.py`
==> ./demo.py <==
import a.b

==> ./a/__init__.py <==

==> ./a/b/c.py <==
# Does not work:
import a.b.t as t
# Works:
# import a.b
# from a.b import t

==> ./a/b/t.py <==

==> ./a/b/__init__.py <==
import a.b.c
# Works:
# import a.b.t

Replacing any import with one of the versions annotated as working fixes it. Stripping another level from the package tree fixes it as well. Why!?

----------
components: Interpreter Core
files: import_error.tar.gz
messages: 103091
nosy: torsten
severity: normal
status: open
title: Incomprehensibly import error
versions: Python 2.6
Added file: http://bugs.python.org/file16915/import_error.tar.gz

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

From report at bugs.python.org  Wed Apr 14 01:53:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Apr 2010 23:53:15 +0000
Subject: [New-bugs-announce] [issue8390] tarfile: use surrogates for
	undecode fields
In-Reply-To: <1271202795.91.0.928981298967.issue8390@psf.upfronthosting.co.za>
Message-ID: <1271202795.91.0.928981298967.issue8390@psf.upfronthosting.co.za>


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

When reading a tar archive, tarfile decodes fields using "replace" error handler by default. The result is that we loose informations if there is an undecodable character.

Since the PEP 383, undecodable filenames are stored using surrogates in Python3. I think that it's a good idea to use surrogates for tar, because it's a common problem to have undecodable data in a tar archive (see the unicode section of the tarfile documentation).

----------
components: Library (Lib), Unicode
files: tarfile_surrogates.patch
keywords: patch
messages: 103099
nosy: haypo, loewis
severity: normal
status: open
title: tarfile: use surrogates for undecode fields
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16917/tarfile_surrogates.patch

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

From report at bugs.python.org  Wed Apr 14 02:01:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 00:01:38 +0000
Subject: [New-bugs-announce] [issue8391] os.execvpe() doesn't support
	surrogates in env
In-Reply-To: <1271203298.02.0.466898460687.issue8391@psf.upfronthosting.co.za>
Message-ID: <1271203298.02.0.466898460687.issue8391@psf.upfronthosting.co.za>


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

It would be nice to support the PEP 383 (surrogateescape) for environment variables in os.execvpe(). Attached patch uses PyUnicode_AsEncodedString(val, Py_FileSystemDefaultEncoding, "surrogateescape") to encode an environment variable value.

I'm not sure that PyUnicode_AsEncodedString(val, Py_FileSystemDefaultEncoding, "surrogateescape") does always return a PyBytes object.

I not patched environment keys, but it might be useful.

----------
components: Library (Lib), Unicode
files: os_execvpe_surrogates.patch
keywords: patch
messages: 103100
nosy: haypo
severity: normal
status: open
title: os.execvpe() doesn't support surrogates in env
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16918/os_execvpe_surrogates.patch

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

From report at bugs.python.org  Wed Apr 14 02:03:32 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 14 Apr 2010 00:03:32 +0000
Subject: [New-bugs-announce] [issue8392] unit tests rather light on testing
	__import__(..., level)
In-Reply-To: <1271203412.15.0.504789215632.issue8392@psf.upfronthosting.co.za>
Message-ID: <1271203412.15.0.504789215632.issue8392@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

At work we are in the process of migrating from Python 2.4 to 2.6.  One
bit of Boost.Python code needs to use PyImport_ImportModuleLevel which
references the __import__ docs.  That describes the use of the level arg.
I then went around looking for examples and didn't find much, certainly not in the Lib/test directory.  I only saw a couple examples which used
level and they both use level=0, so don't test relative imports or
level=-1.

I don't know that I have enough knowledge of how this stuff is supposed
to work, but will give it a shot.

----------
assignee: skip.montanaro
components: Tests
messages: 103102
nosy: skip.montanaro
priority: normal
severity: normal
stage: unit test needed
status: open
title: unit tests rather light on testing __import__(..., level)
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Apr 14 02:55:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 00:55:24 +0000
Subject: [New-bugs-announce] [issue8393] subprocess: support undecodable
	current working directory	on POSIX OS
In-Reply-To: <1271206524.05.0.157551650648.issue8393@psf.upfronthosting.co.za>
Message-ID: <1271206524.05.0.157551650648.issue8393@psf.upfronthosting.co.za>


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

In py3k, subprocess uses _posixsubprocess.fork_exec() function. This function uses surrogateescape error handler for most arguments, but not for the current working directory (cwd).

Attached patch uses PyUnicode_FSConverter() as done for other arguments. I don't know if PyUnicode_FSConverter() result is always a PyBytes, so I added an assertion. It should be fixed.

----------
components: Library (Lib), Windows
files: posixsubprocess_cwd.patch
keywords: patch
messages: 103105
nosy: haypo
severity: normal
status: open
title: subprocess: support undecodable current working directory on POSIX OS
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16920/posixsubprocess_cwd.patch

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

From report at bugs.python.org  Wed Apr 14 03:16:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Apr 2010 01:16:20 +0000
Subject: [New-bugs-announce] [issue8394] ctypes.dlopen() doesn't support
	surrogates
In-Reply-To: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>
Message-ID: <1271207780.68.0.724544413479.issue8394@psf.upfronthosting.co.za>


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

The PEP 383 introduces filename using surrogates. ctypes.dlopen() support them. ctypes.cdll.LoadLibrary('libc\uDCff.so.6') fails with:

   UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' 
   in position 4: surrogates not allowed

Attached patch fixes this issue.

TODO: Remove the assert(PyBytes_Check(name2)). I don't know if PyUnicode_FSConverter() does always return a PyBytes object or not.

----------
components: Library (Lib), Unicode
files: ctypes_dlopen_surrogates.patch
keywords: patch
messages: 103108
nosy: haypo
severity: normal
status: open
title: ctypes.dlopen() doesn't support surrogates
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16921/ctypes_dlopen_surrogates.patch

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

From report at bugs.python.org  Wed Apr 14 06:29:28 2010
From: report at bugs.python.org (Ray.Allen)
Date: Wed, 14 Apr 2010 04:29:28 +0000
Subject: [New-bugs-announce] [issue8395] shutil.copytree() add a copy_func
	parameter.
In-Reply-To: <1271219368.33.0.150416464623.issue8395@psf.upfronthosting.co.za>
Message-ID: <1271219368.33.0.150416464623.issue8395@psf.upfronthosting.co.za>


New submission from Ray.Allen <ysj.ray at gmail.com>:

The shutil.copytree() function copies the whole tree recursively, and copy one single regular file with copy2(). I hope it can be more powerful(), that is, allow specifying a customerized copy function, rather than copy2(). To be specific, add an optional keyword argument, named "copy_func" or something like, default to copy2.

It will be useful for doing some customerized filesystem tree copying.

For example, when writing something like the project install script, or update script, which need to ignore some file while copying the whole directory, or changing ".ini" file after copying, or rename the file name after copying. All the specific copy action can be done in our customerized copy function instead of copy2().

Is there anybody who has the same feature request? Or is there some other module already provides the same functionality?

If so, I can provide a patch for it.

Thanks!

----------
components: Library (Lib)
messages: 103111
nosy: ysj.ray
severity: normal
status: open
title: shutil.copytree() add a copy_func parameter.
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Apr 14 11:50:03 2010
From: report at bugs.python.org (Parth Malwankar)
Date: Wed, 14 Apr 2010 09:50:03 +0000
Subject: [New-bugs-announce] [issue8396] tarfile.open does fails with
	UnicodeDecodeError if parent	dir is unicode
In-Reply-To: <1271238603.95.0.608393654552.issue8396@psf.upfronthosting.co.za>
Message-ID: <1271238603.95.0.608393654552.issue8396@psf.upfronthosting.co.za>


New submission from Parth Malwankar <parth.malwankar at gmail.com>:

If any directory higher up in the hierarchy contains unicode chars, tarfile.open fails with UnicodeDecodeError. Attached script reproduces this error.

[tmp]% python tarfilefail.py 
Traceback (most recent call last):
  File "tarfilefail.py", line 9, in <module>
    tarfile.open(file_name, 'w')
  File "/usr/lib/python2.6/tarfile.py", line 1682, in open
    return cls.taropen(name, mode, fileobj, **kwargs)
  File "/usr/lib/python2.6/tarfile.py", line 1692, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python2.6/tarfile.py", line 1527, in __init__
    self.name = os.path.abspath(name) if name else None
  File "/usr/lib/python2.6/posixpath.py", line 338, in abspath
    path = join(os.getcwd(), path)
  File "/usr/lib/python2.6/posixpath.py", line 70, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 17: ordinal not in range(128)
[tmp]%

----------
files: tarfilefail.py
messages: 103117
nosy: parthm
severity: normal
status: open
title: tarfile.open does fails with UnicodeDecodeError if parent dir is unicode
versions: Python 2.6
Added file: http://bugs.python.org/file16922/tarfilefail.py

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

From report at bugs.python.org  Wed Apr 14 15:01:16 2010
From: report at bugs.python.org (Alex Stapleton)
Date: Wed, 14 Apr 2010 13:01:16 +0000
Subject: [New-bugs-announce] [issue8397] BZ2File doesn't protect against
	mixed iterator and read	usage
In-Reply-To: <1271250076.58.0.0616490142802.issue8397@psf.upfronthosting.co.za>
Message-ID: <1271250076.58.0.0616490142802.issue8397@psf.upfronthosting.co.za>


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

Normal files throw exceptions if you mix methods.

>>> f = open("words")
>>> for l in f:
...     break
... 
>>> f.tell()
8192L
>>> f.readline()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Mixing iteration and read methods would lose data



BZ2Files silently do the wrong thing. (Output is a coincidence. Honest!)

>>> import bz2
>>> f = bz2.BZ2File("words.bz2")
>>> for l in f:
...     break
... 
>>> f.tell()
8192L
>>> f.readline()
'lose\n'


Expected behaviour is for it to throw a ValueError like normal file objects.

----------
components: None
messages: 103126
nosy: Alex.Stapleton
severity: normal
status: open
title: BZ2File doesn't protect against mixed iterator and read usage
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Wed Apr 14 15:15:01 2010
From: report at bugs.python.org (marco stamazza)
Date: Wed, 14 Apr 2010 13:15:01 +0000
Subject: [New-bugs-announce] [issue8398] Modules with a dot in the filename
	don't load
In-Reply-To: <1271250901.88.0.682481223536.issue8398@psf.upfronthosting.co.za>
Message-ID: <1271250901.88.0.682481223536.issue8398@psf.upfronthosting.co.za>


New submission from marco stamazza <giunghi at gmail.com>:

On my windows Xp system running Python 2.6 (from the (x,y) package) I tried to load a module named "GetMy.com_MOD.py". I kept receiving the error 
Traceback (most recent call last):
  File "D:\Docs\Futures-Strategy\StCHF\Test\GetMy.com_2.py", line 6, in <module>
    import GetMy.com_MOD
ImportError: No module named GetMy.com_MOD

Until I removed the dot renaming it to GetMycom_MOD.py, which works very nicely. Maybe the search should be smart enough to look for the last word after a dot to determine if the module exists or not?

Many thanks guys, Python rocks. marco

----------
components: Interpreter Core
messages: 103127
nosy: giunghi
severity: normal
status: open
title: Modules with a dot in the filename don't load
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr 14 15:26:04 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 14 Apr 2010 13:26:04 +0000
Subject: [New-bugs-announce] [issue8399] Document os.open
In-Reply-To: <1271251564.41.0.889317623766.issue8399@psf.upfronthosting.co.za>
Message-ID: <1271251564.41.0.889317623766.issue8399@psf.upfronthosting.co.za>


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

Need to document the that os.O_BINARY flag is obligatory for cross-platform behavior of os.open() on Windows. By default os.open() opens file as binary on Unix, but as text on Windows.


See also issue2028 for discussion of making os.O_BINARY default on py3k. I can reopen this issue.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 103128
nosy: georg.brandl, techtonik
severity: normal
status: open
title: Document os.open
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Apr 14 17:20:42 2010
From: report at bugs.python.org (Karen Tracey)
Date: Wed, 14 Apr 2010 15:20:42 +0000
Subject: [New-bugs-announce] [issue8400] zipimporter find_module fullname
	mis-documented
In-Reply-To: <1271258442.34.0.660774695694.issue8400@psf.upfronthosting.co.za>
Message-ID: <1271258442.34.0.660774695694.issue8400@psf.upfronthosting.co.za>


New submission from Karen Tracey <kmtracey at gmail.com>:

The fullname parameter to zipimporter find_module is documented to be a "fully qualified (dotted) module name". (From http://docs.python.org/library/zipimport.html#zipimport.zipimporter.find_module.) However, passing a fully-qualified dotted module appears to never work. Rather it appears that you must use the file system path separator instead of dots. For example on Windows:

C:\>echo %pythonpath%
\tmp\blah-1.0-py2.6.egg

C:\>python
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from blah.models import speak
>>> speak.__file__
'C:\\tmp\\blah-1.0-py2.6.egg\\blah\\models\\speak.pyc'
>>> speak.sayhi()
Hi from blah.models.speak sayhi function.

The egg has top-level blah package and under it models, it appears to work fine for normal use.  But zipimport zipimporter find_module won't find the models sub-module using dotted path notation:

>>> import sys
>>> sys.path[1]
'C:\\tmp\\blah-1.0-py2.6.egg'
>>> import zipimport
>>> zi = zipimport.zipimporter(sys.path[1])
>>> zi.find_module('blah')
<zipimporter object "C:\tmp\blah-1.0-py2.6.egg">
>>> zi.find_module('blah.models')
>>> zi.find_module('blah/models')
>>> zi.find_module('blah\\models')
<zipimporter object "C:\tmp\blah-1.0-py2.6.egg">
>>>

On Linux, the 'blah/models' version is the one that works.

Tested as far back as Python2.3 and as far forward as 2.7a3.

----------
messages: 103132
nosy: kmtracey
severity: normal
status: open
title: zipimporter find_module fullname mis-documented
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Apr 14 17:41:50 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Wed, 14 Apr 2010 15:41:50 +0000
Subject: [New-bugs-announce] [issue8401] Strange behavior of bytearray slice
	assignment
In-Reply-To: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>
Message-ID: <1271259710.42.0.373058487219.issue8401@psf.upfronthosting.co.za>


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

>>> a = bytearray()
>>> a[:] = 0 # Is it a feature?
>>> a
bytearray(b'')
>>> a[:] = 10 # If so, why not document it?
>>> a
bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
>>> a[:] = -1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: negative count
>>> a[:] = -1000000000000000000000 # This should raise ValueError, not TypeError.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable
>>> a[:] = 1000000000000000000
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError
>>> a[:] = 1000000000000000000000 # This should raise OverflowError, not TypeError.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable
>>> a[:] = [] # Are some empty sequences better than others?
>>> a[:] = ()
>>> a[:] = list("")
>>> a[:] = ""
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: string argument without an encoding

----------
components: Interpreter Core
messages: 103133
nosy: abacabadabacaba
severity: normal
status: open
title: Strange behavior of bytearray slice assignment
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu Apr 15 02:51:27 2010
From: report at bugs.python.org (george hu)
Date: Thu, 15 Apr 2010 00:51:27 +0000
Subject: [New-bugs-announce] [issue8402] glob returns empty list with "["
	character in the folder	name
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>


New submission from george hu <geohuz at gmail.com>:

Have this problem in python 2.5.4 under windows. 
I'm trying to return a list of files in a directory by using glob. It keeps returning a empty list until I tested/adjusted folder name by removing "[" character from it. Not sure if this is a bug.

glob.glob("c:\abc\afolderwith[test]\*") returns empty list
glob.glob("c:\abc\afolderwithtest]\*") returns files

----------
messages: 103160
nosy: george.hu
severity: normal
status: open
title: glob returns empty list with "[" character in the folder name
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Apr 15 03:00:03 2010
From: report at bugs.python.org (ivank)
Date: Thu, 15 Apr 2010 01:00:03 +0000
Subject: [New-bugs-announce] [issue8403] dis.dis gives different results if
	Ctrl-C is pressed
In-Reply-To: <1271293203.08.0.221458450606.issue8403@psf.upfronthosting.co.za>
Message-ID: <1271293203.08.0.221458450606.issue8403@psf.upfronthosting.co.za>


New submission from ivank <ivan at ludios.org>:

If you run
>>> dis.dis(lambda: 99**1000003)
and press Ctrl-C immediately, you'll see the numbers without constant folding:
  1           0 LOAD_CONST               1 (99)
              3 LOAD_CONST               2 (1000003)
              6 BINARY_POWER        
              7 RETURN_VALUE        

If you wait long enough instead (don't press Ctrl-C), you'll see a very big number.

It seems strange to do two different things. Perhaps the KeyboardInterrupt should be rethrown instead?

----------
components: Library (Lib)
messages: 103161
nosy: ivank
severity: normal
status: open
title: dis.dis gives different results if Ctrl-C is pressed
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Apr 15 03:23:48 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 15 Apr 2010 01:23:48 +0000
Subject: [New-bugs-announce] [issue8404] Set operations don't work for
	dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

The examples of set operations in http://docs.python.org/dev/library/stdtypes#dictionary-view-objects don't work in the current 2.7 trunk:

-> ./python.exe
Python 2.7b1+ (trunk:80084:80085M, Apr 14 2010, 21:17:06) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> dishes = {'eggs': 2, 'sausage': 1, 'bacon': 1, 'spam': 500}
>>> keys = dishes.viewkeys()
>>> keys & {'eggs', 'bacon', 'salad'}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for &: 'dict_keys' and 'set'
>>> keys | {'eggs'}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for |: 'dict_keys' and 'set'

Is this a documentation bug, and set operations are only supported in 3.x?  Or does the code need to be fixed?

(Assigned to Alexandre, since he committed the backport patch; please feel free to reassign.  Marking as release blocker; if it's a documentation bug, we can lower the priority.)

----------
assignee: alexandre.vassalotti
messages: 103166
nosy: akuchling, alexandre.vassalotti
priority: release blocker
severity: normal
status: open
title: Set operations don't work for dictionary views
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 15 04:42:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 15 Apr 2010 02:42:02 +0000
Subject: [New-bugs-announce] [issue8405] Improve test_os._kill (failing on
	slow machines)
In-Reply-To: <1271299322.61.0.635546677584.issue8405@psf.upfronthosting.co.za>
Message-ID: <1271299322.61.0.635546677584.issue8405@psf.upfronthosting.co.za>


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

test_os._kill is used by test_kill_sigterm and test_kill_int and is failing on a slow Windows buildbot due to timing issues between the process starting and the signal being sent. I've checked in a few small time.sleep hacks in the meantime to see if that would help the bot, but I'd like to get a solid fix in there.

The attached patch adds a loop to the test function to see that even if the subprocess doesn't respond right away, it will have a few chances to respond and run the test. If the expected message isn't piped from the subprocess after 5 retries, the test fails.

----------
assignee: brian.curtin
components: Library (Lib), Windows
files: fix_test_os.diff
keywords: patch
messages: 103179
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: Improve test_os._kill (failing on slow machines)
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16928/fix_test_os.diff

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

From report at bugs.python.org  Thu Apr 15 05:12:32 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 15 Apr 2010 03:12:32 +0000
Subject: [New-bugs-announce] [issue8406] Make some setup.py paths
	exclude-able
In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za>
Message-ID: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

The topic of the vileness of Fink or MacPorts came up in python-dev when
discussing building a Mac installer.  I remembered that a couple /sw and
/opt/local directories are searched unconditionally, making it a bit
more challenging for someone to create a framework build which didn't
rely on one or the other.

The attached makes the addition of /sw/... or /opt/local/... directory
searches conditional on the presence of /sw/bin or /opt/local/bin in
PATH.  I don't have more time to expand upon the concept more, but it
might also be useful to exclude other platform-dependent optional
directories from searching (such as /opt/sfw for Solaris).

----------
components: Build
messages: 103181
nosy: skip.montanaro
severity: normal
status: open
title: Make some setup.py paths exclude-able
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 15 07:00:39 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 15 Apr 2010 05:00:39 +0000
Subject: [New-bugs-announce] [issue8407] expose signalfd(2) and
	sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>


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

Linux offers the signalfd syscall since 2.6.22 (with minor changes afterwards).  This call allows signals to be handled as bytes read out of a file descriptor, rather than as interruptions to the flow of a program.  Quite usefully, this file descriptor can be select()'d on (or poll()'d, epoll()'d, etc) alongside other "normal" file descriptors.

In order to effectively use signalfd(), the signals in question must be blocked, though.  So it makes sense to expose sigprocmask(2) at the same time, in order to allow this blocking to be set up.

----------
assignee: exarkun
components: Extension Modules, Library (Lib)
messages: 103182
nosy: exarkun
priority: normal
severity: normal
status: open
title: expose signalfd(2) and sigprocmask(2) in the signal module
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 15 10:01:47 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 15 Apr 2010 08:01:47 +0000
Subject: [New-bugs-announce] [issue8408] need console/pager module
In-Reply-To: <1271318507.97.0.95305497914.issue8408@psf.upfronthosting.co.za>
Message-ID: <1271318507.97.0.95305497914.issue8408@psf.upfronthosting.co.za>


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

Many many Python tools have duplicating code related to getting console properties like width and height to provide pagination and cute progress bars. While the issue seems minor, making such features work crossplatform way requires many tuits. That's why it is highly desirable to have console module inside Python stdlib.

----------
components: Library (Lib)
messages: 103187
nosy: techtonik
severity: normal
status: open
title: need console/pager module
type: feature request
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Apr 15 16:28:14 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 15 Apr 2010 14:28:14 +0000
Subject: [New-bugs-announce] [issue8409] gettext should honor $LOCPATH
	environment variable
In-Reply-To: <1271341694.43.0.480005164083.issue8409@psf.upfronthosting.co.za>
Message-ID: <1271341694.43.0.480005164083.issue8409@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

LOCPATH is an environment variable recognized by locale(1)

http://man.he.net/?topic=locale&section=all

gettext.find() should probably consult $LOCPATH and use that for localedir if the argument is not given.

----------
assignee: barry
components: Library (Lib)
keywords: easy
messages: 103220
nosy: barry
priority: normal
severity: normal
status: open
title: gettext should honor $LOCPATH environment variable
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Apr 15 22:00:46 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Apr 2010 20:00:46 +0000
Subject: [New-bugs-announce] [issue8410] Fix emulated lock to be 'fair'
In-Reply-To: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za>
Message-ID: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za>


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

On pthreads plaforms, if the posix_sem functions aren't available (when _POSIX_SEMAPHORES isn't defined), the python lock is implemented with a mutex and a condition variable.  This appears to be the case on Mac OS X, for example.
The problem is that this lock does not provide fairness to threads trying to acquire it.  This makes it a very poor candidate to implement the GIL, which is a lock that is held all the time, and all the threads are in constant competition to claim.
Other implementations of the python lock, such as the posix_sem based ones (linux) and Event based (MS Windows) provide fairness through that underlying synchronization primitive.

This patch fixes the "emulated semaphore" by making all competing threads wait their turn in the condition variable, thus enjoying whatever fairness that primitive provides.

I've not tested this patch for compilation since I don't have access to a mac to do that.  But the mechanism has been tested successfully on windows.

See also issue 8299, where this has been discussed at length.

----------
assignee: ronaldoussoren
components: Interpreter Core, Macintosh
files: pthread_lock.patch
keywords: needs review, patch, patch
messages: 103247
nosy: krisvale, ronaldoussoren
severity: normal
status: open
title: Fix emulated lock to be 'fair'
versions: Python 2.7
Added file: http://bugs.python.org/file16933/pthread_lock.patch

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

From report at bugs.python.org  Thu Apr 15 22:35:43 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 15 Apr 2010 20:35:43 +0000
Subject: [New-bugs-announce] [issue8411] Improve condition variable
	emulation on NT
In-Reply-To: <1271363743.96.0.308083925586.issue8411@psf.upfronthosting.co.za>
Message-ID: <1271363743.96.0.308083925586.issue8411@psf.upfronthosting.co.za>


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

As per Antoine's suggestion, here is a patch to improve condition variable emulation on windows.

By using the windows Semaphore (which hasn't always been available) all of the problems in emulating condition variables using Events disappear.  in particular, the "lost wakeup" bug can be elimintated, and the same object easily supports bot the "signal" and "broadcast" mode of waking up threads.  We can also use the CRICITAL_SECTION objects as the associated mutex which is much lighter weight than using a kernel object.

I do think I?ve caught all the corner cases.  It is also simpler to prove because this construct is simpler than the previous one.  If, however, i have missed a spot, I'd be interested to know about it.  Not completely impossible since race conditions are devious beasts.  Ive tested this extensively on Windows.

See also issue 8299 where this implementation was presented.

----------
components: Interpreter Core
files: nt_cond.patch
keywords: needs review, patch, patch
messages: 103251
nosy: krisvale, pitrou
severity: normal
status: open
title: Improve condition variable emulation on NT
versions: Python 3.2
Added file: http://bugs.python.org/file16934/nt_cond.patch

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

From martin at v.loewis.de  Thu Apr 15 22:32:57 2010
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 15 Apr 2010 22:32:57 +0200
Subject: [New-bugs-announce] [issue8410] Fix emulated lock to be 'fair'
In-Reply-To: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za>
References: <1271361646.51.0.206027864382.issue8410@psf.upfronthosting.co.za>
Message-ID: <4BC777F9.50205@v.loewis.de>

> On pthreads plaforms, if the posix_sem functions aren't available
> (when _POSIX_SEMAPHORES isn't defined), the python lock is
> implemented with a mutex and a condition variable.  This appears to
> be the case on Mac OS X, for example. The problem is that this lock
> does not provide fairness to threads trying to acquire it. 

Why do you think condition variables don't provide fairness?

From report at bugs.python.org  Fri Apr 16 03:10:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 01:10:22 +0000
Subject: [New-bugs-announce] [issue8412] os.system() doesn't support
	surrogates nor bytes
In-Reply-To: <1271380222.1.0.273272196711.issue8412@psf.upfronthosting.co.za>
Message-ID: <1271380222.1.0.273272196711.issue8412@psf.upfronthosting.co.za>


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

os.system() doesn't support bytes, bytearray not str containing surrogates.

Attached patch uses PyUnicode_FSConverter, bytes2str and release_bytes in (the non-Windows version of) os.system() to support all of this. It locks the buffer because os.system() releases the GIL when calling system().

----------
components: Library (Lib), Unicode
files: os_system_surrogates.patch
keywords: patch
messages: 103280
nosy: haypo
severity: normal
status: open
title: os.system() doesn't support surrogates nor bytes
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16941/os_system_surrogates.patch

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

From report at bugs.python.org  Fri Apr 16 03:28:10 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 16 Apr 2010 01:28:10 +0000
Subject: [New-bugs-announce] [issue8413] String interpolation doesn't work
	with sys.version_info
In-Reply-To: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>
Message-ID: <1271381290.83.0.815567007844.issue8413@psf.upfronthosting.co.za>


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

String interpolation doesn't work with sys.version_info in Python versions in which sys.version_info is a named tuple. It's a regression in Python 2.7 and 3.1. This problem doesn't concern named tuples created using collections.namedtuple().

This problem might also concern sys.getwindowsversion(), but I don't have access to Windows system, so I can't check it.

$ python2.6 -c 'import sys; print("%s.%s.%s-%s-%s" % sys.version_info)'
2.6.5-final-0
$ python2.7 -c 'import sys; print("%s.%s.%s-%s-%s" % sys.version_info)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: not enough arguments for format string
$ python3.0 -c 'import sys; print("%s.%s.%s-%s-%s" % sys.version_info)'
3.0.1-final-0
$ python3.1 -c 'import sys; print("%s.%s.%s-%s-%s" % sys.version_info)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: not enough arguments for format string

----------
components: Library (Lib)
messages: 103282
nosy: Arfrever
severity: normal
status: open
title: String interpolation doesn't work with sys.version_info
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Apr 16 03:49:14 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Fri, 16 Apr 2010 01:49:14 +0000
Subject: [New-bugs-announce] [issue8414] Add test cases for assert
In-Reply-To: <1271382554.96.0.638288219507.issue8414@psf.upfronthosting.co.za>
Message-ID: <1271382554.96.0.638288219507.issue8414@psf.upfronthosting.co.za>


New submission from Gregory Nofi <crackityjones2004-p at yahoo.com>:

I'm adding some assert tests to test_grammar.py to verify that the assert statement raises (or doesn't raise) an AssertionError properly.

NOTE: I'm currently helping Dino port IronPython tests into CPython. This is part of that series.

----------
components: Tests
files: test_grammar.v2.patch
keywords: patch
messages: 103284
nosy: gnofi
severity: normal
status: open
title: Add test cases for assert
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16942/test_grammar.v2.patch

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

From report at bugs.python.org  Fri Apr 16 06:28:23 2010
From: report at bugs.python.org (H Krishnan)
Date: Fri, 16 Apr 2010 04:28:23 +0000
Subject: [New-bugs-announce] [issue8415] namedtuple vs tuple
In-Reply-To: <1271392103.11.0.515361003447.issue8415@psf.upfronthosting.co.za>
Message-ID: <1271392103.11.0.515361003447.issue8415@psf.upfronthosting.co.za>


New submission from H Krishnan <hetchkay at gmail.com>:

Named tuples and tuples have different creation behavior. Changing a tuple to a namedtuple will involve changing the usage as well. For example:

>>> ntuple = collections.namedtuple("ntuple", "a,b")
>>> ntuple(1,2)
ntuple(a=1, b=2)
>>> tuple(1,2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: tuple() takes at most 1 argument (2 given)
>>> tuple([1,2])
(1, 2)
>>> ntuple([1,2])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __new__() takes exactly 3 arguments (2 given)
>>>

Because of this, to create a tuple object given a 'tuple class', we need to do something like:
def makeTuple(tupleCls, *args):
   if hasattr(tupleCls, "_fields"):
      return tupleCls(*args)
   else:
      return tupleCls(args)

My suggestion: A namedtuple should also accept a single iterable as argument, in which case, the iterable will be broken up and assigned to individual fields.
This will break an existing behaviour of namedtuple: if only one field is present in the namedtuple and an iterable is passed to the namedtuple, that field is currently assigned the iterable. However, namedtuples are seldom used for single fields and so this may not be that important.

----------
components: None
messages: 103289
nosy: hkrishnan
severity: normal
status: open
title: namedtuple vs tuple
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr 16 08:03:54 2010
From: report at bugs.python.org (Santiago Gala)
Date: Fri, 16 Apr 2010 06:03:54 +0000
Subject: [New-bugs-announce] [issue8416] python 2.6.5 documentation can't
	search
In-Reply-To: <1271397834.22.0.547082855086.issue8416@psf.upfronthosting.co.za>
Message-ID: <1271397834.22.0.547082855086.issue8416@psf.upfronthosting.co.za>


New submission from Santiago Gala <sgala at apache.org>:

http://docs.python.org/release/2.6.5/search.html?q=regular+expression

fails. It fails because

http://docs.python.org/release/2.6.5/searchindex.js

returns 404 NOT FOUND

There are really two bugs here:
* that the file is not there, and
* that the page gives no clue that there is something broken inside

IMO the second one is more important: the page stays forever with the Searching and the dots moving...

I reported against build and Documentation as I'm not sure if the web site belongs here and where is the issue originating.

----------
assignee: georg.brandl
components: Documentation
messages: 103293
nosy: georg.brandl, sgala
severity: normal
status: open
title: python 2.6.5 documentation can't search
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr 16 09:43:56 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Fri, 16 Apr 2010 07:43:56 +0000
Subject: [New-bugs-announce] [issue8417] bytes and bytearray constructors
	raise TypeError for very	large ints
In-Reply-To: <1271403836.14.0.808706592166.issue8417@psf.upfronthosting.co.za>
Message-ID: <1271403836.14.0.808706592166.issue8417@psf.upfronthosting.co.za>


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

>>> bytes(10)
b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
>>> bytes(10 ** 100)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable

----------
components: Interpreter Core
messages: 103300
nosy: abacabadabacaba
severity: normal
status: open
title: bytes and bytearray constructors raise TypeError for very large ints
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri Apr 16 15:47:22 2010
From: report at bugs.python.org (Alf P. Steinbach)
Date: Fri, 16 Apr 2010 13:47:22 +0000
Subject: [New-bugs-announce] [issue8418] Crash 0xc0000417
	STATUS_INVALID_CRUNTIME_PARAMETER on	program exit
In-Reply-To: <1271425642.06.0.059153749397.issue8418@psf.upfronthosting.co.za>
Message-ID: <1271425642.06.0.059153749397.issue8418@psf.upfronthosting.co.za>


New submission from Alf P. Steinbach <alfps at start.no>:

Python 3.1.1 in Windows XP Prof, appears to be a Windows-only problem

Effect: on program exit the interpreter crashes with exception  0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER at address 0x78588389, which appears to be in [msvcr90.dll].

To reproduce: very difficult. I had this occur tree times when, after not running any Python program for a while, hitting Ctrl C at the first prompt of the enclosed program. On subsequent runs (not waiting) the bug does *not* manifest. Possibly a timing issue?

Possibly the same bug: ticket #85 for PyInstaller, <url: http://www.pyinstaller.org/ticket/85> has same exception code and same address and also occurring at program exit. Reported as not manifesting in Linux, only Windows. If same bug may be more reliable way to reproduce.

PS: I reported two or three bugs earlier; one was fixed in 3.1.2. But the "Your issues" link shows no issues for me. Trying to report that via "Report tracker problem" it doesn't recognize me as logged in, and maintains that my login attempt is invalid. So there's like a bug in the tracker's reporting scheme for reporting the bug in the tracker. :-)

----------
components: Interpreter Core
files: sum.v4.py
messages: 103325
nosy: alfps
severity: normal
status: open
title: Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on program exit
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file16948/sum.v4.py

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

From report at bugs.python.org  Fri Apr 16 17:03:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Apr 2010 15:03:05 +0000
Subject: [New-bugs-announce] [issue8419] dict constructor allows invalid
	identifiers in **kwargs
In-Reply-To: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>
Message-ID: <1271430185.29.0.771672162256.issue8419@psf.upfronthosting.co.za>


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

In all versions of CPython right now, the following works.

>>> dict({1:2}, **{3:4})
{1: 2, 3: 4}

Other Python implementations raise TypeError for this;  CPython should probably do the same, beginning with deprecating this behaviour in Python 3.2 and removing it in 3.3.

>From a python-dev posting[1] by Alex Gaynor:

"""
I ran into the follow behavior while making sure Django works
correctly on PyPy.  The following behavior was observed in all tested
versions of CPython (2.5, 3.1):

>>> def f(**kwargs):
...     print(kwargs)
...
>>> kwargs = {1: 3}
>>>
>>> dict({}, **kwargs)
{1: 3}
>>> f(**kwargs)
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: f() keywords must be strings
>>>

This behavior seems pretty strange to me, indeed PyPy gives the
TypeError for both attempts.  I just wanted to confirm that it was in
fact intentional.
"""

Raghuram Devarakonda says (in the same python-dev thread):

"I ran into same issue with Django on Jython yesterday [1] since Jython
too gives TypeError for 'dict({}, **kwargs)'."

Guido, on the suggestion that both the CPython and PyPy behaviour be left as is, and that the behaviour be regarded as implementation defined:

"That is just going to cause some programs to have a portability
surprise. I think one or the other should be fixed. I am fine with declaring dict({}, **{1:3}) illegal, since after all it is abuse of the ** mechanism. We should deprecate it in at least one version though."


[1] http://mail.python.org/pipermail/python-dev/2010-April/099427.html

----------
components: Interpreter Core
messages: 103330
nosy: mark.dickinson
priority: normal
severity: normal
stage: unit test needed
status: open
title: dict constructor allows invalid identifiers in **kwargs
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Apr 16 17:43:35 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Fri, 16 Apr 2010 15:43:35 +0000
Subject: [New-bugs-announce] [issue8420] set_lookkey is unsafe
In-Reply-To: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>
Message-ID: <1271432615.46.0.0442636661618.issue8420@psf.upfronthosting.co.za>


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

I've noticed that set_lookkey (in Objects/setobject.c) does some unsafe things:
Objects/setobject.c:
> if (entry->hash == hash) {
> 	startkey = entry->key;
> 	Py_INCREF(startkey);
> 	cmp = PyObject_RichCompareBool(startkey, key, Py_EQ);
> 	Py_DECREF(startkey);
At this point, object pointed to by startkey could be deallocated, and then new object may be allocated at the same address.
> 	if (cmp < 0)
> 		return NULL;
> 	if (table == so->table && entry->key == startkey) {
At this point, the table may be reallocated at the same address but with different (possibly smaller) size, so entry->key may be in deallocated memory. Also, entry->key may be equal to startkey but still point to an object other than one key was compared with.
> 		if (cmp > 0)
> 			return entry;
> 	}
> 	else {
> 		/* The compare did major nasty stuff to the
> 		 * set:  start over.
> 		 */
> 		return set_lookkey(so, key, hash);
This can lead to infinite recursion.
> 	}

----------
components: Interpreter Core
messages: 103333
nosy: abacabadabacaba
severity: normal
status: open
title: set_lookkey is unsafe
versions: Python 3.1

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

From report at bugs.python.org  Fri Apr 16 18:26:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 16:26:46 +0000
Subject: [New-bugs-announce] [issue8421] tiger buildbot: unable to resolv
	hostname address
In-Reply-To: <1271435206.59.0.838389424852.issue8421@psf.upfronthosting.co.za>
Message-ID: <1271435206.59.0.838389424852.issue8421@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/3.x/builders/x86 Tiger 3.x/builds/6/steps/test/logs/stdio:
======================================================================
ERROR: testSockName (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_socket.py", line 504, in testSockName
    my_ip_addr = socket.gethostbyname(socket.gethostname())
socket.gaierror: [Errno 7] No address associated with nodename

----------
messages: 103337
nosy: haypo
severity: normal
status: open
title: tiger buildbot: unable to resolv hostname address
versions: Python 3.2

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

From report at bugs.python.org  Fri Apr 16 18:31:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 16:31:06 +0000
Subject: [New-bugs-announce] [issue8422] tiger buildbot:
	test_abspath_issue3426 failure	(test_genericpath.py)
In-Reply-To: <1271435466.82.0.847060352272.issue8422@psf.upfronthosting.co.za>
Message-ID: <1271435466.82.0.847060352272.issue8422@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/3.x/builders/x86 Tiger 3.x/builds/6/steps/test/logs/stdio

test test_ntpath failed -- Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_genericpath.py", line 288, in test_abspath_issue3426
    with support.temp_cwd(b'\xe7w\xf0'):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/contextlib.py", line 17, in __enter__
    return next(self.gen)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 392, in temp_cwd
    os.mkdir(name)
OSError: [Errno 22] Invalid argument

As discussed on IRC: Mac OS X deny the creation of a directory with an invalid utf8 name. The test should be skipped on Mac OS X (sys.platform == 'darwin').

----------
messages: 103338
nosy: haypo
severity: normal
status: open
title: tiger buildbot: test_abspath_issue3426 failure (test_genericpath.py)

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

From report at bugs.python.org  Fri Apr 16 18:35:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 16:35:49 +0000
Subject: [New-bugs-announce] [issue8423] tiger buildbot: test_pep277 failures
In-Reply-To: <1271435749.81.0.011008649482.issue8423@psf.upfronthosting.co.za>
Message-ID: <1271435749.81.0.011008649482.issue8423@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/3.x/builders/x86 Tiger 3.x/builds/6/steps/test/logs/stdio

test test_pep277 failed -- multiple errors occurred; run in verbose mode for details
Re-running test test_pep277 in verbose mode
test_directory (test.test_pep277.UnicodeFileTests) ... ok
test_failures (test.test_pep277.UnicodeFileTests) ... ok
test_listdir (test.test_pep277.UnicodeFileTests) ... FAIL
test_normalize (test.test_pep277.UnicodeFileTests) ... ERROR
test_open (test.test_pep277.UnicodeFileTests) ... ok
test_rename (test.test_pep277.UnicodeFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFCFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFCFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFCFileTests) ... FAIL
test_normalize (test.test_pep277.UnicodeNFCFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFCFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFCFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFDFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFDFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFDFileTests) ... ok
test_normalize (test.test_pep277.UnicodeNFDFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFDFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFDFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFKCFileTests) ... FAIL
test_normalize (test.test_pep277.UnicodeNFKCFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_normalize (test.test_pep277.UnicodeNFKDFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFKDFileTests) ... ok

======================================================================
ERROR: test_normalize (test.test_pep277.UnicodeFileTests)
----------------------------------------------------------------------
test test_pep277 crashed -- <class 'UnicodeEncodeError'>: 'ascii' codec can't encode characters in position 222-239: ordinal not in range(128)
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 905, in runtest_inner
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_pep277.py", line 195, in test_main
    UnicodeNFKDFileTests,
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 1000, in run_unittest
    _run_suite(suite)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 974, in _run_suite
    result = runner.run(suite)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", line 158, in run
    result.printErrors()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", line 108, in printErrors
    self.printErrorList('ERROR', self.errors)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", line 116, in printErrorList
    self.stream.writeln("%s" % err)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", line 24, in writeln
    self.write(arg)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 222-239: ordinal not in range(128)

----------
messages: 103340
nosy: haypo
severity: normal
status: open
title: tiger buildbot: test_pep277 failures
versions: Python 3.2

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

From report at bugs.python.org  Fri Apr 16 18:36:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 16:36:38 +0000
Subject: [New-bugs-announce] [issue8424] tiger buildbot: test_itimer_virtual
	failures
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>


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

test_itimer_virtual (test.test_signal.ItimerTest) ... FAIL

======================================================================
FAIL: test_itimer_prof (test.test_signal.ItimerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 391, in test_itimer_prof
    self.fail('timeout waiting for sig_prof signal')
AssertionError: timeout waiting for sig_prof signal

======================================================================
FAIL: test_itimer_virtual (test.test_signal.ItimerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 372, in test_itimer_virtual
    (signal.getitimer(self.itimer),))
AssertionError: timeout waiting for sig_vtalrm signal; signal.getitimer(self.itimer) gives: (0.29, 0.2)

----------------------------------------------------------------------
Ran 13 tests in 15.302s

----------
messages: 103341
nosy: haypo
severity: normal
status: open
title: tiger buildbot: test_itimer_virtual failures
versions: Python 3.2

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

From report at bugs.python.org  Fri Apr 16 19:19:42 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Fri, 16 Apr 2010 17:19:42 +0000
Subject: [New-bugs-announce] [issue8425] a -= b should be fast if a is a
	small set and b is a	large set
In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>
Message-ID: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>


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

>>> small_set = set(range(2000))
>>> large_set = set(range(20000000))
>>> large_set -= small_set # Fast
>>> small_set -= large_set # Slow, should be fast
>>> small_set = small_set - large_set # Fast

----------
components: Interpreter Core
messages: 103343
nosy: abacabadabacaba
severity: normal
status: open
title: a -= b should be fast if a is a small set and b is a large set
type: resource usage
versions: Python 3.1

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

From report at bugs.python.org  Fri Apr 16 20:38:06 2010
From: report at bugs.python.org (Ian Davis)
Date: Fri, 16 Apr 2010 18:38:06 +0000
Subject: [New-bugs-announce] [issue8426] multiprocessing.Queue fails to
	get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>


New submission from Ian Davis <ian.w.davis at gmail.com>:

I'm trying to parallelize some scientific computing jobs using multiprocessing.Pool.  I've also tried rolling my own Pool equivalent using Queues.  In trying to return very large result objects from Pool.map()/imap() or via Queue.put(), I've noticed that multiprocessing seems to hang on the receiving end.  On Cygwin 1.7.1/Python 2.5.2 it hangs with no CPU activity.  On Centos 5.2/Python 2.6.2 it hangs with 100% CPU.  cPickle is perfectly capable of pickling these objects, although they may be 100's of MB, so I think it's the communication.  There's also some asymmetry in the error whether it's the parent or child putting the large object.  The put does appear to succeed;  it's the get() on the other end that hangs forever.

Example code:
-----
from multiprocessing import *

def child(task_q, result_q):
    while True:
        print "  Getting task..."
        task = task_q.get()
        print "  Got task", task[:10]
        task = task * 100000000
        print "  Putting result", task[:10]
        result_q.put(task)
        print "  Done putting result", task[:10]
        task_q.task_done()

def parent():
    task_q = JoinableQueue()
    result_q = JoinableQueue()
    worker = Process(target=child, args=(task_q,result_q))
    worker.daemon = True
    worker.start()
    #tasks = ["foo", "bar", "ABC" * 100000000, "baz"]
    tasks = ["foo", "bar", "ABC", "baz"]
    for task in tasks:
        print "Putting task", task[:10], "..."
        task_q.put(task)
        print "Done putting task", task[:10]
    task_q.join()
    for task in tasks:
        print "Getting result..."
        print "Got result", result_q.get()[:10]

if __name__ == '__main__':
    parent()
-----

If run as is, I get
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py", line 242, in _feed
    send(obj)
MemoryError: out of memory
(*** hangs, I hit ^C ***)
Got result
Traceback (most recent call last):
Process Process-1:
Traceback (most recent call last):
  File "cygwin_multiprocessing_queue.py", line 32, in <module>
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/process.py", line 237, in _bootstrap
    parent()
  File "cygwin_multiprocessing_queue.py", line 29, in parent
    print "Got result", result_q.get()[:10]
    self.run()
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/process.py", line 93, in run
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py", line 91, in get
    self._target(*self._args, **self._kwargs)
  File "cygwin_multiprocessing_queue.py", line 6, in child
    res = self._recv()
KeyboardInterrupt
    task = task_q.get()
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py", line 91, in get
    res = self._recv()
KeyboardInterrupt


If instead I comment out the multiplication in child() and uncomment the large task in parent(), then I get
  Getting task...
Putting task foo ...
Done putting task foo
Putting task bar ...
  Got task foo
  Putting result foo
Done putting task bar
Putting task ABCABCABCA ...
Done putting task ABCABCABCA
Putting task baz ...
  Done putting result foo
  Getting task...
  Got task bar
  Putting result bar
  Done putting result bar
  Getting task...
Done putting task baz
(*** hangs, I hit ^C ***)
Traceback (most recent call last):
  File "cygwin_multiprocessing_queue.py", line 32, in <module>
    parent()
  File "cygwin_multiprocessing_queue.py", line 26, in parent
    task_q.join()
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py", line 303, in join
    self._cond.wait()
  File "/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/synchronize.py", line 212, in wait
    self._wait_semaphore.acquire(True, timeout)
KeyboardInterrupt

----------
components: Library (Lib)
messages: 103349
nosy: Ian.Davis
severity: normal
status: open
title: multiprocessing.Queue fails to get() very large objects
type: crash
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Fri Apr 16 22:50:07 2010
From: report at bugs.python.org (Andrei Paraschivescu)
Date: Fri, 16 Apr 2010 20:50:07 +0000
Subject: [New-bugs-announce] [issue8427] toplevel jumps to another location
	on the screen
In-Reply-To: <1271451007.13.0.573906972341.issue8427@psf.upfronthosting.co.za>
Message-ID: <1271451007.13.0.573906972341.issue8427@psf.upfronthosting.co.za>


New submission from Andrei Paraschivescu <andreip1 at comcast.net>:

The effect is the window just jumps to another location, matching left corners with another window in the same Python application. Its size doesn't change. 

The effect is somewhat erratic, the best I've been able to create is a situation where it happens 90% of the time. The application contains a number of widget.after calls, and I have not been able to replicate it with a small example.

I am running Mac OS X 10.4.11 and Python 2.6; running from my PC with Windows XP the effect doesn't happen, so it might be a OS X/Tk issue.

----------
components: Tkinter
messages: 103358
nosy: aparasch
severity: normal
status: open
title: toplevel jumps to another location on the screen
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr 16 22:56:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 20:56:52 +0000
Subject: [New-bugs-announce] [issue8428] buildbot: test_multiprocessing
	timeout
In-Reply-To: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>
Message-ID: <1271451412.83.0.723333785051.issue8428@psf.upfronthosting.co.za>


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

Example: http://www.python.org/dev/buildbot/3.x/builders/x86 FreeBSD 7.2 3.x/builds/480/steps/test/logs/stdio

-----------
test_multiprocessing
test test_multiprocessing failed -- Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_multiprocessing.py", line 737, in test_notify_all
    self.assertReturnsIfImplemented(6, get_value, woken)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_multiprocessing.py", line 111, in assertReturnsIfImplemented
    return self.assertEqual(value, res)
AssertionError: 6 != 5

Re-running test test_multiprocessing in verbose mode
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_notify (test.test_multiprocessing.WithProcessesTestCondition) ... ok
test_notify_all (test.test_multiprocessing.WithProcessesTestCondition) ... FAIL
test_timeout (test.test_multiprocessing.WithProcessesTestCondition) ... ok
test_connection (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_duplex_false (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_sendbytes (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_spawn_close (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_event (test.test_multiprocessing.WithProcessesTestEvent) ... ok
test_finalize (test.test_multiprocessing.WithProcessesTestFinalize) ... ok
test_heap (test.test_multiprocessing.WithProcessesTestHeap) ... ok
test_import (test.test_multiprocessing.WithProcessesTestImportStar) ... ok
test_listener_client (test.test_multiprocessing.WithProcessesTestListenerClient) ... ok
test_lock (test.test_multiprocessing.WithProcessesTestLock) ... ok
test_lock_context (test.test_multiprocessing.WithProcessesTestLock) ... ok
test_rlock (test.test_multiprocessing.WithProcessesTestLock) ... ok
test_enable_logging (test.test_multiprocessing.WithProcessesTestLogging) ... ok
test_level (test.test_multiprocessing.WithProcessesTestLogging) ... ok
test_rapid_restart (test.test_multiprocessing.WithProcessesTestManagerRestart) ... ok
test_apply (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_async (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_async_timeout (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_imap (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_imap_unordered (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_make_pool (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_map (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_map_chunksize (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_terminate (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_pool_worker_lifetime (test.test_multiprocessing.WithProcessesTestPoolWorkerLifetime) ... 
command timed out: 1800 seconds without output, killing pid 87365
process killed by signal 9
program finished with exit code -1
elapsedTime=6317.267055
-----------

----------
keywords: buildbot
messages: 103359
nosy: haypo
severity: normal
status: open
title: buildbot: test_multiprocessing timeout
versions: Python 3.2

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

From report at bugs.python.org  Fri Apr 16 23:56:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Apr 2010 21:56:39 +0000
Subject: [New-bugs-announce] [issue8429] buildbot: test_subprocess timeout
In-Reply-To: <1271454999.83.0.583856946737.issue8429@psf.upfronthosting.co.za>
Message-ID: <1271454999.83.0.583856946737.issue8429@psf.upfronthosting.co.za>


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

test_subprocess hungs for 30 min or more.

The bug occurs on buildbots:
 - ARMv7Thumb Ubuntu 3.1 (r80093)
 - ARMv4 Debian 3.x (r80102)
 - ARMv7Thumb Ubuntu 3.x (r80020)
 - alpha Debian 3.x (r80020)
 - x86 FreeBSD 7.2 3.x (r80102)
 - sparc Debian trunk (r80085)

----------
keywords: buildbot
messages: 103368
nosy: haypo
severity: normal
status: open
title: buildbot: test_subprocess timeout
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Apr 17 15:39:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 13:39:53 +0000
Subject: [New-bugs-announce] [issue8430] test_site failure with non-ASCII
	directory
In-Reply-To: <1271511593.69.0.166956245853.issue8430@psf.upfronthosting.co.za>
Message-ID: <1271511593.69.0.166956245853.issue8430@psf.upfronthosting.co.za>


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

r80137 (PEP 3147) introduced a test in test_site. The test fails on non-ASCII directory because stdout uses ASCII whereas the directories contains non-ASCII characters.

http://www.python.org/dev/buildbot/builders/AMD64 Ubuntu wide 3.x/builds/848

Attached patch is a workaround to this issue. The path is encoded to ASCII using backslashreplace error handler. But the patch is not perfect, it should use the reverse operation to get the path as an unicode string. But I don't know how to implement the reverse operation of .encode("ascii", "backslashreplace").

----------
files: test_site.patch
keywords: buildbot, patch
messages: 103400
nosy: haypo
severity: normal
status: open
title: test_site failure with non-ASCII directory
versions: Python 3.2
Added file: http://bugs.python.org/file16959/test_site.patch

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

From report at bugs.python.org  Sat Apr 17 15:51:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 13:51:04 +0000
Subject: [New-bugs-announce] [issue8431] buildbot: test_tokenize and test_io
	hung on ARMv4 Debian	3.x
In-Reply-To: <1271512264.44.0.220821397982.issue8431@psf.upfronthosting.co.za>
Message-ID: <1271512264.44.0.220821397982.issue8431@psf.upfronthosting.co.za>


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

test_tokenize and test_io does sometimes hung on buildbot ARMv4 Debian 3.x. It looks to be related to #8429.

http://www.python.org/dev/buildbot/builders/ARMv4 Debian 3.x/builds/52/steps/test/logs/stdio
---------
...
test_tokenize

command timed out: 1800 seconds without output, killing pid 10998
process killed by signal 9
program finished with exit code -1
elapsedTime=12155.584910
---------

http://www.python.org/dev/buildbot/builders/ARMv4 Debian 3.x/builds/50/steps/test/logs/stdio
----------
...
test_io

command timed out: 1800 seconds without output, killing pid 18097
process killed by signal 9
program finished with exit code -1
elapsedTime=3859.149082
----------

----------
keywords: buildbot
messages: 103401
nosy: haypo
severity: normal
status: open
title: buildbot: test_tokenize and test_io hung on ARMv4 Debian 3.x
versions: Python 3.2

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

From report at bugs.python.org  Sat Apr 17 18:36:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 16:36:35 +0000
Subject: [New-bugs-announce] [issue8432] build: test_send_signal of
	test_subprocess failure
In-Reply-To: <1271522195.0.0.944847217112.issue8432@psf.upfronthosting.co.za>
Message-ID: <1271522195.0.0.944847217112.issue8432@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/builders/x86 FreeBSD 3.x/builds/211/steps/test/logs/stdio

Example:
======================================================================
FAIL: test_send_signal (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_subprocess.py", line 770, in test_send_signal
    self.assertIn(b'KeyboardInterrupt', stderr)
AssertionError: b'KeyboardInterrupt' not found in b''

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

----------
keywords: buildbot
messages: 103409
nosy: haypo
severity: normal
status: open
title: build: test_send_signal of test_subprocess failure
versions: Python 3.2

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

From report at bugs.python.org  Sat Apr 17 19:26:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 17:26:24 +0000
Subject: [New-bugs-announce] [issue8433] buildbot: test_curses failure
In-Reply-To: <1271525184.22.0.100709248737.issue8433@psf.upfronthosting.co.za>
Message-ID: <1271525184.22.0.100709248737.issue8433@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/builders/sparc Debian 3.x/builds/62/steps/test/logs/stdio

test_curses
[?1049h(B[?7h[?5h[?5l[?12l[?25habc[?1000h[?1000l(B[?1049l
[?1l>test test_curses crashed -- <class '_curses.error'>: getmouse() returned ERR

Re-running test test_curses in verbose mode
[?1049h[?12l[?25h(B[?7h[?1000h[?5h[?5labc[?1000h[?1000l(B[?1049l
[?1l>test test_curses crashed -- <class '_curses.error'>: getmouse() returned ERR
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 905, in runtest_inner
  File "/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_curses.py", line 291, in test_main
    main(stdscr)
  File "/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_curses.py", line 275, in main
    module_funcs(stdscr)
  File "/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_curses.py", line 228, in module_funcs
    m = curses.getmouse()
_curses.error: getmouse() returned ERR

----------
keywords: buildbot
messages: 103411
nosy: haypo
severity: normal
status: open
title: buildbot: test_curses failure
versions: Python 3.2

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

From report at bugs.python.org  Sat Apr 17 20:20:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Apr 2010 18:20:45 +0000
Subject: [New-bugs-announce] [issue8434] buildbot: test_gdb failure on sparc
	Ubuntu trunk
In-Reply-To: <1271528445.34.0.175485251427.issue8434@psf.upfronthosting.co.za>
Message-ID: <1271528445.34.0.175485251427.issue8434@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/builders/sparc Ubuntu trunk/builds/76/steps/test/logs/stdio

test_gdb
test test_gdb failed -- multiple errors occurred; run in verbose mode for details
Re-running test 'test_gdb' in verbose mode
test_NULL_instance_dict (test.test_gdb.PrettyPrintTests)
Ensure that a PyInstanceObject with with a NULL in_dict is handled ... ok
test_NULL_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with NULL ob_type is handled gracefully ... ok
test_NULL_ptr (test.test_gdb.PrettyPrintTests)
Ensure that a NULL PyObject* is handled gracefully ... ok
test_builtin_function (test.test_gdb.PrettyPrintTests) ... ok
test_builtin_method (test.test_gdb.PrettyPrintTests) ... ok
test_builtins_help (test.test_gdb.PrettyPrintTests)
Ensure that the new-style class _Helper in site.py can be handled ... ok
test_classic_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of classic class instances ... ok
test_corrupt_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a corrupt ob_type is handled gracefully ... ok
test_corrupt_tp_flags (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_flags is handled ... ok
test_corrupt_tp_name (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_name is handled ... ok
test_dicts (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of dictionaries ... ok
test_exceptions (test.test_gdb.PrettyPrintTests) ... ok
test_frames (test.test_gdb.PrettyPrintTests) ... ok
test_frozensets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of frozensets ... ok
test_getting_backtrace (test.test_gdb.PrettyPrintTests) ... ok
test_int (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "int" values ... ok
test_lists (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of lists ... ok
test_long (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "long" values ... ok
test_modern_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of new-style class instances ... ok
test_selfreferential_dict (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a dict doesn't lead proxyval ... ok
test_selfreferential_list (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a list doesn't lead proxyval ... ok
test_selfreferential_new_style_instance (test.test_gdb.PrettyPrintTests) ... ok
test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests) ... ok
test_sets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of sets ... ok
test_singletons (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of True, False and None ... ok
test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of strings ... ok
test_subclassing_list (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a list subclass ... ok
test_subclassing_tuple (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a tuple subclass ... ok
test_truncation (test.test_gdb.PrettyPrintTests)
Verify that very long output is truncated ... ok
test_tuples (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of tuples ... ok
test_unicode (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode values ... ok
test_basic_command (test.test_gdb.PyListTests)
Verify that the "py-list" command works ... FAIL
test_one_abs_arg (test.test_gdb.PyListTests)
Verify the "py-list" command with one absolute argument ... FAIL
test_two_abs_args (test.test_gdb.PyListTests)
Verify the "py-list" command with two absolute arguments ... FAIL
test_down_at_bottom (test.test_gdb.StackNavigationTests)
Verify handling of "py-down" at the bottom of the stack ... FAIL
test_pyup_command (test.test_gdb.StackNavigationTests)
Verify that the "py-up" command works ... FAIL
test_up_at_top (test.test_gdb.StackNavigationTests)
Verify handling of "py-up" at the top of the stack ... FAIL
test_up_then_down (test.test_gdb.StackNavigationTests)
Verify "py-up" followed by "py-down" ... FAIL
test_basic_command (test.test_gdb.PyBtTests)
Verify that the "py-bt" command works ... FAIL
test_basic_command (test.test_gdb.PyPrintTests)
Verify that the "py-print" command works ... FAIL
test_print_after_up (test.test_gdb.PyPrintTests) ... FAIL
test_printing_builtin (test.test_gdb.PyPrintTests) ... FAIL
test_printing_global (test.test_gdb.PyPrintTests) ... FAIL
test_basic_command (test.test_gdb.PyLocalsTests) ... FAIL
test_locals_after_up (test.test_gdb.PyLocalsTests) ... FAIL

======================================================================
FAIL: test_basic_command (test.test_gdb.PyListTests)
Verify that the "py-list" command works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 535, in test_basic_command
    cmds_after_breakpoint=['py-list'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_one_abs_arg (test.test_gdb.PyListTests)
Verify the "py-list" command with one absolute argument
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 552, in test_one_abs_arg
    cmds_after_breakpoint=['py-list 9'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_two_abs_args (test.test_gdb.PyListTests)
Verify the "py-list" command with two absolute arguments
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 565, in test_two_abs_args
    cmds_after_breakpoint=['py-list 1,3'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_down_at_bottom (test.test_gdb.StackNavigationTests)
Verify handling of "py-down" at the bottom of the stack
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 588, in test_down_at_bottom
    cmds_after_breakpoint=['py-down'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_pyup_command (test.test_gdb.StackNavigationTests)
Verify that the "py-up" command works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 578, in test_pyup_command
    cmds_after_breakpoint=['py-up'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\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/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 595, in test_up_at_top
    cmds_after_breakpoint=['py-up'] * 4)
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_up_then_down (test.test_gdb.StackNavigationTests)
Verify "py-up" followed by "py-down"
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 602, in test_up_then_down
    cmds_after_breakpoint=['py-up', 'py-down'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_basic_command (test.test_gdb.PyBtTests)
Verify that the "py-bt" command works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 615, in test_basic_command
    cmds_after_breakpoint=['py-bt'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_basic_command (test.test_gdb.PyPrintTests)
Verify that the "py-print" command works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 630, in test_basic_command
    cmds_after_breakpoint=['py-print args'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_print_after_up (test.test_gdb.PyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 636, in test_print_after_up
    cmds_after_breakpoint=['py-up', 'py-print c', 'py-print b', 'py-print a'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_printing_builtin (test.test_gdb.PyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 648, in test_printing_builtin
    cmds_after_breakpoint=['py-print len'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_printing_global (test.test_gdb.PyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 642, in test_printing_global
    cmds_after_breakpoint=['py-print __name__'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_basic_command (test.test_gdb.PyLocalsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 655, in test_basic_command
    cmds_after_breakpoint=['py-locals'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\n" != ''

======================================================================
FAIL: test_locals_after_up (test.test_gdb.PyLocalsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 661, in test_locals_after_up
    cmds_after_breakpoint=['py-up', 'py-locals'])
  File "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/Lib/test/test_gdb.py", line 111, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: "/home/pybot/buildarea/trunk.klose-ubuntu-sparc/build/python: can't open file 'Lib/test/test_gdb_sample.py': [Errno 2] No such file or directory\nError occurred in Python command: No frame is currently selected.\nError occurred in Python command: No frame is currently selected.\n" != ''

----------------------------------------------------------------------
Ran 45 tests in 72.756s

FAILED (failures=14)
test test_gdb failed -- multiple errors occurred

----------
keywords: buildbot
messages: 103420
nosy: haypo
severity: normal
status: open
title: buildbot: test_gdb failure on sparc Ubuntu trunk
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 17 21:26:19 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Sat, 17 Apr 2010 19:26:19 +0000
Subject: [New-bugs-announce] [issue8435] It is possible to observe a
	mutating frozenset
In-Reply-To: <1271532379.1.0.0904311359185.issue8435@psf.upfronthosting.co.za>
Message-ID: <1271532379.1.0.0904311359185.issue8435@psf.upfronthosting.co.za>


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

This code shows that frozensets aren't really immutable. The same frozenset is printed twice, with different content. Buggy functions are set_contains, set_remove and set_discard, all in Objects/setobject.c

class bad:
	def __eq__(self, other):
		global f2
		f2 = other
		print_f2()
		s1.add("querty")
		return self is other
	def __hash__(self):
		return hash(f1)
def print_f2():
	print(id(f2), repr(f2))
f1 = frozenset((1, 2, 3))
s1 = set(f1)
s1 in {bad()}
print_f2()

----------
components: Interpreter Core
messages: 103426
nosy: abacabadabacaba
severity: normal
status: open
title: It is possible to observe a mutating frozenset
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sat Apr 17 21:37:21 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Sat, 17 Apr 2010 19:37:21 +0000
Subject: [New-bugs-announce] [issue8436] set.__init__ accepts keyword args
In-Reply-To: <1271533041.82.0.66984927267.issue8436@psf.upfronthosting.co.za>
Message-ID: <1271533041.82.0.66984927267.issue8436@psf.upfronthosting.co.za>


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

>>> list().__init__(a=0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'a' is an invalid keyword argument for this function
>>> set().__init__(a=0)

----------
components: Interpreter Core
messages: 103427
nosy: abacabadabacaba
severity: normal
status: open
title: set.__init__ accepts keyword args
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sun Apr 18 00:45:08 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 17 Apr 2010 22:45:08 +0000
Subject: [New-bugs-announce] [issue8437] test_gdb: gdb.Frame has no
	attribute function
In-Reply-To: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>
Message-ID: <1271544308.84.0.729212765087.issue8437@psf.upfronthosting.co.za>


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

I get a number of failures in test_gdb with gdb 7.0.1 about gdb.Frame, e.g.

FAIL: test_basic_command (test.test_gdb.PyListTests)                  
Verify that the "py-list" command works                               
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 538, in test_basic_command
    cmds_after_breakpoint=['py-list'])                                             
  File "/home/martin/work/27/Lib/test/test_gdb.py", line 111, in get_stack_trace   
    self.assertEquals(err, '')                                                     
AssertionError: "Error occurred in Python command: 'gdb.Frame' object has no attribute 'function'\n" != ''

----------
assignee: dmalcolm
messages: 103442
nosy: dmalcolm, haypo, loewis, ncoghlan
severity: normal
status: open
title: test_gdb: gdb.Frame has no attribute function

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

From report at bugs.python.org  Sun Apr 18 10:25:33 2010
From: report at bugs.python.org (Ray.Allen)
Date: Sun, 18 Apr 2010 08:25:33 +0000
Subject: [New-bugs-announce] [issue8438] Codecs: "surrogateescape" error
	handler in Python 2.7
In-Reply-To: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>
Message-ID: <1271579133.48.0.14681438148.issue8438@psf.upfronthosting.co.za>


New submission from Ray.Allen <ysj.ray at gmail.com>:

According to PEP 383, the new "surrogateescape" error handler of codecs should begin to appear since Python3.1, but in the trunk I found some code have already used it:

Modules/_io/fileio.c:

static int
fileio_init(PyObject *oself, PyObject *args, PyObject *kwds){
    ...
    stringobj = PyUnicode_AsEncodedString(
		u, Py_FileSystemDefaultEncoding, "surrogateescape");
    ...

Obviously, the "surrogateescape" error handler not exists. 

Some test code:
===========================
import io

file_name = u'\udc80.txt'
f = io.FileIO(file_name)
===========================

When run this piece of code on a machine whose file system default encoding is gb2312, will raise an exception:

LookupError: unknown error handler name 'surrogateescape'

I don't know weather this is a bug?

Thanks.

----------
components: Unicode
messages: 103470
nosy: loewis, ysj.ray
severity: normal
status: open
title: Codecs: "surrogateescape" error handler in Python 2.7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr 18 12:20:36 2010
From: report at bugs.python.org (Tim Golden)
Date: Sun, 18 Apr 2010 10:20:36 +0000
Subject: [New-bugs-announce] [issue8439] test_linecache failing in py3k
	r80169
In-Reply-To: <4BCADCEA.2060609@timgolden.me.uk>
Message-ID: <4BCADCEA.2060609@timgolden.me.uk>


New submission from Tim Golden <mail at timgolden.me.uk>:

test_linecache in the current py3k branch is failing on my WinXP machine with ERROR_SHARING_VIOLATION.
The attached trivial patch appears to fix the problem, altho' I'm unfamiliar
with the module in question so it may be that there's more to be done.

----------
files: test_linecache.py.patch
keywords: patch
messages: 103475
nosy: tim.golden
severity: normal
status: open
title: test_linecache failing in py3k r80169
Added file: http://bugs.python.org/file16970/test_linecache.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8439>
_______________________________________
-------------- next part --------------
Index: test_linecache.py
===================================================================
--- test_linecache.py	(revision 80169)
+++ test_linecache.py	(working copy)
@@ -114,6 +114,7 @@
                 for index, line in enumerate(source):
                     self.assertEquals(line, getline(source_name, index + 1))
                     source_list.append(line)
+                source.close ()
 
         finally:
             support.unlink(source_name)

From report at bugs.python.org  Sun Apr 18 15:13:42 2010
From: report at bugs.python.org (Tim Golden)
Date: Sun, 18 Apr 2010 13:13:42 +0000
Subject: [New-bugs-announce] [issue8440] test_heapq interfering with
	test_import on py3k
In-Reply-To: <4BCB057A.7030108@timgolden.me.uk>
Message-ID: <4BCB057A.7030108@timgolden.me.uk>


New submission from Tim Golden <mail at timgolden.me.uk>:

If test_heapq is run before test_import on the current py3k head,
test_import will fail as per the attached traceback.

python -m test.regrtest -W test_heapq test_import > test_import.log

At a glance I can't see any obvious reason why test_heapq should have
any effect on test_import. Raising this bug while I try to narrow down.

An extra assert inside support.make_legacy_pyc confirms that
the .pyc being renamed into does in fact already exist.

Running test_import on its own or via regrtest when not preceded
by test_heapq runs with error.

----------
files: test_import.log
messages: 103488
nosy: tim.golden
severity: normal
status: open
title: test_heapq interfering with test_import on py3k
Added file: http://bugs.python.org/file16972/test_import.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8440>
_______________________________________
-------------- next part --------------
test_heapq
test_import
compiled to __pycache__\longlist.cpython-32.pyc
test test_import failed -- Traceback (most recent call last):
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\lib\test\test_import.py", line 167, in test_module_with_large_stack
    exec('import ' + module)
  File "<string>", line 1, in <module>
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\lib\importlib\_bootstrap.py", line 151, in decorated
    return fxn(self, module)
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\lib\importlib\_bootstrap.py", line 320, in load_module
    code_object = self.get_code(module.__name__)
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\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'

Re-running test test_import in verbose mode
test_case_sensitivity (test.test_import.ImportTests) ... ok
test_double_const (test.test_import.ImportTests) ... ok
test_execute_bit_not_copied (test.test_import.ImportTests) ... skipped 'test meaningful only on posix systems'
test_failing_import_sticks (test.test_import.ImportTests) ... ok
test_failing_reload (test.test_import.ImportTests) ... ok
test_file_to_source (test.test_import.ImportTests) ... ok
test_imp_module (test.test_import.ImportTests) ... ok
test_import (test.test_import.ImportTests) ... ok
test_import_by_filename (test.test_import.ImportTests) ... ok
test_import_initless_directory_warning (test.test_import.ImportTests) ... ok
test_import_name_binding (test.test_import.ImportTests) ... ok
test_module_with_large_stack (test.test_import.ImportTests) ... compiled to __pycache__\longlist.cpython-32.pyc
ERROR
test___cached__ (test.test_import.PycacheTests) ... ok
test___cached___legacy_pyc (test.test_import.PycacheTests) ... ok
test_import_pyc_path (test.test_import.PycacheTests) ... ok
test_missing_source (test.test_import.PycacheTests) ... ok
test_missing_source_legacy (test.test_import.PycacheTests) ... ok
test_package___cached__ (test.test_import.PycacheTests) ... ok
test_package___cached___from_pyc (test.test_import.PycacheTests) ... ok
test_unwritable_directory (test.test_import.PycacheTests) ... skipped 'test meaningful only on posix systems'
test_basics (test.test_import.PycRewritingTests) ... ok
test_foreign_code (test.test_import.PycRewritingTests) ... ok
test_incorrect_code_name (test.test_import.PycRewritingTests) ... ok
test_module_without_source (test.test_import.PycRewritingTests) ... ok
test_UNC_path (test.test_import.PathsTests) ... ok
test_trailing_slash (test.test_import.PathsTests) ... ok
test_issue3221 (test.test_import.RelativeImportTests) ... ok
test_relimport_star (test.test_import.RelativeImportTests) ... ok
test_override_builtin (test.test_import.OverridingImportBuiltinTests) ... ok

======================================================================
ERROR: test_module_with_large_stack (test.test_import.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\lib\test\test_import.py", line 161, in test_module_with_large_stack
    make_legacy_pyc(filename)
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\lib\test\support.py", line 209, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
WindowsError: [Error 183] Cannot create a file when that file already exists

----------------------------------------------------------------------
Ran 29 tests in 1.672s

FAILED (errors=1, skipped=2)
test test_import failed -- Traceback (most recent call last):
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\lib\test\test_import.py", line 161, in test_module_with_large_stack
    make_legacy_pyc(filename)
  File "C:\work-in-progress\make-snapshots\branches\py3k\python\lib\test\support.py", line 209, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
WindowsError: [Error 183] Cannot create a file when that file already exists


From report at bugs.python.org  Sun Apr 18 16:09:04 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 14:09:04 +0000
Subject: [New-bugs-announce] [issue8441] Framework build broken in 3.2 brunk
In-Reply-To: <1271599744.14.0.685635086765.issue8441@psf.upfronthosting.co.za>
Message-ID: <1271599744.14.0.685635086765.issue8441@psf.upfronthosting.co.za>


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

I cannot build a framework build of the 3.2 branch at the moment due to unresolved references to "_Py_char2wchar" when linking the dylib that gets placed into the framework:

Undefined symbols:
  "__Py_char2wchar", referenced from:
      _Py_Main in libpython3.2.a(main.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
Undefined symbols:
  "__Py_char2wchar", referenced from:
      _Py_Main in libpython3.2.a(main.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status


This is because that symbol is defined in Modules/python.c which doesn't get linked into the shared library.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 103491
nosy: ronaldoussoren
priority: release blocker
severity: normal
status: open
title: Framework build broken in 3.2 brunk
versions: Python 3.2

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

From report at bugs.python.org  Sun Apr 18 17:15:37 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 15:15:37 +0000
Subject: [New-bugs-announce] [issue8442] Broken zipfile with python 3.2 on
	osx
In-Reply-To: <1271603737.34.0.035153225146.issue8442@psf.upfronthosting.co.za>
Message-ID: <1271603737.34.0.035153225146.issue8442@psf.upfronthosting.co.za>


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

In the output of test_distutils with python 3.2 (current version checkout):
======================================================================
ERROR: test_prune_file_list (distutils.tests.test_sdist.SDistTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ronald/Projects/python/python-3.x/Lib/distutils/tests/test_sdist.py", line 131, in test_prune_file_list
    zip_file = zipfile.ZipFile(join(dist_folder, 'fake-1.0.zip'))
  File "/Users/ronald/Projects/python/python-3.x/Lib/zipfile.py", line 684, in __init__
    self._GetContents()
  File "/Users/ronald/Projects/python/python-3.x/Lib/zipfile.py", line 710, in _GetContents
    self._RealGetContents()
  File "/Users/ronald/Projects/python/python-3.x/Lib/zipfile.py", line 758, in _RealGetContents
    filename = filename.decode('cp437')
LookupError: unknown encoding: cp437

----------
components: Library (Lib)
messages: 103495
nosy: ronaldoussoren
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Broken zipfile with  python 3.2 on osx
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Apr 18 17:15:40 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 15:15:40 +0000
Subject: [New-bugs-announce] [issue8443] Broken zipfile with python 3.2 on
	osx
In-Reply-To: <1271603740.29.0.626086145163.issue8443@psf.upfronthosting.co.za>
Message-ID: <1271603740.29.0.626086145163.issue8443@psf.upfronthosting.co.za>


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

In the output of test_distutils with python 3.2 (current version checkout):
======================================================================
ERROR: test_prune_file_list (distutils.tests.test_sdist.SDistTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ronald/Projects/python/python-3.x/Lib/distutils/tests/test_sdist.py", line 131, in test_prune_file_list
    zip_file = zipfile.ZipFile(join(dist_folder, 'fake-1.0.zip'))
  File "/Users/ronald/Projects/python/python-3.x/Lib/zipfile.py", line 684, in __init__
    self._GetContents()
  File "/Users/ronald/Projects/python/python-3.x/Lib/zipfile.py", line 710, in _GetContents
    self._RealGetContents()
  File "/Users/ronald/Projects/python/python-3.x/Lib/zipfile.py", line 758, in _RealGetContents
    filename = filename.decode('cp437')
LookupError: unknown encoding: cp437

----------
components: Library (Lib)
messages: 103496
nosy: ronaldoussoren
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Broken zipfile with  python 3.2 on osx
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Apr 18 22:44:10 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 18 Apr 2010 20:44:10 +0000
Subject: [New-bugs-announce] [issue8444] openssl version detection doesn't
	work properly when	using OSX SDK
In-Reply-To: <1271623450.52.0.5635482395.issue8444@psf.upfronthosting.co.za>
Message-ID: <1271623450.52.0.5635482395.issue8444@psf.upfronthosting.co.za>


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

setup.py detects the version of openssl by looking for openssl headers on a deduced search path. That path is not guaranteed to be equal to the real compiler search path, in particular not when building using the OSX 10.4 SDK on MacOSX 10.6: in that situation the compiler will use a header file with the following definition:

#define OPENSSL_VERSION_NUMBER  0x009070cfL

While setup.py reads the header file in /usr/include which contains this definition:

#define OPENSSL_VERSION_NUMBER  0x009080cfL

The actual version is below the sha256 cutoff in setup.py, while setup.py detects a newer version that is above that cutoff. That results in a tree where setup.py tries to build _sha256 using OpenSSL, but fails. That in turn results in a build of hashlib that doesn't work.


Note that this is a specific instance of Issue7724, but fixing this particular issue is probably easier than fixing the generic issue.

----------
assignee: tarek
components: Build, Distutils
messages: 103526
nosy: ronaldoussoren, tarek
priority: critical
severity: normal
stage: needs patch
status: open
title: openssl version detection doesn't work properly when using OSX SDK
type: compile error
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Apr 18 23:29:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 21:29:12 +0000
Subject: [New-bugs-announce] [issue8445] buildbot: test_ttk_guionly failures
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/builders/x86 Tiger trunk/builds/15/steps/test/logs/stdio

test test_ttk_guionly failed -- multiple errors occurred; run in verbose mode for details
Re-running test 'test_ttk_guionly' in verbose mode
test_horizontal_range (test_ttk.test_extensions.LabeledScaleTest) ... ok
test_initialization (test_ttk.test_extensions.LabeledScaleTest) ... ok
test_resize (test_ttk.test_extensions.LabeledScaleTest) ... ok
test_variable_change (test_ttk.test_extensions.LabeledScaleTest) ... ok
test_widget_destroy (test_ttk.test_extensions.LabeledScaleTest) ... ok
test_initialization (test_ttk.test_extensions.OptionMenuTest) ... ok
test_menu (test_ttk.test_extensions.OptionMenuTest) ... ok
test_widget_destroy (test_ttk.test_extensions.OptionMenuTest) ... ok
test_configure (test_ttk.test_style.StyleTest) ... ok
test_layout (test_ttk.test_style.StyleTest) ... ok
test_lookup (test_ttk.test_style.StyleTest) ... ok
test_map (test_ttk.test_style.StyleTest) ... ok
test_theme_use (test_ttk.test_style.StyleTest) ... ok
test_identify (test_ttk.test_widgets.WidgetTest) ... FAIL
test_widget_state (test_ttk.test_widgets.WidgetTest) ... ok
test_invoke (test_ttk.test_widgets.ButtonTest) ... ok
test_invoke (test_ttk.test_widgets.CheckbuttonTest) ... ok
test_invoke (test_ttk.test_widgets.RadiobuttonTest) ... ok
test_postcommand (test_ttk.test_widgets.ComboboxTest) ... ok
test_values (test_ttk.test_widgets.ComboboxTest) ... ok
test_virtual_event (test_ttk.test_widgets.ComboboxTest) ... ok
test_bbox (test_ttk.test_widgets.EntryTest) ... ok
test_identify (test_ttk.test_widgets.EntryTest) ... ok
test_revalidation (test_ttk.test_widgets.EntryTest) ... ok
test_validation (test_ttk.test_widgets.EntryTest) ... ok
test_validation_options (test_ttk.test_widgets.EntryTest) ... ok
test_add (test_ttk.test_widgets.PanedwindowTest) ... ok
test_forget (test_ttk.test_widgets.PanedwindowTest) ... ok
test_insert (test_ttk.test_widgets.PanedwindowTest) ... ok
test_pane (test_ttk.test_widgets.PanedwindowTest) ... ok
test_sashpos (test_ttk.test_widgets.PanedwindowTest) ... ok
test_custom_event (test_ttk.test_widgets.ScaleTest) ... ok
test_get (test_ttk.test_widgets.ScaleTest) ... ok
test_set (test_ttk.test_widgets.ScaleTest) ... ok
test_add_and_hidden (test_ttk.test_widgets.NotebookTest) ... ok
test_forget (test_ttk.test_widgets.NotebookTest) ... ok
test_index (test_ttk.test_widgets.NotebookTest) ... ok
test_insert (test_ttk.test_widgets.NotebookTest) ... ok
test_select (test_ttk.test_widgets.NotebookTest) ... ok
test_tab (test_ttk.test_widgets.NotebookTest) ... ok
test_tab_identifiers (test_ttk.test_widgets.NotebookTest) ... ERROR
test_tabs (test_ttk.test_widgets.NotebookTest) ... ok
test_traversal (test_ttk.test_widgets.NotebookTest) ... FAIL
test_bbox (test_ttk.test_widgets.TreeviewTest) ... ok
test_children (test_ttk.test_widgets.TreeviewTest) ... ok
test_column (test_ttk.test_widgets.TreeviewTest) ... ok
test_delete (test_ttk.test_widgets.TreeviewTest) ... ok
test_detach_reattach (test_ttk.test_widgets.TreeviewTest) ... ok
test_exists (test_ttk.test_widgets.TreeviewTest) ... ok
test_focus (test_ttk.test_widgets.TreeviewTest) ... ok
test_heading (test_ttk.test_widgets.TreeviewTest) ... ok
test_heading_callback (test_ttk.test_widgets.TreeviewTest) ... FAIL
test_index (test_ttk.test_widgets.TreeviewTest) ... ok
test_insert_item (test_ttk.test_widgets.TreeviewTest) ... ok
test_set (test_ttk.test_widgets.TreeviewTest) ... ok
test_tag_bind (test_ttk.test_widgets.TreeviewTest) ... ok
test_tag_configure (test_ttk.test_widgets.TreeviewTest) ... ok

======================================================================
ERROR: test_tab_identifiers (test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/lib-tk/test/test_ttk/test_widgets.py", line 560, in test_tab_identifiers
    self.assertEqual(self.nb.tab('@5,5'), self.nb.tab('current'))
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/lib-tk/ttk.py", line 922, in tab
    return _val_or_dict(kw, self.tk.call, self._w, "tab", tab_id)
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/lib-tk/ttk.py", line 318, in _val_or_dict
    res = func(*(args + options))
TclError: tab '@5,5' not found

======================================================================
FAIL: test_identify (test_ttk.test_widgets.WidgetTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/lib-tk/test/test_ttk/test_widgets.py", line 27, in test_identify
    self.assertEqual(self.widget.identify(5, 5), "label")
AssertionError: 'Button.button' != 'label'

======================================================================
FAIL: test_traversal (test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/lib-tk/test/test_ttk/test_widgets.py", line 721, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child1))
AssertionError: '.33941048' != '.33942584'

======================================================================
FAIL: test_heading_callback (test_ttk.test_widgets.TreeviewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/lib-tk/test/test_ttk/test_widgets.py", line 941, in test_heading_callback
    self.fail("The command associated to the treeview heading wasn't "
AssertionError: The command associated to the treeview heading wasn't invoked.

----------------------------------------------------------------------
Ran 57 tests in 0.361s

----------
keywords: buildbot
messages: 103534
nosy: haypo
severity: normal
status: open
title: buildbot: test_ttk_guionly failures
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr 19 00:12:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:12:37 +0000
Subject: [New-bugs-announce] [issue8446] buildbot: DeprecationWarning not
	raised for icglue	(test_py3kwarn.TestStdlibRemovals)
In-Reply-To: <1271628757.81.0.455065561336.issue8446@psf.upfronthosting.co.za>
Message-ID: <1271628757.81.0.455065561336.issue8446@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/builders/x86 Tiger trunk/builds/15/steps/test/logs/stdio

test_py3kwarn
test test_py3kwarn failed -- Traceback (most recent call last):
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/test/test_py3kwarn.py", line 387, in test_platform_specific_removals
    self.check_removal(module_name, optional=True)
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/test/test_py3kwarn.py", line 376, in check_removal
    .format(module_name))
AssertionError: DeprecationWarning not raised for icglue

Re-running test 'test_py3kwarn' in verbose mode
test_backquote (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_buffer (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_builtin_function_or_method_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_cell_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_code_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_dict_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_file_xreadlines (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_forbidden_names (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_frame_attributes (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_hash_inheritance (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_methods_members (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_object_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_operator (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_paren_arg_names (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_slice_methods (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_softspace (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_sort_cmp_arg (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_sys_exc_clear (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_tuple_parameter_unpacking (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_type_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok
test_mutablestring_removal (test.test_py3kwarn.TestStdlibRemovals) ... ok
test_optional_module_removals (test.test_py3kwarn.TestStdlibRemovals) ... ok
test_os_path_walk (test.test_py3kwarn.TestStdlibRemovals) ... ok
test_platform_independent_removals (test.test_py3kwarn.TestStdlibRemovals) ... ok
test_platform_specific_removals (test.test_py3kwarn.TestStdlibRemovals) ... FAIL
test_reduce_move (test.test_py3kwarn.TestStdlibRemovals) ... ok

======================================================================
FAIL: test_platform_specific_removals (test.test_py3kwarn.TestStdlibRemovals)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/test/test_py3kwarn.py", line 387, in test_platform_specific_removals
    self.check_removal(module_name, optional=True)
  File "/Users/db3l/buildarea/trunk.bolen-tiger/build/Lib/test/test_py3kwarn.py", line 376, in check_removal
    .format(module_name))
AssertionError: DeprecationWarning not raised for icglue

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

----------
keywords: buildbot
messages: 103537
nosy: haypo
severity: normal
status: open
title: buildbot: DeprecationWarning not raised for icglue (test_py3kwarn.TestStdlibRemovals)
versions: Python 3.2

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

From report at bugs.python.org  Mon Apr 19 00:23:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:23:09 +0000
Subject: [New-bugs-announce] [issue8447] buildbot: test_httpservers failure
	(No module named	operator)
In-Reply-To: <1271629389.65.0.354940045225.issue8447@psf.upfronthosting.co.za>
Message-ID: <1271629389.65.0.354940045225.issue8447@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/builders/x86 Tiger 3.1/builds/16/steps/test/logs/stdio

test_httpservers
[28139 refs]
[28139 refs]
[28139 refs]
Traceback (most recent call last):
  File "/private/tmp/tmpqYIZuO/cgi-bin/file2.py", line 2, in <module>
    import cgi
  File "/Users/db3l/buildarea/3.1.bolen-tiger/build/Lib/cgi.py", line 34, in <module>
    from operator import attrgetter
ImportError: No module named operator
[28142 refs]
Warning: os.environ was modified by test_httpservers
test test_httpservers failed -- Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.1.bolen-tiger/build/Lib/test/test_httpservers.py", line 380, in test_post
    self.assertEquals(res.read(), b'1, python, 123456\n')
AssertionError: b'' != b'1, python, 123456\n'

----------
keywords: buildbot
messages: 103540
nosy: haypo
severity: normal
status: open
title: buildbot: test_httpservers failure (No module named operator)
versions: Python 3.1

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

From report at bugs.python.org  Mon Apr 19 00:27:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Apr 2010 22:27:58 +0000
Subject: [New-bugs-announce] [issue8448] buildbot: test_subprocess failure
	(test_no_leaking, Broken pipe)
In-Reply-To: <1271629678.61.0.824360658357.issue8448@psf.upfronthosting.co.za>
Message-ID: <1271629678.61.0.824360658357.issue8448@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/builders/sparc Debian 3.1/builds/49/steps/test/logs/stdio

test_subprocess
* ob
object  : <refcnt 0 at 0x1038220>
type    : str
refcount: 0
address : 0x1038220
* op->_ob_prev->_ob_next
object  : <refcnt 0 at 0x1038220>
type    : str
refcount: 0
address : 0x1038220
* op->_ob_next->_ob_prev
object  : [29082 refs]
.
    this bit of output is from a test of stdout in a different process ...
.
    this bit of output is from a test of stdout in a different process ...
test test_subprocess failed -- Traceback (most recent call last):
  File "/home/pybot/buildarea-sid/3.1.klose-debian-sparc/build/Lib/test/test_subprocess.py", line 459, in test_no_leaking
    data = p.communicate(b"lime")[0]
  File "/home/pybot/buildarea-sid/3.1.klose-debian-sparc/build/Lib/subprocess.py", line 727, in communicate
    return self._communicate(input)
  File "/home/pybot/buildarea-sid/3.1.klose-debian-sparc/build/Lib/subprocess.py", line 1203, in _communicate
    stdout, stderr = self._communicate_with_poll(input)
  File "/home/pybot/buildarea-sid/3.1.klose-debian-sparc/build/Lib/subprocess.py", line 1269, in _communicate_with_poll
    input_offset += os.write(fd, chunk)
OSError: [Errno 32] Broken pipe

----------
keywords: buildbot
messages: 103542
nosy: haypo
severity: normal
status: open
title: buildbot: test_subprocess failure (test_no_leaking, Broken pipe)
versions: Python 3.1

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

From report at bugs.python.org  Mon Apr 19 00:45:31 2010
From: report at bugs.python.org (mschu)
Date: Sun, 18 Apr 2010 22:45:31 +0000
Subject: [New-bugs-announce] [issue8450] httplib: false BadStatusLine()
	raised
In-Reply-To: <1271630731.08.0.327097174192.issue8450@psf.upfronthosting.co.za>
Message-ID: <1271630731.08.0.327097174192.issue8450@psf.upfronthosting.co.za>


New submission from mschu <mschu.dev at gmail.com>:

Independent from HTTP strict, an invalid BadStatusLine() exception is raised when a keep-alive connection exceeds its timeout:

client->server <request>
s->c <answer>
<connection timeout passing>
s->c: FIN/ACK
c->s: ACK
c->s: <get request>/FIN
s->c: RST (without data)

which raises the exception.

An easy workaround is to either poll information often enough for the server to not close the connection or close and reopen the connection. However, the exception is misleading.

----------
components: Library (Lib)
messages: 103545
nosy: mschu
severity: normal
status: open
title: httplib: false BadStatusLine() raised
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Apr 19 07:26:40 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Mon, 19 Apr 2010 05:26:40 +0000
Subject: [New-bugs-announce] [issue8451] syslog.syslog('msg') logs message
	with ident "python".
In-Reply-To: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>
Message-ID: <1271654800.68.0.746629224445.issue8451@psf.upfronthosting.co.za>


New submission from Sean Reifschneider <jafo at tummy.com>:

As discussed in this thread:

http://mail.python.org/pipermail/python-dev/2010-March/098500.html

The syslog module is using the C argv[0] as the program name, not the python sys.argv[0].  So, in most cases this means that unless you explicitly set a ident, you get "python" as the ident.  Not entirely helpful.

This patch:

 - Makes openlog arguments keyword args.
 - Makes openlog ident argument optional.
 - If ident is not passed to ident, basename(sys.argv[0]) is used.
 - The first call to syslog.syslog() calls ident() with no options
   (if it hasn't previously been called).
 - Variously related documentation changes.

"make test" with this succeeds.

I think this is ready to go into the trunk, but would like a review.  I'll check with the release maintainer about if this is appropriate for 2.7b.

Sean

----------
components: Library (Lib)
keywords: easy, needs review, patch
messages: 103555
nosy: jafo
priority: normal
severity: normal
stage: patch review
status: open
title: syslog.syslog('msg') logs message with ident "python".
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Apr 19 08:30:33 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 19 Apr 2010 06:30:33 +0000
Subject: [New-bugs-announce] [issue8453] build_installer.py breaks bzip
	compilation
In-Reply-To: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>
Message-ID: <1271658633.93.0.462061502654.issue8453@psf.upfronthosting.co.za>


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

The current build_installer fails to build dependencies, e.g. with

gcc-4.0 -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -o bzip2 bzip2.o -L. -lbz2
collect2: cannot find 'ld'
collect2: cannot find 'ld'
lipo: can't open input file: /var/tmp//cc8o5UUU.out (No such file or directory)

For the full buildlog, see

http://www.python.org/dev/buildbot/builders/2.7.dmg/builds/9/steps/compile/logs/stdio

----------
assignee: ronaldoussoren
messages: 103557
nosy: loewis, ronaldoussoren
severity: normal
status: open
title: build_installer.py breaks bzip compilation
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr 19 13:27:11 2010
From: report at bugs.python.org (Perbandt)
Date: Mon, 19 Apr 2010 11:27:11 +0000
Subject: [New-bugs-announce] [issue8454] unittest Module Problem with
	different Kinds of Invocation
In-Reply-To: <1271676431.2.0.515537507325.issue8454@psf.upfronthosting.co.za>
Message-ID: <1271676431.2.0.515537507325.issue8454@psf.upfronthosting.co.za>


New submission from Perbandt <adalbert.perbandt at infineon.com>:

I just figured out a problem with the Python module 'unittest.py',
version 1.63.

The function '__init__' behaves a bit strange in certain circumstances.
It is called either directly from the command line or it is called when
unit tests are to be executeded from a script.
The latter form is used by the pyunit Ant task. It generates such a
python script an passes it into a python process. Example:

import unittest
s = open('PyUnit-report.log', 'w')
unittest.main(module=None,
              defaultTest=None,       
         argv=[plugins.Excel_5P_Import_Test','plugins.HDL_Import_Test',
                    'plugins.IPXact_Import_Test'],
              testRunner=unittest.TextTestRunner(stream=s))
 
The paroblem with this way of activating the unittest module is that
in the function parseArgs (lines 775 to 796) the first element from
argv is skipped:
 
778: options, args = getopt.getopt(argv[1:], 'hHvq',
779                                ['help','verbose','quiet'])
 
This way the first test module from the list of test modules passed in
by pyunit gets lost.

After analyzing your code I think it would be better to do the
skipping of the first element from argv directly in the __init__
method of the class 'TestProgram' at lines 760, 761. The code there
should look as follows:
 
760     if argv is None:
761         argv = sys.argv[1:]
 
This code would skip the first element from the argv array only when
the __init__ method would be called indirectly from the command line.

----------
components: Extension Modules
messages: 103576
nosy: AP
severity: normal
status: open
title: unittest Module Problem with different Kinds of Invocation
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Mon Apr 19 13:29:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 11:29:04 +0000
Subject: [New-bugs-announce] [issue8455] buildbot: test_urllib2_localnet
	failures (Connection	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/builders/x86 Tiger 3.x/builds/25/steps/test/logs/stdio

test_urllib2_localnet
test test_urllib2_localnet failed -- multiple errors occurred; run in verbose mode for details
Re-running test test_urllib2_localnet in verbose mode
test_proxy_qop_auth_int_works_or_throws_urlerror (test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_proxy_qop_auth_works (test.test_urllib2_localnet.ProxyAuthTests) ... ERROR
test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... ERROR
test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... ERROR
test_200 (test.test_urllib2_localnet.TestUrlopen) ... ok
test_200_with_parameters (test.test_urllib2_localnet.TestUrlopen) ... ok
test_404 (test.test_urllib2_localnet.TestUrlopen) ... ok
test_bad_address (test.test_urllib2_localnet.TestUrlopen) ... ok
test_basic (test.test_urllib2_localnet.TestUrlopen) ... ok
test_chunked (test.test_urllib2_localnet.TestUrlopen) ... ok
test_geturl (test.test_urllib2_localnet.TestUrlopen) ... ok
test_info (test.test_urllib2_localnet.TestUrlopen) ... ok
test_redirection (test.test_urllib2_localnet.TestUrlopen) ... ok
test_sending_headers (test.test_urllib2_localnet.TestUrlopen) ... ok

======================================================================
ERROR: test_proxy_qop_auth_works (test.test_urllib2_localnet.ProxyAuthTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1072, in do_open
    h.request(req.get_method(), req.selector, req.data, headers)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 938, in request
    self._send_request(method, url, body, headers)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 976, in _send_request
    self.endheaders(body)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 934, in endheaders
    self._send_output(message_body)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 788, in _send_output
    self.send(msg)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 729, in send
    self.connect()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 711, in connect
    self.timeout, self.source_address)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/socket.py", line 321, in create_connection
    raise error(msg)
socket.error: [Errno 61] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_urllib2_localnet.py", line 278, in test_proxy_qop_auth_works
    result = self.opener.open(self.URL)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 349, in open
    response = self._open(req, data)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 367, in _open
    '_open', req)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 327, in _call_chain
    result = func(*args)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1090, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1075, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [Errno 61] Connection refused>

======================================================================
ERROR: test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1072, in do_open
    h.request(req.get_method(), req.selector, req.data, headers)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 938, in request
    self._send_request(method, url, body, headers)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 976, in _send_request
    self.endheaders(body)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 934, in endheaders
    self._send_output(message_body)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 788, in _send_output
    self.send(msg)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 729, in send
    self.connect()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 711, in connect
    self.timeout, self.source_address)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/socket.py", line 321, in create_connection
    raise error(msg)
socket.error: [Errno 61] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_urllib2_localnet.py", line 266, in test_proxy_with_bad_password_raises_httperror
    self.URL)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 456, in assertRaises
    callableObj(*args, **kwargs)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 349, in open
    response = self._open(req, data)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 367, in _open
    '_open', req)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 327, in _call_chain
    result = func(*args)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1090, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1075, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [Errno 61] Connection refused>

======================================================================
ERROR: test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1072, in do_open
    h.request(req.get_method(), req.selector, req.data, headers)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 938, in request
    self._send_request(method, url, body, headers)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 976, in _send_request
    self.endheaders(body)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 934, in endheaders
    self._send_output(message_body)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 788, in _send_output
    self.send(msg)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 729, in send
    self.connect()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/http/client.py", line 711, in connect
    self.timeout, self.source_address)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/socket.py", line 321, in create_connection
    raise error(msg)
socket.error: [Errno 61] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_urllib2_localnet.py", line 272, in test_proxy_with_no_password_raises_httperror
    self.URL)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py", line 456, in assertRaises
    callableObj(*args, **kwargs)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 349, in open
    response = self._open(req, data)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 367, in _open
    '_open', req)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 327, in _call_chain
    result = func(*args)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1090, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/urllib/request.py", line 1075, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [Errno 61] Connection refused>

----------------------------------------------------------------------
Ran 14 tests in 10.076s

----------
components: Library (Lib), Tests
keywords: buildbot
messages: 103577
nosy: haypo
severity: normal
status: open
title: buildbot: test_urllib2_localnet failures (Connection refused) on Tiger buildbot
versions: Python 3.2

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

From report at bugs.python.org  Mon Apr 19 13:31:32 2010
From: report at bugs.python.org (AndiDog)
Date: Mon, 19 Apr 2010 11:31:32 +0000
Subject: [New-bugs-announce] [issue8456] sqlite3.connect documentation is
	incorrect
In-Reply-To: <1271676692.22.0.105359668933.issue8456@psf.upfronthosting.co.za>
Message-ID: <1271676692.22.0.105359668933.issue8456@psf.upfronthosting.co.za>


New submission from AndiDog <AndiDog at web.de>:

The sqlite3.connect documentation (keyword args) is incorrect:

    sqlite3.connect(database[, timeout, isolation_level, detect_types, factory])

As opposed to the C implementation:

    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O|diOiOi", kwlist,
                                     &database, &timeout, detect_types, &isolation_level, &check_same_thread, &factory, &cached_statements))
    {
        return NULL; 
   }

----------
assignee: georg.brandl
components: Documentation
messages: 103578
nosy: AndiDog, georg.brandl
severity: normal
status: open
title: sqlite3.connect documentation is incorrect
versions: Python 2.6

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

From report at bugs.python.org  Mon Apr 19 13:35:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 11:35:11 +0000
Subject: [New-bugs-announce] [issue8457] buildbot: test_asynchat and
	test_smtplib failures on	Tiger: [Errno 9] Bad file descriptor
In-Reply-To: <1271676911.81.0.0770773207045.issue8457@psf.upfronthosting.co.za>
Message-ID: <1271676911.81.0.0770773207045.issue8457@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/builders/x86 Tiger 2.6/builds/9/steps/test/logs/stdio

test_asynchat
test test_asynchat produced unexpected output:
**********************************************************************
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a04f8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0c38> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a09f8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0b78> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a07f8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0c38> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a09f8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0cf8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a07f8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0c38> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a07b8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0cb8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a04f8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0c38> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a07b8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_asynchat.echo_client at 0x45a0d78> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])

**********************************************************************

test_smtplib
test test_smtplib produced unexpected output:
**********************************************************************
error: uncaptured python exception, closing channel <test.test_smtplib.SimSMTPChannel 127.0.0.1:55603 at 0x4323cb8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_smtplib.SimSMTPChannel 127.0.0.1:55606 at 0x43236f8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])
error: uncaptured python exception, closing channel <test.test_smtplib.SimSMTPChannel 127.0.0.1:55609 at 0x43152b8> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|readwrite|107] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/asyncore.py|handle_expt_event|441] [<string>|getsockopt|1] [/Users/db3l/buildarea/2.6.bolen-tiger/build/Lib/socket.py|_dummy|165])

**********************************************************************

----------
components: Library (Lib), Tests
messages: 103579
nosy: db3l, haypo
severity: normal
status: open
title: buildbot: test_asynchat and test_smtplib failures on Tiger: [Errno 9] Bad file descriptor
versions: Python 2.6

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

From report at bugs.python.org  Mon Apr 19 13:53:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 11:53:46 +0000
Subject: [New-bugs-announce] [issue8458] buildbot: test_cmd_line failure on
	Tiger: [Errno 9] Bad	file descriptor
In-Reply-To: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>
Message-ID: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>


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

The error only occured once, and it was not reproduced when test_cmd_line was rerunning in verbose mode.

http://www.python.org/dev/buildbot/builders/x86 Tiger 3.x/builds/25/steps/test/logs/stdio

test test_cmd_line failed -- Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_cmd_line.py", line 58, in test_q
    self.verify_valid_flag('-Qold')
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_cmd_line.py", line 49, in verify_valid_flag
    data = self.start_python(cmd_line)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_cmd_line.py", line 34, in start_python
    p = spawn_python(*args)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/script_helper.py", line 29, in spawn_python
    stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/subprocess.py", line 694, in __init__
    self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor

Re-running test test_cmd_line in verbose mode
test_directories (test.test_cmd_line.CmdLineTest) ... ok
test_large_PYTHONPATH (test.test_cmd_line.CmdLineTest) ... ok
test_optimize (test.test_cmd_line.CmdLineTest) ... ok
test_q (test.test_cmd_line.CmdLineTest) ... ok
test_run_code (test.test_cmd_line.CmdLineTest) ... ok
test_run_module (test.test_cmd_line.CmdLineTest) ... ok
test_run_module_bug1764407 (test.test_cmd_line.CmdLineTest) ... ok
test_site_flag (test.test_cmd_line.CmdLineTest) ... ok
test_unbuffered_input (test.test_cmd_line.CmdLineTest) ... ok
test_unbuffered_output (test.test_cmd_line.CmdLineTest) ... ok
test_usage (test.test_cmd_line.CmdLineTest) ... ok
test_verbose (test.test_cmd_line.CmdLineTest) ... ok
test_version (test.test_cmd_line.CmdLineTest) ... ok

----------------------------------------------------------------------
Ran 13 tests in 3.860s

OK

----------
components: Library (Lib), Tests
keywords: buildbot
messages: 103583
nosy: db3l, haypo
severity: normal
status: open
title: buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad file descriptor
versions: Python 3.2

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

From report at bugs.python.org  Mon Apr 19 14:24:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 12:24:35 +0000
Subject: [New-bugs-announce] [issue8459] buildbot: test_select failure on
	Python 2.6, Windows
In-Reply-To: <1271679875.89.0.922749709725.issue8459@psf.upfronthosting.co.za>
Message-ID: <1271679875.89.0.922749709725.issue8459@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/builders/x86 XP-5 2.6/builds/147/steps/test/logs/stdio

test_select
test test_select failed -- Traceback (most recent call last):
  File "C:\buildslave\2.6.moore-windows\build\lib\test\test_select.py", line 24, in test_returned_list_identity
    r, w, x = select.select([], [], [], 1)
error: (10022, 'An invalid argument was supplied')

----------
components: Extension Modules, Tests
keywords: buildbot
messages: 103587
nosy: haypo
severity: normal
status: open
title: buildbot: test_select failure on Python 2.6, Windows
versions: Python 2.6

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

From report at bugs.python.org  Mon Apr 19 14:42:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 12:42:26 +0000
Subject: [New-bugs-announce] [issue8460] Set a timeout in test_urllib2net
In-Reply-To: <1271680946.0.0.750800193746.issue8460@psf.upfronthosting.co.za>
Message-ID: <1271680946.0.0.750800193746.issue8460@psf.upfronthosting.co.za>


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

If an URL doesn't answer, the whole test hung. Many buildbots turned red because an URL (maybe ftp://ftp.kernel.org/pub/linux/kernel/README) didn't answer during few minutes (it works again).

We should add a timeout, eg. 5 minutes. I don't know what to do on timeout: ignore the test? skip the test? Ignore should be fine.

----------
components: Library (Lib), Tests
messages: 103590
nosy: haypo
severity: normal
status: open
title: Set a timeout in test_urllib2net
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Apr 19 15:43:42 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 19 Apr 2010 13:43:42 +0000
Subject: [New-bugs-announce] [issue8461] PythonLauncher universal build
	fails due to missing -arch	and -sysroot
In-Reply-To: <1271684622.87.0.695093789846.issue8461@psf.upfronthosting.co.za>
Message-ID: <1271684622.87.0.695093789846.issue8461@psf.upfronthosting.co.za>


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

Fixes for Issue8366 corrected build failures with universal builds on OS X due to changes in the settings of CFLAGS and BASECFLAGS, which had caused -arch values to be added to both CFLAGS and BASECFLAGS.  The Mac Makefile for the PythonLauncher app needs to be changed as well, otherwise universal builds can now fail with errors like:

ld warning: in FileSettings.o, file is not of required architecture
ld warning: in MyAppDelegate.o, file is not of required architecture
ld warning: in MyDocument.o, file is not of required architecture
ld warning: in PreferencesWindowController.o, file is not of required architecture
ld warning: in doscript.o, file is not of required architecture
ld warning: in main.o, file is not of required architecture
Undefined symbols for architecture i386:
  "_main", referenced from:
      __start in crt1.o
ld: symbol(s) not found for architecture i386

The attached patch corrects the problem.

----------
assignee: ronaldoussoren
components: Macintosh
files: issue-python-launcher-arch.txt
messages: 103594
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: PythonLauncher universal build fails due to missing -arch and -sysroot
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16987/issue-python-launcher-arch.txt

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

From report at bugs.python.org  Mon Apr 19 17:34:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Apr 2010 15:34:47 +0000
Subject: [New-bugs-announce] [issue8462] raise test_support.TestSkipped() is
	used outside main() /	test_main()
In-Reply-To: <1271691287.55.0.252586227307.issue8462@psf.upfronthosting.co.za>
Message-ID: <1271691287.55.0.252586227307.issue8462@psf.upfronthosting.co.za>


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

unittest in Python 2.6 has to SkipTest exception, but test_support has a TestSkipped which can be used to skip the whole file.

TestSkipped should not be used in a test function. Following tests have to be fixed: test_decimal, test_ioctl, test_largefile, test_nis, test_ossaudiodev, test_pty. Replace raise by return. To dislpay, print >>sys.stderr can be used.

----------
components: Tests
messages: 103609
nosy: haypo
severity: normal
status: open
title: raise test_support.TestSkipped() is used outside main() / test_main()
versions: Python 2.6

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

From report at bugs.python.org  Mon Apr 19 18:25:25 2010
From: report at bugs.python.org (Lino Mastrodomenico)
Date: Mon, 19 Apr 2010 16:25:25 +0000
Subject: [New-bugs-announce] [issue8463] shutil.make_archive() supports bz2,
	but it's not documented
In-Reply-To: <1271694325.38.0.340874793293.issue8463@psf.upfronthosting.co.za>
Message-ID: <1271694325.38.0.340874793293.issue8463@psf.upfronthosting.co.za>


New submission from Lino Mastrodomenico <l.mastrodomenico at gmail.com>:

The new function shutil.make_archive() supports bzip2 compression using "bztar" as format parameter, but neither the documentation nor the docstring mention it (all the other compression formats are correctly listed).

----------
assignee: georg.brandl
components: Documentation
messages: 103614
nosy: georg.brandl, mastrodomenico
severity: normal
status: open
title: shutil.make_archive() supports bz2, but it's not documented
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Apr 19 19:39:00 2010
From: report at bugs.python.org (Lino Mastrodomenico)
Date: Mon, 19 Apr 2010 17:39:00 +0000
Subject: [New-bugs-announce] [issue8464] tarfile creates tarballs with
	execute permissions set
In-Reply-To: <1271698740.9.0.952847416624.issue8464@psf.upfronthosting.co.za>
Message-ID: <1271698740.9.0.952847416624.issue8464@psf.upfronthosting.co.za>


New submission from Lino Mastrodomenico <l.mastrodomenico at gmail.com>:

tarfile.open(filename, "w|") creates a tar file with execute permissions set, if filename doesn't exist (i.e. it uses mode 0777 minus the umask). It should instead use mode 0666 minus the umask, which is what happens when using mode "w:..." instead of "w|...".

AFAICT this bug has always been present since the introduction of tarfile in Python 2.3, but it may soon become more noticeable since the new function shutil.make_archive() in Python 2.7 and 3.2 uses tarfile with mode "w|".

I have attached a patch for the trunk.

----------
components: Library (Lib)
files: tarfile.diff
keywords: patch
messages: 103617
nosy: mastrodomenico
severity: normal
status: open
title: tarfile creates tarballs with execute permissions set
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16991/tarfile.diff

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

From report at bugs.python.org  Mon Apr 19 23:11:17 2010
From: report at bugs.python.org (Aaron Sherman)
Date: Mon, 19 Apr 2010 21:11:17 +0000
Subject: [New-bugs-announce] [issue8465] Backreferences vs. escapes: a
	silent failure solved
In-Reply-To: <1271711477.02.0.868706319352.issue8465@psf.upfronthosting.co.za>
Message-ID: <1271711477.02.0.868706319352.issue8465@psf.upfronthosting.co.za>


New submission from Aaron Sherman <ajs at ajs.com>:

I tested this under 2.6 and 3.1. Under both, the common mistake that I'm sure many others have made, and which cost me quite some time today was:

 re.sub(r'(foo)bar', '\1baz', 'foobar')

It's obvious, I'm sure, to many reading this that the second "r" was left out before the replacement spec. It's probably obvious that this is going to happen quite a lot, and there are many edge cases which are equally baffling to the uninitiated (e.g. \8, \418 and \1111)

In order to avoid this, I'd like to request that such usage be deprecated, leaving only numeric escapes of the form matched by r'\\[0-7][0-7][0-7]?(?!\d)' as valid, non-deprecated uses (e.g. \01 or \111 are fine). Let's look at what that would do:

Right now, the standard library uses escape sequences with \n where n is a single digit in a handful of places like sndhdr.py and difflib.py. These are certainly not widespread enough to consider this a common usage, but certainly those few would have to change to add a leading zero before the digit.

OK, so the specific requested feature is that \xxx produces a warning where xxx is:

* any single digit or
* any invalid sequence of two or three digits (e.g containing 8 or 9) or
* any sequence of 4 or more digits

... guiding the user to the more explicit \01, \x01 or, if they intended a literal backslash, the r notation.

If you wish to go a step further, I'd suggest adding a no-op escape \e such that:

 \41\e1

would print "!1". Otherwise, there's no clean way to halt the interpretation of a digit-based escape sequence.

----------
components: Regular Expressions, Unicode
messages: 103640
nosy: Aaron.Sherman
severity: normal
status: open
title: Backreferences vs. escapes: a silent failure solved
type: feature request
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Tue Apr 20 11:28:23 2010
From: report at bugs.python.org (Anthon van der Neut)
Date: Tue, 20 Apr 2010 09:28:23 +0000
Subject: [New-bugs-announce] [issue8466] typo in tp_name of cStringIO
In-Reply-To: <1271755703.18.0.103883949918.issue8466@psf.upfronthosting.co.za>
Message-ID: <1271755703.18.0.103883949918.issue8466@psf.upfronthosting.co.za>


New submission from Anthon van der Neut <anthon at mnt.org>:

if you execute the following code from 
  cStringIO import StringIO
  x = StringIO()
  x.get_value()
you will see that the AttributeError line has a typo
it displays 'cStringIO.StringO' instead of 'cStringIO.StringIO'
this error is in line 529 of the Modules/cStringIO.c code (of 2.7b1)

----------
components: Library (Lib)
messages: 103687
nosy: anthon
severity: normal
status: open
title: typo in tp_name of cStringIO
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Apr 20 14:02:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 12:02:55 +0000
Subject: [New-bugs-announce] [issue8467] subprocess: surrogates of the error
	message (Python	implementation on non-Windows)
In-Reply-To: <1271764975.75.0.223846589239.issue8467@psf.upfronthosting.co.za>
Message-ID: <1271764975.75.0.223846589239.issue8467@psf.upfronthosting.co.za>


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

On a non-Windows OS where _posixsubprocess is missing (subprocess uses the pure Python implementation), if the child fails with a Python exception and the exception message contains a surrogate character, message.encode() fails silently (exception while processing exceptions are just ignored).

Surrogates should be passed to the parent process: surrogatepass can be used for that. Attached patch implements this idea with an unit test.

--

_posixsubprocess is not concerned because it writes an empty message for OSError (the parent process calls os.strerror() to get the message) or "Exception occurred in preexec_fn." (pure ASCII string) for RuntimeError.

On Windows, _subprocess.CreateProcess() calls PyErr_SetFromWindowsErr() on failure without the filename. So there is no surrogates here.

----------
components: Library (Lib)
files: subprocess_errmsg.patch
keywords: patch
messages: 103694
nosy: haypo
severity: normal
status: open
title: subprocess: surrogates of the error message (Python implementation on non-Windows)
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17005/subprocess_errmsg.patch

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

From report at bugs.python.org  Tue Apr 20 14:12:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 12:12:49 +0000
Subject: [New-bugs-announce] [issue8468] bz2: support surrogates in filename,
	and bytes/bytearray filename
In-Reply-To: <1271765569.25.0.596764444797.issue8468@psf.upfronthosting.co.za>
Message-ID: <1271765569.25.0.596764444797.issue8468@psf.upfronthosting.co.za>


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

bz2 uses "s" format to parse the filename argument: it uses the default (unicode) encoding to encode the unicode filename to a byte string. It should use the default file system encoding instead.

It should also support surrogates in unicode filename and bytes/bytearray filenames.

Attached patch uses PyUnicode_FSConverter() to implement that.

----------
components: Library (Lib), Unicode
files: bz2_surrogates.patch
keywords: patch
messages: 103696
nosy: haypo
severity: normal
status: open
title: bz2: support surrogates in filename, and bytes/bytearray filename
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17006/bz2_surrogates.patch

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

From report at bugs.python.org  Tue Apr 20 14:30:50 2010
From: report at bugs.python.org (Mads Kiilerich)
Date: Tue, 20 Apr 2010 12:30:50 +0000
Subject: [New-bugs-announce] [issue8469] struct - please make sizes explicit
In-Reply-To: <1271766650.13.0.432849451622.issue8469@psf.upfronthosting.co.za>
Message-ID: <1271766650.13.0.432849451622.issue8469@psf.upfronthosting.co.za>


New submission from Mads Kiilerich <mads at kiilerich.com>:

The struct module is often used (at least by me) to implement protocols  and binary formats. That makes the exact sizes (number of bits/bytes) of the different types very important.

Please add the sizes to for example the table on http://docs.python.org/library/struct . I know that some of the sizes varies with the platform, and in these cases it is fine to define it in terms of the C types, but for Python programmers writing cross-platform code such variable types doesn't matter and are "never" used. (I assume that it is possible to specify all possible types in a cross-platform way, but I'm not sure and the answer is not obvious from the documentation.)

----------
components: Library (Lib)
messages: 103699
nosy: kiilerix
severity: normal
status: open
title: struct - please make sizes explicit
versions: Python 2.6

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

From report at bugs.python.org  Tue Apr 20 17:29:09 2010
From: report at bugs.python.org (phep)
Date: Tue, 20 Apr 2010 15:29:09 +0000
Subject: [New-bugs-announce] [issue8470] Let cmd.cmd.intro be unicode
	friendly
In-Reply-To: <1271777349.17.0.192920763608.issue8470@psf.upfronthosting.co.za>
Message-ID: <1271777349.17.0.192920763608.issue8470@psf.upfronthosting.co.za>


New submission from phep <patrice.pillot at teletopie.net>:

Since cmd.cmdloop() says:

# ...
self.stdout.write(str(self.intro)+"\n")
# ....

one cannot use unicode characters in cmd.cmd.intro, for example the copyright (?) character (u'\xa9').

TIA

----------
messages: 103726
nosy: phep
severity: normal
status: open
title: Let cmd.cmd.intro be unicode friendly
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Tue Apr 20 17:41:13 2010
From: report at bugs.python.org (Lennart Regebro)
Date: Tue, 20 Apr 2010 15:41:13 +0000
Subject: [New-bugs-announce] [issue8471] Unicode returns in doctest can make
	subsequent tests fail
In-Reply-To: <1271778073.88.0.928922878854.issue8471@psf.upfronthosting.co.za>
Message-ID: <1271778073.88.0.928922878854.issue8471@psf.upfronthosting.co.za>


New submission from Lennart Regebro <regebro at gmail.com>:

If we return unicode, SpoofOut's buf variable becomes automagically converted to unicode. This means all subsequent output becomes converted to unicode, and if the output contains non-ascii characters that fails.

That means that 

    >>> print u'\xe9'.encode('utf-8')
    ?

Will work just fine, but

    >>> print u'abc'
    abc

    >>> print u'\xe9'.encode('utf-8')
    ?

Will fail.

    
The reason for this is that when "resetting" the doctest output only a truncate(0) is done, so the buf variable will continue to be unicode. I include tests + a patch that will set self.buf to '' if empty when trunkated. Other options are also possible, like changing the .truncate(0) to a .buf = '' but that's ugly, or adding a reset() method on SpoofOUt.

----------
components: Extension Modules, Tests
files: doctest_unicode.patch
keywords: patch
messages: 103728
nosy: lregebro
severity: normal
status: open
title: Unicode returns in doctest can make subsequent tests fail
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file17007/doctest_unicode.patch

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

From report at bugs.python.org  Tue Apr 20 18:37:35 2010
From: report at bugs.python.org (Alexander Myodov)
Date: Tue, 20 Apr 2010 16:37:35 +0000
Subject: [New-bugs-announce] [issue8472] itertools.filterfalse() function
	missing
In-Reply-To: <1271781455.61.0.874507707977.issue8472@psf.upfronthosting.co.za>
Message-ID: <1271781455.61.0.874507707977.issue8472@psf.upfronthosting.co.za>


New submission from Alexander Myodov <amyodov at gmail.com>:

The documentation (eg at http://docs.python.org/release/2.6.5/library/functions.html#filter) tells that there should be an itertools.filterfalse() function complementary to builtin filter() function, that returns the list of elements (instead of the iterator over them, as ifilterfalse() does), for which the condition is failed. This function is absent from Python 2.x branch (though obviously is present in 3.x, as all the i* functions are renamed to their non-i* counterparts).

----------
messages: 103733
nosy: honeyman
severity: normal
status: open
title: itertools.filterfalse() function missing
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Apr 20 18:40:17 2010
From: report at bugs.python.org (Lennart Regebro)
Date: Tue, 20 Apr 2010 16:40:17 +0000
Subject: [New-bugs-announce] [issue8473] doctest fails if you have
	inconsistent lineendings
In-Reply-To: <1271781617.9.0.374951389596.issue8473@psf.upfronthosting.co.za>
Message-ID: <1271781617.9.0.374951389596.issue8473@psf.upfronthosting.co.za>


New submission from Lennart Regebro <regebro at gmail.com>:

If the doctest file has both Windows and unix lineendings you get an error. Yeah, I know, it's not a serious bug, but it's also easy to fix.

Attached patch with test. Seems to not be an issue on Python 3.

----------
components: Extension Modules, Tests
files: doctest_lineendings.patch
keywords: patch
messages: 103735
nosy: lregebro
severity: normal
status: open
title: doctest fails if you have inconsistent lineendings
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file17008/doctest_lineendings.patch

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

From report at bugs.python.org  Tue Apr 20 19:58:40 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Tue, 20 Apr 2010 17:58:40 +0000
Subject: [New-bugs-announce] [issue8474] Duplicate tests in email test suite
In-Reply-To: <1271786320.05.0.85623215859.issue8474@psf.upfronthosting.co.za>
Message-ID: <1271786320.05.0.85623215859.issue8474@psf.upfronthosting.co.za>


New submission from Shashwat Anand <anand.shashwat at gmail.com>:

In trunk/Lib/email/test/test_email.py, test_default_cte() is repeated twice, one being the subset of other. Attached patch resolve the duplicity.

----------
components: Library (Lib)
files: test_email.patch
keywords: patch
messages: 103739
nosy: barry, l0nwlf, r.david.murray
severity: normal
status: open
title: Duplicate tests in email test suite
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17009/test_email.patch

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

From report at bugs.python.org  Wed Apr 21 00:53:24 2010
From: report at bugs.python.org (David Bolen)
Date: Tue, 20 Apr 2010 22:53:24 +0000
Subject: [New-bugs-announce] [issue8475] build-installer fix for doc
	building on OSX 10.4
In-Reply-To: <1271804004.62.0.250618279224.issue8475@psf.upfronthosting.co.za>
Message-ID: <1271804004.62.0.250618279224.issue8475@psf.upfronthosting.co.za>


New submission from David Bolen <db3l.net at gmail.com>:

The attached suggested patch changes build-installer to pass along the same Python executable that it itself is running under to the documentation Makefile.  This fixes an issue on OSX where pruning the PATH reverts to the system python (2.3.5) which is too old for Sphinx.  

This does now mean that build-installer itself needs to be run under 2.5+ which contradicts its initial usage comments.  I suspect we should just give up supporting it under 2.3, since an underlying tool no longer supports that, but have not changed those comments in this patch

----------
assignee: ronaldoussoren
components: Macintosh
files: build-installer.diff
keywords: patch
messages: 103790
nosy: db3l, ronaldoussoren
severity: normal
status: open
title: build-installer fix for doc building on OSX 10.4
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17014/build-installer.diff

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

From report at bugs.python.org  Wed Apr 21 00:57:42 2010
From: report at bugs.python.org (David Bolen)
Date: Tue, 20 Apr 2010 22:57:42 +0000
Subject: [New-bugs-announce] [issue8476] build-installer fix for setIcon
	when no script path	specified
In-Reply-To: <1271804262.14.0.282161229164.issue8476@psf.upfronthosting.co.za>
Message-ID: <1271804262.14.0.282161229164.issue8476@psf.upfronthosting.co.za>


New submission from David Bolen <db3l.net at gmail.com>:

The attached suggested patch fixes a small bug where if you execute the build-installer script without an explicit path (e.g., "python build-installer.py") the setIcon compilation will fail since dirname(__file__) is an empty string, so it ends up looking for files beneath "/".

It also normalizes the function slightly, since part of the previous code explicitly used dirname(__file__) whereas part of the code just assumed the output directory was relative to the current directory.

----------
assignee: ronaldoussoren
components: Macintosh
files: build-installer.diff
keywords: patch
messages: 103791
nosy: db3l, ronaldoussoren
severity: normal
status: open
title: build-installer fix for setIcon when no script path specified
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17015/build-installer.diff

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

From report at bugs.python.org  Wed Apr 21 01:38:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Apr 2010 23:38:38 +0000
Subject: [New-bugs-announce] [issue8477] _ssl: support surrogates in
	filenames, and bytes/bytearray filenames
In-Reply-To: <1271806718.84.0.17803607621.issue8477@psf.upfronthosting.co.za>
Message-ID: <1271806718.84.0.17803607621.issue8477@psf.upfronthosting.co.za>


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

_ssl.sslwrap() has 3 filename arguments: key_file, cert_file and cacerts_file. It uses "z" format to parse them.

Attached patch uses PyUnicode_FSConverter() to support surrogates, bytes and bytearray. It fixes also test_decode_certificate() function.

----------
components: Library (Lib), Unicode
files: ssl_surrogates.patch
keywords: patch
messages: 103793
nosy: haypo
severity: normal
status: open
title: _ssl: support surrogates in filenames, and bytes/bytearray filenames
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17017/ssl_surrogates.patch

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

From report at bugs.python.org  Wed Apr 21 04:18:32 2010
From: report at bugs.python.org (rb)
Date: Wed, 21 Apr 2010 02:18:32 +0000
Subject: [New-bugs-announce] [issue8478] tokenize.untokenize first token
	missing failure case
In-Reply-To: <1271816312.19.0.485614247328.issue8478@psf.upfronthosting.co.za>
Message-ID: <1271816312.19.0.485614247328.issue8478@psf.upfronthosting.co.za>


New submission from rb <rb-oss-2 at justgohome.co.uk>:

When altering tokens and thus not providing token location information, tokenize.untokenize sometimes misses out the first token. Failure case below.

Expected output: 'import foo ,bar\n'
Actual output: 'foo ,bar\n'

$ python
Python 2.6.4 (r264:75706, Dec  7 2009, 18:43:55) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import StringIO, tokenize
>>> 
>>> def strip(iterable):
...     for t_type, t_str, (srow, scol), (erow, ecol), line in iterable:
...         yield t_type, t_str
... 
>>> source = StringIO.StringIO('import foo, bar\n')
>>> print repr(tokenize.untokenize(strip(tokenize.generate_tokens(source.readline))))
'foo ,bar \n'
>>> source.seek(0)
>>> print repr(tokenize.untokenize(tokenize.generate_tokens(source.readline)))
'import foo, bar\n'
>>>

----------
components: Library (Lib)
messages: 103799
nosy: rb
severity: normal
status: open
title: tokenize.untokenize first token missing failure case
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr 21 08:17:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 21 Apr 2010 06:17:06 +0000
Subject: [New-bugs-announce] [issue8479] test_gdb: No stack
In-Reply-To: <1271830626.82.0.53867280614.issue8479@psf.upfronthosting.co.za>
Message-ID: <1271830626.82.0.53867280614.issue8479@psf.upfronthosting.co.za>


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

test_gdb currently fails on 3k; some tests with a "No stack" message. I'll attach the full output, but would like this issue to focus on the "No stack" failures.

----------
files: test_gdb.txt
messages: 103802
nosy: loewis
severity: normal
status: open
title: test_gdb: No stack
versions: Python 3.2
Added file: http://bugs.python.org/file17019/test_gdb.txt

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

From report at bugs.python.org  Wed Apr 21 08:19:13 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 21 Apr 2010 06:19:13 +0000
Subject: [New-bugs-announce] [issue8480] test_gdb: No frame is currently
	selected.
In-Reply-To: <1271830753.76.0.281280336768.issue8480@psf.upfronthosting.co.za>
Message-ID: <1271830753.76.0.281280336768.issue8480@psf.upfronthosting.co.za>


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

test_gdb fails on 3k; some tests with a message "Error occurred in Python command: No frame is currently selected."

A separate problem was reported as #8479; I'm attaching the full test_gdb output.

----------
assignee: dmalcolm
files: test_gdb.txt
messages: 103803
nosy: dmalcolm, loewis
severity: normal
status: open
title: test_gdb: No frame is currently selected.
versions: Python 3.2
Added file: http://bugs.python.org/file17020/test_gdb.txt

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

From report at bugs.python.org  Wed Apr 21 09:17:07 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 21 Apr 2010 07:17:07 +0000
Subject: [New-bugs-announce] [issue8481] doc: ctypes no need to explicitly
	allocate writable	memory with Structure
In-Reply-To: <1271834227.47.0.0148350492358.issue8481@psf.upfronthosting.co.za>
Message-ID: <1271834227.47.0.0148350492358.issue8481@psf.upfronthosting.co.za>


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

ctypes docs should mention that Structures can be passed with byref() to functions expecting pointer to mutable memory without explicit allocation of mutable memory block with create_string_buffer() or similar function.

----------
assignee: georg.brandl
components: Documentation
messages: 103804
nosy: georg.brandl, techtonik
severity: normal
status: open
title: doc: ctypes no need to explicitly allocate writable memory with Structure
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Apr 21 12:12:49 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Apr 2010 10:12:49 +0000
Subject: [New-bugs-announce] [issue8482] test_gdb - "(unable to read python
	frame information)"	mismatch
In-Reply-To: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>
Message-ID: <1271844769.16.0.663071395235.issue8482@psf.upfronthosting.co.za>


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

Remaining failure after resolution of issue8437:
======================================================================
FAIL: test_basic_command (test.test_gdb.PyBtTests)                    
Verify that the "py-bt" command works                                 
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "/home/ncoghlan/devel/python/Lib/test/test_gdb.py", line 638, in test_basic_command                                                                      
    ''')                                                                        
  File "/home/ncoghlan/devel/python/Lib/test/test_gdb.py", line 158, in assertMultilineMatches                                                                  
    msg='%r did not match %r' % (actual, pattern))                              
AssertionError: 'Breakpoint 1 at 0x453510: file Objects/object.c, line 330.\n[Thread debugging using libthread_db enabled]\n\nBreakpoint 1, PyObject_Print (op=42, fp=0x7ffff7532780, flags=1)\n    at Objects/object.c:330\n330\t\treturn internal_print(op, fp, flags, 0);\n#3 Frame 0x808680, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 10, in baz (args=(1, 2, 3))\n    print(42)\n#7 (unable to read python frame information)\n#10 Frame 0x81a220, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 7, in bar (a=1, b=2, c=3)\n    baz(a, b, c)\n#13 Frame 0x807f00, for file /home/ncoghlan/devel/python/Lib/test/gdb_sample.py, line 4, in foo (a=1, b=2, c=3)\n    bar(a, b, c)\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 4, in foo \\(a=1, b=2, c=3\\)\n    bar\\(a, b, c\\)\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 12, in <module> \\(\\)\nfoo\\(1, 2, 3\\)\n'

----------
components: Library (Lib), Tests
keywords: 64bit
messages: 103808
nosy: dmalcolm, haypo, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gdb - "(unable to read python frame information)" mismatch
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr 21 12:55:25 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 21 Apr 2010 10:55:25 +0000
Subject: [New-bugs-announce] [issue8483] asyncore.dispatcher.__repr__() is
	weird
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

This is rather confusing:

Python 2.6.4 (r264:75706, Mar  8 2010, 08:41:55)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket, asyncore
>>> class T:
...     pass
...
>>> t = T()
>>> print t
<__main__.T instance at 0x18237a0>
>>> print repr(t)
<__main__.T instance at 0x18237a0>
>>> class A(asyncore.dispatcher):
...     pass
...
>>> a = A()
>>> print a
None
>>> print repr(a)
<__main__.A at 0x179c0e0>
>>> class B(asyncore.dispatcher):
...     def __init__(self, *args):
...             asyncore.dispatcher.__init__(self, *args)
...
>>> sock = socket.socket()
>>> b = B(sock)
>>> print b
<socket._socketobject object at 0x7fcef226e8a0>
>>> print repr(b)
<__main__.B at 0x179c0e0>

Here's dispatcher's __repr__:

    def __repr__(self):
        status = [self.__class__.__module__+"."+self.__class__.__name__]
        if self.accepting and self.addr:
            status.append('listening')
        elif self.connected:
            status.append('connected')
        if self.addr is not None:
            try:
                status.append('%s:%d' % self.addr)
            except TypeError:
                status.append(repr(self.addr))
        return '<%s at %#x>' % (' '.join(status), id(self))

Which doesn't seem excessively complex...

----------
components: Library (Lib)
messages: 103816
nosy: djc
severity: normal
status: open
title: asyncore.dispatcher.__repr__() is weird
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr 21 13:56:20 2010
From: report at bugs.python.org (Beda Kosata)
Date: Wed, 21 Apr 2010 11:56:20 +0000
Subject: [New-bugs-announce] [issue8484] ssl socket with certificate
	verification fails on SHA256	digest algorithm
In-Reply-To: <1271850980.01.0.0395535667848.issue8484@psf.upfronthosting.co.za>
Message-ID: <1271850980.01.0.0395535667848.issue8484@psf.upfronthosting.co.za>


New submission from Beda Kosata <beda at zirael.org>:

When trying a secure connection to an HTTPS server with server certificate verification, I get very strange behaviour when the digest used in the signing certificate is SHA-256 (+RSA).
On Windows with Python 2.6.4 or 2.6.5, I consistently get the following error:

ssl.SSLError: [Errno 1] _ssl.c:480: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm

When I tried to reproduce this on Ubuntu Linux, I found that it either failed with the same error or succeeded in case the hashlib was imported before the actual code. I got the same behaviour on Gentoo Linux with Python 2.6.4 and Fedora 11 and Debian unstable with other versions of Python 2.6.
On Windows, importing hashlib prior to the code does not fix it as is does on Linux.

Using openssl s_client (openssl s_client -connect sha256.tbs-internet.com:443 -CAfile chain.pem) give no error, so the problem is not directly with openssl.
It seems that the Python ssl (_ssl) library does not load properly the corresponding hash modules from openssl or something like this.

I attach a sample script with the hashlib import commented out. I also add a pem file with certificates needed for the code to check the server certificate.

P.S.- I was able to reproduce the same behaviour with another site using SHA-256 base digests.

----------
components: Library (Lib)
files: ssl_check.py
messages: 103823
nosy: beda
severity: normal
status: open
title: ssl socket with certificate verification fails on SHA256 digest algorithm
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file17021/ssl_check.py

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

From report at bugs.python.org  Wed Apr 21 14:23:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Apr 2010 12:23:36 +0000
Subject: [New-bugs-announce] [issue8485] Don't accept bytearray as filenames,
	or simplify the API
In-Reply-To: <1271852616.85.0.795804679597.issue8485@psf.upfronthosting.co.za>
Message-ID: <1271852616.85.0.795804679597.issue8485@psf.upfronthosting.co.za>


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

r72313 (PEP 383) created the PyUnicode_FSConverter() function: encode an object to a byte string using the default file system encoding. PyBytes and PyByteArray are leaved unchanged (just increment the reference counter), PyUnicode is encoded to PyBytes (if the encoder produces something else, an error is raised).

In my opinion, a file name is a character string (Windows) or a byte string (POSIX) and a bytearray object is unexpected. Only few function support this type: no function of os.path accept them. In the Python test suite, no function use bytearray for filenames.

It's already complex to support 2 types (bytes and str) for filenames in os.path, I think that a third type is too much and has no real world use case (the module manipuling filenames is os.path and it doesn't support bytearray and nobody noticed that).

Suppport bytearray is complex because we need to acquire a lock (using PyObject_GetBuffer()) and release the lock (o->ob_type->tp_as_buffer->bf_releasebuffer(o, 0)... that's not really intuitive...). posixmodule.c uses functions bytes2str() and realease_bytes() to handle bytearray easily. But these functions are static and other modules have to reimplement them.

I propose the reject bytearray in PyUnicode_FSConverter(), or to simplify the API and fix Python to accept bytearray filename everywhere especially in os.path.

***

Reject bytearray in PyUnicode_FSConverter() is trivial only there is only one test that have to be changed in the whole Python3 test suite: test_empty_bytearray in test_bytes.py. This function shows that bytearray is complex and introduce subtle bugs (the lock/GIL issue). All code using PyUnicode_FSConverter() would become simpler.

Example:

----
/* Release the lock, decref the object. */
static void
release_bytes(PyObject* o)
{
        if (PyByteArray_Check(o))
                o->ob_type->tp_as_buffer->bf_releasebuffer(o, 0);
        Py_DECREF(o);
}

...
realease_byte(path);
----

becomes "Py_DECREF(path);" and release_bytes() can be removed.

And
------------
static char*
bytes2str(PyObject* o, int lock)
{
        if(PyBytes_Check(o))
                return PyBytes_AsString(o);
        else if(PyByteArray_Check(o)) {
                if (lock && PyObject_GetBuffer(o, NULL, 0) < 0)
                        /* On a bytearray, this should not fail. */
                        PyErr_BadInternalCall();
                return PyByteArray_AsString(o);
        } else {
                /* The FS converter should have verified that this
                   is either bytes or bytearray. */
                Py_FatalError("bad object passed to bytes2str");
                /* not reached. */
                return "";
        }
}

...
path = bytes2str(opath);
------------

becomes "path = PyBytes_AS_STRING(opath);" (or maybe "path = PyBytes_AsString(opath);" if you don't trust PyUnicode_FSConverter)  and bytes2str() can be removed.

***

Simplify the API means that bytes2str() and release_bytes() should become protected functions (not static, but prefixed by "_Py_") or maybe public ("Py_" prefix).

But the most complex part is to modify os.path to support bytearray, and this task would not be funny :-)

----------
components: Interpreter Core, Library (Lib), Unicode
messages: 103829
nosy: haypo
severity: normal
status: open
title: Don't accept bytearray as filenames, or simplify the API
versions: Python 3.2

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

From report at bugs.python.org  Wed Apr 21 14:49:28 2010
From: report at bugs.python.org (Benjamin VENELLE)
Date: Wed, 21 Apr 2010 12:49:28 +0000
Subject: [New-bugs-announce] [issue8486] [PATCH] threading.Event()
In-Reply-To: <1271854168.83.0.00990516221114.issue8486@psf.upfronthosting.co.za>
Message-ID: <1271854168.83.0.00990516221114.issue8486@psf.upfronthosting.co.za>


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

Hi,

I'm suggesting to declare a __bool__() function as an alias for is_set() in Event class from threading package. So Event objects could be used like booleans.

Ex:

I thought 'while(not event): do_something()' is much intuitive than 'while(not event.is_set()): do_something()'

----------
components: Library (Lib)
messages: 103835
nosy: Kain94
severity: normal
status: open
title: [PATCH] threading.Event()
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Apr 21 17:57:19 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 21 Apr 2010 15:57:19 +0000
Subject: [New-bugs-announce] [issue8487] os.mknod() fails on NFS mounted
	directories
In-Reply-To: <1271865439.77.0.481642755955.issue8487@psf.upfronthosting.co.za>
Message-ID: <1271865439.77.0.481642755955.issue8487@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

$ cat test.py
#!/usr/bin/env python
import os
import stat
dbfile = './testfile.test'
with open(dbfile, 'w') as fh:
    print('Opened file for writing')
os.unlink(dbfile)
os.mknod(dbfile, stat.S_IRUSR | stat.S_IWUSR | stat.S_IFREG)
print('Mknod\'ed file')

[cliff at ih ~]$ cd tmp              <-- nfs mounted on a 64bit Fedora box
[cliff at ih tmp]$ ~/tmp/test.py
Opened file for writing
Traceback (most recent call last):
  File "/home/cliff/tmp/test.py", line 9, in <module>
    os.mknod(dbfile, stat.S_IRUSR | stat.S_IWUSR | stat.S_IFREG)
OSError: [Errno 2] No such file or directory

[cliff at ih tmp]$ cd /tmp           <-- locally mounted on a HD
[cliff at ih tmp]$ ~/tmp/test.py
Opened file for writing
Mknod'ed file


I think the mknod() call really shouldn't fail if it tries to create an ordinary file that can be created with open() with problems.

----------
components: IO
messages: 103860
nosy: Nikratio
severity: normal
status: open
title: os.mknod() fails on NFS mounted directories
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr 21 20:25:09 2010
From: report at bugs.python.org (Torsten Landschoff)
Date: Wed, 21 Apr 2010 18:25:09 +0000
Subject: [New-bugs-announce] [issue8488] Docstrings of non-data descriptors
	"ignored"
In-Reply-To: <1271874309.07.0.567011993617.issue8488@psf.upfronthosting.co.za>
Message-ID: <1271874309.07.0.567011993617.issue8488@psf.upfronthosting.co.za>


New submission from Torsten Landschoff <t.landschoff at gmx.net>:

[I would assign priority minor to this, but the tracker won't let me]

I really like the online documentation features of python. However, I wonder about the output of the following simple example:

class Descriptor(object):
    """Doc of a non-data descriptor."""
    def __get__(self, instance, owner):
        return 42 if instance else self

class GetSetDescriptor(Descriptor):
    """Doc of a data-descriptor."""
    def __set__(self, instance, value):
        pass

class Demo(object):
    non_data = Descriptor()
    data = GetSetDescriptor()

help(Demo)


This results in

Help on class Demo in module __main__:

class Demo(builtins.object)
 |  Methods defined here:
 |  
 |  non_data = <__main__.Descriptor object>
 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |  
 |  __dict__
 |      dictionary for instance variables (if defined)
 |  
 |  __weakref__
 |      list of weak references to the object (if defined)
 |  
 |  data
 |      Doc of a data-descriptor.


I think the behaviour of pydoc wrt. the non_data descriptor is a bit out of line. I would have expected to find the docstring in the output here.

----------
components: Library (Lib)
files: doc.py
messages: 103880
nosy: torsten
severity: normal
status: open
title: Docstrings of non-data descriptors "ignored"
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17027/doc.py

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

From report at bugs.python.org  Wed Apr 21 21:17:49 2010
From: report at bugs.python.org (Domen)
Date: Wed, 21 Apr 2010 19:17:49 +0000
Subject: [New-bugs-announce] [issue8489] smtplib.SMTP.login() breaks with
	unicode input
In-Reply-To: <1271877469.99.0.897777864709.issue8489@psf.upfronthosting.co.za>
Message-ID: <1271877469.99.0.897777864709.issue8489@psf.upfronthosting.co.za>


New submission from Domen <ielectric at gmail.com>:

Module smtplib, line 574, in login
  Module smtplib, line 538, in encode_cram_md5
  Module hmac, line 72, in __init__
TypeError: character mapping must return integer, None or unicode

Following traceback occurs when doing connection.login(u'foobar at domain.com', 'justdoit') to issue an ESMTP.

Python 2.6.4 (r264:75706, Mar 11 2010, 18:33:18)

----------
components: Unicode
messages: 103890
nosy: iElectric
severity: normal
status: open
title: smtplib.SMTP.login() breaks with unicode input
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr 21 21:34:01 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 21 Apr 2010 19:34:01 +0000
Subject: [New-bugs-announce] [issue8490] asyncore test suite
In-Reply-To: <1271878441.03.0.198922650318.issue8490@psf.upfronthosting.co.za>
Message-ID: <1271878441.03.0.198922650318.issue8490@psf.upfronthosting.co.za>


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

The patch in attachment provides actual tests for asyncore.dispatcher class API, including all handle_* callback methods.

----------
assignee: josiahcarlson
files: asyncore.patch
keywords: patch, patch
messages: 103896
nosy: giampaolo.rodola, josiah.carlson, josiahcarlson, michael.foord, r.david.murray
severity: normal
status: open
title: asyncore test suite
Added file: http://bugs.python.org/file17029/asyncore.patch

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

From report at bugs.python.org  Wed Apr 21 21:58:33 2010
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 21 Apr 2010 19:58:33 +0000
Subject: [New-bugs-announce] [issue8491] Need readline command and
	keybinding information
In-Reply-To: <1271879913.89.0.268262009322.issue8491@psf.upfronthosting.co.za>
Message-ID: <1271879913.89.0.268262009322.issue8491@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The documentation of the readline module refers to readline initialization files, but does not give any information about their format or the available commands. I realize that this is a standard part of environments that support readline, not anything specific to Python, but as long as the module documentations mentions the init file it should give a link to documentation about it.

----------
assignee: georg.brandl
components: Documentation
messages: 103902
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Need readline command and keybinding information
versions: Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Wed Apr 21 22:02:07 2010
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 21 Apr 2010 20:02:07 +0000
Subject: [New-bugs-announce] [issue8492] Addition to readline module to get
	dictionary of	keystrokes and commands
In-Reply-To: <1271880127.18.0.454462638892.issue8492@psf.upfronthosting.co.za>
Message-ID: <1271880127.18.0.454462638892.issue8492@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

Requesting a function to be added to the readline module that produces a dictionary of the current keystroke bindings Also, one to write it to a file in readline init file format. This would be a big help for people interested in customizing the behavior of readline inside Python.

----------
components: Library (Lib)
messages: 103905
nosy: MLModel
severity: normal
status: open
title: Addition to readline module to get dictionary of keystrokes and commands
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Apr 21 22:40:22 2010
From: report at bugs.python.org (Matthew Cowles)
Date: Wed, 21 Apr 2010 20:40:22 +0000
Subject: [New-bugs-announce] [issue8493] socket's send can raise errno 35
	under OS X, which causes problems in sendall
In-Reply-To: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>
Message-ID: <1271882422.56.0.460521234971.issue8493@psf.upfronthosting.co.za>


New submission from Matthew Cowles <mdcowles at users.sourceforge.net>:

[From a question first posted to python-help]

A socket's send function may return 0 if no bytes have been sent. Under at least OS X 10.6.2, it may also raise errno 35 (resource temporarily unavailable) if no network buffers are available. If a Python coder is using socket.send() that's no problem. They can catch the exception and try again. but it makes socket.sendall() (which is implemented as calls to send() ) not very useful. I expect that it would be fairly easy to have it check for that error number in addition to checking for an incomplete send.

As far as I'm aware, it's only OS X that ever does that.

----------
components: Library (Lib)
messages: 103908
nosy: mdcowles
severity: normal
status: open
title: socket's send can raise errno 35 under OS X, which causes problems in sendall
versions: Python 2.6

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

From report at bugs.python.org  Thu Apr 22 00:42:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 21 Apr 2010 22:42:43 +0000
Subject: [New-bugs-announce] [issue8494] test_gdb assertEndsWith failing
In-Reply-To: <1271889763.37.0.542639938729.issue8494@psf.upfronthosting.co.za>
Message-ID: <1271889763.37.0.542639938729.issue8494@psf.upfronthosting.co.za>


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

test_gdb fails on 3k, with the attached output.

----------
assignee: dmalcolm
files: test_gdb.txt
messages: 103919
nosy: dmalcolm, loewis
severity: normal
status: open
title: test_gdb assertEndsWith failing
versions: Python 3.2
Added file: http://bugs.python.org/file17033/test_gdb.txt

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

From report at bugs.python.org  Thu Apr 22 02:43:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 00:43:07 +0000
Subject: [New-bugs-announce] [issue8495] test_gdb: use utf8+surrogateescape
	charset?
In-Reply-To: <1271896987.77.0.833309837495.issue8495@psf.upfronthosting.co.za>
Message-ID: <1271896987.77.0.833309837495.issue8495@psf.upfronthosting.co.za>


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

Because of a strange bug, gdb writes random bytes to stdout. test_gdb decodes output as utf8, but these random bytes cause a UnicodeDecodeError:

ERROR: test_int (__main__.PrettyPrintTests)
Verify the pretty-printing of various "int"/long values
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_gdb.py", line 188, in test_int
    self.assertGdbRepr(1000000000000)
  File "Lib/test/test_gdb.py", line 176, in assertGdbRepr
    cmds_after_breakpoint)
  File "Lib/test/test_gdb.py", line 144, in get_gdb_repr
    import_site=import_site)
  File "Lib/test/test_gdb.py", line 120, in get_stack_trace
    out, err = self.run_gdb(*args)
  File "Lib/test/test_gdb.py", line 62, in run_gdb
    return out.decode('utf-8'), err.decode('utf-8')
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1882-1887: unsupported Unicode code range

surrogateescape should be used the invalid sequence using surrogates.

---

See attached file for the strange gdb bug.

command is the byte string "id(1000000000000)\n\0" (19 bytes, strlen=18), but gdb prints bytes after the \0. Stranger: print (*command)@15 does also prints these random bytes, whereas print (*command)@14 doesn't.

----------
components: Tests
files: gdb_bug.txt
messages: 103929
nosy: haypo
severity: normal
status: open
title: test_gdb: use utf8+surrogateescape charset?
versions: Python 3.2
Added file: http://bugs.python.org/file17038/gdb_bug.txt

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

From report at bugs.python.org  Thu Apr 22 02:47:53 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Thu, 22 Apr 2010 00:47:53 +0000
Subject: [New-bugs-announce] [issue8496] mailcap.lookup() returns filter
	iterator rather than list	if key is given
In-Reply-To: <1271897273.03.0.77391363509.issue8496@psf.upfronthosting.co.za>
Message-ID: <1271897273.03.0.77391363509.issue8496@psf.upfronthosting.co.za>


New submission from Gregory Nofi <crackityjones2004-p at yahoo.com>:

The lookup method in the Python 3.2 mailcap module still uses filter as if it will return a list, like it did in Python 2. If a value for the "key" argument is passed to the method, the method will return a filter iterator rather than a list.

I discovered this while running a test I created for mailcap. It's not checked in yet. See Issue6484.

This is probably low priority because mailcap.lookup() is an internal method. It is used by mailcap.findmatch(), which actually handles the filter iterator gracefully. Nevertheless, I don't think it should return a different type based on whether the key argument is passed. The fix is simple enough.

----------
components: Library (Lib)
files: mailcap.v3.patch
keywords: patch
messages: 103931
nosy: gnofi
severity: normal
status: open
title: mailcap.lookup() returns filter iterator rather than list if key is given
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file17040/mailcap.v3.patch

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

From report at bugs.python.org  Thu Apr 22 04:38:09 2010
From: report at bugs.python.org (reynaldo)
Date: Thu, 22 Apr 2010 02:38:09 +0000
Subject: [New-bugs-announce] [issue8497] Technology and Licensing Related
	Query
In-Reply-To: <4C13B9D0-9CF0-48E2-AE72-830EFBF202C2@w3.org>
Message-ID: <m2ka4f83ee11004211938sec62cc48w2e2de289ff9b2847@mail.gmail.com>


New submission from reynaldo <renben77 at gmail.com>:

Ok

---------- Forwarded message ----------
From: "Ian Jacobs" <ij at w3.org>
Date: Apr 21, 2010 5:14 AM
Subject: Re: Technology and Licensing Related Query
To: "Hila Pilcer" <hilap at meitar.com>

On 19 Apr 2010, at 3:32 PM, Hila Pilcer wrote:

Hello Hila,

W3C specifications may be used at no charge and without license; you may
create WSDL documents freely.

 _ Ian

----------
files: unnamed
messages: 103937
nosy: renben
severity: normal
status: open
title: Technology and Licensing Related Query
Added file: http://bugs.python.org/file17043/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8497>
_______________________________________
-------------- next part --------------
<p>Ok</p>
<p><blockquote type="cite">---------- Forwarded message ----------<br>From: &quot;Ian Jacobs&quot; &lt;<a href="mailto:ij at w3.org">ij at w3.org</a>&gt;<br>Date: Apr 21, 2010 5:14 AM<br>Subject: Re: Technology and Licensing Related Query<br>
To: &quot;Hila Pilcer&quot; &lt;<a href="mailto:hilap at meitar.com">hilap at meitar.com</a>&gt;<br><br><p><font color="#500050"><br>On 19 Apr 2010, at 3:32 PM, Hila Pilcer wrote:<br><br>&gt; To whom it may concern,<br>&gt;<br>
&gt; We write to you on be...</font></p>
Hello Hila,<br>
<br>
W3C specifications may be used at no charge and without license; you may create WSDL documents freely.<br>
<br>
??_ Ian<p><font color="#500050"><br><br>&gt; Many thanks<br>&gt;<br>&gt; Best regards<br>&gt;<br>&gt; Hila Pilcer, Adv.<br>&gt; Meitar Liquornik Geva &amp; Leshem Brandwein, L...</font></p><font color="#888888">
--<br>
Ian Jacobs (<a href="mailto:ij at w3.org" target="_blank">ij at w3.org</a>) ?? ??<a href="http://www.w3.org/People/Jacobs/" target="_blank">http://www.w3.org/People/Jacobs/</a><br>
Tel: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??+1 718 260 9447<br>
<br>
<br>
</font></blockquote></p>

From report at bugs.python.org  Thu Apr 22 12:02:53 2010
From: report at bugs.python.org (Daniel Evers)
Date: Thu, 22 Apr 2010 10:02:53 +0000
Subject: [New-bugs-announce] [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>


New submission from Daniel Evers <dermojo at googlemail.com>:

I'm trying to rewrite a server application in python that accepts exactly 1 connection. I have a previous version written in C that can call listen() on a socket with a backlog of 0 connections, but this is not possible in python. In Modules/socketmodule.c (function socket_listen) the backlog is reset to at least "1".

----------
components: Extension Modules
messages: 103942
nosy: Daniel.Evers
severity: normal
status: open
title: Cannot use backlog = 0 for sockets
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Apr 22 16:56:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Apr 2010 14:56:12 +0000
Subject: [New-bugs-announce] [issue8499] Set a timeout in test_urllibnet
In-Reply-To: <1271948172.1.0.95585075241.issue8499@psf.upfronthosting.co.za>
Message-ID: <1271948172.1.0.95585075241.issue8499@psf.upfronthosting.co.za>


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

As #8460 (test_urllib2net), test_urllibnet fails if a website doesn't answer. Today, it was www.python.org during few minutes:

http://www.python.org/dev/buildbot/all/builders/amd64 gentoo 3.1/builds/482/steps/test/logs/stdio
---
test_urllibnet
test test_urllibnet failed -- multiple errors occurred; run in verbose mode for details
---
(the test was executed again, but www.python.org was back)

test_urllib should use a timeout, as done for test_urllib2: see #8460.

----------
components: Library (Lib), Tests
messages: 103971
nosy: haypo, orsenthil
severity: normal
status: open
title: Set a timeout in test_urllibnet
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Apr 22 19:42:43 2010
From: report at bugs.python.org (Zach Lym)
Date: Thu, 22 Apr 2010 17:42:43 +0000
Subject: [New-bugs-announce] [issue8500] Erroneous Invalid Syntax Error
In-Reply-To: <1271958163.54.0.165869378642.issue8500@psf.upfronthosting.co.za>
Message-ID: <1271958163.54.0.165869378642.issue8500@psf.upfronthosting.co.za>


New submission from Zach Lym <zachlym at indolering.com>:

>>> I love you python
  File "<stdin>", line 1
    I love you python
         ^
SyntaxError: invalid syntax
>>>

There is nothing invalid about that!

----------
components: None
messages: 103973
nosy: indolering
severity: normal
status: open
title: Erroneous Invalid Syntax Error
type: compile error
versions: Python 2.5

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

From report at bugs.python.org  Thu Apr 22 23:35:45 2010
From: report at bugs.python.org (Jim Fulton)
Date: Thu, 22 Apr 2010 21:35:45 +0000
Subject: [New-bugs-announce] [issue8501] --dry-run option doesn't work
In-Reply-To: <1271972145.51.0.00309332974734.issue8501@psf.upfronthosting.co.za>
Message-ID: <1271972145.51.0.00309332974734.issue8501@psf.upfronthosting.co.za>


New submission from Jim Fulton <jim at zope.com>:

The --dry-run option is ignored by the install command.
It leads to an error when used as a global option.

It should be fixed or removed.  I vote for removal, but don't really care. Removal seems easier. :)

To reproduce, create the simple project:

  http://docs.python.org/distutils/introduction.html#a-simple-example

and then try the option.

See also:

  http://mail.python.org/pipermail/distutils-sig/2010-April/016000.html

----------
assignee: tarek
components: Distutils
messages: 103979
nosy: j1m, tarek
severity: normal
status: open
title: --dry-run option doesn't work
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Fri Apr 23 03:10:07 2010
From: report at bugs.python.org (jhg)
Date: Fri, 23 Apr 2010 01:10:07 +0000
Subject: [New-bugs-announce] [issue8502] proposal: encourage xgettext rather
	than pygettext.py in	gettext docs
In-Reply-To: <1271985007.3.0.675755685137.issue8502@psf.upfronthosting.co.za>
Message-ID: <1271985007.3.0.675755685137.issue8502@psf.upfronthosting.co.za>


New submission from jhg <jhg at upb.de>:

Wanting to figure out how to support multiple languages in my applications I read the gettext documentation and got to the part saying one should use pygettext.py to create .po files.

After copying that program from the python SVN repository I later found out that it cannot cope with plurals, i.e. ngettext(). xgettext can do that just fine. Since pygettext.py was not modified in 5 years I propose changing the documentation of gettext to encourage xgettext rather than pygettext.py.

My proposed changes are attached (edited as text file; I do not know how to convert it to a webpage and hence did not test that).
I used the 2.7b1 documentation, but the patch appears to apply just as well to the 3.1.2 documentation.

----------
assignee: georg.brandl
components: Documentation
files: gettext.txt.patch
keywords: patch
messages: 103988
nosy: georg.brandl, jhg
severity: normal
status: open
title: proposal: encourage xgettext rather than pygettext.py in gettext docs
versions: Python 2.7
Added file: http://bugs.python.org/file17048/gettext.txt.patch

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

From report at bugs.python.org  Fri Apr 23 09:56:12 2010
From: report at bugs.python.org (mike s)
Date: Fri, 23 Apr 2010 07:56:12 +0000
Subject: [New-bugs-announce] [issue8503] smtpd module does not allow
In-Reply-To: <1272009372.5.0.274856265398.issue8503@psf.upfronthosting.co.za>
Message-ID: <1272009372.5.0.274856265398.issue8503@psf.upfronthosting.co.za>


New submission from mike s <suchanek at kovagroup.ca>:

The SMTPServer supplied by the smtpd library allows clients to send mail to any domain. This makes the server attractive to spammers, thinking they have found an open relay.

The patch below adds an "accept_domain" method to SMTPServer (documented below) which can be overridden by the user to compare the incoming domain against a list, etc, and return True or False (True=accept address, False=reject).

My apologies if this is the wrong place to submit this; I have not submitted a patch like this before and am just hoping to help! :)

Mike

--- smtpd.py.bak	2010-04-23 00:22:39.000000000 -0700
+++ smtpd.py	2010-04-23 00:51:22.000000000 -0700
@@ -241,6 +241,10 @@
         if not address:
             self.push('501 Syntax: RCPT TO: <address>')
             return
+	address_domain = address.split('@')[1]
+	if self._SMTPChannel__server.accept_domain(address_domain) is False:
+	    self.push('554 Relay access denied')
+	    return
         self.__rcpttos.append(address)
         print >> DEBUGSTREAM, 'recips:', self.__rcpttos
         self.push('250 Ok')
@@ -289,6 +293,15 @@
         print >> DEBUGSTREAM, 'Incoming connection from %s' % repr(addr)
         channel = SMTPChannel(self, conn, addr)
 
+    def accept_domain(self,domain):
+    	"""domain is a string like domain.com that specifes the domain of
+	an email address supplied by client's RCPT TO command.
+	
+	Override this method to determine whether SMTPServer should
+	accept mail for a given domain. This is handy for preventing
+	spammers from thinking you are running an open relay."""
+    	return True
+
     # API for "doing something useful with the message"
     def process_message(self, peer, mailfrom, rcpttos, data):
         """Override this abstract method to handle messages from the client.

----------
components: Library (Lib)
messages: 103993
nosy: mike.s
severity: normal
status: open
title: smtpd module does not allow
versions: 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/issue8503>
_______________________________________

From report at bugs.python.org  Fri Apr 23 12:02:45 2010
From: report at bugs.python.org (Tim Lyons)
Date: Fri, 23 Apr 2010 10:02:45 +0000
Subject: [New-bugs-announce] [issue8504] bsddb databases in python 2.6 are
	not compatible with	python 2.5 and are slow in python 2.6
In-Reply-To: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>
Message-ID: <1272016965.12.0.964555236843.issue8504@psf.upfronthosting.co.za>


New submission from Tim Lyons <guy.linton at gmail.com>:

A database created under python 2.5 cannot be opened under python 2.6. It gives the error message "DB_RUNRECOVERY: Fatal error, run database recovery -- process-private: unable to find environment ", and a database created under python 2.6 cannot be opened under python 2.5 (see http://trac.macports.org/ticket/24310). (This in in Mac OS X: In Windows XP SP3, Python 2.6 can read a Python 2.5 bsddb data base.
but not the other way around. If you try, you will end up with a corrupt data base.)

python 2.6 bsddb is very much slower than python 2.5. Specifically, in Gramps, import of a 500 person xml file takes 12 sec with python25 and 9 mins 30 secs with python26. The slowness has been observed in Mac OS X (See http://trac.macports.org/ticket/23768) and in Windows (see http://www.gramps-project.org/bugs/view.php?id=3750).

I am not sure, but I think that both systems are using the same underlying database module db46, and that the difference may be in the different interface modules: "_bsddb.so" (on Mac OS X)

----------
components: Library (Lib)
messages: 103998
nosy: guy.linton
severity: normal
status: open
title: bsddb databases in python 2.6 are not compatible with python 2.5 and are slow in python 2.6
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr 23 14:31:15 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 23 Apr 2010 12:31:15 +0000
Subject: [New-bugs-announce] [issue8505] 2to3 fix_future.py removes
	__future__ imports, but should it?
In-Reply-To: <1272025875.68.0.994022757539.issue8505@psf.upfronthosting.co.za>
Message-ID: <1272025875.68.0.994022757539.issue8505@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Lines such as the following are removed by fix_future.py in 2to3

from __future__ import absolute_import, unicode_literals

I think this is unnecessary and I have a case where it causes problems.  It's unnecessary because this import is essentially a no-op in Python 3, so it does no harm, and serves no actual useful purpose to remove.  It causes harm because of a common idiom in doctest setups:

def setup(testobj):
    """Test setup."""
    # Make sure future statements in our doctests match the Python code.
    testobj.globs['absolute_import'] = absolute_import
    testobj.globs['unicode_literals'] = unicode_literals

fix_future.py removes the import so these cause NameErrors.  Sure, I can wrap them in try/excepts, but still what's the point of fix_future?

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 104008
nosy: barry
severity: normal
status: open
title: 2to3 fix_future.py removes __future__ imports, but should it?
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Apr 23 14:38:04 2010
From: report at bugs.python.org (Erik Schweller)
Date: Fri, 23 Apr 2010 12:38:04 +0000
Subject: [New-bugs-announce] [issue8506] SimpleXMLRPCServer Socket not
	closed after shutdown call
In-Reply-To: <1272026284.3.0.0989904198918.issue8506@psf.upfronthosting.co.za>
Message-ID: <1272026284.3.0.0989904198918.issue8506@psf.upfronthosting.co.za>


New submission from Erik Schweller <othererik at gmail.com>:

Calling shutdown on a SimpleXMLRPCServer will stop the server but does not close the socket, meaning new connections to the same address will fail. 

Example:

  srv = SimpleXMLRPCServer((ip, port),
                                      logRequests=False, allow_none=True)
  srv.serve_forever(poll_interval=2)


srv.shutdown() is made available to the registered class instance.


The current workaround is to delete the socket (or call close() on the socket) after the server is shutdown, (i.e., "del srv.socket") but it seems this should be handled when the server is shutdown.

----------
components: Library (Lib)
messages: 104009
nosy: othererik
severity: normal
status: open
title: SimpleXMLRPCServer Socket not closed after shutdown call
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr 23 15:33:08 2010
From: report at bugs.python.org (Robert Escriva)
Date: Fri, 23 Apr 2010 13:33:08 +0000
Subject: [New-bugs-announce] [issue8507] abc.abstractproperty does not copy
	docstring
In-Reply-To: <1272029588.75.0.820614439308.issue8507@psf.upfronthosting.co.za>
Message-ID: <1272029588.75.0.820614439308.issue8507@psf.upfronthosting.co.za>


New submission from Robert Escriva <bugs.python at mail.robescriva.com>:

Attached file shows interpreter session where the bug manifests.

It was my expectation that abc.abstractproperty would copy the docstring just like property.  Instead, the docstring is the one for abc.abstractproperty itself.

----------
components: Library (Lib)
files: python.abc.abstractproperty.bug
messages: 104012
nosy: rescrv
severity: normal
status: open
title: abc.abstractproperty does not copy docstring
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17052/python.abc.abstractproperty.bug

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

From report at bugs.python.org  Fri Apr 23 16:48:06 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 23 Apr 2010 14:48:06 +0000
Subject: [New-bugs-announce] [issue8508] 2to3 fixer for gettext's .ugettext
In-Reply-To: <1272034086.61.0.0547716106043.issue8508@psf.upfronthosting.co.za>
Message-ID: <1272034086.61.0.0547716106043.issue8508@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

gettext module in Python 3 does not have a .ugettext method because everything's already unicodes.  Here's a fixer for that.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: fix_ugettext.py
messages: 104015
nosy: barry
severity: normal
status: open
title: 2to3 fixer for gettext's .ugettext
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17053/fix_ugettext.py

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

From report at bugs.python.org  Fri Apr 23 17:16:46 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 23 Apr 2010 15:16:46 +0000
Subject: [New-bugs-announce] [issue8509] fix autoconf quoting in help
	strings and code snippets
In-Reply-To: <1272035806.11.0.986586497024.issue8509@psf.upfronthosting.co.za>
Message-ID: <1272035806.11.0.986586497024.issue8509@psf.upfronthosting.co.za>


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

the attached patch adds quoting to help strings and code snippets, following the autoconf quotation rule of thumb "One pair of quotes per pair of parentheses".

checked that the generated files are identical.

----------
components: Build
files: configure.in.diff
keywords: needs review, patch
messages: 104017
nosy: doko
severity: normal
status: open
title: fix autoconf quoting in help strings and code snippets
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17054/configure.in.diff

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

From report at bugs.python.org  Fri Apr 23 17:26:20 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 23 Apr 2010 15:26:20 +0000
Subject: [New-bugs-announce] [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>


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

update to autoconf2.65

----------
components: Build
files: autoconf2.65.diff
keywords: needs review, patch
messages: 104018
nosy: doko
severity: normal
status: open
title: update to autoconf2.65
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17055/autoconf2.65.diff

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

From report at bugs.python.org  Fri Apr 23 19:03:26 2010
From: report at bugs.python.org (Matthew Cowles)
Date: Fri, 23 Apr 2010 17:03:26 +0000
Subject: [New-bugs-announce] [issue8511] Small mistake in tutorial web page
In-Reply-To: <1272042206.62.0.681043010082.issue8511@psf.upfronthosting.co.za>
Message-ID: <1272042206.62.0.681043010082.issue8511@psf.upfronthosting.co.za>


New submission from Matthew Cowles <mdcowles at users.sourceforge.net>:

[Originally from a post to the python-help list]

Over at:

http://docs.python.org/py3k/tutorial/datastructures.html#sets

it says:

>>> fruit = ['apple', 'orange', 'apple', 'pear', 'orange', 'banana']
>>> fruit = set(basket)               # create a set without duplicates

I suspect that the first line should begin:

>>> basket =

----------
assignee: georg.brandl
components: Documentation
messages: 104028
nosy: georg.brandl, mdcowles
severity: normal
status: open
title: Small mistake in tutorial web page
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 24 00:34:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 22:34:13 +0000
Subject: [New-bugs-announce] [issue8512] os.execvpe()
Message-ID: <1272062053.09.0.0607896315436.issue8512@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: Library (Lib)
nosy: haypo
severity: normal
status: open
title: os.execvpe()
versions: Python 3.1

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

From report at bugs.python.org  Sat Apr 24 00:42:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 22:42:07 +0000
Subject: [New-bugs-announce] [issue8513] subprocess: support bytes program
	name
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>


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

While fixing #8391, I realized that subprocess doesn't support bytes program name if it's not an absolute path:
-------
$ ./python
>>> import subprocess
>>> subprocess.call([b'echo'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 449, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 681, in __init__
    restore_signals, start_new_session)
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 1116, in _execute_child
    for exe in executable_list)
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 1115, in <genexpr>
    executable_list = tuple(fs_encode(exe)
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 1114, in <genexpr>
    for dir in path_list)
  File "/home/SHARE/SVN/py3k/Lib/posixpath.py", line 75, in join
    if b.startswith(sep):
TypeError: expected an object with the buffer interface
[62826 refs]
-------

I'm working on a patch.

----------
components: Library (Lib), Unicode
messages: 104059
nosy: haypo
severity: normal
status: open
title: subprocess: support bytes program name
versions: Python 3.2

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

From report at bugs.python.org  Sat Apr 24 01:39:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Apr 2010 23:39:12 +0000
Subject: [New-bugs-announce] [issue8514] Create fs_encode() and fs_decode()
	functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>


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

Python3 uses unicode filenames in Windows and bytes filenames (but support also unicode filenames) on other OS. We have to support both types. On POSIX system, bytes filenames can be stored in unicode filenames using sys.getfilesystemencoding() and the surrogateescape error handler (to store undecodable bytes as unicode surrogates, see PEP 383).

I would like to create fs_encode() and fs_decode() in os.path to ease the manipulation of filenames in the two bytes (str and bytes).
 * Use fs_decode() to convert a filename from the OS native format to unicode
 * Use fs_encode() to convert an unicode filename to the OS native format

On Windows, fs_decode() and fs_encode() don't touch the filename, but reject filenames of types different than str (unicode) with a TypeError, especially bytes filename.

Mac OS X rejects invalid UTF-8 filenames, and so surrogateescape should maybe not be used on this OS.

Attached patch is an implementation of this issue.

----------
components: Library (Lib), Unicode
files: os_path_fs_encode_decode.patch
keywords: patch
messages: 104063
nosy: haypo
severity: normal
status: open
title: Create fs_encode() and fs_decode() functions in os.path
versions: Python 3.2
Added file: http://bugs.python.org/file17061/os_path_fs_encode_decode.patch

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

From report at bugs.python.org  Sat Apr 24 03:18:10 2010
From: report at bugs.python.org (Bruce Frederiksen)
Date: Sat, 24 Apr 2010 01:18:10 +0000
Subject: [New-bugs-announce] [issue8515] idle "Run Module" (F5) does not set
	__file__ variable
In-Reply-To: <1272071890.53.0.295001627395.issue8515@psf.upfronthosting.co.za>
Message-ID: <1272071890.53.0.295001627395.issue8515@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen <dangyogi at gmail.com>:

The python CLI always sets the __file__ variable, whether run as:

$ python foobar.py

or

$ python -m foobar

or

$ python
>>> import foobar   # __file__ set in foobar module

The idle program sets the __file__ variable properly when you do the import from the idle shell, but __file__ is not set with the "Run Module" (F5) command from the editor.

I've included a patch file to set __file__, but it doesn't del it after the module has run.  But maybe this is OK, because the os.chdir is not undone either???

----------
components: IDLE
files: idle.patch
keywords: patch
messages: 104066
nosy: dangyogi
severity: normal
status: open
title: idle "Run Module" (F5) does not set __file__ variable
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17062/idle.patch

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

From report at bugs.python.org  Sat Apr 24 10:12:00 2010
From: report at bugs.python.org (Peter Landgren)
Date: Sat, 24 Apr 2010 08:12:00 +0000
Subject: [New-bugs-announce] [issue8516] Speed difference between Python 2.5
	and 2.6 during	filling bsddb database.
In-Reply-To: <1272096720.68.0.81332970497.issue8516@psf.upfronthosting.co.za>
Message-ID: <1272096720.68.0.81332970497.issue8516@psf.upfronthosting.co.za>


New submission from Peter Landgren <peter.talken at telia.com>:

The time it takes, in the application Gramps, to fill an empty bsddb database by importing an XML backup or a GECDOM file, incrises from about 2 minutes to about an hour in Windows XP ana Windows 7. No such degradation has been sen in Linux.

The Gramps code was the same in all test cases.
The running conditions were:
 
Python 2.5                     Python 2.6
Windows  4.4.5.3 (4, 6, 20)    4.7.3 (4.7.25)
Linux    4.4.5.3 (4, 6, 21)    4.7.3 (4.7.25)

Note one little version difference between Windows and Python.

If I install bsddb3 and change Gramps code for that, no noticable speed degradation can be seen.
Windows only with Python 2.6  bsddb3 4.8.4 (4.8.26).

I have run profiling and attach the results.

(Sorry for the fuzz I made in issue 8504.)

The only way of providing a test case,as far as I can find, is to install Gramps, create a new Family Tree (empty database) and import an test XML backup. There are two testcases (*.gramps)  available in:
http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps32/example/gramps/

Gramps can be found at: 
http://www.gramps-project.org/wiki/index.php?title=Installation

----------
components: Library (Lib)
files: statistics_for_python_25_26_run.txt.tar.gz
messages: 104067
nosy: PeterL
severity: normal
status: open
title: Speed difference between Python 2.5 and 2.6 during filling bsddb database.
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file17063/statistics_for_python_25_26_run.txt.tar.gz

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

From report at bugs.python.org  Sat Apr 24 14:20:17 2010
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Sat, 24 Apr 2010 12:20:17 +0000
Subject: [New-bugs-announce] [issue8517] Apple Style Guide link is broken in
	the "Documenting	Python" chapter
In-Reply-To: <1272111617.25.0.289566077781.issue8517@psf.upfronthosting.co.za>
Message-ID: <1272111617.25.0.289566077781.issue8517@psf.upfronthosting.co.za>


New submission from Brandon Craig Rhodes <brandon at rhodesmill.org>:

On this page, the Style Guide for people who want to try contributing to the Python documentation:

docs.python.org/documenting/style.html

there is a broken link to the Apple Style Guide.  The 2008 edition now seems gone and people are now apparently supposed to visit:

http://developer.apple.com/Mac/library/documentation/UserExperience/Conceptual/APStyleGuide/APSG_2009.pdf

----------
assignee: georg.brandl
components: Documentation
messages: 104077
nosy: brandon-rhodes, georg.brandl
severity: normal
status: open
title: Apple Style Guide link is broken in the "Documenting Python" chapter
versions: Python 2.6

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

From report at bugs.python.org  Sat Apr 24 16:25:28 2010
From: report at bugs.python.org (=?utf-8?q?Adri=C3=A1n_Deccico?=)
Date: Sat, 24 Apr 2010 14:25:28 +0000
Subject: [New-bugs-announce] [issue8518] small typo in
	http://docs.python.org/howto/doanddont.html
In-Reply-To: <1272119128.07.0.474354873892.issue8518@psf.upfronthosting.co.za>
Message-ID: <1272119128.07.0.474354873892.issue8518@psf.upfronthosting.co.za>


New submission from Adri?n Deccico <deccico at gmail.com>:

Hi, in this document: 

Idioms and Anti-Idioms in Python

In the "except" section, where it says:

"The example above is better written"

it should said: 

"The example below is better written"

----------
assignee: georg.brandl
components: Documentation
messages: 104091
nosy: Adri?n.Deccico, georg.brandl
severity: normal
status: open
title: small typo in http://docs.python.org/howto/doanddont.html
versions: Python 2.6

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

From report at bugs.python.org  Sat Apr 24 18:09:51 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 24 Apr 2010 16:09:51 +0000
Subject: [New-bugs-announce] [issue8519] [patch] doc: termios and ioctl
	reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>


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

The patch adds link to reference with various flags for termios functions and fcntl.ioctl call.

----------
assignee: georg.brandl
components: Documentation
files: ____.reference-termios-specification-for-flags.diff
keywords: patch
messages: 104094
nosy: georg.brandl, techtonik
severity: normal
status: open
title: [patch] doc: termios and ioctl reference links
versions: Python 2.7
Added file: http://bugs.python.org/file17068/____.reference-termios-specification-for-flags.diff

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

From report at bugs.python.org  Sat Apr 24 19:09:52 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Apr 2010 17:09:52 +0000
Subject: [New-bugs-announce] [issue8520] test doc issue
In-Reply-To: <1272128992.76.0.452224107424.issue8520@psf.upfronthosting.co.za>
Message-ID: <1272128992.76.0.452224107424.issue8520@psf.upfronthosting.co.za>


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

Testing delivery of tracker messages, and autonosy for docs issues.

----------
assignee: docs at python
components: Documentation
messages: 104102
nosy: docs at python, georg.brandl
severity: normal
status: open
title: test doc issue
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 24 19:27:09 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 24 Apr 2010 17:27:09 +0000
Subject: [New-bugs-announce] [issue8521] Allow some winreg functions to
	accept keyword arguments
Message-ID: <1272130029.0.0.870477919071.issue8521@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
assignee: brian.curtin
components: Extension Modules, Windows
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow some winreg functions to accept keyword arguments
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sat Apr 24 19:57:35 2010
From: report at bugs.python.org (=?utf-8?q?Adri=C3=A1n_Deccico?=)
Date: Sat, 24 Apr 2010 17:57:35 +0000
Subject: [New-bugs-announce] [issue8522] enhacement proposal
	in	http://docs.python.org/howto/doanddont.html
In-Reply-To: <1272131855.89.0.865652130353.issue8522@psf.upfronthosting.co.za>
Message-ID: <1272131855.89.0.865652130353.issue8522@psf.upfronthosting.co.za>


New submission from Adri?n Deccico <deccico at gmail.com>:

Hi, in "Exceptions" section. 

Instead of using:

def get_status(file):
    fp = open(file)
    try:
        return fp.readline()
    finally:
        fp.close()

Why no suggest this method:

def get_status(file):
    with open(file) as fp:
	return fp.readline()


which will properly close the file.

----------
assignee: docs at python
components: Documentation
messages: 104111
nosy: Adri?n.Deccico, docs at python
severity: normal
status: open
title: enhacement proposal in http://docs.python.org/howto/doanddont.html
versions: Python 2.6

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

From report at bugs.python.org  Sat Apr 24 20:57:43 2010
From: report at bugs.python.org (rubenlm)
Date: Sat, 24 Apr 2010 18:57:43 +0000
Subject: [New-bugs-announce] [issue8523] shutil.rmtree and os.listdir cannot
	recover on error	conditions
In-Reply-To: <1272135463.46.0.698266589767.issue8523@psf.upfronthosting.co.za>
Message-ID: <1272135463.46.0.698266589767.issue8523@psf.upfronthosting.co.za>


New submission from rubenlm <ruben at libhertz.com>:

The code that lists directory contents in rmtree is:

try:
  names = os.listdir(path)
except os.error, err:
  onerror(os.listdir, path, sys.exc_info())

If there is an error there is nothing the "onerror" function can do to fix the problem because the variable "names" will not be updated after the problem is solved in "onerror".

Two possible solutions:

1 - Call os.listdir() again after onerror()

    try:
      names = os.listdir(path)
    except os.error, err:
      onerror(os.listdir, path, sys.exc_info())
      names = os.listdir(path)

2 - Allow onerror() to return a value and set "names" to that value.

    try:
      names = os.listdir(path)
    except os.error, err:
      names = onerror(os.listdir, path, sys.exc_info())

----------
components: Extension Modules
messages: 104117
nosy: rubenlm
severity: normal
status: open
title: shutil.rmtree and os.listdir cannot recover on error conditions
versions: Python 2.5

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

From report at bugs.python.org  Sat Apr 24 22:47:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Apr 2010 20:47:47 +0000
Subject: [New-bugs-announce] [issue8524] SSL sockets do not retain the
	parent socket's attributes
In-Reply-To: <1272142067.91.0.0552245215724.issue8524@psf.upfronthosting.co.za>
Message-ID: <1272142067.91.0.0552245215724.issue8524@psf.upfronthosting.co.za>


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

In 3.x, SSL sockets are created by dup()ing the original socket and then closing it. No attempt is made to conserve the socket's characteristics, such as the timeout and probably other flags.

I understand that it may be too late to change the design decision of using dup() and closing the original, but perhaps we should make a best effort to retain the original socket's characteristics. Or perhaps this limitation should be clearly documented (since especially 2.x works differently).

----------
components: Library (Lib)
messages: 104129
nosy: giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
status: open
title: SSL sockets do not retain the parent socket's attributes
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Apr 25 01:10:02 2010
From: report at bugs.python.org (Rob Cliffe)
Date: Sat, 24 Apr 2010 23:10:02 +0000
Subject: [New-bugs-announce] [issue8525] Small enhancement to help()
In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>
Message-ID: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>


New submission from Rob Cliffe <rob.cliffe at btinternet.com>:

help() on an exception class lists the method resolution order, which is in effect the class inheritance hierarchy.  E.g. help(ArithmeticError) lists ArithmeticError, StandardError, Exception, BaseException, __builtin__.object.  It struck me it would help to find my way around if it also listed the builtin SUBclasses (if any).  Something like:
    Built-in subclasses:
        FloatingPointError
        OverflowError
        ZeroDivisionError
In fact why not do it for any class, not just exceptions?
I attach a patched version of pydoc.py - tested but only on my PC which is running Python 2.5 under Windows XP.  I have added lines 1129-1148 to the docclass method of the TextDoc class (and flagged them # [RAC] ).
(I don't pretend to understand the magic where __builtins__ is a dictionary when pydoc.py is run but becomes a module later on.  Never mind - the patch works (I believe).)
For consistency, a similar patch would also have to be made to the docclass nethod of the HTMLDoc class (which outputs HTML rather than plain text).  I have not attempted this as I don't know how it is called and hence how to test any patch, but it should be straightforward for anyone with the know-how.

----------
files: pydoc.py
messages: 104134
nosy: robcliffe
severity: normal
status: open
title: Small enhancement to help()
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file17075/pydoc.py

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

From report at bugs.python.org  Sun Apr 25 02:07:14 2010
From: report at bugs.python.org (Bill Janssen)
Date: Sun, 25 Apr 2010 00:07:14 +0000
Subject: [New-bugs-announce] [issue8526] msilib doesn't support multiple CAB
	instances in same	installer
In-Reply-To: <1272154034.54.0.42494510324.issue8526@psf.upfronthosting.co.za>
Message-ID: <1272154034.54.0.42494510324.issue8526@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

Working with Python 2.6.5, I find I cannot put multiple CABs in the same installer.  This is due to this statement in msilib.CAB.commit():

        add_data(db, "Media",
                [(1, self.index, None, "#"+self.name, None, None)])

The key, 1, must be different for each record in the 'Media' table.  The symptom is an exception something like this:

_msi.MSIError: Could not insert [(1, 3, None, '#foo', None, None)] into Media

----------
assignee: loewis
components: Distutils, Library (Lib), Windows
keywords: easy
messages: 104135
nosy: janssen, loewis
severity: normal
status: open
title: msilib doesn't support multiple CAB instances in same installer
versions: Python 2.6, Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Apr 25 03:33:56 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 25 Apr 2010 01:33:56 +0000
Subject: [New-bugs-announce] [issue8527] [PEP 3147] compileall.compile_dir()
	called multiple times	creates empty __pycache__/__pycache__
	subdirectories
In-Reply-To: <1272159236.82.0.290282900197.issue8527@psf.upfronthosting.co.za>
Message-ID: <1272159236.82.0.290282900197.issue8527@psf.upfronthosting.co.za>


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

compileall.compile_dir() called multiple times creates empty __pycache__/__pycache__ subdirectories. I'm attaching the patch.

$ mkdir test
$ touch test/__init__.py
$ python3.2 -c 'import compileall; compileall.compile_dir("test")'
Listing test ...
Compiling test/__init__.py ...
$ tree test
test
??? __init__.py
??? __pycache__
    ??? __init__.cpython-32.pyc

1 directory, 2 files
$ python3.2 -c 'import compileall; compileall.compile_dir("test")'
Listing test ...
Listing test/__pycache__ ...
$ tree test
test
??? __init__.py
??? __pycache__
    ??? __init__.cpython-32.pyc
    ??? __pycache__

2 directories, 2 files

----------
components: Library (Lib)
files: compileall.patch
keywords: patch
messages: 104139
nosy: Arfrever, barry
severity: normal
status: open
title: [PEP 3147] compileall.compile_dir() called multiple times creates empty __pycache__/__pycache__ subdirectories
versions: Python 3.2
Added file: http://bugs.python.org/file17076/compileall.patch

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

From report at bugs.python.org  Sun Apr 25 11:22:56 2010
From: report at bugs.python.org (akira)
Date: Sun, 25 Apr 2010 09:22:56 +0000
Subject: [New-bugs-announce] [issue8528] typo in argparse documentation
In-Reply-To: <1272187376.31.0.670187043497.issue8528@psf.upfronthosting.co.za>
Message-ID: <1272187376.31.0.670187043497.issue8528@psf.upfronthosting.co.za>


New submission from akira <4kir4.1i at gmail.com>:

`messges` should be replaced by `messages` on http://docs.python.org/dev/library/argparse.html#upgrading-optparse-code page.

----------
assignee: docs at python
components: Documentation
messages: 104144
nosy: akira, docs at python
severity: normal
status: open
title: typo in argparse documentation
type: behavior

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

From report at bugs.python.org  Sun Apr 25 19:01:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 25 Apr 2010 17:01:53 +0000
Subject: [New-bugs-announce] [issue8529] subclassing builtin class (str,
	unicode, list...) needs to override __getslice__
In-Reply-To: <1272214913.44.0.488253042315.issue8529@psf.upfronthosting.co.za>
Message-ID: <1272214913.44.0.488253042315.issue8529@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

It looks like a bug, because __getslice__ is deprecated since 2.0.

If you subclass a builtin type and override the __getitem__ method, you need to override the (deprecated) __getslice__ method too.
And if you run your program with "python -3", it 

Example script:


class Upper(unicode):

    def __getitem__(self, index):
        return unicode.__getitem__(self, index).upper()

    #def __getslice__(self, i, j):
        #return self[i:j:]


if __name__ == '__main__':
    text = Upper('Lorem ipsum')

    print text[:]
    print text[::]

----------
components: Interpreter Core
messages: 104148
nosy: flox
priority: normal
severity: normal
status: open
title: subclassing builtin class (str, unicode, list...) needs to override __getslice__
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr 25 20:05:11 2010
From: report at bugs.python.org (Alex)
Date: Sun, 25 Apr 2010 18:05:11 +0000
Subject: [New-bugs-announce] [issue8530] Stringlib fastsearch can read
	beyond the front of an array
In-Reply-To: <1272218711.28.0.946765845832.issue8530@psf.upfronthosting.co.za>
Message-ID: <1272218711.28.0.946765845832.issue8530@psf.upfronthosting.co.za>


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

In Objects/stringlib/fastsearch.h the lines:

                if (!STRINGLIB_BLOOM(mask, s[i-1]))

and

                if (!STRINGLIB_BLOOM(mask, s[i-1]))

can read beyond the front of the array that is passed to it when the loop enters with i = 0.

I originally noticed this when porting the algorithm to PyPy (which has bounds checking :)), all tests pass if I simple add `if i-1 >= 0` before the conditional.  This doesn't appear to actually cause the algorithm to ever break, but it is unsafe.

----------
messages: 104149
nosy: alex
severity: normal
status: open
title: Stringlib fastsearch can read beyond the front of an array

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

From report at bugs.python.org  Mon Apr 26 00:51:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 25 Apr 2010 22:51:34 +0000
Subject: [New-bugs-announce] [issue8531] libffi: selected processor does not
	support stfeqd/ldfd	(ARMv7Thumb)
In-Reply-To: <1272235894.81.0.335308962849.issue8531@psf.upfronthosting.co.za>
Message-ID: <1272235894.81.0.335308962849.issue8531@psf.upfronthosting.co.za>


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

Errors on ARMv7Thumb Ubuntu 3.1 buildbot.

http://www.python.org/dev/buildbot/builders/ARMv7Thumb Ubuntu 3.1/builds/37/steps/compile/logs/stdio

creating build/temp.linux-armv7l-3.1-pydebug/libffi
checking build system type... armv7l-unknown-linux-gnu
checking host system type... armv7l-unknown-linux-gnu
checking target system type... armv7l-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
...
config.status: executing src commands
building '_ctypes' extension
creating build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi
creating build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src
creating build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/_ctypes.c -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/_ctypes.o
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/callbacks.c -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/callbacks.o
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/callproc.c -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/callproc.o
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/stgdict.c -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/stgdict.o
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/cfield.c -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/cfield.o
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/malloc_closure.c -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/malloc_closure.o
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/prep_cif.o
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -Wall -Wstrict-prototypes -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi/include -Ibuild/temp.linux-armv7l-3.1-pydebug/libffi -I/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src -I. -I./Include -I/usr/local/include -IInclude -I/home/doko/buildarea/3.1.klose-linux-arm/build -c /home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.S -o build/temp.linux-armv7l-3.1-pydebug/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.o
/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.S: Assembler messages:
/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.S:203: Error: selected processor does not support `stfeqs f0,[r2]'
/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.S:208: Error: selected processor does not support `stfeqd f0,[r2]'
/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.S:283: Error: selected processor does not support `ldfs f0,[sp]'
/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.S:286: Error: selected processor does not support `ldfd f0,[sp]'
/home/doko/buildarea/3.1.klose-linux-arm/build/Modules/_ctypes/libffi/src/arm/sysv.S:289: Error: selected processor does not support `ldfd f0,[sp]'

----------
components: Library (Lib)
messages: 104179
nosy: haypo
severity: normal
status: open
title: libffi: selected processor does not support stfeqd/ldfd (ARMv7Thumb)
versions: Python 3.1

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

From report at bugs.python.org  Mon Apr 26 05:41:42 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 26 Apr 2010 03:41:42 +0000
Subject: [New-bugs-announce] [issue8532] Refinements to Python 3 New GIL
In-Reply-To: <1272253302.41.0.224696539666.issue8532@psf.upfronthosting.co.za>
Message-ID: <1272253302.41.0.224696539666.issue8532@psf.upfronthosting.co.za>


New submission from David Beazley <dave at dabeaz.com>:

The attached patch makes two simple refinements to the new GIL implemented in Python 3.2.   Each is briefly described below.

1. Changed mechanism for thread time expiration

In the current implementation, threads perform a timed-wait on a condition variable.  If time expires and no thread switches have occurred, the currently running thread is forced to drop the GIL.

In the patch, timeouts are now performed by a special "GIL monitor" thread.  This thread runs independently of Python and simply handles time expiration.  Basically, it records the number of thread switches, sleeps for a specified interval (5ms), and then looks at the number of thread switches again.  If no switches occurred, it forces the currently running thread to drop the GIL.

With this monitor thread, it is no longer necessary to perform any timed condition variable waits.  This approach has a few subtle benefits.  First, threads no longer sit in a wait/timeout cycle when trying to get the GIL (so, there is less overhead).   Second, you get FIFO scheduling of threads.  When time expires, the thread that has been waiting the longest on the condition variable runs next.  Generally, you want this.

2. A very simple two-level priority mechanism

A new attribute 'cpu_bound' is added to the PyThreadState structure.  If a thread is ever forced to drop the GIL, this attribute is simply set True (1).  If a thread gives up the GIL voluntarily, it is set back to False (0).  This attribute is used to set up simple scheduling (described next).

There are now two separate condition variables (gil_cpu_cond) and (gil_io_cond) that separate waiting threads according to their cpu_bound attribute setting.  CPU-bound threads wait on gil_cpu_cond whereas I/O-bound threads wait on gil_io_cond. 

Using the two condition variables, the following scheduling rules are enforced:

   - If there are any waiting I/O bound threads, they are always signaled first, before any CPU-bound threads.
   - If an I/O bound thread wants the GIL, but a CPU-bound thread is running, the CPU-bound thread is immediately forced to drop the GIL.
   - If a CPU-bound thread wants the GIL, but another CPU-bound thread is running, the running thread is immediately forced to drop the GIL if its time period has already expired.

Results
-------
This patch gives excellent results for both the ccbench test and all of my previous I/O bound tests.  Here is the output:

== CPython 3.2a0.0 (py3k:80470:80497M) ==
== i386 Darwin on 'i386' ==

--- Throughput ---

Pi calculation (Python)

threads=1: 871 iterations/s.
threads=2: 844 ( 96 %)
threads=3: 838 ( 96 %)
threads=4: 826 ( 94 %)

regular expression (C)

threads=1: 367 iterations/s.
threads=2: 345 ( 94 %)
threads=3: 339 ( 92 %)
threads=4: 327 ( 89 %)

bz2 compression (C)

threads=1: 384 iterations/s.
threads=2: 728 ( 189 %)
threads=3: 695 ( 180 %)
threads=4: 707 ( 184 %)

--- Latency ---

Background CPU task: Pi calculation (Python)

CPU threads=0: 0 ms. (std dev: 0 ms.)
CPU threads=1: 0 ms. (std dev: 0 ms.)
CPU threads=2: 1 ms. (std dev: 2 ms.)
CPU threads=3: 0 ms. (std dev: 1 ms.)
CPU threads=4: 0 ms. (std dev: 1 ms.)

Background CPU task: regular expression (C)

CPU threads=0: 0 ms. (std dev: 0 ms.)
CPU threads=1: 2 ms. (std dev: 1 ms.)
CPU threads=2: 1 ms. (std dev: 1 ms.)
CPU threads=3: 1 ms. (std dev: 1 ms.)
CPU threads=4: 2 ms. (std dev: 1 ms.)

Background CPU task: bz2 compression (C)

CPU threads=0: 0 ms. (std dev: 0 ms.)
CPU threads=1: 0 ms. (std dev: 2 ms.)
CPU threads=2: 2 ms. (std dev: 3 ms.)
CPU threads=3: 0 ms. (std dev: 1 ms.)
CPU threads=4: 0 ms. (std dev: 1 ms.)

--- I/O bandwidth ---

Background CPU task: Pi calculation (Python)

CPU threads=0: 5850.9 packets/s.
CPU threads=1: 5246.8 ( 89 %)
CPU threads=2: 4228.9 ( 72 %)
CPU threads=3: 4222.8 ( 72 %)
CPU threads=4: 2959.5 ( 50 %)

Particular attention should be given to tests involving I/O performance.  In particular, here are the results of the I/O bandwidth test using the unmodified GIL:

--- I/O bandwidth ---

Background CPU task: Pi calculation (Python)

CPU threads=0: 6007.1 packets/s.
CPU threads=1: 189.0 ( 3 %)
CPU threads=2: 19.7 ( 0 %)
CPU threads=3: 19.7 ( 0 %)
CPU threads=4: 5.1 ( 0 %)

Other Benefits
--------------
This patch does not involve any complicated libraries, platform specific functionality, low-level lock twiddling, or mathematically complex priority scheduling algorithms.  Emphasize: The code is simple.

Negative Aspects
----------------
This modification might introduce a starvation effect where CPU-bound threads never get to run if there is an extremely heavy load of I/O-bound threads competing for the GIL.

Is starvation a real problem or a theoretical problem?  Hard to say. Would need study.

----------
components: Interpreter Core
files: gil.patch
keywords: patch
messages: 104192
nosy: dabeaz
severity: normal
status: open
title: Refinements to Python 3 New GIL
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file17083/gil.patch

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

From report at bugs.python.org  Mon Apr 26 12:43:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Apr 2010 10:43:13 +0000
Subject: [New-bugs-announce] [issue8533] regrtest: use backslashreplace
	error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>


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

If a test fails, regrtest writes the backtrace to sys.stdout. If the backtrace contains a non-ASCII characters, it's encoded using sys.stdout encoding.

In some conditions, sys.stdout is unable to encode some or all non-ASCII characters. Eg. if there is no locale set (empty environment or at least empty LANG variable value), sys.stdout.encoding="ascii".

If regrtest fails to display a test output (error backtrace), regrtest exits directly (don't execute next tests).

I propose to use backslashreplace error handler in sys.stdout, as done for sys.stderr to avoid this annoying issue.

Attached patch (for py3k) replace sys.stdout by a new file using backslashreplace, just before executing the tests.

I don't know if the issue concerns also Python2.

----------
files: regrtest_stdout_backslashreplace.patch
keywords: patch
messages: 104212
nosy: haypo
severity: normal
status: open
title: regrtest: use backslashreplace error handler for stdout
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17090/regrtest_stdout_backslashreplace.patch

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

From report at bugs.python.org  Mon Apr 26 12:52:15 2010
From: report at bugs.python.org (simon)
Date: Mon, 26 Apr 2010 10:52:15 +0000
Subject: [New-bugs-announce] [issue8534] multiprocessing not working from egg
In-Reply-To: <1272279135.33.0.722115657871.issue8534@psf.upfronthosting.co.za>
Message-ID: <1272279135.33.0.722115657871.issue8534@psf.upfronthosting.co.za>


New submission from simon <ext-simon.steiner at nokia.com>:

testmultiprocessing.py:

def main():
    import multiprocessing

    proc = multiprocessing.Process(target=runhi)
    proc.start()
    proc.join()
    
def runhi():
    print 'hi'
    
if __name__ == "__main__":
    main()

testmultiprocessing.py is inside myegg.egg

set PYTHONPATH=myegg.egg

python -m testmultiprocessing

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Python26\lib\multiprocessing\forking.py", line 341, in main
    prepare(preparation_data)
  File "C:\Python26\lib\multiprocessing\forking.py", line 450, in prepare
    file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named testmultiprocessing

----------
components: Library (Lib)
messages: 104215
nosy: simonsteiner
severity: normal
status: open
title: multiprocessing not working from egg
versions: Python 2.6

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

From report at bugs.python.org  Mon Apr 26 13:00:43 2010
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 26 Apr 2010 11:00:43 +0000
Subject: [New-bugs-announce] [issue8535] passing optimization flags to the
	linker required for	builds with gcc -flto
In-Reply-To: <1272279643.52.0.447435684789.issue8535@psf.upfronthosting.co.za>
Message-ID: <1272279643.52.0.447435684789.issue8535@psf.upfronthosting.co.za>


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

Building with -flto (GCC 4.5.0) requires passing the very same optimization flags to the linker (lto1) as well. The attached patch just does this.  Tested on Linux only, I don't know what will/could break on on other systems/compilers.

Tested with a static build (--disable-shared) on x86_64. pybench results improve by 5% when building with 4.5.0 instead of 4.4.3, and by another 5% by building with -flto.

----------
components: Build
files: make-lto.diff
keywords: needs review, patch
messages: 104217
nosy: doko
severity: normal
status: open
title: passing optimization flags to the linker required for builds with gcc -flto
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17091/make-lto.diff

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

From report at bugs.python.org  Mon Apr 26 19:23:11 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 26 Apr 2010 17:23:11 +0000
Subject: [New-bugs-announce] [issue8536] Support new features of ZLIB 1.2.5
In-Reply-To: <1272302591.08.0.11918516326.issue8536@psf.upfronthosting.co.za>
Message-ID: <1272302591.08.0.11918516326.issue8536@psf.upfronthosting.co.za>


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

Zlib 1.2.5 adds new features like "inflateReset2()", "inflateMark()", or "Z_TREES" flags.

We should support them if we have zlib 1.2.5 installed.

I think the patch is trivial, beside testing that we have a recent zlib version.

----------
keywords: easy
messages: 104254
nosy: jcea
severity: normal
status: open
title: Support new features of ZLIB 1.2.5
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon Apr 26 19:36:34 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 26 Apr 2010 17:36:34 +0000
Subject: [New-bugs-announce] [issue8537] Add ConfigureAction to argparse
In-Reply-To: <1272303394.25.0.68455397409.issue8537@psf.upfronthosting.co.za>
Message-ID: <1272303394.25.0.68455397409.issue8537@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

>From a python-dev email from Neal Becker, copied here so it won't get lost.
----------------------------
steven.bethard at gmail.com made a very nice module for me to enhance argparse called argparse_bool.py, which contains ConfigureAction.  This will allow a boolean value to be set very like the gnu configure style:

--foo
--with-foo
--without-foo
--no-foo
--foo=yes
--foo=no

I've been happily using it, and I think it would be of sufficient general interest to include it with the standard library.

----------
components: Library (Lib)
files: argparse_bool.py
messages: 104258
nosy: bethard, eric.smith
severity: normal
status: open
title: Add ConfigureAction to argparse
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17099/argparse_bool.py

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

From report at bugs.python.org  Mon Apr 26 19:38:07 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 26 Apr 2010 17:38:07 +0000
Subject: [New-bugs-announce] [issue8538] Add ConfigureAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

>From a python-dev email from Neal Becker, copied here so it won't get lost.
----------------------------
steven.bethard at gmail.com made a very nice module for me to enhance argparse called argparse_bool.py, which contains ConfigureAction.  This will allow a boolean value to be set very like the gnu configure style:

--foo
--with-foo
--without-foo
--no-foo
--foo=yes
--foo=no

I've been happily using it, and I think it would be of sufficient general interest to include it with the standard library.

----------
components: Library (Lib)
files: argparse_bool.py
messages: 104259
nosy: bethard, eric.smith
severity: normal
status: open
title: Add ConfigureAction to argparse
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17100/argparse_bool.py

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

From report at bugs.python.org  Mon Apr 26 19:38:11 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 26 Apr 2010 17:38:11 +0000
Subject: [New-bugs-announce] [issue8539] Add ConfigureAction to argparse
In-Reply-To: <1272303491.8.0.482178644573.issue8539@psf.upfronthosting.co.za>
Message-ID: <1272303491.8.0.482178644573.issue8539@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

>From a python-dev email from Neal Becker, copied here so it won't get lost.
----------------------------
steven.bethard at gmail.com made a very nice module for me to enhance argparse called argparse_bool.py, which contains ConfigureAction.  This will allow a boolean value to be set very like the gnu configure style:

--foo
--with-foo
--without-foo
--no-foo
--foo=yes
--foo=no

I've been happily using it, and I think it would be of sufficient general interest to include it with the standard library.

----------
components: Library (Lib)
files: argparse_bool.py
messages: 104260
nosy: bethard, eric.smith
severity: normal
status: open
title: Add ConfigureAction to argparse
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17101/argparse_bool.py

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

From report at bugs.python.org  Mon Apr 26 19:45:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 26 Apr 2010 17:45:31 +0000
Subject: [New-bugs-announce] [issue8540] Make Context._clamp public in
	decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>


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

The Context class in the decimal module has a hidden _clamp attribute, that controls whether to clamp values with large exponents.  (Clamping a Decimal value involves adding extra significant zeros to decrease its exponent, while not altering the numeric value;  it's sometimes necessary to get the exponent within a legal range).

I think we should consider making this attribute public (documenting it, having it appear in the __str__ or __repr__ of a Context), for a couple of reasons:

(1) It's necessary for full compliance with the specification:  Python's default behaviour is actually non-compliant with the spec;  it's only after doing getcontext()._clamp = 1 that it complies.

(2) Clamping is necessary for modeling the standard formats described in IEEE 754-2008 (decimal64, decimal128), etc.  These formats are coming into use in other languages (gcc already supports them and C201x may well include them).  To be able to communicate effectively with other languages using these formats, it would be useful to expose Context._clamp.

----------
components: Library (Lib)
messages: 104263
nosy: facundobatista, mark.dickinson, rhettinger, skrah
severity: normal
stage: unit test needed
status: open
title: Make Context._clamp public in decimal module
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon Apr 26 22:32:02 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Apr 2010 20:32:02 +0000
Subject: [New-bugs-announce] [issue8541] Test issue
In-Reply-To: <1272313922.39.0.094018844125.issue8541@psf.upfronthosting.co.za>
Message-ID: <1272313922.39.0.094018844125.issue8541@psf.upfronthosting.co.za>


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

What is the default priority?

----------
messages: 104274
nosy: loewis
severity: normal
status: open
title: Test issue

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

From report at bugs.python.org  Mon Apr 26 22:33:20 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 26 Apr 2010 20:33:20 +0000
Subject: [New-bugs-announce] [issue8542] Another test issue
In-Reply-To: <1272314000.64.0.308936581064.issue8542@psf.upfronthosting.co.za>
Message-ID: <1272314000.64.0.308936581064.issue8542@psf.upfronthosting.co.za>


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

What is the priority now?

----------
messages: 104275
nosy: loewis
priority: normal
severity: normal
status: open
title: Another test issue

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

From report at bugs.python.org  Tue Apr 27 02:21:56 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 27 Apr 2010 00:21:56 +0000
Subject: [New-bugs-announce] [issue8543] asynchat documentation issues
In-Reply-To: <1272327716.6.0.330146837093.issue8543@psf.upfronthosting.co.za>
Message-ID: <1272327716.6.0.330146837093.issue8543@psf.upfronthosting.co.za>


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

I recently took a look at asynchat doc and found out it has some issues which should be addressed.
In my opinion the following methods and functions should NOT be mentioned:


- async_chat.refill_buffer()

this has been removed in Python 2.6 and no longer exists, plus there was no reason to override it in the first place as it was an internal method


 - asynchat.find_prefix_at_end(haystack, needle)

there's really no reason to mention this one, it is just used internally by async_chat class to implement the terminator logic


- async_chat.handle_close()
- async_chat.readable()
- async_chat.writable()
- async_chat.handle_read()
- async_chat.handle_write()

all inherited from asyncore, plus, aside from handle_close(), they should *NOT* be overridden as they implement the entire logic behind asynchat module


- class asynchat.simple_producer(data[, buffer_size=512])
- class asynchat.fifo([list=None])

as discussed in issue 6916 these are very old classes which are no longer used; imho not worth to be mentioned in the doc


- async_chat._collect_incoming_data(data)
- async_chat._get_data()

both added in 2.6 (this isn't mentioned), not sure if it's worth mentioning them (I wouldn't) but they're basically private methods which are never used in the base class and only provide a sample implementation


I think asynchat documentation should focus more on showing those parts of the API which are really going to be used, basically push*(), close_when_done() and terminator-related methods.
All other methods like handle_*(), etc..., are deliberately not supposed to be used and only create confusion.

I think I'm going to attach a patch tomorrow but I'd like to hear the opinion of Josiah Carlson before doing anything.

----------
assignee: docs at python
components: Documentation
messages: 104292
nosy: docs at python, giampaolo.rodola, josiah.carlson, josiahcarlson, r.david.murray
priority: normal
severity: normal
status: open
title: asynchat documentation issues
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Apr 27 06:25:06 2010
From: report at bugs.python.org (LOLLA RADHA KRISHNA MURTHY)
Date: Tue, 27 Apr 2010 04:25:06 +0000
Subject: [New-bugs-announce] [issue8544] i didn't get rqrd output for
	programme in python?(plz...	help)
In-Reply-To: <1272342306.38.0.0856724920628.issue8544@psf.upfronthosting.co.za>
Message-ID: <1272342306.38.0.0856724920628.issue8544@psf.upfronthosting.co.za>


New submission from LOLLA RADHA KRISHNA MURTHY <radhakrishna21 at rocketmail.com>:

i want to print the all posssibilities that occurs in rearrangement of letter between given input?(repetations are not allowed)?

suppose i give input as car => the output is like this

car
cra
acr
arc
rac
rca

like that ..i want factorial of length of the given input ?

----------
messages: 104294
nosy: abdelazer, krishnalolla
priority: normal
severity: normal
status: open
title: i didn't get rqrd output for programme in python?(plz... help)

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

From report at bugs.python.org  Tue Apr 27 06:26:19 2010
From: report at bugs.python.org (LOLLA RADHA KRISHNA MURTHY)
Date: Tue, 27 Apr 2010 04:26:19 +0000
Subject: [New-bugs-announce] [issue8545] i didn't get rqrd output for
	programme in python?(plz...	help)
In-Reply-To: <1272342379.47.0.213432765207.issue8545@psf.upfronthosting.co.za>
Message-ID: <1272342379.47.0.213432765207.issue8545@psf.upfronthosting.co.za>


New submission from LOLLA RADHA KRISHNA MURTHY <radhakrishna21 at rocketmail.com>:

i want to print the all posssibilities that occurs in rearrangement of letter between given input?(repetations are not allowed)?

suppose i give input as car => the output is like this

car
cra
acr
arc
rac
rca

like that ..i want factorial of length of the given input ?

----------
components: Regular Expressions
messages: 104295
nosy: abdelazer, krishnalolla
priority: normal
severity: normal
status: open
title: i didn't get rqrd output for programme in python?(plz... help)
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr 27 10:26:49 2010
From: report at bugs.python.org (Patrick Sabin)
Date: Tue, 27 Apr 2010 08:26:49 +0000
Subject: [New-bugs-announce] [issue8546] The parameter buffering in
	_pyio.open doesn't work the	same as in the builtin open
In-Reply-To: <1272356809.52.0.04485285277.issue8546@psf.upfronthosting.co.za>
Message-ID: <1272356809.52.0.04485285277.issue8546@psf.upfronthosting.co.za>


New submission from Patrick Sabin <patricksabin at gmx.at>:

As far as I understand the _pyio.open function should resemble the builtin open, but in case of the buffering parameter, it doesn't. The builtin version doesn't allow None as argument, but this is the default in the _pyio.open signature.

I attached a patch, which changes the default value of the buffering parameter to -1, which is the default in the builtin version.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: change_pyio_open_buffering_parameter.diff
keywords: patch
messages: 104301
nosy: docs at python, pyfex
priority: normal
severity: normal
status: open
title: The parameter buffering in _pyio.open doesn't work the same as in the builtin open
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17103/change_pyio_open_buffering_parameter.diff

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

From report at bugs.python.org  Tue Apr 27 14:23:19 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 27 Apr 2010 12:23:19 +0000
Subject: [New-bugs-announce] [issue8547] unittest test discovery can fail
	when package under test	is also installed globally
In-Reply-To: <1272370999.28.0.856365005412.issue8547@psf.upfronthosting.co.za>
Message-ID: <1272370999.28.0.856365005412.issue8547@psf.upfronthosting.co.za>


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

When test discovery is invoked on a package on the filesystem which is also installed in site-packages then importing the tests will look in the installed version. This causes discovery to run the wrong tests or fail.

We can detect this (compare the __file__ against the expected location) and also insert the top level path as the first location in sys.path instead of appending it to the end.

If we detect a failed import then we should error out with an appropriate message.

(Nose gets round this by patching __import__ to import from a specific location which seems potentially fragile.)

----------
assignee: michael.foord
components: Library (Lib)
messages: 104313
nosy: michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest test discovery can fail when package under test is also installed globally
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Apr 27 18:43:11 2010
From: report at bugs.python.org (Jeff Binder)
Date: Tue, 27 Apr 2010 16:43:11 +0000
Subject: [New-bugs-announce] [issue8548] Building on CygWin 1.7: PATH_MAX
	redefined
In-Reply-To: <1272386591.01.0.834578637911.issue8548@psf.upfronthosting.co.za>
Message-ID: <1272386591.01.0.834578637911.issue8548@psf.upfronthosting.co.za>


New submission from Jeff Binder <extruded at gmail.com>:

Building Python 3.1.2 on Cygwin 1.7, I got errors in main.c stemming from a warning: PATH_MAX redefined (see attached log).  I got around this by commenting out the #define.  I don't know if the best solution is #ifndef, #undef, or something else. . . . I know CygWin has changed the value of PATH_MAX in 1.7 (see: http://www.cygwin.com/cygwin-ug-net/ov-new1.7.html), though I'm not sure why that would cause this problem.

----------
components: Installation
files: python-build-logs.tar.gz
messages: 104334
nosy: jbinder
priority: normal
severity: normal
status: open
title: Building on CygWin 1.7: PATH_MAX redefined
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file17107/python-build-logs.tar.gz

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

From report at bugs.python.org  Tue Apr 27 20:31:20 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 27 Apr 2010 18:31:20 +0000
Subject: [New-bugs-announce] [issue8549] Modules/_ssl.c: extra comma breaks
	build on AIX
In-Reply-To: <1272393080.82.0.0882803221687.issue8549@psf.upfronthosting.co.za>
Message-ID: <1272393080.82.0.0882803221687.issue8549@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Modules/_ssl.c

guido at 36917	
    64
enum py_ssl_version {
guido at 36917	
    65
	PY_SSL_VERSION_SSL2,
guido at 36917	
    66
	PY_SSL_VERSION_SSL3,
guido at 36917	
    67
	PY_SSL_VERSION_SSL23,
guido at 36917	
    68
	PY_SSL_VERSION_TLS1,
guido at 36917	
    69
};

Attached patch fixes this issue.

----------
components: Build
messages: 104347
nosy: srid
priority: normal
severity: normal
status: open
title: Modules/_ssl.c: extra comma breaks build on AIX
versions: Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue Apr 27 22:56:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Apr 2010 20:56:43 +0000
Subject: [New-bugs-announce] [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>


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

We should expose SSL contexts at the Python level, and rework SSL sockets to use those objects internally (rather than creating their own private context).
It would allow to:
- specify the various options iteratively, rather than having to dump them all in the wrap_socket() arguments
- add methods to query information about the current options, key/cert, etc.
- solve issue3823 (you can build the context first, passing it the key/cert info, then drop privileges before creating any sockets)
- more easily share and reuse configuration information
- possibly add more powerful functionality such as sessions

The way I see it, the existing wrap_socket() module-level function would be kept for compatibility; context objects would expose their own wrap_socket() method, without all the arguments of course.

----------
components: Library (Lib)
messages: 104359
nosy: giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Expose SSL contexts
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Wed Apr 28 00:20:21 2010
From: report at bugs.python.org (David Albert Torpey)
Date: Tue, 27 Apr 2010 22:20:21 +0000
Subject: [New-bugs-announce] [issue8551] Start argument for str.rfind used
	incorrectly
In-Reply-To: <1272406821.86.0.455746879552.issue8551@psf.upfronthosting.co.za>
Message-ID: <1272406821.86.0.455746879552.issue8551@psf.upfronthosting.co.za>


New submission from David Albert Torpey <dtorp at users.sourceforge.net>:

The purpose of the start argument in str.find() and str.rfind() is to allow for repeated searches.  

>>> def find_third_occurrence(s, value):
...	p = s.find(value)
...	p = s.find(value, p+1)
...	return s.find(value, p+1)
...
>>> find_third_occurrence('scientific american', 'c')
16

The rfind() method is meant for searching from the right, but its start argument is used internally as if it were searching from the left.  This bug makes it useless for repeated searches from the right.

>>> 'scientific american'.rfind('c')
16
>>> 'scientific american'.rfind('c', 15)
16
>>> 'scientific american'.rfind('c', 14)
16

Having found the first 'c' from the right at position 16, there is no way to tell it to search further from the right and find the second 'c' at position 9.

----------
components: Interpreter Core
messages: 104375
nosy: dtorp
priority: normal
severity: normal
status: open
title: Start argument for str.rfind used incorrectly
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Apr 28 00:55:51 2010
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 27 Apr 2010 22:55:51 +0000
Subject: [New-bugs-announce] [issue8552] msilib can't create large CAB files
In-Reply-To: <1272408951.39.0.507376251976.issue8552@psf.upfronthosting.co.za>
Message-ID: <1272408951.39.0.507376251976.issue8552@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

I'm trying to create a CAB file containing about 69MB of data, in 4555 files.  msilib fails in CAB.commit():

$ python build-msi-installer.py /c/UpLib/1.7.9 ~/uplib 1.7.9 ./uplib-1.7.9.msi
c:\Documents and Settings\wjanssen\uplib\win32\uplib-1.7.9.msi
install_location c:/UpLib/1.7.9
c:\docume~1\wjanssen\locals~1\temp\tmpu5dwz6 68943045
gc: collecting generation 0...
gc: objects in each generation: 670 702 8255
gc: done, 0.0000s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 707 1364 8255
gc: done, 0.0000s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 699 2031 8255
gc: done, 0.0000s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 794 2680 8255
gc: done, 0.0000s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 730 3373 8255
gc: done, 0.0000s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 765 4018 8255
gc: done, 0.0000s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 741 4697 8255
gc: done, 0.0000s elapsed.
(1, 4555, None, '#prereqs', None, None)
Traceback (most recent call last):
  File "build-msi-installer.py", line 780, in <module>
    p.run()
  File "build-msi-installer.py", line 243, in run
    self.add_files()
  File "build-msi-installer.py", line 312, in add_files
    cab.commit(self.db)
  File "c:\Python26\lib\msilib\__init__.py", line 223, in commit
    [(1, self.index, None, "#"+self.name, None, None)])
  File "c:\Python26\lib\msilib\__init__.py", line 97, in add_data
    v = db.OpenView("SELECT * FROM `%s`" % table)
_msi.MSIError: 1: 2229 2: c:\Documents and Settings\wjanssen\uplib\win32\uplib-1.7.9.msi 3: Media 4: SELECT * FROM `Media` 
gc: collecting generation 2...
gc: objects in each generation: 416 5351 8254
gc: done, 0.0000s elapsed.
$

(I added a bit of code to print out the Media table record, and the size of the file created with FCICreate.)

This works fine if I choose a slightly smaller subset, such as /c/UpLib/1.7.9/lib, for instance.  So I'm guessing this is a memory problem; at some point there's just not enough memory to open the MSI file and load the Media table.

I opened the MSI file with orca and sure enough, there is no Media table in it.  Not sure how to take that, though;  perhaps the table only appears after a record has been written to it.

Another reason to allow multiple CAB files in a single installer?

----------
components: Library (Lib), Windows
messages: 104379
nosy: janssen, loewis
priority: normal
severity: normal
status: open
title: msilib can't create large CAB files
type: resource usage
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr 28 03:18:32 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Wed, 28 Apr 2010 01:18:32 +0000
Subject: [New-bugs-announce] [issue8553] 2to3 breaks relative imports
In-Reply-To: <1272417512.55.0.562035321264.issue8553@psf.upfronthosting.co.za>
Message-ID: <1272417512.55.0.562035321264.issue8553@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin <jyasskin at gmail.com>:

2to3, at least the version in the python-2 tree, currently turns

  from . import refactor

into

  from .. import refactor

which breaks the transformation of 2to3 itself.  The attached patch fixes this and tests it.

Once someone's looked this over, where should I commit it? I'm not sure where 2to3 actually lives anymore.

----------
components: Library (Lib)
files: 2to3_fix.patch
keywords: needs review, patch, patch
messages: 104392
nosy: jyasskin
priority: normal
severity: normal
stage: patch review
status: open
title: 2to3 breaks relative imports
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17114/2to3_fix.patch

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

From report at bugs.python.org  Wed Apr 28 03:31:32 2010
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 28 Apr 2010 01:31:32 +0000
Subject: [New-bugs-announce] [issue8554] suspicious comment in
	msilib.py/__init__.py
In-Reply-To: <1272418292.04.0.0208509109493.issue8554@psf.upfronthosting.co.za>
Message-ID: <1272418292.04.0.0208509109493.issue8554@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

Take a look at the first line of make_id().  What does that comment mean?  Is the wrong line commented out?

def make_id(str, add_num=True):
    #str = str.replace(".", "_") # colons are allowed

----------
components: Library (Lib), Windows
messages: 104393
nosy: janssen, loewis
priority: low
severity: normal
status: open
title: suspicious comment in msilib.py/__init__.py
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr 28 03:47:35 2010
From: report at bugs.python.org (py.user)
Date: Wed, 28 Apr 2010 01:47:35 +0000
Subject: [New-bugs-announce] [issue8555] tkinter doesn't see _tkinter
In-Reply-To: <1272419255.64.0.530413038247.issue8555@psf.upfronthosting.co.za>
Message-ID: <1272419255.64.0.530413038247.issue8555@psf.upfronthosting.co.za>


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

[guest at station ~]$ python3
Python 3.1.2 (r312:79147, Apr 28 2010, 11:57:19)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1+2
3
>>> import tkinter
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.1/tkinter/__init__.py", line 39, in <module>
    import _tkinter # If this fails your Python may not be configured for Tk
ImportError: No module named _tkinter
>>>

----------
components: Tkinter
messages: 104397
nosy: py.user
priority: normal
severity: normal
status: open
title: tkinter doesn't see _tkinter
type: compile error
versions: Python 3.1

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

From report at bugs.python.org  Wed Apr 28 06:57:27 2010
From: report at bugs.python.org (Jeff McNeil)
Date: Wed, 28 Apr 2010 04:57:27 +0000
Subject: [New-bugs-announce] [issue8556] Confusing string formatting examples
In-Reply-To: <1272430647.21.0.217416978231.issue8556@psf.upfronthosting.co.za>
Message-ID: <1272430647.21.0.217416978231.issue8556@psf.upfronthosting.co.za>


New submission from Jeff McNeil <jeff at jmcneil.net>:

I was going through the string formatting examples this evening and noticed this:

print '%(language)s has %(#)03d quote types.' % \
          {'language': "Python", "#": 2}


The example uses a '#' as a map key. This is somewhat misleading as if we had simply left the parenthesis off, the '#' would have been interpreted as an alternate conversion flag. Should be updated to use a more verbose (and less confusing) dictionary key.

----------
assignee: docs at python
components: Documentation
files: stdtypes.rst.2.6.5.patch
keywords: patch
messages: 104410
nosy: docs at python, mcjeff
priority: normal
severity: normal
status: open
title: Confusing string formatting examples
versions: Python 2.6
Added file: http://bugs.python.org/file17115/stdtypes.rst.2.6.5.patch

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

From report at bugs.python.org  Wed Apr 28 12:44:54 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Wed, 28 Apr 2010 10:44:54 +0000
Subject: [New-bugs-announce] [issue8557] subprocess portability issue
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>


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

On POSIX systems, the PATH environment variable is always used to
look up directory-less executable names passed as the first argument to Popen(...), but on Windows, PATH is only considered when shell=True is also passed.  

Actually I think it may be slightly weirder than that when
shell=False, because the following holds for me:

C:\>rem ##### Prepare minimal PATH #####
C:\>set "PATH=C:\Python26\Scripts;C:\Python26;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem"

C:\>rem ##### Prepare a minimal, clean environment #####
C:\>virtualenv --no-site-packages e:\zzz
New python executable in e:\zzz\Scripts\python.exe
Installing setuptools................done.

C:\>rem ##### Show that shell=True makes the difference in determining whether PATH is respected #####
C:\>python
Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'])
<subprocess.Popen object at 0x0000000001DBE080>
>>> C:\Python26\python.exe

>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'], env={'PATH':r'e:\zzz\Scripts'})
<subprocess.Popen object at 0x0000000001F05A90>
>>> C:\Python26\python.exe

>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'], env={'PATH':r'e:\zzz\Scripts'}, shell=True)
<subprocess.Popen object at 0x0000000001F05B00>
>>> e:\zzz\Scripts\python.exe

That is, it looks like the environment at the time Python is invoked is what counts unless I pass shell=True.  I don't even seem to be able to override this behavior by changing os.environ: you can clear() it and pass env={} and subprocess.Popen(['python']) still succeeds.

This is a very important problem for portable code and one that took me hours to suss out.  I think:

a) the current behavior needs to be documented
b) it needs to be fixed if possible
c) otherwise, shell=True should be the default

----------
assignee: docs at python
components: Documentation
messages: 104422
nosy: dabrahams, docs at python
priority: normal
severity: normal
status: open
title: subprocess portability issue
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr 28 12:46:46 2010
From: report at bugs.python.org (holger krekel)
Date: Wed, 28 Apr 2010 10:46:46 +0000
Subject: [New-bugs-announce] [issue8558] StringIO().truncate causes
	zero-bytes in getvalue()
In-Reply-To: <1272451606.03.0.52752121391.issue8558@psf.upfronthosting.co.za>
Message-ID: <1272451606.03.0.52752121391.issue8558@psf.upfronthosting.co.za>


New submission from holger krekel <holger.krekel at gmail.com>:

Running the attached file with python3.1.1 works fine, all assertions pass.  Running it with 3.1.2 gives me this output: 

$ python3.1.2/bin/python3.1 stringio_fail.py
Traceback (most recent call last):
  File "stringio_fail.py", line 12, in <module>
    assert s == "world", repr(s)
AssertionError: '\x00\x00\x00\x00\x00world'

----------
components: IO
files: stringio_fail.py
messages: 104423
nosy: hpk
priority: normal
severity: normal
status: open
title: StringIO().truncate causes zero-bytes in getvalue()
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file17116/stringio_fail.py

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

From report at bugs.python.org  Wed Apr 28 15:58:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Apr 2010 13:58:59 +0000
Subject: [New-bugs-announce] [issue8559] test_gdb: test_strings() fails with
	ASCII locale
In-Reply-To: <1272463139.31.0.880014845784.issue8559@psf.upfronthosting.co.za>
Message-ID: <1272463139.31.0.880014845784.issue8559@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/builders/alpha Debian 3.x/builds/67/steps/test/logs/stdio

======================================================================
ERROR: test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode strings
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_gdb.py", line 230, in test_strings
    self.assertGdbRepr('\u2620')
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_gdb.py", line 176, in assertGdbRepr
    cmds_after_breakpoint)
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_gdb.py", line 144, in get_gdb_repr
    import_site=import_site)
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_gdb.py", line 120, in get_stack_trace
    out, err = self.run_gdb(*args)
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_gdb.py", line 60, in run_gdb
    args, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/subprocess.py", line 670, in __init__
    restore_signals, start_new_session)
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/subprocess.py", line 1115, in _execute_child
    restore_signals, start_new_session, preexec_fn)
UnicodeEncodeError: 'ascii' codec can't encode character '\u2620' in position 4: ordinal not in range(128)

You can try with: "LANG= ./python Lib/test/regrtest.py test_gdb".

We should skip the test if '\u2620' is not encodable to sys.getfileystemencoding(), or maybe use '\\u2620'.

----------
components: Tests, Unicode
messages: 104431
nosy: dmalcolm, haypo, loewis
priority: normal
severity: normal
status: open
title: test_gdb: test_strings() fails with ASCII locale
versions: Python 3.2

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

From report at bugs.python.org  Wed Apr 28 19:01:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Apr 2010 17:01:45 +0000
Subject: [New-bugs-announce] [issue8560] regrtest: add a minimal "progress
	bar"
In-Reply-To: <1272474105.27.0.516301529425.issue8560@psf.upfronthosting.co.za>
Message-ID: <1272474105.27.0.516301529425.issue8560@psf.upfronthosting.co.za>


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

regrtest takes between 10 and 20 minutes to run the full test suite. It would be nice to see the progress of the test suite with a kind of progress bar. Add the test number would be enough:

$ ./python Lib/test/regrtest.py                             
...
test_grammar (1/340)                                             
test_opcodes (2/340)                                             
test_dict (3/340)                                                
test_builtin (4/340)                                             
test_exceptions (5/340)                                          
test_types (6/340)                                               
test_unittest (7/340)                                            
...

Attached patch implements that (classic version and multiprocess version).

----------
files: regrtest_progress-py3k.patch
keywords: patch
messages: 104440
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest: add a minimal "progress bar"
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17119/regrtest_progress-py3k.patch

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

From report at bugs.python.org  Wed Apr 28 21:14:27 2010
From: report at bugs.python.org (Nate DeSimone)
Date: Wed, 28 Apr 2010 19:14:27 +0000
Subject: [New-bugs-announce] [issue8561] Install .exes generated with
	distutils to not do a CRC	check
In-Reply-To: <1272482067.44.0.313764636607.issue8561@psf.upfronthosting.co.za>
Message-ID: <1272482067.44.0.313764636607.issue8561@psf.upfronthosting.co.za>


New submission from Nate DeSimone <nateman1352 at gmail.com>:

During network transit, .exe generated with distutils may become corrupted.  The part of the file that is a binary executable is small compared to the full package typically, so it is possible for the installer to run and lay down bad files.  It would be nice if the setup program ran a CRC check on itself before running.

----------
assignee: tarek
components: Distutils
messages: 104451
nosy: Nate.DeSimone, tarek
priority: normal
severity: normal
status: open
title: Install .exes generated with distutils to not do a CRC check
type: feature request
versions: 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/issue8561>
_______________________________________

From report at bugs.python.org  Wed Apr 28 21:45:41 2010
From: report at bugs.python.org (AdamN)
Date: Wed, 28 Apr 2010 19:45:41 +0000
Subject: [New-bugs-announce] [issue8562] hasattr(open,
	'newlines') example gives incorrect results from  PEP0278
In-Reply-To: <1272483941.45.0.330180944367.issue8562@psf.upfronthosting.co.za>
Message-ID: <1272483941.45.0.330180944367.issue8562@psf.upfronthosting.co.za>


New submission from AdamN <adam at varud.com>:

This bug from the Ubuntu list is being moved here:

https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/570737

Newlines support is enabled on Ubuntu but the example from:

http://www.python.org/dev/peps/pep-0278/

Does not give the correct results (of True):

    if hasattr(open, 'newlines'):
            print 'We have universal newline support'

I don't know if this is a documentation problem or whether there is another attr that matters here.

----------
assignee: docs at python
components: Documentation, Windows
messages: 104454
nosy: adamnelson, docs at python
priority: normal
severity: normal
status: open
title: hasattr(open,'newlines') example gives incorrect results from  PEP0278
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr 28 22:01:41 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 28 Apr 2010 20:01:41 +0000
Subject: [New-bugs-announce] [issue8563] [PEP 3147]
	compileall.compile_file() creates empty	__pycache__
	directories for non-.py files
In-Reply-To: <1272484901.98.0.740885457698.issue8563@psf.upfronthosting.co.za>
Message-ID: <1272484901.98.0.740885457698.issue8563@psf.upfronthosting.co.za>


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

compileall.compile_file() creates empty __pycache__ directories for non-.py files.
This problem usually occurs when compileall.compile_file() is called by compileall.compile_dir() and a subdirectory contains non-code files (e.g. locales, images, templates, documentation).
__pycache__ directories also should not be created when generation of .pyc / .pyo files failed due to e.g. SyntaxErrors.
I'm attaching the patch.

$ mkdir test
$ touch test/file
$ tree test
test
??? file

0 directories, 1 file
$ python3.2 -c 'import compileall; compileall.compile_file("test/file")'
$ tree test
test
??? file
??? __pycache__

1 directory, 1 file

----------
components: Library (Lib)
files: compileall.patch
keywords: patch
messages: 104458
nosy: Arfrever, barry
priority: normal
severity: normal
status: open
title: [PEP 3147] compileall.compile_file() creates empty __pycache__ directories for non-.py files
versions: Python 3.2
Added file: http://bugs.python.org/file17121/compileall.patch

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

From report at bugs.python.org  Wed Apr 28 23:51:54 2010
From: report at bugs.python.org (Peter Fein)
Date: Wed, 28 Apr 2010 21:51:54 +0000
Subject: [New-bugs-announce] [issue8564] Update documentation on
	doctest/unittest2 integration
In-Reply-To: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>
Message-ID: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>


New submission from Peter Fein <pfein at pobox.com>:

The documentation on integrating doctests in a file of unittests is confusing and out of date.  This patch updates the documentation to use unittest2 test discovery.

----------
assignee: docs at python
components: Documentation
files: doctest_unittest_integration_doc.diff
keywords: patch
messages: 104468
nosy: docs at python, pfein
priority: normal
severity: normal
status: open
title: Update documentation on doctest/unittest2 integration
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file17123/doctest_unittest_integration_doc.diff

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

From report at bugs.python.org  Thu Apr 29 01:17:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Apr 2010 23:17:02 +0000
Subject: [New-bugs-announce] [issue8565] Always run regrtest.py with -bb
In-Reply-To: <1272496622.45.0.3289728333.issue8565@psf.upfronthosting.co.za>
Message-ID: <1272496622.45.0.3289728333.issue8565@psf.upfronthosting.co.za>


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

-bb option helps debug because it detects errors earlier (comparing byte and unicode strings looks strange, it should be a bug).

Attached patch re-exec regrtest.py with -bb if -bb was not used.

----------
components: Tests
files: regrtest_bb.patch
keywords: patch
messages: 104474
nosy: haypo
priority: normal
severity: normal
status: open
title: Always run regrtest.py with -bb
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17124/regrtest_bb.patch

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

From report at bugs.python.org  Thu Apr 29 01:52:34 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Wed, 28 Apr 2010 23:52:34 +0000
Subject: [New-bugs-announce] [issue8566] 2to3 should run under python 2.5
In-Reply-To: <1272498754.37.0.0259400258036.issue8566@psf.upfronthosting.co.za>
Message-ID: <1272498754.37.0.0259400258036.issue8566@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin <jyasskin at gmail.com>:

Sorry for being all curmudgeonly, but we're using 2to3 in the benchmark suite at http://hg.python.org/benchmarks/, and, since many of the non-CPython implementations are still only 2.5-compatible, the version there needs to run under python 2.5. At the same time, we'd like to be able to use the benchmark version of 2to3 to convert benchmarks to python-3, so we can benchmark changes to CPython's py3k branch. To do that, it'd be nice to be able to import the official 2to3 repository to pick up bug fixes. Therefore, it would be nice for the official repository to run under 2.5.

Here's a patch accomplishing that. It passes its test suite under both 2.5 and 2.6, and can convert itself, and then the converted version can reconvert the original version and get the same result.

You can also review the patch at http://codereview.appspot.com/996043.

----------
assignee: benjamin.peterson
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3_support_2.5.patch
keywords: needs review, patch, patch
messages: 104475
nosy: benjamin.peterson, jyasskin
priority: normal
severity: normal
stage: patch review
status: open
title: 2to3 should run under python 2.5
versions: Python 2.5, Python 2.7
Added file: http://bugs.python.org/file17125/2to3_support_2.5.patch

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

From report at bugs.python.org  Thu Apr 29 13:10:29 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Apr 2010 11:10:29 +0000
Subject: [New-bugs-announce] [issue8567] decimal module doesn't respect
	precedence rules for	exceptional conditions
In-Reply-To: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>
Message-ID: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>


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

http://speleotrove.com/decimal/daexcep.html specifies a precedence for decimal exceptional conditions (scroll right to the bottom of the page):

"""The Clamped, Inexact, Rounded, and Subnormal conditions can coincide with each other or with other conditions. In these cases then any trap enabled for another condition takes precedence over (is handled before) all of these, any Subnormal trap takes precedence over Inexact, any Inexact trap takes precedence over Rounded, and any Rounded trap takes precedence over Clamped.""" 

Currently the decimal module doesn't follow this.  For example, the following should raise decimal.Overflow, not decimal.Inexact:

Python 3.2a0 (py3k:80609, Apr 29 2010, 11:46:22)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> getcontext().traps[Inexact] = True
>>> Decimal('1e100').exp()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/dickinsm/Source/py3k/Lib/decimal.py", line 3002, in exp
    ans = ans._fix(context)
  File "/home/dickinsm/Source/py3k/Lib/decimal.py", line 1658, in _fix
    context._raise_error(Inexact)
  File "/home/dickinsm/Source/py3k/Lib/decimal.py", line 3866, in _raise_error
    raise error(explanation)
decimal.Inexact: None


It's also not clear to me exactly which flags should be set in a case like this.

----------
assignee: mark.dickinson
messages: 104484
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: decimal module doesn't respect precedence rules for exceptional conditions
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/issue8567>
_______________________________________

From report at bugs.python.org  Thu Apr 29 13:45:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Apr 2010 11:45:18 +0000
Subject: [New-bugs-announce] [issue8568] Test issue
In-Reply-To: <1272541518.32.0.0725910640112.issue8568@psf.upfronthosting.co.za>
Message-ID: <1272541518.32.0.0725910640112.issue8568@psf.upfronthosting.co.za>


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

Test issue:  I just got a 'there was a problem with your submission: tracker maintainers informed' message when submitting issue 8567, though it looks as though the submission succeeded.

Here's a test issue to try to reproduce.

Steps taken:

Click on "Create New" in the Issues menu.
Enter title and nosy fields;  all other fields left unspecified.
In nosy list, specify: "skrah,rhettinger,facundo.batista"  (note that the last entry is misspelled;  it should be "facundobatista").

Hit "Submit New Entry".

This takes me to a new page (URL http://bugs.python.org/issue) with the message:

"""
An error has occurred

A problem was encountered processing your request. The tracker maintainers have been notified of the problem.
"""

After hitting the back button in my browser (Firefox) and trying 'Submit New Entry' again I get the 'Your request is being processed.  Please be patient' message.)

Correcting the nosy list allows the submission to go through.

----------
messages: 104485
nosy: facundobatista, mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
status: open
title: Test issue

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

From report at bugs.python.org  Thu Apr 29 14:48:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Apr 2010 12:48:35 +0000
Subject: [New-bugs-announce] [issue8569] Upgrade OpenSSL in Windows builds
In-Reply-To: <1272545315.42.0.523139730845.issue8569@psf.upfronthosting.co.za>
Message-ID: <1272545315.42.0.523139730845.issue8569@psf.upfronthosting.co.za>


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

I don't know how official installers are built, but the standard build procedure with the Visual Studio files uses a custom checkout of OpenSSL 0.9.8l. OpenSSL is now at version 1.0.x, which adds security fixes and improvements.

I'd suggest upgrade the "custom checkout" to use the latest OpenSSL version, at least for dev branches (it may be too disruptive for the bugfix branches, since OpenSSL seems to have a history of changing behaviour a bit even between what look like minor versions). I don't have an idea how to do this myself, Linux being my development platform.

----------
components: Build, Windows
messages: 104496
nosy: brian.curtin, christian.heimes, loewis, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: Upgrade OpenSSL in Windows builds
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Apr 29 16:57:20 2010
From: report at bugs.python.org (rom16384)
Date: Thu, 29 Apr 2010 14:57:20 +0000
Subject: [New-bugs-announce] [issue8570] 2to3 crashes with "AttributeError:
	'int' object has no	attribute 'startswith'"
In-Reply-To: <1272553040.84.0.60116015533.issue8570@psf.upfronthosting.co.za>
Message-ID: <1272553040.84.0.60116015533.issue8570@psf.upfronthosting.co.za>


New submission from rom16384 <rom16384 at yahoo.com>:

The attached file crashes 2to3 with traceback:

Traceback (most recent call last):
  File "/usr/bin/2to3", line 6, in <module>
    sys.exit(main("lib2to3.fixes"))
  File "/usr/lib/python2.6/lib2to3/main.py", line 129, in main
    rt.refactor(args, options.write, options.doctests_only)
  File "/usr/lib/python2.6/lib2to3/refactor.py", line 196, in refactor
    self.refactor_file(dir_or_file, write, doctests_only)
  File "/usr/lib/python2.6/lib2to3/refactor.py", line 235, in refactor_file
    tree = self.refactor_string(input, filename)
  File "/usr/lib/python2.6/lib2to3/refactor.py", line 260, in refactor_string
    self.refactor_tree(tree, name)
  File "/usr/lib/python2.6/lib2to3/refactor.py", line 294, in refactor_tree
    self.traverse_by(self.post_order_heads, tree.post_order())
  File "/usr/lib/python2.6/lib2to3/refactor.py", line 316, in traverse_by
    results = fixer.match(node)
  File "/usr/lib/python2.6/lib2to3/fixes/fix_numliterals.py", line 18, in match
    (node.value.startswith("0") or node.value[-1] in "Ll"))
AttributeError: 'int' object has no attribute 'startswith'


The code is from a version of pupynere, trimmed to reveal the traceback.
Python 2.6.4, OS: Ubuntu 9.10 (Karmic).

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3_crash.py
messages: 104518
nosy: rom16384
priority: normal
severity: normal
status: open
title: 2to3 crashes with "AttributeError: 'int' object has no attribute 'startswith'"
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file17128/2to3_crash.py

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

From report at bugs.python.org  Thu Apr 29 17:35:57 2010
From: report at bugs.python.org (Denis Dmitriev)
Date: Thu, 29 Apr 2010 15:35:57 +0000
Subject: [New-bugs-announce] [issue8571] zlib causes a SystemError when
	decompressing a chunk >1GB
In-Reply-To: <1272555357.11.0.654496142988.issue8571@psf.upfronthosting.co.za>
Message-ID: <1272555357.11.0.654496142988.issue8571@psf.upfronthosting.co.za>


New submission from Denis Dmitriev <dmitriev at deshaw.com>:

There's a bug in python's zlibmodule.c that makes it raise SystemError whenever it tries to decompress a chunk larger than 1GB is size. Here's an example of this in action:

dmitriev at ...:~/moo/zlib_bug> cat zlib_bug.py 
import zlib

def test_zlib(size_mb):
    print "testing zlib with a %dMB object" % size_mb
    c = zlib.compressobj(1)
    sm = c.compress(' ' * (size_mb*1024*1024)) + c.flush()
    d = zlib.decompressobj()
    dm = d.decompress(sm) + d.flush()

test_zlib(1024)
test_zlib(1025)

dmitriev at ...:~/moo/zlib_bug> python2.6 zlib_bug.py 
testing zlib with a 1024MB object
testing zlib with a 1025MB object
Traceback (most recent call last):
  File "zlib_bug.py", line 11, in <module>
    test_zlib(1025)
  File "zlib_bug.py", line 8, in test_zlib
    dm = d.decompress(sm) + d.flush()
SystemError: Objects/stringobject.c:4271: bad argument to internal function

dmitriev at ...:~/moo/zlib_bug>

A similar issue was reported in issue1372; however, either this one is different, or the issue still exists in all versions of Python 2.6 that I tested, on both Solaris and Mac OS X. These are all 64-bit builds and have no problem manipulating multi-GB structures, so it's not an out-of-memory condition:

dmitriev at ...:~/moo/zlib_bug> python2.6   
Python 2.6.1 (r261:67515, Nov 18 2009, 12:21:47) 
[GCC 4.3.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> len(' ' * (6000*1024*1024))
6291456000
>>>

----------
components: Library (Lib)
messages: 104522
nosy: ddmitriev
priority: normal
severity: normal
status: open
title: zlib causes a SystemError when decompressing a chunk >1GB
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Thu Apr 29 17:57:13 2010
From: report at bugs.python.org (Walter Woods)
Date: Thu, 29 Apr 2010 15:57:13 +0000
Subject: [New-bugs-announce] [issue8572] httplib getheader() does not work
	as documented
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>


New submission from Walter Woods <woodswalben at gmail.com>:

Calling HTTPResponse.getheader('Testabnew', 'Default') throws an exception rather than returning default, python 3.1.2.  Problem code appears to be line 601 of client.py:


    def getheader(self, name, default=None):
        if self.headers is None:
            raise ResponseNotReady()
-        return ', '.join(self.headers.get_all(name, default))

Which should probably changed to:

+        result = self.headers.get_all(name, None)
+        if result:
+            return ', '.join(result)
+        else:
+            return default

Not as elegant, but what appears to happen is if default is not an array, then get_all returns it, and the string join fails with a TypeError.

----------
messages: 104532
nosy: Walter.Woods
priority: normal
severity: normal
status: open
title: httplib getheader() does not work as documented
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Thu Apr 29 22:30:29 2010
From: report at bugs.python.org (Longpoke)
Date: Thu, 29 Apr 2010 20:30:29 +0000
Subject: [New-bugs-announce] [issue8573] Buggy _strerror in asyncore
In-Reply-To: <1272573029.96.0.566961009055.issue8573@psf.upfronthosting.co.za>
Message-ID: <1272573029.96.0.566961009055.issue8573@psf.upfronthosting.co.za>


New submission from Longpoke <longpoke at gmail.com>:

This function in asyncore is buggy:

def _strerror(err):
    res = os.strerror(err)
    if res == 'Unknown error':
        res = errorcode[err]
    return res

- os.strerror may throw ValueError depending on the os, or return a string saying something like: "Unknown error 1234".
- os.strerror never returns "Unknown error" for me, so "Unknown error <err>" is always returned for me (Linux 2.6.32)
- if os.strerrror failed, it's likely that it wont be in errno.errcode either

Maybe it should be written like this:
def _strerror(err):
    try:
        return strerror(err)
    except ValueError:
        return "Unknown error {0}".format(err)

----------
components: Library (Lib)
messages: 104583
nosy: q94IjzUfnNoyv4c75mMw
priority: normal
severity: normal
status: open
title: Buggy _strerror in asyncore
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr 30 01:43:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Apr 2010 23:43:55 +0000
Subject: [New-bugs-announce] [issue8574] transient_internet()
	(test_support): use	socket.setdefaulttimeout() and
	test_robotparser failure
In-Reply-To: <1272584635.55.0.748550054978.issue8574@psf.upfronthosting.co.za>
Message-ID: <1272584635.55.0.748550054978.issue8574@psf.upfronthosting.co.za>


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

Many tests of the Python test suite depends on the availability of websites, especially www.python.org. Python.org has some troubles since some days, and many buildbots failed (test_robotparser failure).

I propose to use a default timeout of 60 seconds in transient_internet(), and then use transient_internet() in tests using the internet.

Patches:
 - transient_internet.py: set temporary the defalt socket timeout to 60 seconds (and then restore the previous default value), and catch also weird IOError (which contain in socket.error as the 2nd argument) from urllib
 - test_robotparser_transient_internet.py: use "with transient_internet():" to do not hung anymore (for 1800 seconds!) if a website is down

On Linux, you can use "iptables -I OUTPUT -p tcp --dport 80 -j DROP" (drop all outgoing packets) to simulate a network failure, and set the default timeout value of transient_internet() to 3 seconds.

----------
files: transient_internet.patch
keywords: patch
messages: 104596
nosy: haypo
priority: normal
severity: normal
status: open
title: transient_internet() (test_support): use socket.setdefaulttimeout() and test_robotparser failure
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17134/transient_internet.patch

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

From report at bugs.python.org  Fri Apr 30 06:15:24 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 30 Apr 2010 04:15:24 +0000
Subject: [New-bugs-announce] [issue8575] Update/reorganize _winreg
	documentation
In-Reply-To: <1272600924.34.0.491501715071.issue8575@psf.upfronthosting.co.za>
Message-ID: <1272600924.34.0.491501715071.issue8575@psf.upfronthosting.co.za>


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

This patch cleans up the use of a few external MSDN links, adds a bunch of constants which were previously undocumented, and reorganizes a table to fit in with those constants.

Patch uploaded to http://codereview.appspot.com/969045 for review.

----------
assignee: brian.curtin
components: Documentation, Windows
files: winreg_doc_update.diff
keywords: needs review, patch, patch
messages: 104612
nosy: brian.curtin, ezio.melotti
priority: normal
severity: normal
stage: patch review
status: open
title: Update/reorganize _winreg documentation
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17143/winreg_doc_update.diff

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

From report at bugs.python.org  Fri Apr 30 11:18:04 2010
From: report at bugs.python.org (Paul Moore)
Date: Fri, 30 Apr 2010 09:18:04 +0000
Subject: [New-bugs-announce] [issue8576] test_support.find_unused_port can
	cause socket conflicts	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

test_support.find_unused_port attempts to find an unused port to use. The approach is fragile (as noted in the docstring) in certain cases. In particular, it appears that Windows takes a short time to free the socket after it is closed, meaning that when the caller tries to open a socket on the returned port number, it gets permission issues.

A sleep(0.1) just before returning the port number appears to address the issue, but this is not a proper solution.

http://msdn.microsoft.com/en-us/library/ms737582%28v=VS.85%29.aspx describes the SO_LINGER and SO_DONTLINGER socket options, which may be related, but in my initial tests I haven't been able to get these to work.

----------
components: Tests, Windows
keywords: buildbot
messages: 104614
nosy: pmoore
priority: normal
severity: normal
status: open
title: test_support.find_unused_port can cause socket conflicts on Windows

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

From report at bugs.python.org  Fri Apr 30 12:40:04 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 30 Apr 2010 10:40:04 +0000
Subject: [New-bugs-announce] [issue8577] test_distutils fails if srcdir !=
	builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>


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

When I build the trunk with srcdir != builddir test_distutils fails when running tests.

To reproduce:
* Create a checkout of the trunk and chdir into this
* mkdir build
* cd build
* ../configure
* make test

This results in a failure for test_distutils

----------
assignee: tarek
components: Distutils, Library (Lib)
messages: 104616
nosy: ronaldoussoren, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_distutils fails if srcdir != builddir
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr 30 15:58:21 2010
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 30 Apr 2010 13:58:21 +0000
Subject: [New-bugs-announce] [issue8578] PyWeakref_GetObject
In-Reply-To: <1272635901.2.0.350528689181.issue8578@psf.upfronthosting.co.za>
Message-ID: <1272635901.2.0.350528689181.issue8578@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

PyWeakref_GetObject(wref) returns a borrowed reference, but that's rather dangerous.  The fact that wref stays alive does not prevent the returned object from being collected (by definition -- wref is a weak reference).  That means that either we must explicitly and immediately do a Py_INCREF() (and later Py_DECREF()) on the result of the function, or we must use it for a very short time.

As an example of why this interface encourages buggy behavior, the sole user of PyWeakref_GetObject() in Module/* is Module/_sqlite/connection.c, which does

    statement = PyWeakref_GetObject(weakref);

and then call some functions passing 'statement' as argument.  The called functions can do anything (because they release the GIL).  So in particular they can cause 'statement' to be freed while still in use, either directly or indirectly via the cycle-GC.

This should be fixed; I suggest deprecating PyWeakref_GetObject() and adding another C API function that does not return a borrowed reference.

----------
components: Interpreter Core
messages: 104634
nosy: arigo
priority: normal
severity: normal
status: open
title: PyWeakref_GetObject
type: crash

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

From report at bugs.python.org  Fri Apr 30 20:02:31 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 30 Apr 2010 18:02:31 +0000
Subject: [New-bugs-announce] [issue8579] Add missing tests for FlushKey,
	LoadKey, and SaveKey in winreg
In-Reply-To: <1272650551.21.0.0191974450566.issue8579@psf.upfronthosting.co.za>
Message-ID: <1272650551.21.0.0191974450566.issue8579@psf.upfronthosting.co.za>


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

Per the comment at the top of Lib/test/test_winreg.py, FlushKey, LoadKey, and SaveKey are currently untested.

I have a minimal patch worked up. I'll expand on it and upload shortly.

----------
assignee: brian.curtin
components: Extension Modules, Windows
messages: 104655
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: Add missing tests for FlushKey, LoadKey, and SaveKey in winreg
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/issue8579>
_______________________________________

From report at bugs.python.org  Fri Apr 30 22:13:56 2010
From: report at bugs.python.org (Jorge Bosch)
Date: Fri, 30 Apr 2010 20:13:56 +0000
Subject: [New-bugs-announce] [issue8580] Problem urllib2.URLError
In-Reply-To: <1272658436.51.0.144833703939.issue8580@psf.upfronthosting.co.za>
Message-ID: <1272658436.51.0.144833703939.issue8580@psf.upfronthosting.co.za>


New submission from Jorge Bosch <jorgebosch86 at gmail.com>:

hello. Im new on this kind of programation. Well it could sound newbie...but I have this error and I dont know how to fix it.

Well its related with an AutoUpdater for a Online Game (GTLegends, Altbierbude software) but no one manage to solve it..

Here is the Log of the error:

Traceback (most recent call last):
  File "C:\Download\AutoUpdate\altbierbude_en.pyw", line 134, in <module>
    main()
  File "C:\Download\AutoUpdate\altbierbude_en.pyw", line 93, in main
    the_app.myconfig = GetAppConfig(source_url, config_filename)
  File "C:\Download\AutoUpdate\altbierbude_en.pyw", line 52, in GetAppConfig
    cfg_data = GetUrlData(url+filename)
  File "C:\Download\AutoUpdate\altbierbude_en.pyw", line 31, in GetUrlData
    url_handle = opener.open( url )
  File "C:\Python26\lib\urllib2.py", line 389, in open
    response = self._open(req, data)
  File "C:\Python26\lib\urllib2.py", line 407, in _open
    '_open', req)
  File "C:\Python26\lib\urllib2.py", line 367, in _call_chain
    result = func(*args)
  File "C:\Python26\lib\urllib2.py", line 1146, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "C:\Python26\lib\urllib2.py", line 1121, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error [Errno 10061] No se puede establecer una conexi?n ya que el equipo de destino deneg? expresamente dicha conexi?n>

----------
messages: 104661
nosy: m_enanos
priority: normal
severity: normal
status: open
title: Problem urllib2.URLError
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr 30 22:34:32 2010
From: report at bugs.python.org (Jason Baker)
Date: Fri, 30 Apr 2010 20:34:32 +0000
Subject: [New-bugs-announce] [issue8581] Logging handlers do not handle
	double-closing very well
In-Reply-To: <1272659672.58.0.428458764285.issue8581@psf.upfronthosting.co.za>
Message-ID: <1272659672.58.0.428458764285.issue8581@psf.upfronthosting.co.za>


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

The logging handler does not handle double-closing very well:

>>> from logging import StreamHandler
>>> h = StreamHandler()
>>> h.close()
>>> h.close()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/logging/__init__.py", line 705, in close
    del _handlers[self]
KeyError: <logging.StreamHandler instance at 0xb7609c8c>

There are two possible approaches to this:

 1. Raise a better error.
 2. Ignore the duplicate close.

This patch takes option 2 as this is likely not indicative of any kind of programmer error, but it shouldn't be too difficult to take option 1 instead.

----------
components: Library (Lib)
messages: 104662
nosy: Jason.Baker
priority: normal
severity: normal
status: open
title: Logging handlers do not handle double-closing very well
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri Apr 30 23:06:37 2010
From: report at bugs.python.org (Jason Gross)
Date: Fri, 30 Apr 2010 21:06:37 +0000
Subject: [New-bugs-announce] [issue8582] urllib.urlretrieve fails with
	ValueError: Invalid format	string
In-Reply-To: <1272661597.76.0.557782808753.issue8582@psf.upfronthosting.co.za>
Message-ID: <1272661597.76.0.557782808753.issue8582@psf.upfronthosting.co.za>


New submission from Jason Gross <jasongross9 at gmail.com>:

When calling urllib.urlretrieve with a data:image/png url (possibly with other urls too) and a local file name, it fails with
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    urlretrieve(url, file_name)
  File "D:\Python26\Lib\urllib.py", line 93, in urlretrieve
    return _urlopener.retrieve(url, filename, reporthook, data)
  File "D:\Python26\Lib\urllib.py", line 237, in retrieve
    fp = self.open(url, data)
  File "D:\Python26\Lib\urllib.py", line 205, in open
    return getattr(self, name)(url)
  File "D:\Python26\Lib\urllib.py", line 596, in open_data
    time.gmtime(time.time())))

This can be fixed by replacing %T on line 595 with %H : %M : %S (which I found as the definition of %T on http://www.opengroup.org/onlinepubs/009695399/functions/strftime.html)

----------
components: Library (Lib)
messages: 104664
nosy: Jason.Gross
priority: normal
severity: normal
status: open
title: urllib.urlretrieve fails with ValueError: Invalid format string
type: crash
versions: Python 2.7

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

From w_h_falk at yahoo.de  Wed Apr  7 10:01:07 2010
From: w_h_falk at yahoo.de (Wilfried Falk)
Date: Wed, 07 Apr 2010 08:01:07 -0000
Subject: [New-bugs-announce] A (severe) bug in Python
Message-ID: <449177.53387.qm@web29018.mail.ird.yahoo.com>

Hello Ladies and Gentlemen,

attached to this email is a rtf-file which shows a (severe) bug in Python. The point of matter is a exchange of? ?liste += [a]? ?and?? liste = liste + [a].

Best regards
Dr. Wilfried Falk

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verf?gt ?ber einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BugInPython.rtf
Type: application/rtf
Size: 890 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20100407/ccc6743c/attachment-0001.rtf>

From w_h_falk at yahoo.de  Fri Apr 16 19:37:41 2010
From: w_h_falk at yahoo.de (Wilfried Falk)
Date: Fri, 16 Apr 2010 17:37:41 -0000
Subject: [New-bugs-announce] Bug in Python 3.1.2
Message-ID: <129902.66790.qm@web29008.mail.ird.yahoo.com>

Hello Ladies and Gentlemen,

attached to this email you will find a rtf-file which shows a Bug in Python 3.1.2

Best regards
Dr. Wilfried Falk?

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verf?gt ?ber einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BugInPython.rtf
Type: application/rtf
Size: 413 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20100416/632225f7/attachment-0001.rtf>

From roundup-admin at psf.upfronthosting.co.za  Mon Apr 19 00:30:17 2010
From: roundup-admin at psf.upfronthosting.co.za (roundup-admin at psf.upfronthosting.co.za)
Date: Sun, 18 Apr 2010 22:30:17 -0000
Subject: [New-bugs-announce] [issue8449] buildbot: test_dbm and test_dbm_ndbm
Message-ID: <20100418223017.3DCB2781BC@psf.upfronthosting.co.za>

failures
To: new-bugs-announce at python.org
From: STINNER Victor <report at bugs.python.org>
Date: Sun, 18 Apr 2010 22:30:17 +0000
Precedence: bulk
X-Roundup-Name: Python tracker
X-Roundup-Loop: hello
X-Roundup-Version: 1.4.10
Reply-To: Python tracker <report at bugs.python.org>
Message-Id: <1271629817.22.0.668476357491.issue8449 at psf.upfronthosting.co.za>
X-Roundup-issue-status: open
X-Roundup-issue-keywords: buildbot
X-Roundup-issue-severity: normal
X-Roundup-issue-versions: Python 3.1
In-Reply-To: <1271629817.22.0.668476357491.issue8449 at psf.upfronthosting.co.za>
Content-Transfer-Encoding: quoted-printable


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

http://www.python.org/dev/buildbot/builders/ia64 Ubuntu 3.1/builds/451/step=
s/test/logs/stdio

test_dbm
__fop_file_setup:  Retry limit (100) exceeded
__fop_file_setup:  Retry limit (100) exceeded
__fop_file_setup:  Retry limit (100) exceeded
__fop_file_setup:  Retry limit (100) exceeded
__fop_file_setup:  Retry limit (100) exceeded
__fop_file_setup:  Retry limit (100) exceeded
__fop_file_setup:  Retry limit (100) exceeded
test test_dbm failed -- multiple errors occurred; run in verbose mode for d=
etails

test_dbm_ndbm
__fop_file_setup:  Retry limit (100) exceeded
__fop_file_setup:  Retry limit (100) exceeded
test test_dbm_ndbm failed -- multiple errors occurred; run in verbose mode =
for details

Re-running test 'test_dbm' in verbose mode
test_keys (test.test_dbm.WhichDBTestCase) ... ok
test_whichdb (test.test_dbm.WhichDBTestCase) ... __fop_file_setup:  Retry l=
imit (100) exceeded
ERROR
test_anydbm_access (test.test_dbm.TestCase-dbm.ndbm) ... __fop_file_setup: =
 Retry limit (100) exceeded
ERROR
test_anydbm_creation (test.test_dbm.TestCase-dbm.ndbm) ... __fop_file_setup=
:  Retry limit (100) exceeded
ERROR
test_anydbm_keys (test.test_dbm.TestCase-dbm.ndbm) ... __fop_file_setup:  R=
etry limit (100) exceeded
ERROR
test_anydbm_modification (test.test_dbm.TestCase-dbm.ndbm) ... __fop_file_s=
etup:  Retry limit (100) exceeded
ERROR
test_anydbm_not_existing (test.test_dbm.TestCase-dbm.ndbm) ... ok
test_anydbm_read (test.test_dbm.TestCase-dbm.ndbm) ... __fop_file_setup:  R=
etry limit (100) exceeded
ERROR
test_error (test.test_dbm.TestCase-dbm.ndbm) ... ok
test_anydbm_access (test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_creation (test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_keys (test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_modification (test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_not_existing (test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_read (test.test_dbm.TestCase-dbm.dumb) ... ok
test_error (test.test_dbm.TestCase-dbm.dumb) ... ok

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_whichdb (test.test_dbm.WhichDBTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 127, in test_whichdb
    f =3D module.open(_fname, 'c')
_dbm.error: [Errno 17] File exists

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_anydbm_access (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 93, in test_anydbm_access
    self.init_db()
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 48, in init_db
    f =3D dbm.open(_fname, 'n')
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/dbm/__init__.=
py", line 88, in open
    return mod.open(file, flag, mode)
_dbm.error: [Errno 17] File exists

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_anydbm_creation (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 66, in test_anydbm_creation
    f =3D dbm.open(_fname, 'c')
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/dbm/__init__.=
py", line 88, in open
    return mod.open(file, flag, mode)
_dbm.error: [Errno 17] File exists

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_anydbm_keys (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 87, in test_anydbm_keys
    self.init_db()
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 48, in init_db
    f =3D dbm.open(_fname, 'n')
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/dbm/__init__.=
py", line 88, in open
    return mod.open(file, flag, mode)
_dbm.error: [Errno 17] File exists

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_anydbm_modification (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 74, in test_anydbm_modification
    self.init_db()
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 48, in init_db
    f =3D dbm.open(_fname, 'n')
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/dbm/__init__.=
py", line 88, in open
    return mod.open(file, flag, mode)
_dbm.error: [Errno 17] File exists

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_anydbm_read (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 81, in test_anydbm_read
    self.init_db()
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
.py", line 48, in init_db
    f =3D dbm.open(_fname, 'n')
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/dbm/__init__.=
py", line 88, in open
    return mod.open(file, flag, mode)
_dbm.error: [Errno 17] File exists

----------------------------------------------------------------------
Ran 16 tests in 602.508s

FAILED (errors=3D6)
test test_dbm failed -- multiple errors occurred
Re-running test 'test_dbm_ndbm' in verbose mode
test_keys (test.test_dbm_ndbm.DbmTestCase) ... __fop_file_setup:  Retry lim=
it (100) exceeded
ERROR
test_modes (test.test_dbm_ndbm.DbmTestCase) ... __fop_file_setup:  Retry li=
mit (100) exceeded
ERROR

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_keys (test.test_dbm_ndbm.DbmTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
_ndbm.py", line 13, in setUp
    self.d =3D dbm.ndbm.open(self.filename, 'c')
_dbm.error: [Errno 17] File exists

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ERROR: test_modes (test.test_dbm_ndbm.DbmTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea/3.1.klose-debian-ia64/build/Lib/test/test_dbm=
_ndbm.py", line 13, in setUp
    self.d =3D dbm.ndbm.open(self.filename, 'c')
_dbm.error: [Errno 17] File exists

----------------------------------------------------------------------
Ran 2 tests in 200.800s

FAILED (errors=3D2)
test test_dbm_ndbm failed -- multiple errors occurred

----------
keywords: buildbot
messages: 103544
nosy: haypo
severity: normal
status: open
title:=20
  buildbot: test_dbm and test_dbm_ndbm
  failures
versions: Python 3.1

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

From w_h_falk at yahoo.de  Sun Apr 18 20:19:13 2010
From: w_h_falk at yahoo.de (Wilfried Falk)
Date: Sun, 18 Apr 2010 18:19:13 -0000
Subject: [New-bugs-announce] bug in Python?
Message-ID: <176597.89083.qm@web29006.mail.ird.yahoo.com>

Dear Ladies and Gentlemen,

attached to my last email??(Friday, 16.04.2010 / 17:37 GMT), was a wrong?rtf-file. What I really want to show you is now attached to this email? (a play of colours).

Best regards
Dr. Wilfried Falk?

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verf?gt ?ber einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugInPython.rtf
Type: application/rtf
Size: 439 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20100418/d91b54a0/attachment-0001.rtf>

From w_h_falk at yahoo.de  Mon Apr 19 18:41:25 2010
From: w_h_falk at yahoo.de (Wilfried Falk)
Date: Mon, 19 Apr 2010 16:41:25 -0000
Subject: [New-bugs-announce] bug in Python?
Message-ID: <362659.99819.qm@web29005.mail.ird.yahoo.com>

Dear Ladies and Gentlemen,

what I want to show you today is again attached to the email as rtf-file.

Best regards
Dr. Wilfried Falk

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verf?gt ?ber einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugInPython3.rtf
Type: application/rtf
Size: 1326 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20100419/614f062f/attachment-0001.rtf>